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

Reply via email to