Re: push.default???

From: Junio C Hamano <gitster@pobox.com>
Date: Jun 24, 2009, 06:35 UTC
Message-ID: <7vbpoe16lv.fsf@alter.siamese.dyndns.org>
In-Reply-To: <buoljniyybp.fsf@dhlpc061.dev.necel.com>

Miles Bader <miles@gnu.org> writes:

Show 14 quoted lines

> Junio C Hamano <gitster@pobox.com> writes:
>> 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.
>
> You seem to be making a lot of assumptions about workflows here.
>
> It seems quite plausible to me that one might want to keep the remote
> branch separate, even after pushing.  It's very common to cooperatively
> develop feature branches for a very long time before merging to the
> "real" master, but it's still extremely useful to keep them as branches
> in the same local git directory.

Sorry, but I do not understand your point.

My "feature is cooked, let's test it together with master" does not mean "Now we are done with the feature, so let's 'branch -d' it" at all. That is an orthogonal issue. You can keep 'feature' in the local repository indefinitely.

Keeping the remote branch separate means pushing 'feature' to 'feature', and keep it there. I do not have any problem with that, either.

The '--track' I was having hard time justifying to myself was about pushing 'feature' (and other features 'feature2', 'feature3',... that are all forked from 'master' at the remote side) to 'master' at remote. In other words, the workflow being discussed to support why --track was a good mode was about updating the remote 'master', not about keeping the branches separate.

Either you are not following the thread, or you are agreeing with me without realizing, or perhaps a bit of both.