Re: git bug? + question

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

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?

    With separate remotes, I'd need something like:

            for b in master maint next pu
            do
                    git checkout $b && git pull && make || break
            done

    And I also would need to have per-branch configuration to merge
    from ". remotes/origin/$b" without re-fetching while on a
    non-master branch $b, for the above to work.  I still need to
    remember to process "master" first, so all things considered,
    this is a regression in usability for my workflow.

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
	...

Side note: the above would not actually work because I am
missing an earlier patch by Santi to special case 'dot' as the
value of "branch.$name.remote", but I think you get the idea.

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.

I do not mind treating "master" specially at all; my otherwise
idle repositories with working tree (read: ones on secondary
machines I use primarily to build git binary for that machine or
that platform, not to develop on) always have "master" checked
out; I start working in them while "master" is checked out, and
I'll be on "master" before I leave that machine.

If I keep using the traditional layout, where master is fetched
to origin and next, maint and pu are used to track the remote, I
do not have to do any of the above remote/branch configuration
in the .git/config file, and after one "git pull" while on
"master", I'd have all four branches up to date, ready to be
checked out and compiled.

But I suspect this "following multiple branches at the same
time, switch between them only to compile, test and install but
never develop on them" workflow is rather specific to top-level
maintainer's workflow and that is why I said defaulting to
separate-remote would be an inconvenience to a minority.