Michael Haggerty <mhag...@alum.mit.edu> writes: > On 07/15/2013 11:43 PM, Junio C Hamano wrote: >> [...] >> This was a good exercise for git-imerge.[...] >> >> A few things I noticed: >> [...] >> >> - The final step "imerge finish" gave me this ugliness: >> >> Merge commit 93d9353... into commit cb5d2fc7 >> >> Perhaps you can at least use the initial branch name >> "nd/magic-pathspec" I gave you, and use "git fmt-merge-msg"? > > I tried to implement this but it is not obvious from the documentation > (to say the least) how to use "git fmt-merge-msg". It appears that this > program takes, on standard input, something like > > <sha1> TAB TAB <text1> LF > <sha1> TAB TAB <text2> LF > <sha1> TAB TAB <text3> LF > ... > > (the two TABs are required!).
Correct; fmt-merge-msg is designed to read FETCH_HEAD that can have 'not-for-merge' marker between these two HTs. <text$N> are also expected to be in a specific format to explain where the object being merged described by the line came from. > But a bit of the magic of these merge messages is how the <text> are > generated in the first place; e.g., > > refs/heads/foo -> "branch 'foo'" > refs/remotes/bar/baz -> "remote-tracking branch 'bar/baz'" > > Is this magic available via any Git commands, or do I have to replicate it? This is all internal to "fetch" and "git merge", which are the only things that need to know the specifics. store_updated_refs() is where entries in FETCH_HEAD are written. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
