Useful tracking branches and auto merging

Hi,

For some time now I've stopped using 'git pull', and used 'git fetch', and now 'git remote update', however, this is still not ideal.

 Your branch is behind 'origin/master' by 17 commits, and can be fast-forwarded.

This message doesn't tell me _how_ I can 'fast-forward', I do 'git merge origin/master' but if git already knows 'master' is tracking 'origin/master' why should I specify that? Perhaps 'git merge --tracking'.

But, while we are on that, why not automatically merge the tracking branches? Perhaps 'git remote update --auto-merge', configurable so I can make auto-merge the default, and perhaps make it the default in 1.8. Also, maybe some people would like them to be auto merged only when they can be fast-forwarded.

I believe this would make remote tracking branches much more useful. What do you think?

Cheers

Felipe Contreras wrote:

git merge @{u}

Maybe 'git pull --all' could be taught to eventually do this? That would be incompatible with its current behavior of fetching everything and merging some random branch, but I don't think anyone is relying on that.

On Mon, Oct 4, 2010 at 11:46 PM, Jonathan Nieder <jrnieder@gmail.com> wrote:

Interesting, I don't find anything like that in the documentation. Moreover, wouldn't it make sense to make 'git merge' = 'git merge @{u}'?

Maybe, I feel 'git pull' is for single branches or repos, whereas 'git remote update' is pretty clear it's for all the repos, so if some merging is to be done for all the repos, it should be some form of 'git remote', no?

Felipe Contreras wrote:

The @{upstream} notation is documented in gitrevisions(7). But yes, a more prominent mention (maybe some examples?) would be nice.

I think so, yes. :)

If I remember correctly, the current status is:

 - 'git remote' is for adding, removing, and pruning remotes
 - 'git fetch <remote>' and 'git fetch --all' are for updating them, and
 - 'git remote update' is for backward compatibility.

On Mon, Oct 4, 2010 at 11:57 PM, Jonathan Nieder <jrnieder@gmail.com> wrote:

Great :)

Oh, I thought 'git remote update' was newer. If 'git fetch --all' is supposed to be used instead, then I guess 'git pull --all' makes sense, but personally I would like it to error out if the merge is not fast-forward.

Cheers.

On Mon, Oct 04, 2010 at 11:56:02PM +0300, Felipe Contreras wrote:

Isn't that what 'git pull' does? Especially after using 'git fetch'?

I prefer 'git merge' as one of the few git commands without magic behavior and DWIMery.

Clemens

On Sun, Oct 10, 2010 at 8:15 PM, Clemens Buchacher <drizzd@aon.at> wrote:

No, it hits the network again: git pull = git fetch + git merge @{u}

If I already did 'git fetch' why should I do it again?

There's no magic involved, it's just what you would expect, what else should 'git merge' (without arguments) do?

On Sun, Oct 10, 2010 at 08:30:22PM +0300, Felipe Contreras wrote:

I would expect it to do nothing, or just output a usage. The proposed behavior is also unexpected because git-pull already does (almost) the same thing.

Clemens

On Sun, Oct 10, 2010 at 8:45 PM, Clemens Buchacher <drizzd@aon.at> wrote:

So you are not going to type this command, how can such change in behavior affect you?

Not true. By your logic 'git fetch' should also do nothing because 'git pull' does "the same thing".

Jonathan Nieder <jrnieder@gmail.com> writes:

I vaguely recall that we had discussions to disable "git pull --all", which most likely is a mistake?

On Tue, Oct 5, 2010 at 7:35 PM, Junio C Hamano <gitster@pobox.com> wrote:

I believe this use-case is valid:

 * The user wants *all* his remote tracking branches to point to the
latest branch head in all the repos in the case the can be
fast-forwarded, and in the case they can't, print an error and
continue with the rest.

Right now I would have to do 'git fetch --all' go to every remote tracking branch, and do 'git merge @{upstream}'.

Do you have a better idea how to achieve that instead of 'git pull --all'?

Felipe Contreras <felipe.contreras@gmail.com> writes:

I would not be so sure about the validity of that use case.

If your tracking branches are always trailing, never having any real work of your own, there is no reason to have them locally, instead of checking them out on demand. So let's forget about that case.

When you are collaborating with somebody else, sharing a topic branch, and you are behind because you were not working on it while the other parties progressed the shared topic, it would be convenient if your local branch is fast-forwarded before you start to work on it. One possible solution for that would be to teach "git pull" to fast-forward such backgrounded tracking branches that are not checked out. Another obvious alternative is to teach "git checkout" tell you where you are, and even tell you that you could fast-forward [*1*].

On the other hand, if you have forked a topic branch to build your new nifty feature at some known point (e.g. immediately after the upstream reached a new stable point), but you haven't done any real work on it, it is doubtful that it is even a good idea to fast-forward it automatically to begin with. C.f.

   Message-ID: <AANLkTim85sH_2o=xCiDuoQrHq_7ZL96Y91xQMGxUP5Fy@mail.gmail.com>

   "The real problem is that maintainers often pick random - and not at
    all stable - points for their development to begin with. They just
    pick some random "this is where Linus -git tree is today", and do
    their development on top of that. THAT is the problem - they are
    unaware that there's some nasty bug in that version."

IOW, once I decided one point is a good place to fork a topic, created a branch off of it, but didn't have a chance to do a real work on it yet, it would be very irritating if "git pull" updated that branch only because I do not have my own commit on it yet.

I see little sanity in doing this with any option whose name has "all"; it largely depends on the workflow, and in a single repository, some branches may want to get fast-forwarded automatically while others don't [*2*].

[Footnotes]

*1* It is plausible that you could go one step further and define branch.frotz.autofastforward configuration variable to tell "git checkout" to fast-forward in such a case, perhaps only when the working tree and the index are clean.

*2* It also is plausible that the same branch.frotz.autofastforward configuration variable can be noticed by "git pull".

On Tue, Oct 5, 2010 at 11:10 PM, Junio C Hamano <gitster@pobox.com> wrote:

Don't be so quick. Typing 'master' is certain easier than 'origin/master', or 'stable' rather than 'linux-stable/master', or 'vj-feature-1' rather than 'whatever-repo-this-came-from/feature-1'. The fact that you don't do it doesn't mean it's not a valid use-case.

Fortunately we have 'git checkout --no-track -b origin/foo'. Problem solved.

But rather, what I do is: % git branch -t origin/foo % git checkout -b nifty-feature foo

Then either:
1) fork of a local branch
2) use --no-track
3) don't do 'git pull --all'

I think if you are issuing 'git pull --all' you want your remote tracking branches to fast forward if possible, if not, why are you doing 'git pull --all'?

Cheers.