You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@trafficserver.apache.org by Leif Hedstrom <zw...@apache.org> on 2015/08/07 05:03:50 UTC

[GIT] Yes, git pull --rebase is my friend

Hi all,

gentle reminder for everyone. And this is important, to not get all these incredibly ugly merge commits over and over again (which also makes RM’ing much harder to find the necessary back port commits):

1) Always run git pull —rebase before pushing upstream. It can almost always (some branching shenanigans in git excluded) be run anytime before, after and during merging and pushes.

2) Particularly important, and we’ve said this before: Always, I mean *always* run “git pull —rebase” after you’ve merged a github pull request into your local repository. This is covered by #1 above anyways, but is worth repeating. If you *don’t* do this, the commit message loses out the information about who actually did the commit on behalf to the author. This loses out when we (sometimes) need to see who did what.


Yes, I’m definitely no git expert, and likely I’ve got things messed up myself. But I find that “git pull —rebase” really makes things a lot nicer upstream. If anyone else have better tips and best practices, please share. If I’m wrong about using “git pull —rebase”, please educate me too.

Thanks,

— Leif

P.s

I put this in my .gitconfig:

	pr = pull —rebase


which then lets me run simply “git pr”.

Re: [GIT] Yes, git pull --rebase is my friend

Posted by Leif Hedstrom <zw...@apache.org>.
> On Aug 7, 2015, at 9:35 AM, James Peach <jp...@apache.org> wrote:
> 
> 
>> On Aug 6, 2015, at 8:03 PM, Leif Hedstrom <zw...@apache.org> wrote:
>> 
>> Hi all,
>> 
>> gentle reminder for everyone. And this is important, to not get all these incredibly ugly merge commits
> 
> Let's get Infra to install a git hook to reject merge commits on master.


+1.

I submitted a proposal for the Summit to have a discussion / tutorial on Git. Maybe we can collect our wish list, and proposals, there, and bring to Infra? I think it’d be difficult to get them to do something without either solid background information or implementation details. At least that’s the impression I get.

— leif


Re: [GIT] Yes, git pull --rebase is my friend

Posted by James Peach <jp...@apache.org>.
> On Aug 6, 2015, at 8:03 PM, Leif Hedstrom <zw...@apache.org> wrote:
> 
> Hi all,
> 
> gentle reminder for everyone. And this is important, to not get all these incredibly ugly merge commits

Let's get Infra to install a git hook to reject merge commits on master.

> over and over again (which also makes RM’ing much harder to find the necessary back port commits):
> 
> 1) Always run git pull —rebase before pushing upstream. It can almost always (some branching shenanigans in git excluded) be run anytime before, after and during merging and pushes.
> 
> 2) Particularly important, and we’ve said this before: Always, I mean *always* run “git pull —rebase” after you’ve merged a github pull request into your local repository. This is covered by #1 above anyways, but is worth repeating. If you *don’t* do this, the commit message loses out the information about who actually did the commit on behalf to the author. This loses out when we (sometimes) need to see who did what.
> 
> 
> Yes, I’m definitely no git expert, and likely I’ve got things messed up myself. But I find that “git pull —rebase” really makes things a lot nicer upstream. If anyone else have better tips and best practices, please share. If I’m wrong about using “git pull —rebase”, please educate me too.
> 
> Thanks,
> 
> — Leif
> 
> P.s
> 
> I put this in my .gitconfig:
> 
> 	pr = pull —rebase
> 
> 
> which then lets me run simply “git pr”.


Re: [GIT] Yes, git pull --rebase is my friend

Posted by Leif Hedstrom <zw...@apache.org>.
> On Aug 6, 2015, at 9:03 PM, Leif Hedstrom <zw...@apache.org> wrote:
> 
> Hi all,
> 
> gentle reminder for everyone. And this is important, to not get all these incredibly ugly merge commits over and over again (which also makes RM’ing much harder to find the necessary back port commits):


Not directly related to this, but someone sent this to another mailing list, and it’s pretty good advice (re: git commit messages):

	http://chris.beams.io/posts/git-commit/



We should discuss here (and at the summit), but adopting something like this might help as well.

Cheers,

— Leif

P.s
   Thanks Ask :-).