Junio C Hamano [off-list ref] writes:
Yes, "push --track" lets you postpone the decision; branching, working on
it, pushing it out _and_ _then_ using your "branch -f" trick will let you
postpone the decision even further.
Nonetheless, "push --track" is by far the most natural UI for the most
common case, I think.
And it doesn't add --track to the UI.
That's not a positive...
None of this is _necessary_, it's to make git more convenient.
Halfway-measures seem like "oh the user can just use this branch
command" seem like, well, halfway measures. Sure, it would be nice to
have a branch command _too_, just to make it easier for branch
maintenance, but it's not what's really wanted.
-Miles
--
Faith, n. Belief without evidence in what is told by one who speaks without
knowledge, of things without parallel.
Miles Bader [off-list ref] writes:
quoted
And it doesn't add --track to the UI.
That's not a positive...
Oh, that is definitely a *HUGE* plus. I wouldn't go so far as to say that
the word --track was a mistake. But the thing is, unfortunately it has
already been contaminated by people using it in two completely different
ways and ended up confusing new people. Some use it to mean "this branch
forked off of and builds on top of", and others use it to mean "this ref
holds a copy for reference purposes".
On Sat, Jan 16, 2010 at 3:18 AM, Junio C Hamano [off-list ref] wrote:
quoted
quoted
And it doesn't add --track to the UI.
That's not a positive...
Oh, that is definitely a *HUGE* plus. I wouldn't go so far as to say that
the word --track was a mistake. But the thing is, unfortunately it has
already been contaminated by people using it in two completely different
ways and ended up confusing new people. Some use it to mean "this branch
forked off of and builds on top of", and others use it to mean "this ref
holds a copy for reference purposes".
Then the right thing to do is to rename existing uses of --track so
that they're not confusing. Much-wanted functionality should not be
rejected simply because of an earlier mistake which is essentially
orthogonal to it, and which can be corrected easily enough.
So let's just say we're discussing the semantics, and it will use
another option name, which will be then retrofitted to other similar
uses for consistency (as should surely be done regardless of what
happens with this command):
git push --GRUBBLENUT
-Miles
--
Do not taunt Happy Fun Ball.