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

Felipe Contreras wrote:

 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'.

git merge @{u}

But, while we are on that, why not automatically merge the tracking
branches?

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 [off-list ref] wrote:

Felipe Contreras wrote:

quoted

 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'.

git merge @{u}

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

quoted

But, while we are on that, why not automatically merge the tracking
branches?

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.

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

Felipe Contreras wrote:

On Mon, Oct 4, 2010 at 11:46 PM, Jonathan Nieder [off-list ref] wrote:

quoted

git merge @{u}

Interesting, I don't find anything like that in the documentation.

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

Moreover, wouldn't it make sense to make 'git merge' = 'git merge
@{u}'?

I think so, yes. :)

quoted

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.

Maybe, I feel 'git pull' is for single branches or repos, whereas 'git
remote update' is pretty clear it's for all the repos

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 [off-list ref] wrote:

Felipe Contreras wrote:

quoted

On Mon, Oct 4, 2010 at 11:46 PM, Jonathan Nieder [off-list ref] wrote:

quoted

git merge @{u}

Interesting, I don't find anything like that in the documentation.

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

quoted

Moreover, wouldn't it make sense to make 'git merge' = 'git merge
@{u}'?

I think so, yes. :)

Great :)

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.

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.

-- 
Felipe Contreras

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

Moreover, wouldn't it make sense to make 'git merge' = 'git merge
@{u}'?

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 [off-list ref] wrote:

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

quoted

Moreover, wouldn't it make sense to make 'git merge' = 'git merge
@{u}'?

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

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?

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

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

-- 
Felipe Contreras

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

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

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 [off-list ref] wrote:

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

quoted

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

I would expect it to do nothing, or just output a usage.

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

The
proposed behavior is also unexpected because git-pull already does
(almost) the same thing.

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

-- 
Felipe Contreras