Re: [PATCH] push.default: Rename 'tracking' to 'upstream'

Johan Herland [off-list ref] writes:

In order to make this more understandable to the user, we rename the
push.default == 'tracking' option to push.default == 'upstream'.

While we're there, shouldn't we also rename 'branch.<remote>.merge' to
'branch.<remote>.upstream'?

It has a bit more consequences, since external porcelains/scripts are
likely to call "git config branch.foo.merge", and would be broken by
such change. But maybe 1.8.0 is the time for this kind of things.

-- 
Matthieu Moy
http://www-verimag.imag.fr/~moy/

On Wed, 16 Feb 2011, Matthieu Moy wrote:

Johan Herland [off-list ref] writes:

quoted

In order to make this more understandable to the user, we rename the
push.default == 'tracking' option to push.default == 'upstream'.

While we're there, shouldn't we also rename 'branch.<remote>.merge' to
'branch.<remote>.upstream'?

I have a draft proposal not exactly to rename it, but to replace it by
a new branch.<name>.upstream which would point to local ref rather
than a ref on the remote, so one would have e.g.
branch.topic.upstream = refs/remotes/origin/master. Maybe I should
clean up that proposal and send it soon. The topic comes up quite
frequently.

My biggest concern with it is that it breaks the use case where the
remote is not named, i.e. where one has a configuration that looks
like:

[branch "topic"]
	remote = git://git.kernel.org/pub/scm/git/git.git
	merge = master

I don't know how common that case is, so I don't know if it would it
be acceptable to break it. I would of course not suggest no longer
fall back to reading branch.<name>.(remote+merge), but at some point
we would drop support for that and then we would disallow that use
case.

I'm also not sure the benefits are that great; this is just one of
those things I think "we should do differently if designing git from
scratch".

What do you think? Should I even bother sending a formal proposal?


/Martin

Dnia środa 16. lutego 2011 10:42, Martin von Zweigbergk napisał:

On Wed, 16 Feb 2011, Matthieu Moy wrote:

quoted

Johan Herland [off-list ref] writes:

quoted

In order to make this more understandable to the user, we rename the
push.default == 'tracking' option to push.default == 'upstream'.

While we're there, shouldn't we also rename 'branch.<remote>.merge' to
'branch.<remote>.upstream'?

I have a draft proposal not exactly to rename it, but to replace it by
a new branch.<name>.upstream which would point to local ref rather
than a ref on the remote, so one would have e.g.
branch.topic.upstream = refs/remotes/origin/master. Maybe I should
clean up that proposal and send it soon. The topic comes up quite
frequently.

Actually while I think that it makes more sense to use local ref for
'branch.<name>.merge' because it is what is merged, i.e.:

  branch.topic.merge = refs/remotes/origin/master

or in case of tracking local branch

  branch.topic.remote = .
  branch.topic.merge  = refs/heads/master

I think that for 'branch.<name>.upstream' it would make more sense to
use the name that *upstream* uses, i.e.

  branch.topic.upstream = refs/heads/master

-- 
Jakub Narebski
Poland

* Martin von Zweigbergk [off-list ref] [110216 10:43]:

On Wed, 16 Feb 2011, Matthieu Moy wrote:

quoted

Johan Herland [off-list ref] writes:

quoted

In order to make this more understandable to the user, we rename the
push.default == 'tracking' option to push.default == 'upstream'.

While we're there, shouldn't we also rename 'branch.<remote>.merge' to
'branch.<remote>.upstream'?

I have a draft proposal not exactly to rename it, but to replace it by
a new branch.<name>.upstream which would point to local ref rather
than a ref on the remote, so one would have e.g.
branch.topic.upstream = refs/remotes/origin/master.

Making it name a local ref name would also make it easier to add support
for listing multiple references.

The use case I miss support for (please hint me if this is already
possible somehow), is having multiple remotes where other people (or
more importantly I at other computers for projects without central
repository) add commits.

Currently one needs to fetch all the remotes and then manually do a
merge remote1/branchname remote2/branchname remote3/branchname and so
on. It would be nice if a single git pull could do that.

	Bernhard R. Link