On Feb 9, 2008, at 3:46 AM, Jeff King wrote:
Another way to "solve" this issue, of course, is to use the
remote layout.
I did the switchover myself some time ago; it was hard at first,
since I
was so used to just check out the branches I just fetched. But
in the
long run the distinction between local and tracking branches made
life
much easier for me.
What do you mean with "the remote layout"? I am using
"remotes"+tracking branches as far as I can tell...
I think he means something like "if I have 'next' and 'origin/next',
then I should check whether 'next' is a subset of 'origin/next'" and
just say "nothing to send." But that suffers from the same "silently
ignoring rewinds" as above. You could ignore the push if you have
next exactly equal to origin/next, but that implies that you
haven't done
any fetching (which is unlikely in the scenario you described).
A similar proposal was discussed last October/November and we
already had patches. We decided against it. The reason is
that the post-condition of "git push" is that all heads that
are considered by the push shall be identical locally and
at the remote. If "git push" does not achieve this it should
report the branches for which the post-condition is not met.
I think Dscho means: do not duplicate remote branches as local
branches. Keep the number of local branches as low as possible.
Only if you want to work on a remote branch, create a local
branch, commit you work, push, and *delete* the local branch.
However, I often use local branches as a reminder which remote
branches I am actively monitoring. If I start to work on them
I first review what's new with "gitk origin/topic --not topic"
and then do the fast forward "git push . origin/topic:topic"
before I actually start working "git checkout topic". For
these branches, Dschos proposal does not work for me.
Steffen
-
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
