Default remote branch for local branch

Default remote branch for local branch

[Pavel Roskin]

Hello!

This is not a ready-to-use proposal, but I think my message can prompt
useful changes in GIT or in the "porcelain".

Let's see how remote changes end up in the head branch of the local
repository (sorry for possible mistakes in terminology):

branch in          "remote"              local              index,
a remote  -------> branch       -------> branch     ------> tree
repository         (e.g. origin)         (e.g. master)

Brought in sync by:
           fetch                 merge              checkout

Relationship stored in:
          .git/remotes           nowhere!!!         .git/HEAD

If I fetch a remote branch, git knows where to get changes.  If I change
the current branch, git remembers that.  But git doesn't remember the
relationship between branches mirroring the remote branches and branches
used for local development.

There are situations when I want to work for a significant time on a
certain branch.   Significant time means that changes are made by
others, and I'm supposed to integrate them and make more changes.  Yet I
may want to take advantage of some patches from another team that uses
the other repository.

I want GIT and porcelains work the same way if I'm working with
repository 1 or repository 2.  As it stands now, git gives preferential
treatment to the "origin" branch.  Whatever branch I'm on, "git-pull"
will pull from "origin".  I believe the special role of the "origin"
branch should be reduced to cg-clone and similar commands.

I think it would be convenient to have git remember the remote branch
for the given local branch.  git should know that if HEAD points to
"local-B", "git-fetch" should fetch from "remote-B", not from "origin".

To implement this, git would have to implement attributes for local
branches (other ideas are welcome).  Currently, there are no attributes
for local branches other than the top SHA1 in .git/refs/heads/

Once at the topic of branch attributes, let's see what else could be
useful?  I think that would be the creator of the branch and the comment
(e.g. "this is for tested commits only, to be merged tomorrow" etc).
Where can this data be stored?  Probably in blobs pointed to by refs in
e.g. .git/refs/branch-data/ or just in plain files e.g.
under .git/branch-data/

I know, it sounds like a lot of work to save a few keystrokes.  But I
think it may be worth it.  Working on different branches should have the
same "look and feel".  Otherwise, git would repeat a design error of
CVS, where the head branch was given preference e.g. for date based
updates.

I'm sorry, reading this mailing list is beyond my capabilities, so
certain overlaps with other postings may be expected, unless I'm
suggesting something totally off-base :-)

-- 
Regards,
Pavel Roskin

Re: Default remote branch for local branch

[Junio C Hamano]

Pavel Roskin <proski@gnu.org> writes:

> This is not a ready-to-use proposal, but I think my message can prompt
> useful changes in GIT or in the "porcelain".
>...
> I think it would be convenient to have git remember the remote branch
> for the given local branch.  git should know that if HEAD points to
> "local-B", "git-fetch" should fetch from "remote-B", not from "origin".

I am in favor of the general direction this is going.  Something
like this was mentioned on the list in the past twice (I think
Johannes was involved in the discussion but I do not remember
the details offhand).

My understanding is that Cogito uses $GIT_DIR/branches/$name
file as a configuration file per branch - currently it only
records which remote repository's what remote branch the local
branch $name interfaces with.

The $GIT_DIR/remotes/$name file is to describe each remote
repository, and it _wants_ to be able to describe all the
branches we are interested in, primarily because uploading and
downloading multiple, related heads at once is more efficient.
How remote branches are kept track of with the local tracking
branch, and how remote branches are updated from the local
branch heads, are described by Push/Pull lines there.

As you pointed out, we do not have a convenient way to tell git
where you typically merge things from per local branch.  There
are different patterns I've seen:

 - Promiscous.  For example, "master" branch of Linus repository
   pulls from many subsystem maintainers.  Linus could have one
   "remotes" file per subsystem maintainer he often pulls from
   (and "for-linus" branch name in each remote repository tends
   to stay the same), and unlike the rest of us he does not seem
   to pull into many local branches.  The current "remotes"
   setup is really optimized for this mode of usage (you can use
   "remotes" without having local tracking branches).

 - Merging topic branches into "master" (or "release") branch
   and "next" (or "testing") branch -- inside local repository.

 - CVS-like remote tracking.  A single "primary" remote branch
   is tracked using local "origin", merged into local "master"
   and pushed back to the remote.  Both Cogito-like branches/
   setup and having a single $GIT_DIR/remotes/origin file with
   single Push/Pull line would work equally well.

 - Multiple subsystem maintainer trees tracked in the same local
   repository.  Most generally, two local branches per each
   remote head can be used (one tracking branch to fetch into,
   another to build your changes based on it).  Alternatively,
   you can use one local branch per each remote head without
   using any tracking branch.

