Re: git bug? + question

Karl Hasselström <kha@treskal.com> writes:

    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.