On 2006-11-03 00:51:32 -0800, Junio C Hamano wrote:
> Karl Hasselström <kha@xxxxxxxxxxx> 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@xxxxxxxxxxx
www.treskal.com/kalle
-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html