Ramkumar Ramachandra wrote:
> My primary concern is that the proposed @{publish} should be a first-class
> citizen; if it has everything that @{u} has, then we're both good: you'd
> primarily use @{u}, while I'd primarily use @{publish}.
Something like this?
http://article.gmane.org/gmane.comp.ve
Ramkumar Ramachandra wrote:
> We already have a branch.*.pushremote, and I don't see the value of
> branch.*.pushbranch (what you're referring to as pushupstream, I assume)
> except for Gerrit users. Frankly, I don't use full triangular workflows
> myself mainly because my prompt is compromised: wh
Jeff King writes:
> And even in a centralized workflow, I see "upstream" creating problems.
> E.g., you fork a feature branch in the centralized repo; it should not
> get pushed straight back to "master"! And that is why we invented
> "simple", to prevent such things.
Oh, don't get me wrong. I
On Tue, Jan 07, 2014 at 02:06:12PM -0800, Junio C Hamano wrote:
> Jeff King writes:
>
> > I think that is sensible, and only heightens my sense of the "upstream"
> > push.default as useless. :)
>
> Yes, it only is good for centralized world (it was designed back in
> the centralized days after
Jeff King writes:
> I think that is sensible, and only heightens my sense of the "upstream"
> push.default as useless. :)
Yes, it only is good for centralized world (it was designed back in
the centralized days after all, wasn't it?).
--
To unsubscribe from this list: send the line "unsubscribe
On Wed, Jan 08, 2014 at 02:55:04AM +0530, Ramkumar Ramachandra wrote:
> Jeff King wrote:
> > My daily procedure is something like:
> >
> > all_topics |
> > while read topic; do "echo $topic $(git rev-parse $topic@{u})"; done |
> > topo_sort |
> > while read topic upstream; do
> > git r
Jeff King wrote:
> My daily procedure is something like:
>
> all_topics |
> while read topic; do "echo $topic $(git rev-parse $topic@{u})"; done |
> topo_sort |
> while read topic upstream; do
> git rebase $upstream $topic || exit 1
> done
Ah, I was perhaps over-specializing for my o
On Tue, Jan 07, 2014 at 01:07:08PM -0800, Junio C Hamano wrote:
> Jeff King writes:
>
> > Yes, "pushbranch" is probably a better name for what I am referring to.
> > I agree that pushremote is probably enough for sane cases. I seem to
> > recall that people advocating the "upstream" push-default
Jeff King writes:
> Yes, "pushbranch" is probably a better name for what I am referring to.
> I agree that pushremote is probably enough for sane cases. I seem to
> recall that people advocating the "upstream" push-default thought that
> branch name mapping was a useful feature, but I might be
>
On Tue, Jan 07, 2014 at 04:17:00AM +0530, Ramkumar Ramachandra wrote:
> Junio C Hamano wrote:.
> > As I said in the different subthread, I am not convinced that you
> > would need the complexity of branch.*.forkedFrom. If you set your
> > "upstream" to the true upstream (not your publishing point
On Tue, Jan 07, 2014 at 03:40:56AM +0530, Ramkumar Ramachandra wrote:
> Jeff King wrote:
> > Yeah, I had similar thoughts. I personally use "branch.*.merge" as
> > "forkedFrom", and it seems like we are going that way anyway with things
> > like "git rebase" and "git merge" defaulting to upstream.
John Szakmeister wrote:
> I guess it's not a good idea to
> set 'push.default' to 'upstream' in this triangle workflow then,
> otherwise the branch name being pushed to will be 'branch.*.merge'.
> Is that correct? I just want to make sure I understand what's
> happening here.
push.default = upstr
On Mon, Jan 6, 2014 at 5:54 PM, Ramkumar Ramachandra wrote:
> John Szakmeister wrote:
>> Then where does it get pushed? Do you always specify where to save your
>> work?
>>
>> FWIW, I think the idea of treating @{u} as the eventual recipient of
>> your changes is good, but then it seems like Git
John Szakmeister wrote:
> Then where does it get pushed? Do you always specify where to save your work?
>
> FWIW, I think the idea of treating @{u} as the eventual recipient of
> your changes is good, but then it seems like Git is lacking the
> "publish my changes to this other branch" concept.
>
Junio C Hamano wrote:.
> As I said in the different subthread, I am not convinced that you
> would need the complexity of branch.*.forkedFrom. If you set your
> "upstream" to the true upstream (not your publishing point), and
> have "remote.pushdefault"set to 'publish', you can expect
>
>
Ramkumar Ramachandra writes:
> Junio C Hamano wrote:
>> I meant "a single branch" as opposed to "depending on what branch
>> you are sending out, you may have to use a different upstream
>> starting point", and a single "format.defaultTo" that does not read
>> what your HEAD currently points at m
Jeff King wrote:
> Yeah, I had similar thoughts. I personally use "branch.*.merge" as
> "forkedFrom", and it seems like we are going that way anyway with things
> like "git rebase" and "git merge" defaulting to upstream.
My issue with that is that I no idea where my branch is with respect
to my fo
Junio C Hamano wrote:
> I meant "a single branch" as opposed to "depending on what branch
> you are sending out, you may have to use a different upstream
> starting point", and a single "format.defaultTo" that does not read
> what your HEAD currently points at may not be enough.
>
> Unless you set
John Szakmeister writes:
> Am I missing something? If there is something other than @{u} to
> represent this latter concept, I think `git push` should default to
> that instead. But, at least with my current knowledge, that doesn't
> exist--without explicitly saying so--or treating @{u} as that
Jeff King writes:
> On Mon, Jan 06, 2014 at 12:38:30PM -0800, Junio C Hamano wrote:
>
>> > I wonder if it is too late to try to clarify this dual usage. It kind of
>> > seems like the push config is "this is the place I publish to". Which,
>> > in many workflows, just so happens to be the exact s
On Mon, Jan 6, 2014 at 3:42 PM, Jonathan Nieder wrote:
> John Szakmeister wrote:
>
>>I think in a
>> typical, feature branch-based workflow @{u} would be nearly useless.
>
> I thought the idea of @{u} was that it represents which ref one
> ty
On Mon, Jan 06, 2014 at 12:38:30PM -0800, Junio C Hamano wrote:
> > I wonder if it is too late to try to clarify this dual usage. It kind of
> > seems like the push config is "this is the place I publish to". Which,
> > in many workflows, just so happens to be the exact same as the place you
> > f
On Mon, Jan 06, 2014 at 03:29:57PM -0500, John Szakmeister wrote:
> > Yeah, I had similar thoughts. I personally use "branch.*.merge" as
> > "forkedFrom", and it seems like we are going that way anyway with things
> > like "git rebase" and "git merge" defaulting to upstream. But then there
> > is
John Szakmeister wrote:
>I think in a
> typical, feature branch-based workflow @{u} would be nearly useless.
I thought the idea of @{u} was that it represents which ref one
typically wants to compare the current branch to. It is used by
'gi
Jeff King writes:
> On Mon, Jan 06, 2014 at 12:06:51PM -0800, Junio C Hamano wrote:
>
>> Unless you set @{u} to this new configuration, in which case the
>> choice becomes dynamic depending on the current branch, but
>>
>> - if that is the only sane choice based on the current branch, why
>>
On Mon, Jan 6, 2014 at 3:18 PM, Jeff King wrote:
> On Mon, Jan 06, 2014 at 12:06:51PM -0800, Junio C Hamano wrote:
>
>> Unless you set @{u} to this new configuration, in which case the
>> choice becomes dynamic depending on the current branch, but
>>
>> - if that is the only sane choice based on
On Mon, Jan 06, 2014 at 12:06:51PM -0800, Junio C Hamano wrote:
> Unless you set @{u} to this new configuration, in which case the
> choice becomes dynamic depending on the current branch, but
>
> - if that is the only sane choice based on the current branch, why
>not use that as the default
Ramkumar Ramachandra writes:
> Junio C Hamano wrote:
>> - why is a single branch name sufficient?
>
> It does accept a , so any form is allowed; but why would
> anyone want that in a format.defaultTo? I'm not sure we want to impose
> an artificial restriction on the configuration variable though
Jonathan Nieder wrote:
> 1. Most config settings are in noun form: e.g.,
> "[remote] pushDefault = foo". That makes their names easy to guess
> and makes them easy to talk about: I set the default remote for
> pushing by changing the remote.pushdefault setting.
>
> '[url ""] inste
Junio C Hamano wrote:
> - why is a single branch name sufficient?
It does accept a , so any form is allowed; but why would
anyone want that in a format.defaultTo? I'm not sure we want to impose
an artificial restriction on the configuration variable though.
> - is it a better option to simply d
Ramkumar Ramachandra writes:
> A very common workflow for preparing patches involves working off a
> topic branch and generating patches against 'master' to send off to the
> maintainer. However, a plain
>
> $ git format-patch -o outgoing
>
> is a no-op on a topic branch,...
Two points.
- wh
Hi,
Ramkumar Ramachandra wrote:
> a plain
>
> $ git format-patch -o outgoing
>
> is a no-op on a topic branch, and the user has to remember to specify
> 'master' explicitly everytime. Save the user the extra keystrokes by
> introducing format.defaultTo
Not excited. Two re
A very common workflow for preparing patches involves working off a
topic branch and generating patches against 'master' to send off to the
maintainer. However, a plain
$ git format-patch -o outgoing
is a no-op on a topic branch, and the user has to remember to specify
'master' explicitly every
33 matches
Mail list logo
