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