Your proposal to give default branch to pull from per the local
branch would help only the last case.  The first one you do not
switch between local branches at all and pull from many
different places; the second is to merge from different topic
branches from time to time and does not benefit from fixed
configuration; the third does not even need configuration.

Maybe you would want something like this.

In $GIT_DIR/config:

	[pull]
	origin = linus for master
        origin = irq-pio of libata for ata-irq-pio
        origin = pata-drivers of libata for ata-pata

In $GIT_DIR/remotes/linus:

	URL: git://git.kernel.org/.../torvalds/linux-2.6.git
	Pull: refs/heads/master:refs/heads/linus

In $GIT_DIR/remotes/libata
	URL: git://git.kernel.org/.../jgarzik/libata-dev.git
	Pull: refs/heads/irq-pio:refs/remotes/libata/irq-pio
	Pull: refs/heads/pata-drivers:refs/remotes/libata/pata-drivers

This is to maintain three local branches: master, ata-irq-pio
and ata-pata.

You are obviously interested in the mainline Linus kernel, so
while you are on your "master" branch, we will look for
"pull.origin .* for master" and find out you would want
remotes/linus file to be used.  His "master" is copied to your
local "linus" branch, and merged into your "master" branch.

	$ git pull

becomes equivalent to:

        $ git pull linus

You are also interested in the libata work by Jeff, and while
you are on your ata-pata branch

	$ git pull

becomes roughly equivalent to:

	$ git pull libata pata-drivers

While we are on the topic, it _might_ be worthwhile to think
about revamping the syntax of $GIT_DIR/remotes file, maybe even
breaking backward compatibility.  The Pull: lines can be
independently specified which gives flexibility, but I suspect
local tracking branches from the same remote tend to live in the
same place; IOW, you would probably not do something like:

	URL: git://git.kernel.org/.../jgarzik/libata-dev.git
	Pull: refs/heads/irq-pio:refs/remotes/libata/irq-pio
	Pull: refs/heads/pata-drivers:refs/heads/pata-drivers

in practice.

Re: Default remote branch for local branch

[Pavel Roskin]

Hello, Junio!

On Fri, 2006-03-31 at 19:05 -0800, Junio C Hamano wrote:
>  - Multiple subsystem maintainer trees tracked in the same local
>    repository.  Most generally, two local branches per each
>    remote head can be used (one tracking branch to fetch into,
>    another to build your changes based on it).  Alternatively,
>    you can use one local branch per each remote head without
>    using any tracking branch.
> 
> Your proposal to give default branch to pull from per the local
> branch would help only the last case.

Exactly.  I tried to track the main Linus repository and Jeff Garzik's
netdev in one place.  Then I discovered that my repository if full of
unintended merges made by "stg pull".

> The first one you do not
> switch between local branches at all and pull from many
> different places; the second is to merge from different topic
> branches from time to time and does not benefit from fixed
> configuration; the third does not even need configuration.
> 
> Maybe you would want something like this.
>
> In $GIT_DIR/config:
> 
> 	[pull]
> 	origin = linus for master
>         origin = irq-pio of libata for ata-irq-pio
>         origin = pata-drivers of libata for ata-pata

First of all, using "origin" on every line carries to little
information.

Secondly, I think the relationship should be between a local development
branch and a local tracking branch.  After all, all remote data is
placed on a local tracking branch first.  It's better not to jump over
layers of abstraction.  Suppose I want to update "masterB".  I tell git
to sync "originB" first.  git already has rules what to do if it should
sync "originB".  Let's not supersede those rules.

I would write the config like this:

[branch-upstream]
master = linus
ata-irq-pio = irq-pio
ata-pata = pata-drivers

> While we are on the topic, it _might_ be worthwhile to think
> about revamping the syntax of $GIT_DIR/remotes file, maybe even
> breaking backward compatibility.  The Pull: lines can be
> independently specified which gives flexibility, but I suspect
> local tracking branches from the same remote tend to live in the
> same place; IOW, you would probably not do something like:
> 
> 	URL: git://git.kernel.org/.../jgarzik/libata-dev.git
> 	Pull: refs/heads/irq-pio:refs/remotes/libata/irq-pio
> 	Pull: refs/heads/pata-drivers:refs/heads/pata-drivers
> 
> in practice.

Sorry, I don't understand this part.

-- 
Regards,
Pavel Roskin

Re: Default remote branch for local branch

[Jakub Narebski]

Pavel Roskin wrote:

> I'm sorry, reading this mailing list is beyond my capabilities, so
> certain overlaps with other postings may be expected, unless I'm
> suggesting something totally off-base :-)

