Eric Sunshine 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 to's) would
> make i
On Wed, Mar 12, 2014 at 2:04 PM, Junio C Hamano 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 achieve that
Junio C Hamano 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, to be sanit
Linus Torvalds 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 possibly "heads/" from t
On Wed, Jan 29, 2014 at 3:34 PM, Junio C Hamano 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" problem.
Tha
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 t
Junio C Hamano 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.
>
> [Footnote]
>
> *1*
Linus Torvalds 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 a different name.
>
> [
On Thu, Jan 23, 2014 at 2:58 PM, Junio C Hamano 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 or tag locally,
Linus Torvalds 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 or non-match. So the pull
On Thu, Jan 23, 2014 at 11:43 AM, Junio C Hamano 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 think.
If you
Linus Torvalds 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 approach is workable.
Haven
12 matches
Mail list logo
