Philip Oakley <philipoak...@iee.org> writes:

> Historically (5 Nov 2005 v0.99.9-46-g28ffb89) the git-format-patch used
> 'origin' as the upstream branch name. That name is now used as the nominal
> name for the upstream remote.
>
> While 'origin' would be DWIMmed (do what I mean) to be that remote's
> primary branch, do not assume the reader is ready for such magic.

Good thinking.

> Likewise, do not use 'origin/master' which may not be up to date with the
> remote, nor reflect the reader's master branch. The patch series should be
> relative to the reader's view of 'git show-branch HEAD master'.

This however is backwards, no?  The history on 'origin/master' may
not be up-to-date in the sense that if you run 'git fetch' you might
get more, but it absolutely is up-to-date in the sense that it shows
what the origin has to the best of your repository's current
knowledge.

Compared to that, what the user's local 'master' has is much less
relevant.  For one thing, if a more recent commit that is on the
remote repository is missing on 'origin/master' because you haven't
fetched recently, by definition that commit will not be on your
'master' either, so you have the same staleness issue to the exact
degree.  Even worse, when you are developing a topic to upstream, it
is a good practice to merge your topic to your own 'master' to check
it with the wider project codebase that is more recent than where
your topic earlier forked from, and it makes little sense to tell
'exclude what I have on my master' to format-patch when extracting
changes to upstream out of such a topic.  You send what the other
side has, not what you do not have on your local 'master' branch.

> Use the more modern 'master' as the reference branch name.

There is nothing 'modern' in 'master'.

I think the original description was written before we switched to
the separate remote layout.  What is in 'refs/remote/origin/master'
these days was stored and updated at 'refs/heads/origin' and no
other branch from the remote repository was tracked back then.  The
changes to be upstreamed are output by grabbing what are not in
'origin', whose modern equivalent is 'origin/master'.

In short, if your patch were s|origin|origin/master|, instead of
s|origin|master|, that would be an adjustment to the more modern
world that is still faithful to the intent of the original.

> Signed-off-by: Philip Oakley <philipoak...@iee.org>
> ---
>  Documentation/git-format-patch.txt | 10 +++++-----
>  1 file changed, 5 insertions(+), 5 deletions(-)
>
> diff --git a/Documentation/git-format-patch.txt 
> b/Documentation/git-format-patch.txt
> index c0fd470..b0f041f 100644
> --- a/Documentation/git-format-patch.txt
> +++ b/Documentation/git-format-patch.txt
> @@ -523,25 +523,25 @@ $ git format-patch -k --stdout R1..R2 | git am -3 -k
>  ------------
>  
>  * Extract all commits which are in the current branch but not in the
> -origin branch:
> +master branch:
>  +
>  ------------
> -$ git format-patch origin
> +$ git format-patch master
>  ------------
>  +
>  For each commit a separate file is created in the current directory.
>  
> -* Extract all commits that lead to 'origin' since the inception of the
> +* Extract all commits that lead to 'master' since the inception of the
>  project:
>  +
>  ------------
> -$ git format-patch --root origin
> +$ git format-patch --root master
>  ------------
>  
>  * The same as the previous one:
>  +
>  ------------
> -$ git format-patch -M -B origin
> +$ git format-patch -M -B master
>  ------------
>  +
>  Additionally, it detects and handles renames and complete rewrites
--
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