Paolo Bonzini <paolo.bonzini@xxxxxxxxx> writes:
>> If a group sets up a shared public branch, it is typically for
>> working together on some feature.
>>
>> For people used to CVS, this is a nice way to start working with git.
>> It requires --tracking to work properly though (--current only works
>> if you remember to use the same branch name).
>
> Ok, this *is* a usecase. Your local branch is named as a feature but
> it pushes into master. Thanks, I have something to reason about now.
> :-)
I actually have been having a hard time imagining how such a set-up makes
sense, even during your absense (i.e. the timeframe we did push.default).
You are forking off of shared 'master', but you are developing a feature
on a separate branch 'feature'.
That is a sane thing to do for two reasons. (1) Until 'feature' is done
to your own satisfaction, you do not want to contaminate your own 'master'
with the half-cooked feature development in it. (2) While you are working
on 'feature', you may want to update your own 'master' from the shared
repository to monitor how others are doing. Having a separate, pristine
'master' branch allows you to do so more easily, than detaching HEAD at
'origin/master' every once in a while.
However, when 'feature' is fully cooked, before pushing it back to be
shared with others in the group, don't you do any testing with the work
done by others while you were working on 'feature'? That means you first
integrate your 'feature' locally into shared 'master' and make sure all
fits together well.
Until you do that, you cannot be confident that the feature you developed
is fit for public consumption. But if you test after merging 'feature'
into 'master', what you determined as good is in 'master', which you can
push back to the remote's 'master'.
One glitch I can think of is what would happen if you do not want to merge
your feature for final testing to master, but instead rebase your feature
on top of master (let's not discuss why you should or should not rebase at
this point; some projects seem to insist you rebase and there may be no
good technical reason but that is not the topic here). There currently is
no easy UI other than:
$ git checkout master
$ git pull --rebase . feature
$ test test test
$ git push origin master
or even worse:
$ git checkout feature
$ git rebase master
$ git checkout master
$ git merge feature
$ test test test
$ git push origin master
to tell git to integrate your local work done in 'feature' to 'master' by
rebasing, instead of merging. If you do a merge, that is quite
straightforward:
$ git checkout master
$ git merge feature
$ test test test
$ git push origin master
but instead you have to do something like:
$ git checkout feature
$ git rebase master
$ test test test
$ git push origin feature:master
and you end up needing "put my 'feature' into their 'master'".
Could it be possible that this desire to push "tracking" is not a cure for
anything real, but merely a kludge to work around a misfeature of "rebase"
UI that does not allow "integrate that branch here but do not merge it but
by first rebasing it"? In other words, if we had "git merge --rebase" (I
know, I know, it is a terrible name. The word "merge" in this context
means "to integrate"), the above can be done more naturally:
$ git checkout master
$ git merge --rebase feature
$ test test test
$ git push origin master
and the matching push (or "git push origin HEAD") becomes the right thing
to do, eliminating the need for "put my 'feature' into their 'master'".
For a group that sets up a shared public branch to be used for working
together on some feature, replace 'master' with 'some feature' above, and
'feature' with 'your part of the work on the feature'; the story is the
same.
--
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