Junio C Hamano <junkio@xxxxxxx> wrote: > Shawn Pearce <spearce@xxxxxxxxxxx> writes: > > > Yes. Without it: > > > > $ git checkout -b 931233bc666b^ > > $ echo broken >builtin-pickaxe.c > > $ git pull . next && echo good merge > > Updating c2e525d..522da27 > > builtin-pickaxe.c: needs update > > fatal: Entry 'builtin-pickaxe.c' not uptodate. Cannot merge. > > good merge > > > > Say what? There's no way that fast forward was good! Granted this > > use case is horrible but that fast forward went very, very badly, > > but the caller now thinks it was good. > > I think fast forward went Ok in that "git-ls-tree HEAD" gives > the correct merge result from pulling next on top of 931233^ (or > whatever). No it didn't. After doing the pull: $ git rev-parse --verify HEAD c2e525d97f81bc178567cdf4dd7056ce6224eb58 $ git rev-parse --verify 931233bc666b^ c2e525d97f81bc178567cdf4dd7056ce6224eb58 so no the merge result wasn't put into HEAD. Nothing was done. Which is good because to do the merge the working directory has to change but there's a conflict there due to one file being in a modified state. Better we don't change HEAD. > I am undecided if we want to keep what dropsave is > supposed to remove in that case, but exiting with non-zero to > indicate an error condition is needed. I think that elsewhere in git-merge we abort without calling dropsave when things to south. Which is why I aborted before. -- Shawn. - To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html