rebase: refactor reading of state
authorMartin von Zweigbergk <martin.von.zweigbergk@gmail.com>
Sun, 6 Feb 2011 18:43:31 +0000 (13:43 -0500)
committerJunio C Hamano <gitster@pobox.com>
Thu, 10 Feb 2011 22:08:07 +0000 (14:08 -0800)
commit02ac45fa628ef7c529e63bb99fe198704606e7f8
treec87544501d60a9d11e12550a8be39b2729e8028e
parent69a636ad1ac73a596d8c99a4206a6475b15e8d8d
rebase: refactor reading of state

The code reading the state saved in $merge_dir or $rebase_dir is
currently spread out in many places, making it harder to read and to
introduce additional state. Extract this code into one method that
reads the state. Only extract the code associated with the state that
is written when the rebase is initiated. Leave the state that changes
for each commmit, at least for now.

Currently, when resuming a merge-based rebase using --continue or
--skip, move_to_original_branch (via finish_rb_merge) will be called
without head_name and orig_head set. These variables are then lazily
read in move_to_original_branch if head_name is not set (together with
onto, which is unnecessarily read again). Change this by always
eagerly reading the state, for both am-based and merge-based rebase,
in the --continue and --skip cases. Note that this does not change the
behavior for am-based rebase, which read the state eagerly even before
this commit.

Reading the state eagerly means that part of the state will sometimes
be read unnecessarily. One example is when the rebase is continued,
but stops again at another merge conflict. Another example is when the
rebase is aborted. However, since both of these cases involve user
interaction, the delay is hopefully not noticeable. The
call_merge/continue_merge loop is not affected.

Helped-by: Junio C Hamano <gitster@pobox.com>
Signed-off-by: Martin von Zweigbergk <martin.von.zweigbergk@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
git-rebase.sh