Jonathan Nieder jrnie...@gmail.com 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
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 work on,
Junio C Hamano venit, vidit, dixit 08.02.2013 09:16:
Jonathan Nieder jrnie...@gmail.com 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
Michael J Gruber g...@drmicha.warpmail.net 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,
Michael J Gruber g...@drmicha.warpmail.net writes:
Junio C Hamano venit, vidit, dixit 08.02.2013 09:16:
Jonathan Nieder jrnie...@gmail.com 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
Junio C Hamano wrote:
Jeff King p...@peff.net 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
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 pull) will
Michael J Gruber wrote:
Junio C Hamano venit, vidit, dixit 08.02.2013 09:16:
Jonathan Nieder jrnie...@gmail.com 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
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 pulls
Ramkumar Ramachandra artag...@gmail.com writes:
Junio C Hamano wrote:
[remote origin]
url = ... where Ram fetches and pulls from ...
pushurl = ... where Ram pushes to ...
fetch = refs/heads/*:refs/remotes/*
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
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
origin
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 backward,
Jonathan Nieder jrnie...@gmail.com 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
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
Jeff King p...@peff.net 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
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 that
Junio C Hamano gits...@pobox.com 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
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. Instead, it
19 matches
Mail list logo
