www-infrastructure-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Daniel Shahaf <...@daniel.shahaf.name>
Subject Re: [1/2] git commit: f92a685 -
Date Wed, 06 Jun 2012 12:01:05 GMT
Mark Struberg wrote on Wed, Jun 06, 2012 at 06:38:37 +0100:
> this is basically the same like git pull --rebase, isn't?
> 

Perhaps it removes the need to pass --rebase on every 'git pull'..

Daniel

> This is most times fine, but be careful as it can cause history rewriting.
> 
> What we usually do is documented in our Wiki:
> 
> https://cwiki.apache.org/confluence/display/DeltaSpike/Suggested+Git+Workflows
> (section 'working on an own branch')
> 
> History rewriting should be disabled in any sane upstream git repo 
> anyway (at least on the 'master' branch via gitolite). In that case you 
> could do a git reset --hard to reset your HEAD and apply your changes 
> again. As you have all the changes in the other branch it's also much easier to mess
around with history, even squashing commits and getting rid of unneeded cruft with git rebase
--interactive, etc
> 
> LieGrue,
> strub
> 
> 
> 
> ----- Original Message -----
> > From: Brett Porter <brett@apache.org>
> > To: infrastructure-dev@apache.org; Joe Schaefer <joe_schaefer@yahoo.com>
> > Cc: "joes@apache.org" <joes@apache.org>; Sam Ruby <rubys@apache.org>
> > Sent: Wednesday, June 6, 2012 2:08 AM
> > Subject: Re: [1/2] git commit: f92a685 -
> > 
> > 
> > On 06/06/2012, at 4:51 AM, Joe Schaefer wrote:
> > 
> >>  Merge commits do peculiar things- part of what happened
> >>  is that I committed my change locally first, then pulled
> >>  to sync up with the central repo, then pushed back.  Somehow
> >>  history gets reordered and that is supposed to be reflected
> >>  in these merge commit notices.
> > 
> > Nothing peculiar here, though it can be a bit hard to grok from the mails at 
> > first look. I actually prefer these notifications to github's approach of 
> > showing you the diffs of the merge commits all over again, though. 
> > 
> > The common ancestor of the changes was 33cc902, the rev Joe had as HEAD when he

> > made his changes. What is shown here are the files changed by 4 commits on 
> > origin that were merged in to Joe's copy when he pulled the changes. History 
> > wasn't reordered, it just runs in parallel to each other :)
> > 
> > Joe, you probably want this if you use git pull:
> > 
> >   git config branch.master.rebase true
> > 
> > That makes it the equivalent of "git fetch origin; git rebase 
> > origin/master" instead of fetch and merge, so your changes will be 
> > rewritten against the latest commit and the merge commit omitted.
> > 
> > To ensure that is set up on any new repositories cloned:
> > 
> >   git config --global branch.autosetuprebase always
> > 
> > Cheers,
> > Brett
> > 
> > --
> > Brett Porter
> > brett@apache.org
> > http://brettporter.wordpress.com/
> > http://au.linkedin.com/in/brettporter
> > http://twitter.com/brettporter
> >

Mime
View raw message