Re: push.default???

Miles Bader [off-list ref] writes:

Junio C Hamano [off-list ref] writes:

quoted

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.