On Oct 24, 2007, at 10:33 PM, J. Bruce Fields wrote:

quoted text
> On Wed, Oct 24, 2007 at 10:12:29PM +0200, Steffen Prohaska wrote:
>> On Oct 24, 2007, at 9:48 PM, J. Bruce Fields wrote:
>>
>>>
>>>> I want git pull to work like git push.
>>>
>>> That strikes me as a less complete solution, since it only helps  
>>> in the
>>> case where the other branches all happen to be unmodified locally  
>>> (hence
>>> can be fast-forwarded).  In other cases the "git push" will still  
>>> emit a
>>> spurious error.
>>
>> Well, but then there's something you should really think
>> about.
>
> Perhaps, but not necessarily; you may have some branches with local
> changes that you're content to leave unpushed (and un-updated).

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).


quoted text
> So the case where this proposal helps is the case where:
> 	- the user hasn't learned how to name individual branches on the
> 	  push commandline, or has learned to do so, but wants less
> 	  typing, and

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.


quoted text
> 	- the user has one or more unmodified copies of remote branches
> 	  lying around, and
> 	- the user minds being reminded that those copies are out of
> 	  date, and
> 	- the user either has no *modified* copies of local branches, or
> 	  has some but doesn't mind being reminded that they're out of
> 	  date on each push.

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