Re: best git practices, was Re: Git User's Survey 2007 unfinished summary continued
- From
Steffen Prohaska <prohaska@zib.de>
- Date
- Oct 25, 2007, 12:04 UTC
- Message-ID
- <8C2ADF84-2E35-46D3-B894-68341CF26A81@zib.de>
- In-Reply-To
- <Pine.LNX.4.64.0710251117310.25221@racer.site>
On Oct 25, 2007, at 12:27 PM, Johannes Schindelin wrote:
Show 9 quoted lines
> Hi, > > On Thu, 25 Oct 2007, Steffen Prohaska wrote: > >> On Oct 25, 2007, at 1:28 AM, Johannes Schindelin wrote: >> >>> On Thu, 25 Oct 2007, Steffen Prohaska wrote: >>> >>>> On Oct 25, 2007, at 12:14 AM, Johannes Schindelin wrote:
[...]
Show 20 quoted lines
>>>>> But here is a proposal which should make you and your developers >>>>> happy, _and_ should be even easier to explain: >>>>> >>>>> Work with topic branches. And when you're done, delete them. >>>> >>>> Again, if you want to share the topic branch the situation gets >>>> more >>>> complex. >>> >>> Hardly so. In my proposed solution to your problem, there is >>> nothing >>> which prevents you from working off of another branch than "master". >> >> Well if you have several local branches checked out that are >> shared with others you run into the "git push" problem again ... >> (see below at git push origin master). > > Do the same as I, always say "git push origin master" (of course, you > should exchange "master" with whatever branch you want to push). Be > precise.
Well, I'm lazy. git already knows everything. It knows that the current branch is associated with a specific remote and it pushes matching branches by default. And I took care to not pollute the namespace. All my branches are named identical in all repositories I'm dealing with. It's reasonable to want "git push" to do the right thing.
Show 31 quoted lines
>>>>> So the beginning of the day could look like this: >>>>> >>>>> git fetch >>>>> git checkout -b todays-topic origin/master >>>>> >>>>> [hack hack hack] >>>>> [test test test] >>>>> [debug debug debug] >>>>> [occasionally commit] >>>>> [occasionally git rebase -i origin/master] >>>>> >>>>> and the end of the topic >>>>> >>>>> git branch -M master >> >> Isn't this a bit dangerous? It forces to overwrite master no matter >> what's on it. You don't see diffstats nor a fast forward message that >> confirms what you're doing. > > Yeah, I should have said something like "git branch -m master" > (implicitely assuming that you have no current "master" branch). > >>>>> git push origin master >> >> I'd like to see "git push" here. > > I think it is not asking too much for the user to be a bit more > precise. > If you really do not trust your developers to be capable of that, > point > them to git gui.
Well I was more precise and got lazy over time. Now the most I do is "git push --dry-run" and if it looks good I do "git push". Most of the time I just say "git push".
As I pointed out earlier, "git push origin <some-branch>" can create a new branch on the remote. "git push" never creates a new branch. I believe "git push" is safer.
Show 9 quoted lines
>> git branch -m <shared_branch>
>> git push origin <shared_branch>
>> git checkout do-not-work-here
>> git branch -D <shared_branch>
>
> Actually, the last two commands would better be
>
> git checkout HEAD^{commit}
> git branch -d <shared_branch>Wow, looks weird (not too me but to someone who doesn't know git).
Show 12 quoted lines
>>> The problem I see here: you know git quite well. Others don't, and >>> will be mightily confused why pull updates local branches sometimes, >>> and sometimes not. >> >> But it already happens now. "git pull" sometimes merges a remote >> branch >> (--track) and sometimes it reports an error that is fails to do so >> (--no-track). > > If there really is an inconsistent behaviour, then we'll have to > fix that. > We should not introduce inconsistent behaviour on top of that.
It's not inconsistent. It's an option of a branch. Git supports two flavours of local branches. Some branches automatically merge and other don't.
Steffen