From: Damien R. <dr...@ma...> - 2014-03-29 14:05:14
Attachments:
spaghetti-history.png
|
Hi all, As much as I love pasta, I'd rather avoid having our Git history look like a plate of spaghetti, and keep it as linear as possible instead ;-) Grangeway's recent series of merge commits is a typical example of what I strongly believe we should try to avoid. Just have a look at the attached screenshot, and I'm sure you'll agree... When merging pull requests, especially for older branches, please follow these guidelines: 1. Rebase your branch on top of the latest git HEAD git fetch origin git rebase master FeatureBranch Resolve conflicts when you rebase, and don't forget to re-test the code if there were any. 2a. Merge the branch manually git checkout master git merge --no-ff FeatureBranch The --no-ff flag forces the creation of a merge commit, so that the individual commits in the branch stand out as a unit. This makes future maintenance and searches through history easier. Notes: - this is exactly what Github does when you click the "Merge Pull Request" button. - if the branch has a single commit, then the --no-ff flag is not necessary and should not be used (consequently, we should merge manually instead of using the Github button for such pull requests). Attention: make sure to provide a descriptive merge commit message In other words, do *not* keep the Git default text like "Merge branch 'variable-naming' of https://github.com/grangeway/mantisbt into grangeway-variable-naming". These messages are essentially useless, as they do not provide any useful information regarding what the merged branch was about. Instead, briefly describe what the purpose of the branch was, and reference the Github pull request and/or Mantis issue(s) Id. Note: if I'm not mistaken, when you merge from Github, this text is taken from the pull request's subject and description (1st comment). 2b. Merge the pull request from Github As an alternative to 2a, after rebasing (step 1) you can simply force push the rebased branch to your Github fork. git push -f YourFork FeatureBranch The pull request will be automatically updated, and then you can simply click the "Merge pull request" button in Github. For reference, here are a couple of examples of what I consider "good" merge commits: - Manual merge with custom commit message https://github.com/mantisbt/mantisbt/commit/b5194d98fd - Merge from Github https://github.com/mantisbt/mantisbt/commit/e3ed007f3d Of course in the case of a complex branch, especially one where merges *from* master have taken place, it may be too difficult / not worth the effort to rebase, in which case a "normal" merge is acceptable. However we should try to keep these at a minimum to avoid cluttering the history. Thanks for your understanding and consideration. Damien PS: I'll add this to the wiki and/or the developer's guide later as time allows. |
From: P R. <pa...@ma...> - 2014-03-29 14:17:14
|
The steps I followed were the procedure github said to follow to "merge the patch manually through their system" - personally, I generally preferred to rebase commits for the reasons you describe. Really, I'd prefer us to have our processes based around git itself, and not around 'github'. It should be possible for us to handle a pull request from any git remote from any source with a standard method. Paul -----Original Message----- From: Damien Regad [mailto:dr...@ma...] Sent: 29 March 2014 14:05 To: Man...@li... Subject: [mantisbt-dev] Git "Spaghetti" history Hi all, As much as I love pasta, I'd rather avoid having our Git history look like a plate of spaghetti, and keep it as linear as possible instead ;-) Grangeway's recent series of merge commits is a typical example of what I strongly believe we should try to avoid. Just have a look at the attached screenshot, and I'm sure you'll agree... When merging pull requests, especially for older branches, please follow these guidelines: 1. Rebase your branch on top of the latest git HEAD git fetch origin git rebase master FeatureBranch Resolve conflicts when you rebase, and don't forget to re-test the code if there were any. 2a. Merge the branch manually git checkout master git merge --no-ff FeatureBranch The --no-ff flag forces the creation of a merge commit, so that the individual commits in the branch stand out as a unit. This makes future maintenance and searches through history easier. Notes: - this is exactly what Github does when you click the "Merge Pull Request" button. - if the branch has a single commit, then the --no-ff flag is not necessary and should not be used (consequently, we should merge manually instead of using the Github button for such pull requests). Attention: make sure to provide a descriptive merge commit message In other words, do *not* keep the Git default text like "Merge branch 'variable-naming' of https://github.com/grangeway/mantisbt into grangeway-variable-naming". These messages are essentially useless, as they do not provide any useful information regarding what the merged branch was about. Instead, briefly describe what the purpose of the branch was, and reference the Github pull request and/or Mantis issue(s) Id. Note: if I'm not mistaken, when you merge from Github, this text is taken from the pull request's subject and description (1st comment). 2b. Merge the pull request from Github As an alternative to 2a, after rebasing (step 1) you can simply force push the rebased branch to your Github fork. git push -f YourFork FeatureBranch The pull request will be automatically updated, and then you can simply click the "Merge pull request" button in Github. For reference, here are a couple of examples of what I consider "good" merge commits: - Manual merge with custom commit message https://github.com/mantisbt/mantisbt/commit/b5194d98fd - Merge from Github https://github.com/mantisbt/mantisbt/commit/e3ed007f3d Of course in the case of a complex branch, especially one where merges *from* master have taken place, it may be too difficult / not worth the effort to rebase, in which case a "normal" merge is acceptable. However we should try to keep these at a minimum to avoid cluttering the history. Thanks for your understanding and consideration. Damien PS: I'll add this to the wiki and/or the developer's guide later as time allows. |
From: Robert M. <rob...@gm...> - 2014-03-29 21:14:22
|
On Sat, Mar 29, 2014 at 4:17 PM, P Richards <pa...@ma...> wrote: > The steps I followed were the procedure github said to follow to "merge the > patch manually through their system" - personally, I generally preferred to > rebase commits for the reasons you describe. > > Really, I'd prefer us to have our processes based around git itself, and not > around 'github'. It should be possible for us to handle a pull request from > any git remote from any source with a standard method. > > Paul > > > -----Original Message----- > From: Damien Regad [mailto:dr...@ma...] > Sent: 29 March 2014 14:05 > To: Man...@li... > Subject: [mantisbt-dev] Git "Spaghetti" history > > Hi all, > > As much as I love pasta, I'd rather avoid having our Git history look like a > plate of spaghetti, and keep it as linear as possible instead ;-) +1, let's go for fusilli :-) Robert > > Grangeway's recent series of merge commits is a typical example of what I > strongly believe we should try to avoid. Just have a look at the attached > screenshot, and I'm sure you'll agree... > > When merging pull requests, especially for older branches, please follow > these guidelines: > > 1. Rebase your branch on top of the latest git HEAD > > git fetch origin > git rebase master FeatureBranch > > Resolve conflicts when you rebase, and don't forget to re-test the code if > there were any. > > > 2a. Merge the branch manually > > git checkout master > git merge --no-ff FeatureBranch > > The --no-ff flag forces the creation of a merge commit, so that the > individual commits in the branch stand out as a unit. This makes future > maintenance and searches through history easier. > > Notes: > - this is exactly what Github does when you click the "Merge Pull > Request" button. > - if the branch has a single commit, then the --no-ff flag is not > necessary and should not be used (consequently, we should merge manually > instead of using the Github button for such pull requests). > > Attention: make sure to provide a descriptive merge commit message > > In other words, do *not* keep the Git default text like "Merge branch > 'variable-naming' of https://github.com/grangeway/mantisbt into > grangeway-variable-naming". > > These messages are essentially useless, as they do not provide any > useful information regarding what the merged branch was about. Instead, > briefly describe what the purpose of the branch was, and reference the > Github pull request and/or Mantis issue(s) Id. > > Note: if I'm not mistaken, when you merge from Github, this text is > taken from the pull request's subject and description (1st comment). > > > 2b. Merge the pull request from Github > > As an alternative to 2a, after rebasing (step 1) you can simply force > push the rebased branch to your Github fork. > > git push -f YourFork FeatureBranch > > The pull request will be automatically updated, and then you can simply > click the "Merge pull request" button in Github. > > For reference, here are a couple of examples of what I consider "good" > merge commits: > > - Manual merge with custom commit message > https://github.com/mantisbt/mantisbt/commit/b5194d98fd > - Merge from Github > https://github.com/mantisbt/mantisbt/commit/e3ed007f3d > > Of course in the case of a complex branch, especially one where merges > *from* master have taken place, it may be too difficult / not worth the > effort to rebase, in which case a "normal" merge is acceptable. However > we should try to keep these at a minimum to avoid cluttering the history. > > Thanks for your understanding and consideration. > > Damien > > PS: I'll add this to the wiki and/or the developer's guide later as time > allows. > > > ------------------------------------------------------------------------------ > _______________________________________________ > mantisbt-dev mailing list > man...@li... > https://lists.sourceforge.net/lists/listinfo/mantisbt-dev -- http://robert.muntea.nu/ |
From: Damien R. <dr...@ma...> - 2014-03-29 22:04:36
|
On 2014-03-29 22:14, Robert Munteanu wrote: > +1, let's go for fusilli :-) Are you implying that my proposed method is screwed ? ;-) |
From: P R. <pa...@ma...> - 2014-03-29 22:06:28
|
If it's applied at the command line, it's probably not scrwed. -----Original Message----- From: Damien Regad [mailto:dr...@ma...] Sent: 29 March 2014 22:04 To: Man...@li... Subject: Re: [mantisbt-dev] Git "Spaghetti" history On 2014-03-29 22:14, Robert Munteanu wrote: > +1, let's go for fusilli :-) Are you implying that my proposed method is screwed ? ;-) ---------------------------------------------------------------------------- -- _______________________________________________ mantisbt-dev mailing list man...@li... https://lists.sourceforge.net/lists/listinfo/mantisbt-dev |
From: Robert M. <rob...@gm...> - 2014-03-29 22:07:38
|
On Sun, Mar 30, 2014 at 12:04 AM, Damien Regad <dr...@ma...> wrote: > On 2014-03-29 22:14, Robert Munteanu wrote: >> +1, let's go for fusilli :-) > > Are you implying that my proposed method is screwed ? ;-) That's the closest I could find to linear pasta _after_ being boiled. But feel free to propose a better name for how that sort of history looks ;-) > > > > ------------------------------------------------------------------------------ > _______________________________________________ > mantisbt-dev mailing list > man...@li... > https://lists.sourceforge.net/lists/listinfo/mantisbt-dev -- http://robert.muntea.nu/ |
From: Thomas K. <th...@ko...> - 2014-03-31 06:32:12
|
On Saturday, March 29, 2014 03:04:54 PM Damien Regad wrote: > Hi all, > > As much as I love pasta, I'd rather avoid having our Git history look > like a plate of spaghetti, and keep it as linear as possible instead ;-) A benefit of a linear git history is "git bisect" works much nicer. |
From: Damien R. <dr...@ma...> - 2014-05-30 06:46:59
Attachments:
spaghetti-2nd-helping.png
|
Bump for grangeway, with attachment demonstrating what happens to our git history after a wave of 10 merges using Github to merge pull requests instead of following the guidelines I provided. Summary: AVOID USING THE GITHUB "Merge pull request" BUTTON 1. Rebase your branch on top of the latest git HEAD 2. Merge the branch manually - single-commit branches, git merge (fast-forward, no merge commit) - complex feature branches, git merge --no-ff 3. close the pull request, adding a comment fix commit's SHA Thanks for your understanding. On 29.03.2014 15:04, Damien Regad wrote: > Hi all, > > As much as I love pasta, I'd rather avoid having our Git history look > like a plate of spaghetti, and keep it as linear as possible instead ;-) > > Grangeway's recent series of merge commits is a typical example of what > I strongly believe we should try to avoid. Just have a look at the > attached screenshot, and I'm sure you'll agree... > > When merging pull requests, especially for older branches, please follow > these guidelines: > > 1. Rebase your branch on top of the latest git HEAD > > git fetch origin > git rebase master FeatureBranch > > Resolve conflicts when you rebase, and don't forget to re-test the code > if there were any. > > > 2a. Merge the branch manually > > git checkout master > git merge --no-ff FeatureBranch > > The --no-ff flag forces the creation of a merge commit, so that the > individual commits in the branch stand out as a unit. This makes future > maintenance and searches through history easier. > > Notes: > - this is exactly what Github does when you click the "Merge Pull > Request" button. > - if the branch has a single commit, then the --no-ff flag is not > necessary and should not be used (consequently, we should merge manually > instead of using the Github button for such pull requests). > > Attention: make sure to provide a descriptive merge commit message > > In other words, do *not* keep the Git default text like "Merge branch > 'variable-naming' of https://github.com/grangeway/mantisbt into > grangeway-variable-naming". > > These messages are essentially useless, as they do not provide any > useful information regarding what the merged branch was about. Instead, > briefly describe what the purpose of the branch was, and reference the > Github pull request and/or Mantis issue(s) Id. > > Note: if I'm not mistaken, when you merge from Github, this text is > taken from the pull request's subject and description (1st comment). > > > 2b. Merge the pull request from Github > > As an alternative to 2a, after rebasing (step 1) you can simply force > push the rebased branch to your Github fork. > > git push -f YourFork FeatureBranch > > The pull request will be automatically updated, and then you can simply > click the "Merge pull request" button in Github. > > For reference, here are a couple of examples of what I consider "good" > merge commits: > > - Manual merge with custom commit message > https://github.com/mantisbt/mantisbt/commit/b5194d98fd > - Merge from Github > https://github.com/mantisbt/mantisbt/commit/e3ed007f3d > > Of course in the case of a complex branch, especially one where merges > *from* master have taken place, it may be too difficult / not worth the > effort to rebase, in which case a "normal" merge is acceptable. However > we should try to keep these at a minimum to avoid cluttering the history. > > Thanks for your understanding and consideration. > > Damien > > PS: I'll add this to the wiki and/or the developer's guide later as time > allows. > > > ------------------------------------------------------------------------------ > > > > _______________________________________________ > mantisbt-dev mailing list > man...@li... > https://lists.sourceforge.net/lists/listinfo/mantisbt-dev > --- This email is free from viruses and malware because avast! Antivirus protection is active. http://www.avast.com |
From: Paul R. <pa...@ma...> - 2014-05-30 08:34:58
|
That’s fine by me - my personal view is (as i’ve said before) our development process should be around git and not ‘github’. Personally, I’d probably say we should always rebase as opposed to merge? [IIRC the merging process in git keeps the old timestamps] Paul On 30 May 2014, at 07:46, Damien Regad <dr...@ma...> wrote: > Bump for grangeway, with attachment demonstrating what happens to our > git history after a wave of 10 merges using Github to merge pull > requests instead of following the guidelines I provided. > > Summary: AVOID USING THE GITHUB "Merge pull request" BUTTON > > 1. Rebase your branch on top of the latest git HEAD > 2. Merge the branch manually > - single-commit branches, git merge (fast-forward, no merge commit) > - complex feature branches, git merge --no-ff > 3. close the pull request, adding a comment fix commit's SHA > > Thanks for your understanding. > > > On 29.03.2014 15:04, Damien Regad wrote: >> Hi all, >> >> As much as I love pasta, I'd rather avoid having our Git history look >> like a plate of spaghetti, and keep it as linear as possible instead ;-) >> >> Grangeway's recent series of merge commits is a typical example of what >> I strongly believe we should try to avoid. Just have a look at the >> attached screenshot, and I'm sure you'll agree... >> >> When merging pull requests, especially for older branches, please follow >> these guidelines: >> >> 1. Rebase your branch on top of the latest git HEAD >> >> git fetch origin >> git rebase master FeatureBranch >> >> Resolve conflicts when you rebase, and don't forget to re-test the code >> if there were any. >> >> >> 2a. Merge the branch manually >> >> git checkout master >> git merge --no-ff FeatureBranch >> >> The --no-ff flag forces the creation of a merge commit, so that the >> individual commits in the branch stand out as a unit. This makes future >> maintenance and searches through history easier. >> >> Notes: >> - this is exactly what Github does when you click the "Merge Pull >> Request" button. >> - if the branch has a single commit, then the --no-ff flag is not >> necessary and should not be used (consequently, we should merge manually >> instead of using the Github button for such pull requests). >> >> Attention: make sure to provide a descriptive merge commit message >> >> In other words, do *not* keep the Git default text like "Merge branch >> 'variable-naming' of https://github.com/grangeway/mantisbt into >> grangeway-variable-naming". >> >> These messages are essentially useless, as they do not provide any >> useful information regarding what the merged branch was about. Instead, >> briefly describe what the purpose of the branch was, and reference the >> Github pull request and/or Mantis issue(s) Id. >> >> Note: if I'm not mistaken, when you merge from Github, this text is >> taken from the pull request's subject and description (1st comment). >> >> >> 2b. Merge the pull request from Github >> >> As an alternative to 2a, after rebasing (step 1) you can simply force >> push the rebased branch to your Github fork. >> >> git push -f YourFork FeatureBranch >> >> The pull request will be automatically updated, and then you can simply >> click the "Merge pull request" button in Github. >> >> For reference, here are a couple of examples of what I consider "good" >> merge commits: >> >> - Manual merge with custom commit message >> https://github.com/mantisbt/mantisbt/commit/b5194d98fd >> - Merge from Github >> https://github.com/mantisbt/mantisbt/commit/e3ed007f3d >> >> Of course in the case of a complex branch, especially one where merges >> *from* master have taken place, it may be too difficult / not worth the >> effort to rebase, in which case a "normal" merge is acceptable. However >> we should try to keep these at a minimum to avoid cluttering the history. >> >> Thanks for your understanding and consideration. >> >> Damien >> >> PS: I'll add this to the wiki and/or the developer's guide later as time >> allows. >> >> >> ------------------------------------------------------------------------------ >> >> >> >> _______________________________________________ >> mantisbt-dev mailing list >> man...@li... >> https://lists.sourceforge.net/lists/listinfo/mantisbt-dev >> > > > > --- > This email is free from viruses and malware because avast! Antivirus protection is active. > http://www.avast.com > <spaghetti-2nd-helping.png>------------------------------------------------------------------------------ > Time is money. Stop wasting it! Get your web API in 5 minutes. > www.restlet.com/download > http://p.sf.net/sfu/restlet_______________________________________________ > mantisbt-dev mailing list > man...@li... > https://lists.sourceforge.net/lists/listinfo/mantisbt-dev |
From: Damien R. <dr...@ma...> - 2014-05-30 10:03:39
|
On 30.05.2014 10:34, Paul Richards wrote: > we should always rebase as opposed to merge? Not necessarily, although rebasing *before* merge does ensure we have a history which remains as clean as possible. I believe it is useful to see a bunch of related commits (i.e. a feature branch) as a single entity. This is easily achieved with the git merge '--no-ff' flag, which has the added benefit of allowing an additional description of what the whole branch achieves through the merge commit, as opposed to a series of potentially unrelated commits that make it difficult to understand after the fact, which commit belongs to what feature. Just to illustrate my point, consider this simple example, where commits 1-3 are a feature branch and 4+5 are other bugfix Merge --no-ff makes it clear what's happening: ---*----4--------M----5--- \ / 1----2----3 Even better if you actually rebase before merging: ---*----4-------------M----5--- \ / 1----2----3 With Rebase only, you don't realize that 4/5 fix different issues. ---*----4----1----2----3----5--- > [IIRC the merging process in git keeps the old timestamps] If you don't rebase prior to merging, git log might indeed give you a "weird" history with commits from various branches intermixed. The solution to that is to use git log --topo-order [1]. You should consider making that an alias. [1] https://www.kernel.org/pub/software/scm/git/docs/git-log.html#_commit_ordering --- This email is free from viruses and malware because avast! Antivirus protection is active. http://www.avast.com |
From: Damien R. <dr...@ma...> - 2014-08-11 14:30:15
|
bump for atrol ;-) On 29.03.2014 15:04, Damien Regad wrote: > Hi all, > > As much as I love pasta, I'd rather avoid having our Git history look > like a plate of spaghetti, and keep it as linear as possible instead ;-) > > Grangeway's recent series of merge commits is a typical example of what > I strongly believe we should try to avoid. Just have a look at the > attached screenshot, and I'm sure you'll agree... > > When merging pull requests, especially for older branches, please follow > these guidelines: > > 1. Rebase your branch on top of the latest git HEAD > > git fetch origin > git rebase master FeatureBranch > > Resolve conflicts when you rebase, and don't forget to re-test the code > if there were any. > > > 2a. Merge the branch manually > > git checkout master > git merge --no-ff FeatureBranch > > The --no-ff flag forces the creation of a merge commit, so that the > individual commits in the branch stand out as a unit. This makes future > maintenance and searches through history easier. > > Notes: > - this is exactly what Github does when you click the "Merge Pull > Request" button. > - if the branch has a single commit, then the --no-ff flag is not > necessary and should not be used (consequently, we should merge manually > instead of using the Github button for such pull requests). > > Attention: make sure to provide a descriptive merge commit message > > In other words, do *not* keep the Git default text like "Merge branch > 'variable-naming' of https://github.com/grangeway/mantisbt into > grangeway-variable-naming". > > These messages are essentially useless, as they do not provide any > useful information regarding what the merged branch was about. Instead, > briefly describe what the purpose of the branch was, and reference the > Github pull request and/or Mantis issue(s) Id. > > Note: if I'm not mistaken, when you merge from Github, this text is > taken from the pull request's subject and description (1st comment). > > > 2b. Merge the pull request from Github > > As an alternative to 2a, after rebasing (step 1) you can simply force > push the rebased branch to your Github fork. > > git push -f YourFork FeatureBranch > > The pull request will be automatically updated, and then you can simply > click the "Merge pull request" button in Github. > > For reference, here are a couple of examples of what I consider "good" > merge commits: > > - Manual merge with custom commit message > https://github.com/mantisbt/mantisbt/commit/b5194d98fd > - Merge from Github > https://github.com/mantisbt/mantisbt/commit/e3ed007f3d > > Of course in the case of a complex branch, especially one where merges > *from* master have taken place, it may be too difficult / not worth the > effort to rebase, in which case a "normal" merge is acceptable. However > we should try to keep these at a minimum to avoid cluttering the history. > > Thanks for your understanding and consideration. > > Damien > > PS: I'll add this to the wiki and/or the developer's guide later as time > allows. > > > ------------------------------------------------------------------------------ > > > > _______________________________________________ > mantisbt-dev mailing list > man...@li... > https://lists.sourceforge.net/lists/listinfo/mantisbt-dev > --- This email is free from viruses and malware because avast! Antivirus protection is active. http://www.avast.com |