Re: git bug? + question

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

Karl Hasselström [off-list ref] writes:

quoted

On 2006-11-02 18:40:30 -0800, Junio C Hamano wrote:

quoted

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