Branch relationships (was:Re: git diff: support "-U" and "--unified" options properly)

From: Josef Weidendorfer <josef.weidendorfer@gmx.de>
Date: May 14, 2006, 20:49 UTC
Message-ID: <200605142249.17508.Josef.Weidendorfer@gmx.de>
In-Reply-To: <7v7j4o33wc.fsf@assigned-by-dhcp.cox.net>

On Sunday 14 May 2006 19:36, Junio C Hamano wrote:

Show 7 quoted lines

> Josef Weidendorfer <Josef.Weidendorfer@gmx.de> writes:
> 
> > On Saturday 13 May 2006 23:22, you wrote:
> >>  * remotes/ information from .git/config (js/fetchconfig)
> >> ...
> >>    [branch "master"]
> >> 	remote = "ko-private"

I still do not understand the semantic of this line. Is this supposed to do "git pull ko-private" as default pull action and "git push ko-private" as default push?

So using

Show 6 quoted lines

>   ; my private build areas on the kernel.org machines
>    [remote "ko-private"]
>         url = "x86-64-build.kernel.org:git"
>         url = "i386-build.kernel.org:git"
>         push = master:origin
> ...

specifies that "git push" should push to both URLs? This is really confusing: Is the remote "ko-private" now at "x86-64-build.kernel.org:git" or at "i386-build.kernel.org:git" ?

Probably its better to have
  [branch "master"]
    push-remote = "ko-private-x86-64 ko-private-i386"
and entries for 2 remotes.

Neverless, I missed the info "Which branch should be merged in a default pull after fetching the given branches from remote". I understand that this is not needed in your workflow, as you have no upstream.

Show 8 quoted lines

> >  [branch "ko-master"]
> >     tracksremote = "master of ko-private"
> >
> > This also would specify that we are not allowed to commit on "ko-master".
> 
> For my workflow, it is "master of ko"; your notation expresses
> the same constraints more explicitly by being more special
> purpose

Why is this more special purpose? IMHO the only difference is that your proposal puts this information into the remote, and I am putting it to the branch as attribute.

I chose it this way because I always thought that the Pull-lines in .git/remotes where only about giving a default fetch action, ie. they are optionally. But even if I do not want to have a remote branch fetched on default, I want to put the information "XXX of remote RRR is the upstream of local YYY" into some place to be able to do a pull when on that branch.

Show 8 quoted lines

> : "This tracks that one so never touch it any way other 
> than fetching into it" (we may not even allow checking out
> "ko-master" -- I dunno).  
> 
> One issue you might want to think about is it is far more
> efficient to fetch multiple branches from the same git://... URL
> is than fetching them one by one.  The push has exactly the same
> property.

Perhaps an option "when pulling into this branch from a remote, also fetch all branches tracked from this remote", or another one "when fetching/pulling into this branch, update all other branches, too".

> Another thing is the above talks only about constraints, and the
> user has to go all over the config file to find "xxx to
> ko-private" in order to figure out what happens when he says
> "pull ko-private".

I wasn't intending to change the current semantics of the remote section, which specifies what to do when pulling/fetching/pushing from/into this remote.

But you are right; this could get inconsistent. Better find a way to not be able to specify an inconsistent config in the first place.

However, such an inconsistent config is already possible today:

 [remote "r1"]
    fetch = master:master
 [remote "r2"]
    fetch = master:master

This is not really better than

 [branch "master"]
    tracksremote "master of r1"
 [remote "r1"]
    fetch = "notmaster:master"

We already print out a warning when updating a branch tracking a remote is not a fast-forward. So I would leave it as it is, and allow both ways.

This all would be mood if we use refs/remotes consequently: existance of a branch "refs/remotes/r1/master" implicitly specifies that this is a branch tracking a remote, where the remote is named "r1" and the remote branch is "master".

With

 [core]
   useSeparateRemote ; bool

 [r1]
   url = ...
   fetch = master branch2 branch3

a "git fetch r1" would track given remote branches in "remotes/r1/<branch>", and a

 [branch "master"]
   origin = "remotes/r1/master"

would work even without the "fetch" line in the remote section. Here, we can allow both ways without getting inconsistent, as we implicitly have

 [branch "remotes/r1/master"]
   tracksremote = "master of r1"

Regarding syntax: Instead of the "... of ..." values I would prefer two keys "remotebranch"/"remote".

Josef