Ramkumar Ramachandra writes:
> Jonathan Nieder wrote:
>> Ramkumar Ramachandra wrote:
>>
>>> And yes, a regular `git push origin refs/for/master` is just retarded.
>>
>> The usual incantation is "git push gerrit HEAD:refs/for/master". Is
>> the code review creation push that uses a different bran
Ramkumar Ramachandra writes:
> Junio C Hamano wrote:
>> [remote "origin"]
>> url = ... where Ram fetches and pulls from ...
>> pushurl = ... where Ram pushes to ...
>> fetch = refs/heads/*:refs/remotes/*
>> updateTrackOnPush
Jonathan Nieder wrote:
> Ramkumar Ramachandra wrote:
>
>> And yes, a regular `git push origin refs/for/master` is just retarded.
>
> The usual incantation is "git push gerrit HEAD:refs/for/master". Is
> the code review creation push that uses a different branchname from
> the branch the integrator
Michael J Gruber wrote:
> Junio C Hamano venit, vidit, dixit 08.02.2013 09:16:
>> Jonathan Nieder writes:
>>> "Wait, why did the remote rewind?"
>>
>> Oh, I am very well aware of that glitch.
>>
>> "git push" has this hack to pretend as if the pusher immediately
>> turned around and fetched from
Junio C Hamano wrote:
> [remote "origin"]
> url = ... where Ram fetches and pulls from ...
> pushurl = ... where Ram pushes to ...
> fetch = refs/heads/*:refs/remotes/*
> updateTrackOnPush = no
>
> Then "git fetch" (or "git pul
Junio C Hamano wrote:
> Jeff King writes:
>
>> We have the problem now that new users do not necessarily understand the
>> matching strategy, or why it is useful, and get confused. When we move
>> to "simple", we may be switching to a world where the early part of the
>> learning curve is more gen
Michael J Gruber writes:
> Junio C Hamano venit, vidit, dixit 08.02.2013 09:16:
>> Jonathan Nieder writes:
>>
>>> "Wait, why did the remote rewind?"
>>
>> Oh, I am very well aware of that glitch.
>>
>> "git push" has this hack to pretend as if the pusher immediately
>> turned around and fetch
Michael J Gruber writes:
> As for the triangle remote, I really think we should clean up the
> situation regarding push, pushurlinsteadof and the various different and
> inconclusive output formats of "git remote" (with or without "-v", with
> or without a remote name) first, before introducing y
Jeff King writes:
> We have the problem now that new users do not necessarily understand the
> matching strategy, or why it is useful, and get confused. When we move
> to "simple", we may be switching to a world where the early part of the
> learning curve is more gentle for those users, but they
Junio C Hamano venit, vidit, dixit 08.02.2013 09:16:
> Jonathan Nieder writes:
>
>> "Wait, why did the remote rewind?"
>
> Oh, I am very well aware of that glitch.
>
> "git push" has this hack to pretend as if the pusher immediately
> turned around and fetched from the remote.
>
> It shouldn't
On Thu, Feb 07, 2013 at 10:45:07PM -0800, Junio C Hamano wrote:
> To support a triangular arrangement well, there may need some
> thinking on what $branch@{upstream} means. The original intent of
> the upstream mode specified for "push.default" is push the result
> back to what you based your wor
Jonathan Nieder writes:
> "Wait, why did the remote rewind?"
Oh, I am very well aware of that glitch.
"git push" has this hack to pretend as if the pusher immediately
turned around and fetched from the remote.
It shouldn't have been made to do so unconditionally; instead it
should have been de
Junio C Hamano wrote:
> I'd actually see this as Gerrit being weird.
>
> If it wants to quarantine a commit destined to the "master" branch,
> couldn't it just let people push to "master" and then internally
> update "for/master" instead?
It is because pushing doesn't update refs/heads/master. I
Junio C Hamano writes:
> I think the triangle
> arrangement where you want to have "this is where I fetch from and
> integrate with, and that is where I publish" is more common among
> the Git users these days.
Another thing to know about is that the recent move to change the
behaviour of
On Thu, Feb 07, 2013 at 10:08:48PM -0800, Junio C Hamano wrote:
> How best to express the triangle is somewhat tricky, but I think it
> is sensible to say you have "origin" that points to your upstream
> (i.e. me), and "peff" that points to your publishing point, in other
> words, make it explicit
Jeff King writes:
> On Thu, Feb 07, 2013 at 09:44:59PM +0530, Ramkumar Ramachandra wrote:
>
>> This has been annoying me for a really long time, but I never really
>> got around to scratching this particular itch. I have a very common
>> scenario where I fork a project on GitHub. I have two con
On Thu, Feb 07, 2013 at 09:44:59PM +0530, Ramkumar Ramachandra wrote:
> This has been annoying me for a really long time, but I never really
> got around to scratching this particular itch. I have a very common
> scenario where I fork a project on GitHub. I have two configured
> remotes: origin
Jonathan Nieder writes:
> The usual incantation is "git push gerrit HEAD:refs/for/master". Is
> the code review creation push that uses a different branchname from
> the branch the integrator pulls what seems backward, or is it the need
> to specify a refname at all on the command line?
>
> I ag
Hi Ram,
Ramkumar Ramachandra wrote:
> And yes, a regular `git push origin refs/for/master` is just retarded.
The usual incantation is "git push gerrit HEAD:refs/for/master". Is
the code review creation push that uses a different branchname from
the branch the integrator pulls what seems backwar
Ramkumar Ramachandra wrote:
> Ramkumar Ramachandra wrote:
>> And yes, a regular `git push origin refs/for/master` is just retarded.
>
> Actually a git config remote.origin.push refs/heads/*:refs/for/* makes
> more sense here.
Sorry about all that confusion. The first line should be `git push
orig
On 02/07/2013 05:14 PM, Ramkumar Ramachandra wrote:
> This has been annoying me for a really long time, but I never really
> got around to scratching this particular itch. I have a very common
> scenario where I fork a project on GitHub. I have two configured
> remotes: origin which points to "g
21 matches
Mail list logo
