Eric Sunshine sunsh...@sunshineco.com writes:
+Prepare a request to your upstream project to pull your changes to
+their tree to the standard output, by summarizing your changes and
+showing where your changes can be pulled from.
Perhaps splitting this into two sentence (and using fewer
Junio C Hamano gits...@pobox.com writes:
Sorry for back-burnering this topic so long.
I think the following does what you suggested in the message I am
responding to.
Now, hopefully the only thing we need is a documentation update and
the series should be ready to go.
... and here it is,
On Wed, Mar 12, 2014 at 2:04 PM, Junio C Hamano gits...@pobox.com wrote:
Subject: [PATCH] request-pull: documentation updates
The original description talked only about what it does. Instead,
start it with the purpose of the command, i.e. what it is used for,
and then mention what it does to
Linus Torvalds torva...@linux-foundation.org writes:
Thinking some more about the tag_name issue, I realize that the other
patch (Make request-pull able to take a refspec of form
local:remote) broke another thing.
The first patch pretty-printed the local branch-name, removing refs/
and
Junio C Hamano gits...@pobox.com writes:
So there are two remaining items, I think.
- After creating a tags/for-linus signed tag and pushing it to
tags/for-linus, asking request-pull to request that tag to be
pulled seems to lose the tag message from the output.
- Docs.
On Wed, Jan 29, 2014 at 03:34:32PM -0800, Junio C Hamano wrote:
The previous two steps were meant to stop promoting the explicit
refname the user gave to the command to a different ref that points
at it. Most notably, we no longer substitute a branch name the user
used with a name of the tqag
On Wed, Jan 29, 2014 at 3:34 PM, Junio C Hamano gits...@pobox.com wrote:
I am not yet doing the docs, but here is a minimal (and I think is
the most sensible) fix to the If I asked a tag to be pulled, I used
to get the message from the tag in the output---the updated code no
longer does so
Linus Torvalds torva...@linux-foundation.org writes:
So I don't actually think anybody should need to be retrained, or
always use the local:remote syntax. The local:remote syntax exists
only for that special insane case where you used (the same)
local:remote syntax to push out a branch under
Linus Torvalds torva...@linux-foundation.org writes:
So this relaxes the remote matching, and allows using the local:remote
syntax to say that the local branch is differently named from the remote
one.
It is probably worth folding it into the previous patch if you think this
whole
On Thu, Jan 23, 2014 at 11:43 AM, Junio C Hamano gits...@pobox.com wrote:
I am not sure if it is a good idea to hand-craft resulting head is
unique constraint here. We already have disambiguation rules (and
warning mechanism) we use in other places---this part should use the
same rule, I
Linus Torvalds torva...@linux-foundation.org writes:
Yes, so you'll get a warning (or, if you get a partial match, maybe
not even that), but the important part about all these changes is that
it DOESN'T MATTER.
Why? Because it no longer re-writes the target branch name based on
that match
On Thu, Jan 23, 2014 at 2:58 PM, Junio C Hamano gits...@pobox.com wrote:
Will be fine, provided if they always use local:remote syntax, I'd
agree.
Why? No sane user should actually need to use the local:remote syntax.
The normal situation should be that you create the correctly named
branch
12 matches
Mail list logo
