Cc: Andreas Ericsson <ae@...>, Johannes Schindelin <Johannes.Schindelin@...>, Jakub Narebski <jnareb@...>, Federico Mena Quintero <federico@...>, <git@...>
On Oct 24, 2007, at 10:33 PM, J. Bruce Fields wrote:
Personally, I don't dare to work that way. But if you do want
to keep local changes on branches that would normally be pushed
but you do not want to push them now, you must not call "git
push" without arguments in the first place. Then you'll never
see the error emitted by push.
I put local changes that I do not intend to change right away
on a special branch for/<branch>. I only merge them to <branch>
if I decided to push them, and then I push them soon (maybe
after I prepared more branches and then push all at once).
Well, as I wrote above "git push" is a too sharp knife for
me. I _never_ have local changes that I don't intend to push.
So "git push" always does the right thing for me.
I see your point. These are may requirements to make the
proposed behaviour of "git pull" useful. But I'd recommend to
use git exactly as you described when working with a shared
repository:
Just use "git pull" and "git push" and everything will be fine
if you work as follows:
- Use the same branch names that are used on the origin.
- Only check out branches locally that you are especially interested in.
- Only put changes on those branches if you intend to push them.
- Use "git pull" before you start to prepare branches for
"git push".
- Keep you privat work on branches that are named differently
from branches in the shared repository.
Steffen
-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html