You might want to read "Efficient cloning" thread where
--use-separate-remote and --reference options were introduced:
  http://marc.theaimsgroup.com/?l=git&m=114280442802681&w=2
  http://www.gelato.unsw.edu.au/archives/git/0603/18113.html
  http://thread.gmane.org/gmane.comp.version-control.git/17724
and which had discussion on similar subjects (somewhere).

-- 
Jakub Narebski
Warsaw, Poland

Re: Default remote branch for local branch

[Jakub Narebski]

> You might want to read "Efficient cloning" thread where
> --use-separate-remote and --reference options were introduced:
>   http://marc.theaimsgroup.com/?l=git&m=114280442802681&w=2
>   http://www.gelato.unsw.edu.au/archives/git/0603/18113.html
>   http://thread.gmane.org/gmane.comp.version-control.git/17724
> and which had discussion on similar subjects (somewhere).

See also
  Message-ID: <200603011814.43573.Josef.Weidendorfer@gmx.de>

-- 
Jakub Narebski
Warsaw, Poland

Re: Default remote branch for local branch

[Josef Weidendorfer]

On Saturday 01 April 2006 06:18, Pavel Roskin wrote:
> On Fri, 2006-03-31 at 19:05 -0800, Junio C Hamano wrote:
> > Maybe you would want something like this.
> >
> > In $GIT_DIR/config:
> > 
> > 	[pull]
> > 	origin = linus for master
> >         origin = irq-pio of libata for ata-irq-pio
> >         origin = pata-drivers of libata for ata-pata

Let me try to understand this: the general idea is that

  pull.origin = [<refspec> of] <remote> for <branch>

specifies the default action of git-pull if we are on <branch>, ie.
a "git pull" then runs "git pull <remote> [<refspec>]".

So the example above, if .git/remotes/linus would contain two
refspecs, and you are on the branch of the 2nd refspec, it would
do the wrong thing: merge the 1st refspec with current branch.
So I think this is not useful, and if we use above syntax, we
should make the refspec mandatory.

However. I think a syntax mentioning only 2 local branches is better:

  pull.origin = <local upstream for branch> for <branch>

Perhaps I have misunderstood the proposal?

> First of all, using "origin" on every line carries to little
> information.

"origin" is part of the case-insensitive alphanum key, which is the same
for all config values in Junio's proposal. Especially, you can
not use it for head names. So this is fine.

Perhaps we could make a shorther alternative form for the above where
the key part has not to be specified on every line with a rule like

  if the line does not match /^\S+="/, the full line is the value

Then, above could be written as

  [pull.origin]
  linus for master
  irq-pio of libata for ata-irq-pio
  pata-drivers of libata for ata-pata

However, that's only syntactical sugar.
 
> Secondly, I think the relationship should be between a local development
> branch and a local tracking branch.

Agree.
It is also useful to specify this relation if the upstream is purely a
local branch, e.g. when branching off a local branch, and you want to
pull in changes from the local upstream.

This works automatically if git-pull only does upstream fetching if
there is a remote branch associated. The default action of git-fetch
similar could be "fetch the upstream branch, if that tracks a remote
branch", using the same configuration.

> After all, all remote data is 
> placed on a local tracking branch first.  It's better not to jump over
> layers of abstraction.  Suppose I want to update "masterB".  I tell git
> to sync "originB" first.  git already has rules what to do if it should
> sync "originB".  Let's not supersede those rules.

Junio's proposal has the advantage that you do not have to search in all
files in .git/remotes (and even .git/branches) for the remote branch that
maps to a given local branch.
But that is not the big issue.

> I would write the config like this:
> 
> [branch-upstream]
> master = linus
> ata-irq-pio = irq-pio
> ata-pata = pata-drivers

That is not working, as said above. But with above syntax extension,
with s/=/for/ it would be fine.

It would be nice to also support the topic branches, ie. to be able
to specify all topic branches for a branch, and make "git-pull" default
to an octopus merge of the topic branches.
However, "git-pull" can not distinguish between "merge upstream" and
"merge topic branches". Yet, specifying multiple default branches should
be possible.

> > While we are on the topic, it _might_ be worthwhile to think
> > about revamping the syntax of $GIT_DIR/remotes file, maybe even
> > breaking backward compatibility.  The Pull: lines can be
> > independently specified which gives flexibility, but I suspect
> > local tracking branches from the same remote tend to live in the
> > same place; IOW, you would probably not do something like:
> > 
> > 	URL: git://git.kernel.org/.../jgarzik/libata-dev.git
> > 	Pull: refs/heads/irq-pio:refs/remotes/libata/irq-pio
> > 	Pull: refs/heads/pata-drivers:refs/heads/pata-drivers
> > 
> > in practice.

