From: Steffen Prohaska Date: Wed, 24 Oct 2007 22:51:09 GMT Subject: Re: best git practices, was Re: Git User's Survey 2007 unfinished summary continued Message-ID: In-Reply-To: <20071024223815.GN29830@fieldses.org> On Oct 25, 2007, at 12:38 AM, J. Bruce Fields wrote: > On Thu, Oct 25, 2007 at 12:33:37AM +0200, Steffen Prohaska wrote: >> Maybe. I know git quite well now and in a shared workflow "git pull" >> with auto-fast-forward would help me. I often need to run "for each >> local branch: git checkout ; git merge" to get rid of the errors >> reported by "git push". > > Hm. There's gotta be more efficient ways to do that. Maybe "git > push . > origin/branch:branch" for each local "branch"? > > But I'm still a little confused why you don't just want to "git push > name-of-branch" and avoid the whole problem. There are two points: - The current implementation of "git push" creates a remote branch if it does not yet exist. I want a safety net: "git push" only pushes if the remote branch already exists. In a sense "git push" is safer than "git push branch-with-typo". I use "git push branchname" exclusively for _creating_ new branches on the remote. - Sometimes I updated two local branches and want to push. "git push" just works. I started to believe that "git push" should always do the right thing. Maybe it is not possible, but actually "git push" always does the right thing for me if I ignore the error messages about local branches that need merging. I tend to merge all such branches right away, although it is a bit of a hassel. Otherwise, there will be a day I'll miss an important error. What concerns me more is how to explain the behaviour to others. Right now, I can't tell them that "git push" just works but need to go into a lot of details. Steffen