Re: best git practices, was Re: Git User's Survey 2007 unfinished summary continued

From: Steffen Prohaska <prohaska@zib.de>
Date: Oct 24, 2007, 21:16 UTC
Message-ID: <AF6B550F-99FB-4F65-BA07-662AD590D070@zib.de>
In-Reply-To: <20071024203335.GJ29830@fieldses.org>

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

Show 19 quoted lines

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

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

Show 7 quoted lines

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