What is the idea instead?
I think the current syntax is fine, as it is very flexible.
The reasoning about tracking remote branches in the same place
is a porcelain issue to be set up by git-clone.

Perhaps you are missing a remotes editor command?

Josef

> 
> Sorry, I don't understand this part.

Re: Default remote branch for local branch

[Junio C Hamano]

Josef Weidendorfer <Josef.Weidendorfer@gmx.de> writes:

> On Saturday 01 April 2006 06:18, Pavel Roskin wrote:
>> On Fri, 2006-03-31 at 19:05 -0800, Junio C Hamano wrote:
>> > Maybe you would want something like this.
>> >
>> > In $GIT_DIR/config:
>> > 
>> > 	[pull]
>> > 	origin = linus for master
>> >         origin = irq-pio of libata for ata-irq-pio
>> >         origin = pata-drivers of libata for ata-pata
>
> Let me try to understand this: the general idea is that
>
>   pull.origin = [<refspec> of] <remote> for <branch>
>
> specifies the default action of git-pull if we are on <branch>, ie.
> a "git pull" then runs "git pull <remote> [<refspec>]".

Not quite.

It will be (if this were a serious proposal -- I am not
absolutely convinced this is a good idea) more like "git fetch
<remote>" followed by "git-merge HEAD the-refspec-named-there".
The implementation of the above would involve changes to
git-fetch, because it needs to give ".not-for-merge" mark to
different line in FETCH_HEAD depending on [<refspec> of] part.

> So the example above, if .git/remotes/linus would contain two
> refspecs, and you are on the branch of the 2nd refspec, it would
> do the wrong thing: merge the 1st refspec with current branch.

Sorry I fail to visualize this part.

>> Secondly, I think the relationship should be between a local development
>> branch and a local tracking branch.
>
> Agree.
> It is also useful to specify this relation if the upstream is purely a
> local branch, e.g. when branching off a local branch, and you want to
> pull in changes from the local upstream.
>
> This works automatically if git-pull only does upstream fetching if
> there is a remote branch associated. The default action of git-fetch
> similar could be "fetch the upstream branch, if that tracks a remote
> branch", using the same configuration.

Interesting.  

