Re: git bug? + question

From: Karl Hasselström <kha@treskal.com>
Date: Nov 3, 2006, 09:46 UTC
Message-ID: <20061103094655.GA16721@diana.vm.bytemark.co.uk>
In-Reply-To: <7v3b90gbfv.fsf@assigned-by-dhcp.cox.net>

On 2006-11-03 00:51:32 -0800, Junio C Hamano wrote:

Show 35 quoted lines

> Karl Hasselström <kha@treskal.com> writes:
>
> > On 2006-11-02 18:40:30 -0800, Junio C Hamano wrote:
> >
> > > I still need to remember to process "master" first, so all
> > > things considered, this is a regression in usability for my
> > > workflow.
> >
> > Where does this constraint come from?
>
> Because I'll have to have the per-branch configuration that would
> say something like this:
>
>       [remote."gitster"]
>               url = gitster.example.com:/home/junio/git.git/
>               fetch = heads/maint:remotes/gitster/maint
>               fetch = heads/master:remotes/gitster/master
>               fetch = heads/next:remotes/gitster/next
>               fetch = +heads/pu:remotes/gitster/pu
>
>       [branch."master"]
>               remote = gitster
>               merge = heads/master
>       [branch."maint"]
>               remote = .
>               merge = remotes/gitster/maint
>       [branch."next"]
>               remote = .
>               merge = remotes/gitster/next
>       ...
>
> This requires that by the time we update maint, next and pu branches
> with what is in the upstream, their corresponding remotes/gitster/*
> branches are already up-to-date and do not have to be re-fetched,
> and processing master first is what guarantees it.

Ahh, here is where our workflows differ: I would want to have "remote = ." for all the branches, and use "git fetch" to update the remotes. (I guess this is only natural; my workflow requires less state in the head of the user, and so is easier for beginners, while yours is slightly more efficient in terms of number of commands that have to be given.)

Hmm. How about changing the meaning of "remote" slightly? Like this:

      [remote."gitster"]
              url = gitster.example.com:/home/junio/git.git/
              fetch = heads/master:remotes/gitster/master
              fetch = heads/next:remotes/gitster/next
      [branch."master"]
              remote = gitster
              merge = remotes/gitster/master
      [branch."next"]
              remote = gitster
              merge = remotes/gitster/next

This would mean: When the user says "git pull" in master, use the remote gitster to fetch updates to remotes/gitster/master, then merge remotes/gitster/master into master.

With this scheme, "git pull" would never fetch any other branches than those about to be merged; to fetch more in one go, use "git fetch".

I realize this would break existing configs quite badly, so don't take it too seriously.

-- 
Karl Hasselström, kha@treskal.com