On Tue, Feb 17, 2009 at 3:35 AM, Junio C Hamano <gitster@xxxxxxxxx> wrote: > Now to something totally useless. > > After reading the builtin-merge.c and original git-merge.sh (now in > contrib/examples) script, I think it could have done something entirely > different. > > It could have done this instead. > > sed -e '/ not-for-merge /d' > > to learn the commits and their human-readable origins, and it could have > tried to reproduce what "git pull" did when it invoked git-merge using > that information. Then you could use this workflow: > > $ git pull <possibly with arguments> > ... oops, conflicted and is very messy. > ... I tried to resolve, but failed and made the mess even worse. > ... Let's start over. > $ git reset --hard > ... FETCH_HEAD knows which refs are for merging > $ git merge FETCH_HEAD > > That is, no matter what the arguments were for the initial "git pull", > what should be merged is recorded in FETCH_HEAD, and that is how you can > retry the merge without refetching over the network. > > But such a change makes FETCH_HEAD different from what it traditionally > meant, and does that only to "git merge", making the result very > inconsistent. For example, "git log ..FETCH_HEAD" will still use the > object name on the first line, and it won't be a way to convince yourself > that the changes are sensible and it is Ok to run "git merge FETCH_HEAD" > anymore. So I do not think such a change will be an improvement. Unless dwim_ref() is updated to handle FETCH_HEAD specially, and return not the first SHA1, but the one not marked "not-for-merge". Then the UI would at least be consistent, but this would not be backward compatible. j. -- 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
