Andreas Ericsson [off-list ref] writes:
However, there's still this issue:
$ git checkout -b foo origin/pu
Branch foo set up to track remote branch refs/remotes/origin/pu.
Switched to a new branch "foo"
git checkout will say that every time a branch is created from a
tracking branch, unless one tells it --no-track (which people don't
learn about unless they're really into git), so it's quite natural
that people think git will actually make sure, within reasonable
limits, that 'foo' is kept in sync with refs/remotes/origin/pu.
That's not the case, however.
So we could either change the message to be:
"Branch foo set up to track remote branch refs/remotes/origin/pu,
provided you only ever issue git-pull while having branch foo
checked out."
Or we could make 'git checkout -b' default to --no-track, perhaps
giving annoying messages everytime someone "git-checkout -b"'s a
remote tracking branch.
Or we could make git-pull keep git checkout's promises.
The thing is, if you have 200 local branches (because you
interact with 50 repositories with 4 primary branches each), you
do not constantly check all of them out anyway. And the only
place that staleness of the local tracking fork matters is when
you check it out (that is, as long as you train your users that
the way to check differences with the upstream 'pu' in your case
is by doing operations with 'origin/pu' not with your local
'foo').
With that in mind, how about making "git checkout foo", after
foo is set up thusly, to show:
git log --pretty=oneline --left-right origin/pu...foo
if (and only if) they have diverged? Then you can deal with the
staleness of local tracking fork 'foo' in any way you want.
You could even go one step further and make this "checkout foo",
in addition to or instead of showing the above left-right log,
- automatically run "git merge origin/pu" if it is a
fast-forward, and say it did _not_ run that merge if it is
not a fast-forward;
- automatically run "git merge origin/pu" always, even if it is
not a fast-forward;
- automatically run "git rebase origin/pu" always;
Would that make your life easier?
Junio C Hamano wrote:
Andreas Ericsson [off-list ref] writes:
quoted
However, there's still this issue:
$ git checkout -b foo origin/pu
Branch foo set up to track remote branch refs/remotes/origin/pu.
Switched to a new branch "foo"
git checkout will say that every time a branch is created from a
tracking branch, unless one tells it --no-track (which people don't
learn about unless they're really into git), so it's quite natural
that people think git will actually make sure, within reasonable
limits, that 'foo' is kept in sync with refs/remotes/origin/pu.
That's not the case, however.
So we could either change the message to be:
"Branch foo set up to track remote branch refs/remotes/origin/pu,
provided you only ever issue git-pull while having branch foo
checked out."
Or we could make 'git checkout -b' default to --no-track, perhaps
giving annoying messages everytime someone "git-checkout -b"'s a
remote tracking branch.
Or we could make git-pull keep git checkout's promises.
The thing is, if you have 200 local branches (because you
interact with 50 repositories with 4 primary branches each), you
do not constantly check all of them out anyway. And the only
place that staleness of the local tracking fork matters is when
you check it out (that is, as long as you train your users that
the way to check differences with the upstream 'pu' in your case
is by doing operations with 'origin/pu' not with your local
'foo').
Probably, although I think the confusion of 'foo' being something
else than 'origin/pu' after it's been checked out would be hard
to explain. I'll see how the patch turns out. If it all goes tits
up, I'll see if a post-checkout hook can solve it.
With that in mind, how about making "git checkout foo", after
foo is set up thusly, to show:
git log --pretty=oneline --left-right origin/pu...foo
if (and only if) they have diverged? Then you can deal with the
staleness of local tracking fork 'foo' in any way you want.
You could even go one step further and make this "checkout foo",
in addition to or instead of showing the above left-right log,
- automatically run "git merge origin/pu" if it is a
fast-forward, and say it did _not_ run that merge if it is
not a fast-forward;
- automatically run "git merge origin/pu" always, even if it is
not a fast-forward;
- automatically run "git rebase origin/pu" always;
Would that make your life easier?
That it would, except the confusion would then be that it's automatically
rebased for the branches one currently hasn't got checked out while pulling,
and the branch that *is* checked out gets merged (crazy, yes), so those
who prefer the rebase would get what they want by doing something completely
bonkers, such as:
git checkout -b just-gonna-pull HEAD^
git pull
git checkout whatever-other-branch-they-were-on
(yes, "aggresively ignorant", I think Ted said in an earlier mail)
It'd probably be better to go with Dscho's suggestion, although I'm not quite
sure what that was any more. It involved automagical rebasing on fetch or pull
though.
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
On Oct 25, 2007, at 10:18 PM, Andreas Ericsson wrote:
Junio C Hamano wrote:
quoted
Andreas Ericsson [off-list ref] writes:
quoted
With that in mind, how about making "git checkout foo", after
foo is set up thusly, to show:
git log --pretty=oneline --left-right origin/pu...foo
if (and only if) they have diverged? Then you can deal with the
staleness of local tracking fork 'foo' in any way you want.
You could even go one step further and make this "checkout foo",
in addition to or instead of showing the above left-right log,
- automatically run "git merge origin/pu" if it is a
fast-forward, and say it did _not_ run that merge if it is
not a fast-forward;
- automatically run "git merge origin/pu" always, even if it is
not a fast-forward;
- automatically run "git rebase origin/pu" always;
Would that make your life easier?
That it would, except the confusion would then be that it's
automatically
rebased for the branches one currently hasn't got checked out while
pulling,
and the branch that *is* checked out gets merged (crazy, yes), so
those
who prefer the rebase would get what they want by doing something
completely
bonkers, such as:
git checkout -b just-gonna-pull HEAD^
git pull
git checkout whatever-other-branch-they-were-on
(yes, "aggresively ignorant", I think Ted said in an earlier mail)
It'd probably be better to go with Dscho's suggestion, although I'm
not quite
sure what that was any more. It involved automagical rebasing on
fetch or pull
though.
git pull's automagic and the automatic behaviour of git checkout
proposed by Junio should always do the same. git pull should
be changed to act a if your three commands were fused into it
(but obviously implemented differently).
I think teaching "git checkout" a dwim mode is quite
interesting. The required work to bring a local branch
up-to-date with a remote branch is deferred until really needed.
An then "git checkout" does the right thing. A lot of automagic
but definitely intriguing.
Steffen
Steffen Prohaska wrote:
On Oct 25, 2007, at 10:18 PM, Andreas Ericsson wrote:
quoted
Junio C Hamano wrote:
quoted
Andreas Ericsson [off-list ref] writes:
quoted
With that in mind, how about making "git checkout foo", after
foo is set up thusly, to show:
git log --pretty=oneline --left-right origin/pu...foo
if (and only if) they have diverged? Then you can deal with the
staleness of local tracking fork 'foo' in any way you want.
You could even go one step further and make this "checkout foo",
in addition to or instead of showing the above left-right log,
- automatically run "git merge origin/pu" if it is a
fast-forward, and say it did _not_ run that merge if it is
not a fast-forward;
- automatically run "git merge origin/pu" always, even if it is
not a fast-forward;
- automatically run "git rebase origin/pu" always;
Would that make your life easier?
That it would, except the confusion would then be that it's automatically
rebased for the branches one currently hasn't got checked out while
pulling,
and the branch that *is* checked out gets merged (crazy, yes), so those
who prefer the rebase would get what they want by doing something
completely
bonkers, such as:
git checkout -b just-gonna-pull HEAD^
git pull
git checkout whatever-other-branch-they-were-on
(yes, "aggresively ignorant", I think Ted said in an earlier mail)
It'd probably be better to go with Dscho's suggestion, although I'm
not quite
sure what that was any more. It involved automagical rebasing on fetch
or pull
though.
git pull's automagic and the automatic behaviour of git checkout
proposed by Junio should always do the same. git pull should
be changed to act a if your three commands were fused into it
(but obviously implemented differently).
I think it would be better to implement it as a different command that
would do all those weird and tedious dwim things that suit a particular
kind of developer, but only so long as those operations succeed without
conflicts.
So for example the flow could go something like this;
---
read_branch_merge_config();
git fetch
if prefetch(local == remote_tracking)
set ref local to match ref remote_tracking;
else if (--safe-rebase)
try_rebase local onto remote_tracking;
---
It's such a common operation that I really do think it's worth
having support for it. Perhaps with a "--try-rebase" option to
git-pull.
If we then add a a "--push-after-pull" (to work on the current
branch only) we have the "git sync" alias readily available to
accommodate the average reluctant git user, and I'm sure gui
hackers could do wonders with it, especially on windows, where
people seem accustomed to a lot of things happening when clicking
a single button.
I think teaching "git checkout" a dwim mode is quite
interesting. The required work to bring a local branch
up-to-date with a remote branch is deferred until really needed.
An then "git checkout" does the right thing. A lot of automagic
but definitely intriguing.
Yup, and it can be done with a post-checkout hook (which I notice
there are no examples for, so I've added that to my ever-growing
todo).
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231