Re: [PATCH] have merge put FETCH_HEAD data in commit message

From: Junio C Hamano <junkio@cox.net>
Date: Mar 22, 2007, 08:21 UTC
Message-ID: <7vlkhpvgc7.fsf@assigned-by-dhcp.cox.net>
In-Reply-To: <20070322074051.GA29341@mellanox.co.il>

"Michael S. Tsirkin" <mst@dev.mellanox.co.il> writes:

Show 12 quoted lines

>> Quoting Junio C Hamano <junkio@cox.net>:
>> Subject: Re: [PATCH] have merge put FETCH_HEAD data in commit message
>> 
>> "Michael S. Tsirkin" <mst@dev.mellanox.co.il> writes:
>> 
>> > BTW, is there some way to figure it out besides looking at the code
>> > or grepping git archives?
>> 
>> Like SubmittingPatches?
>
> SubmittingPatches is for people contributing to git.
> But how are *users* of git-am supposed to figure it out?

(1) SubmittingPatches describes the git project policy on patch
    formatting, which happens to be similar to the kernel
    project.

(2) Users of git-am, git-format-patch and friends in general are
    not bound by SubmittingPatches, unless they are contributing
    to the git project.  As the policy differs from project to
    project, there is nothing authoritative in git documentation
    set, nor there should be anything stronger than merely our
    recommendation.  Yes, SubmittingPatches could be used as one
    potential BCP that is managed with git, but we are not in
    any position to impose that to other projects.  In other
    words, *users* of git-am are not supposed to figure it out.
    They will not find *their* project policy from git
    documentation, unless their project happens to be the git
    project.

(3) However, we are discussing your patch to support "git merge
    FETCH_HEAD" better, which I took as your contribution to the
    git project.  I asked you to follow the project policy for
    your contribution, and pointed at the document that
    describes the policy.

Clear?

I think your patch means well, and when polished it might be a valuable addition. "Hi!" and "Would the following be appropriate?" are the least of the problems I pointed out, but to clear the dust, let's finish them with responses: "Hi to you!", and "Yes, what the patch tries to do looks very nice, but there are a few issues I would want you to resolve" ;-).

To reiterate the more important points (this is also for my own purpose because I do not want the patch lost in this noise we are making):

 - Checking readability of $GIT_DIR/$remote itself is too loose;
   the name FETCH_HEAD should explicitly be checked, as that is
   the file that has the specific format that is understood by
   fmt-merge-msg.

 - "echo -n" is to be avoided for portability.

 - "git fetch $URL foo bar" would leave two lines in FETCH_HEAD;
   subsequent "git merge FETCH_HEAD" would merge only foo.  Pick
   the first line, stripping out not-for-merge marker and let it
   processed by fmt-merge-msg.