You would need sanity checker for $GIT_DIR/remotes/* files if
you do this to make sure no local tracking branch is by mistake
configured to track two remote branches, which is a good change,
but then:

	git-pull, without parameter, would:

        (1) check if this branch has any local branch it usually
            merges from; if not, do whatever we traditionally
            did (or barf).

        (2) if there is a local branch it merges from, check if
            it is a tracking branch for a remote, by looking at
            remotes/* files.  It would be nice if we could
            detect tracking branches fed from external svn/cvs
            repositories via svn/cvs-import this way at this
            time.  If not, skip the next step and go directly to
            (4).

        (3) run git-fetch (or svn/cvs-import) to update the
            tracking branch;

        (4) merge from that other local branch.

> Junio's proposal has the advantage that you do not have to search in all
> files in .git/remotes (and even .git/branches) for the remote branch that
> maps to a given local branch.
> But that is not the big issue.

A bigger thing is that I am trying to avoid _requiring_ tracking
branches.  If you are not micromanaging your subsystem
maintainers, you should not have to care where they were the
last time you pulled from them.  You should be able to just
pull, examine what the merge brings in, and decide it is worth
merging.  If it isn't, do a "reset", tell them "not good, please
rework and let me know when you are ready," and forget about it.

If we are going require tracking branches, we could do a bit
more with them, like remembering where the tip was when we
fetched the last time (or the time before that...) and diff with
that, but the tracking branch heads are not set up to do things
like that right now -- they are single pointers.

>> Perhaps you are missing a remotes editor command?

Perhaps.  Also perhaps a remotes/ sanity checker.
Something like this:

	$ git branch --describe ata-pata
        Typically merges from pata-drivers branch of
        	git://.../jgarzik/libata-dev.git
	which is tracked with local refs/remotes/libata/pata-drivers.

	$ git branch --decribe refs/remotes/libata/pata-drivers
	Tracking branch for pata-drivers branch of
               	git://.../jgarzik/libata-dev.git

	$ git checkout origin
        warning: you are checking out a tracking branch for "master" branch of
	warning:	git://.../torvalds/linux-2.6.git
	warning: commit/pull/merge commands are disabled.
	hint: you can still create a new branch from here.

Re: Default remote branch for local branch

[Josef Weidendorfer]

On Sunday 02 April 2006 23:40, you wrote:
> > Let me try to understand this: the general idea is that
> >
> >   pull.origin = [<refspec> of] <remote> for <branch>
> >
> > specifies the default action of git-pull if we are on <branch>, ie.
> > a "git pull" then runs "git pull <remote> [<refspec>]".
> 
> Not quite.
> 
> It will be (if this were a serious proposal -- I am not
> absolutely convinced this is a good idea) more like "git fetch
> <remote>" followed by "git-merge HEAD the-refspec-named-there".

So it is not really a <refspec>, but a <localbranch> which has to
appear in the .git/remotes file on the right side of a refspec on
a Pull line.
Then, I think it is redundant to specify the <remote>, as
this can be detected by looking at the .git/remotes files and
searching for <localbranch>.

> > So the example above, if .git/remotes/linus would contain two
> > refspecs, and you are on the branch of the 2nd refspec, it would
> > do the wrong thing: merge the 1st refspec with current branch.
> 
> Sorry I fail to visualize this part.

All I wanted to remark is, that, with

 URL: <remote-URL>
 Pull: refs/head/master:refs/head/remote1
 Pull: refs/head/other:refs/head/remote2

the config

 pull.origin = <remote> for refs/head/my-devel-for-remote2

which does not use the [<refspec> of] part, always is bogus:
We get remote1 merged into my-devel-for-remote2 on a git-pull,
which is not what we want.

> > It is also useful to specify this relation if the upstream is purely a
> > local branch, e.g. when branching off a local branch, and you want to
> > pull in changes from the local upstream.

> 
> Interesting.
> 
> You would need sanity checker for $GIT_DIR/remotes/* files if
> you do this to make sure no local tracking branch is by mistake
> configured to track two remote branches,

Why should this always be a mistake? If you have two developers
doing topic branches for you, you could use this type of config
to make "git-pull" fetching both remotes, and creating an
octopus merge.

And for your "next", you could use this to make "git-pull" merge
both from the stable branch and all topics.

> which is a good change, 

The sanity checker probably should be put into a branch attribute
editor which allows to add the config discussed here. And it
should only print a warning when you are trying to add multiple
upstreams.

> but then:
> 
> 	git-pull, without parameter, would:
> 
>         (1) check if this branch has any local branch it usually
>             merges from; if not, do whatever we traditionally
>             did (or barf).

Yes. This is simply looking up the config.
We could automatically add such a config when branching off to
specify the upstream of a branch.
And git-clone should set this, too, and: We get rid of the current
"origin" hardcoded special handling.

Optionally, branching <new> off from <old> could add <new> as
topic branch of <old>: Thus, if you are on <old> and do git-pull,
you get <new> merged in.

>         (2) if there is a local branch it merges from, check if
>             it is a tracking branch for a remote, by looking at
>             remotes/* files.  It would be nice if we could
>             detect tracking branches fed from external svn/cvs
>             repositories via svn/cvs-import this way at this
>             time.

Good idea. I suppose this needs an entry in .git/remotes like

 URL: ...
 Type: SVN 

>             If not, skip the next step and go directly to 
>             (4).
> 
>         (3) run git-fetch (or svn/cvs-import) to update the
>             tracking branch;

If (1) found multiple branches, do (2)/(3) for every branch.

>         (4) merge from that other local branch.

Or for multiple, do an octopus.


> A bigger thing is that I am trying to avoid _requiring_ tracking
> branches.

I don't think you force anything when you add functionality to git-pull
for the config discussed here. Nobody *has* to use this config - it's
a porcelain thingie.

Cogito could use this, too. AFAIK, it has the same origin/master hardcoded
tracking behavior.

> If you are not micromanaging your subsystem 
> maintainers, you should not have to care where they were the
> last time you pulled from them.  You should be able to just
> pull, examine what the merge brings in, and decide it is worth
> merging.  If it isn't, do a "reset", tell them "not good, please
> rework and let me know when you are ready," and forget about it.
> 
> If we are going require tracking branches,

I do not understand. Why should we require this?

> we could do a bit 
> more with them, like remembering where the tip was when we
> fetched the last time (or the time before that...) and diff with
> that, but the tracking branch heads are not set up to do things
> like that right now -- they are single pointers.
> 
> >> Perhaps you are missing a remotes editor command?
> 
> Perhaps.  Also perhaps a remotes/ sanity checker.
> Something like this:
> ...

Doing this as part of git-branch sounds good.

Josef

Re: Default remote branch for local branch

[Andreas Ericsson]

Josef Weidendorfer wrote:
> 
> Optionally, branching <new> off from <old> could add <new> as
> topic branch of <old>: Thus, if you are on <old> and do git-pull,
> you get <new> merged in.
> 

This is clearly insane. If I'm on <old> and want to sync with my 
upstream source that would be impossible without explicitly telling it 
*not* to merge with <new>. Iow, this change would (possibly) simplify 
for the one repo maintainer, but make things harder for the 30-odd 
developers.

-- 
Andreas Ericsson                   andreas.ericsson@op5.se
OP5 AB                             www.op5.se
Tel: +46 8-230225                  Fax: +46 8-230231

Re: Default remote branch for local branch

[Junio C Hamano]

Josef Weidendorfer <Josef.Weidendorfer@gmx.de> writes:

> On Sunday 02 April 2006 23:40, you wrote:
>> > Let me try to understand this: the general idea is that
>> >
>> >   pull.origin = [<refspec> of] <remote> for <branch>
>> >
>> > specifies the default action of git-pull if we are on <branch>, ie.
>> > a "git pull" then runs "git pull <remote> [<refspec>]".
>> 
>> Not quite.
>> 
>> It will be (if this were a serious proposal -- I am not
>> absolutely convinced this is a good idea) more like "git fetch
>> <remote>" followed by "git-merge HEAD the-refspec-named-there".
>
> So it is not really a <refspec>, but a <localbranch> which has to
> appear in the .git/remotes file on the right side of a refspec on
> a Pull line.

No, I meant <refspec> not <localbranch> here, because I do not
want to force people to have tracking local branch.  The call to
merge in pull that happens immediately after fetch does not use
localbranch, but uses what's recorded in FETCH_HEAD, and if we
were to do this change the above change would most likely to
affect how each remote branch heads fetched are marked for (or
not for) merges.

> All I wanted to remark is, that, with
>
>  URL: <remote-URL>
>  Pull: refs/head/master:refs/head/remote1
>  Pull: refs/head/other:refs/head/remote2
>
> the config
>
>  pull.origin = <remote> for refs/head/my-devel-for-remote2
>
> which does not use the [<refspec> of] part, always is bogus:
> We get remote1 merged into my-devel-for-remote2 on a git-pull,
> which is not what we want.

I think we are on the same page, if you just think of not having
[<refspec> of] a short-hand for naming the first Pull: line.

> Optionally, branching <new> off from <old> could add <new> as
> topic branch of <old>: Thus, if you are on <old> and do git-pull,
> you get <new> merged in.

I agree with Andreas on this part.

>> A bigger thing is that I am trying to avoid _requiring_ tracking
>> branches.
>
> I don't think you force anything when you add functionality to git-pull
> for the config discussed here. Nobody *has* to use this config - it's
> a porcelain thingie.

Not if you made the [<refspec> of] part <localbranch>.  Then
this configuration for default merge source per local branch
feature is available only to people who are willing to use
tracking branches.

>> If you are not micromanaging your subsystem 
>> maintainers, you should not have to care where they were the
>> last time you pulled from them....
>> [...why not needing to use tracking branches is good...]

>> If we are going require tracking branches,
>
> I do not understand. Why should we require this?

I forgot to say "on the other hand" before that "If".

>> we could do a bit 
>> more with them, like remembering where the tip was when we
>> fetched the last time (or the time before that...) and diff with
>> that, but the tracking branch heads are not set up to do things
>> like that right now -- they are single pointers.

Actually I think this part is independent and I did not have to
mention.  There is no point complicating only the tracking
branches at all.

I just wanted to mention that it would be handy to be able to
take snapshots of tracking branch heads, but it does not really
matter whether they are "your" local development branches or
tracking branches.  Just a nightly or on-demand

         d="$GIT_DIR/refs/snapshot/`date '+%Y-%m-%d'`" &&
         mkdir "$GIT_DIR/refs/snapshot/$d" &&
         tar Ccf "$GIT_DIR/refs/" - heads |
         tar Cxf "$d" -

would do, and then you should be able to ask "where was my
'master' head yesterday?".

Re: Default remote branch for local branch

[Josef Weidendorfer]

On Monday 03 April 2006 09:56, Andreas Ericsson wrote:
> Josef Weidendorfer wrote:
> > 
> > Optionally, branching <new> off from <old> could add <new> as
> > topic branch of <old>: Thus, if you are on <old> and do git-pull,
> > you get <new> merged in.
> > 
> 
> This is clearly insane. If I'm on <old> and want to sync with my 
> upstream source that would be impossible without explicitly telling it 
> *not* to merge with <new>. Iow, this change would (possibly) simplify 
> for the one repo maintainer, but make things harder for the 30-odd 
> developers.

Yes.
Therefore I put "optionally" above. But you are right, mixing up
"merge upstream" and "merge downstream" into one config option is insane.

Some idea independent but related:
I still think it is a better UI of a porcelain to try to note metainfo
automatically, ie. storing somewhere that we branched one off another.
What about adding "branch.topic" config option for this?
"git-branch -t newtopic"/"git-checkout -b newtopic -t"
would create a new topic branch, which is remembered in "branch.topic",
and "git-pull -t" merges these topic branches?
To specify that a remote branch is a topic branch of a given local
branch (to be pulled into with "git-pull -t"), we could add
"git-branch --add-topic <refspec>|<remoteURL>".

Josef

Re: Default remote branch for local branch

[Andreas Ericsson]

Josef Weidendorfer wrote:
> On Monday 03 April 2006 09:56, Andreas Ericsson wrote:
> 
>>Josef Weidendorfer wrote:
>>
>>>Optionally, branching <new> off from <old> could add <new> as
>>>topic branch of <old>: Thus, if you are on <old> and do git-pull,
>>>you get <new> merged in.
>>>
>>
>>This is clearly insane. If I'm on <old> and want to sync with my 
>>upstream source that would be impossible without explicitly telling it 
>>*not* to merge with <new>. Iow, this change would (possibly) simplify 
>>for the one repo maintainer, but make things harder for the 30-odd 
>>developers.
> 
> 
> Yes.
> Therefore I put "optionally" above. But you are right, mixing up
> "merge upstream" and "merge downstream" into one config option is insane.
> 
> Some idea independent but related:
> I still think it is a better UI of a porcelain to try to note metainfo
> automatically, ie. storing somewhere that we branched one off another.
> What about adding "branch.topic" config option for this?
> "git-branch -t newtopic"/"git-checkout -b newtopic -t"
> would create a new topic branch, which is remembered in "branch.topic",
> and "git-pull -t" merges these topic branches?
> To specify that a remote branch is a topic branch of a given local
> branch (to be pulled into with "git-pull -t"), we could add
> "git-branch --add-topic <refspec>|<remoteURL>".
> 

Sorry, but I still don't see the use of it. Usually, some topics mature 
faster than others, meaning I'd still have to do the old "git pull . 
this and that", leaving "the-other-one" to soak a bit longer. What 
you're suggesting would make the odd case easier while adding nothing 
for the normal flow.

For archeological purposes it might make some sense to record what the 
branch was named that you forked from, but to me it's more interesting 
to see which state the code was in when the code forked, and this is 
discernable by the merge-base command.

-- 
Andreas Ericsson                   andreas.ericsson@op5.se
OP5 AB                             www.op5.se
Tel: +46 8-230225                  Fax: +46 8-230231

Re: Default remote branch for local branch

[Josef Weidendorfer]

On Monday 03 April 2006 10:23, Junio C Hamano wrote:
> Josef Weidendorfer <Josef.Weidendorfer@gmx.de> writes:
> 
> > On Sunday 02 April 2006 23:40, you wrote:
> >> > Let me try to understand this: the general idea is that
> >> >
> >> >   pull.origin = [<refspec> of] <remote> for <branch>
> >> >
> >> > specifies the default action of git-pull if we are on <branch>, ie.
> >> > a "git pull" then runs "git pull <remote> [<refspec>]".
> >> 
> >> Not quite.
> >> 
> >> It will be (if this were a serious proposal -- I am not
> >> absolutely convinced this is a good idea) more like "git fetch
> >> <remote>" followed by "git-merge HEAD the-refspec-named-there".
> >
> > So it is not really a <refspec>, but a <localbranch> which has to
> > appear in the .git/remotes file on the right side of a refspec on
> > a Pull line.
> 
> No, I meant <refspec> not <localbranch> here, because I do not
> want to force people to have tracking local branch.

Oh, ok. I just had to look up the manual regarding refspecs when
pulling/fetching again: "<ref>" is the same as "<ref>:" and does
not create/use any local branch.

> > All I wanted to remark is, that, with
> >
> >  URL: <remote-URL>
> >  Pull: refs/head/master:refs/head/remote1
> >  Pull: refs/head/other:refs/head/remote2
> >
> > the config
> >
> >  pull.origin = <remote> for refs/head/my-devel-for-remote2
> >
> > which does not use the [<refspec> of] part, always is bogus:
> > We get remote1 merged into my-devel-for-remote2 on a git-pull,
> > which is not what we want.
> 
> I think we are on the same page, if you just think of not having
> [<refspec> of] a short-hand for naming the first Pull: line.

Yes, I understand this. But I do not think that such an optional
shortcut is useful for config files entries. It complicates parsing/editors,
and seems to make it more confusing. Despite, I agree that such optional
shortcuts are nice for porcelain command lines.

As I see the use of "<refspec> of <remote>", I still think that specifying
a local branch is useful, too. So what about

  pull.origin = (<refspec> of <remote> | <localbranch>) for <branch>	

instead? We can distinguish the two cases by looking for the "of".
When the <refspec> is of the form <src>:<dst> (where <dst> is the local
branch), we probably want to sanity check against .git/remotes/.

> > Optionally, branching <new> off from <old> could add <new> as
> > topic branch of <old>: Thus, if you are on <old> and do git-pull,
> > you get <new> merged in.
> 
> I agree with Andreas on this part.

Yup. If we want to support topic branches with defaults, we should use
another config option. And now, I am not convinced about the usefulness
of this any more.

> Not if you made the [<refspec> of] part <localbranch>.  Then
> this configuration for default merge source per local branch
> feature is available only to people who are willing to use
> tracking branches.

Yes, I understand this now.

> I just wanted to mention that it would be handy to be able to
> take snapshots of tracking branch heads, but it does not really
> matter whether they are "your" local development branches or
> tracking branches.  Just a nightly or on-demand
> 
>          d="$GIT_DIR/refs/snapshot/`date '+%Y-%m-%d'`" &&
>          mkdir "$GIT_DIR/refs/snapshot/$d" &&
>          tar Ccf "$GIT_DIR/refs/" - heads |
>          tar Cxf "$d" 

Wow. For this, versioning of the /refs directory as subproject
would be good ;-)

Josef

Re: Default remote branch for local branch

[Petr Baudis]

Dear diary, on Sun, Apr 02, 2006 at 06:17:29PM CEST, I got a letter
where Josef Weidendorfer <Josef.Weidendorfer@gmx.de> said that...
> > I would write the config like this:
> > 
> > [branch-upstream]
> > master = linus
> > ata-irq-pio = irq-pio
> > ata-pata = pata-drivers
> 
> That is not working, as said above. But with above syntax extension,
> with s/=/for/ it would be fine.

I'm sorry but I'm slow and I don't see it - why wouldn't this work?
(Except that the key name is case insensitive, which isn't too big a
deal IMHO.)

I for one think that the 'for'-syntax is insane - it's unreadable (your
primary query is by far most likely to be "what's the upstream when on
branch X", not "what branches is this upstream for"), would convolute
the configuration file syntax unnecessarily and would possibly also
complicate the git-repo-config interface. Pavel's syntax is much nicer.

-- 
				Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
Right now I am having amnesia and deja-vu at the same time.  I think
I have forgotten this before.

Re: Default remote branch for local branch

[Josef Weidendorfer]

On Friday 14 April 2006 18:16, you wrote:
> Dear diary, on Sun, Apr 02, 2006 at 06:17:29PM CEST, I got a letter
> where Josef Weidendorfer <Josef.Weidendorfer@gmx.de> said that...
> > > I would write the config like this:
> > > 
> > > [branch-upstream]
> > > master = linus
> > > ata-irq-pio = irq-pio
> > > ata-pata = pata-drivers
> > 
> > That is not working, as said above. But with above syntax extension,
> > with s/=/for/ it would be fine.
> 
> I'm sorry but I'm slow and I don't see it - why wouldn't this work?
> (Except that the key name is case insensitive, which isn't too big a
> deal IMHO.)

Hmm...
* IMHO "keys are case insensitive" is enough to not qualify for branch
names: currently, branch names are case sensitive, and with above syntax you
effectively change this rule (you can not distinguish upstreams for "master"
vs. "MASTER").
* a dot currently seems to be allowed in branch names. For config keys, the
dot separates subkeys.
* I thought it is a convention for config keys to be alphanum only,
eg. "/" isn't allowed, too (which is mandatory for branch names).
Unfortunately, I found nothing about allowed chars for config keys in the
documentation.
 
> I for one think that the 'for'-syntax is insane - it's unreadable (your
> primary query is by far most likely to be "what's the upstream when on
> branch X", not "what branches is this upstream for"), would convolute
> the configuration file syntax unnecessarily and would possibly also
> complicate the git-repo-config interface.

As far as I remember, the "... for ..." syntax was suggested by Linus for the
proxy.command config a long time ago. The original proposal there was to
use an URL as key part (as far as I can remember).

That said,

> Pavel's syntax is much nicer. 

... I agree with you here.

My suggestion would be to allow an optional syntax in the config file which is mapped
by git-repo-config to the normalized "... for ..."-scheme.
Eg. it should not be mandatory to specify "for ..." after the value of a key.
So instead of

  branch.upstream = linus for master

you should be able to say

  [branch]
  upstream for master = linus


Josef