@matheusbsbs / matheus-bagliano / commits / 5521883490

Fork 0

checkout: do not lose staged removal

The logic to checkout a different commit implements the safety to never lose user's local changes. For example, switching from a commit to another commit, when you have changed a path that is different between them, need to merge your changes to the version from the switched-to commit, which you may not necessarily be able to resolve easily. By default, "git checkout" refused to switch branches, to give you a chance to stash your local changes (or use "-m" to merge, accepting the risks of getting conflicts). This safety, however, had one deliberate hole since early June 2005. When your local change was to remove a path (and optionally to stage that removal), the command checked out the path from the switched-to commit nevertheless. This was to allow an initial checkout to happen smoothly (e.g. an initial checkout is done by starting with an empty index and switching from the commit at the HEAD to the same commit). We can tighten the rule slightly to allow this special case to pass, without losing sight of removal explicitly done by the user, by noticing if the index is truly empty when the operation begins. For historical background, see: http://thread.gmane.org/gmane.comp.version-control.git/4641/focus=4646 This case is marked as *0* in the message, which both Linus and I said "it feels somewhat wrong but otherwise we cannot start from an empty index". Signed-off-by: Junio C Hamano <gitster@pobox.com>

Junio C Hamano committed Sep 7, 2008 at 19:49 UTC 5521883490e85f4d973141972cf16f89a79f1979

5 files changed +24 -2

Documentation/git-read-tree.txt

+10 -1

@@ -160,7 +160,10 @@ Here are the "carry forward" rules:

160 0 nothing nothing nothing (does not happen)

161 1 nothing nothing exists use M

162 2 nothing exists nothing remove path from index

163 - 3 nothing exists exists use M

163 + 3 nothing exists exists, use M if "initial checkout"

164 + H == M keep index otherwise

165 + exists fail

166 + H != M

167

168 clean I==H I==M

169 ------------------

@@ -207,6 +210,12 @@ you picked it up via e-mail in a patch form), `git diff-index

210 merge, but it would not show in `git diff-index --cached $M`

211 output after two-tree merge.

212

213 +Case #3 is slightly tricky and needs explanation. The result from this

214 +rule logically should be to remove the path if the user staged the removal

215 +of the path and then swiching to a new branch. That however will prevent

216 +the initial checkout from happening, so the rule is modified to use M (new

217 +tree) only when the contents of the index is empty. Otherwise the removal

218 +of the path is kept as long as $H and $M are the same.

219

220 3-Way Merge

221 ~~~~~~~~~~~

builtin-checkout.c

@@ -242,6 +242,8 @@ static int merge_working_tree(struct checkout_opts *opts,

242 }

243

244 /* 2-way merge to the new branch */

245 + topts.initial_checkout = (!active_nr &&

246 + (old->commit == new->commit));

247 topts.update = 1;

248 topts.merge = 1;

249 topts.gently = opts->merge;

builtin-read-tree.c

@@ -206,6 +206,7 @@ int cmd_read_tree(int argc, const char **argv, const char *unused_prefix)

206 break;

207 case 2:

208 opts.fn = twoway_merge;

209 + opts.initial_checkout = !active_nr;

210 break;

211 case 3:

212 default:

unpack-trees.c

+10 -1

@@ -941,8 +941,17 @@ int twoway_merge(struct cache_entry **src, struct unpack_trees_options *o)

941 return -1;

942 }

943 }

944 - else if (newtree)

944 + else if (newtree) {

945 + if (oldtree && !o->initial_checkout) {

946 + /*

947 + * deletion of the path was staged;

948 + */

949 + if (same(oldtree, newtree))

950 + return 1;

951 + return reject_merge(oldtree, o);

952 + }

953 return merged_entry(newtree, current, o);

954 + }

955 return deleted_entry(oldtree, current, o);

956 }

957

unpack-trees.h

@@ -26,6 +26,7 @@ struct unpack_trees_options {

26 verbose_update:1,

27 aggressive:1,

28 skip_unmerged:1,

29 + initial_checkout:1,

30 gently:1;

31 const char *prefix;

32 int pos;