Hi Gautam, There's a few branches that will need some cleanup! Don't bother reverting the next commit. You can clean it up before it goes to master. Rob On 10/24/15 11:37 AM, Gautam Bisht wrote:

Hi Rob,

I believe my recent merge of PR-367 (jinyuntang/lnd/betr) into next is reason behind this email.

I will revert my commit on next and work with Jinyun to either clean up history for his branch or use another branch to issue a new PR, so we have a clean history in master.

-Gautam.

On Sat, Oct 24, 2015 at 8:25 AM, Robert Jacob <[email protected] <mailto:[email protected]>> wrote:

Hello Integrators,

Before merging a long-lived branch with dozens of commits to next/master, which is probably going to happen a lot in the next week, look at the log of the branch and see if some commits can be combined with rebase.

The reason for combining commits is to keep a clean commit history.

"A clean commit history is one where each commit is a solid piece of work, representing a milestone in your feature or fix. It doesn’t have to be a large amount of work, just some good chunk that, conceptually, stands alone.

An unclean commit history is often littered with commits like “Fixed a bug in my previous commit” or “Oops, forgot this file” or “rewrite that subroutine again for the 3rd time.”

The commit history lives forever once the branch is merged to master.

A good how to page is here: http://gitready.com/advanced/2009/02/10/squashing-commits-with-rebase.html

Rob _______________________________________________ ACME-SE mailing list [email protected] <mailto:[email protected]> https://lists.mcs.anl.gov/mailman/listinfo/acme-se

Hi Jed, Thanks for the advice. Turns out the messy branch was reverted off of next so, from your option 3, sounds like they can rebase to clean it up. Rob On 10/24/15 1:55 PM, Jed Brown wrote:

Robert Jacob <[email protected]> writes:

...

There's a few branches that will need some cleanup! Don't bother reverting the next commit. You can clean it up before it goes to master.

Please don't. When you rebase, you're literally making a new sequence of commits with no semantic relation to the first one. If it effects exactly the same change, then you won't have merge conflicts, but there will still be multiple commits providing the same change and "git blame" on 'next' can't reliably tell you where the change came from. Moreover, if the change is not identical, then you need to resolve conflicts and the state of 'master' can become different than 'next' even after the non-abandoned branches have graduated. This can be very confusing even to an expert.

My recommendation:

1. For branches that have already been merged to 'next', just live with the fact that they are unclean and take it as a lesson for next time.

2. Rebase branches that have not been merged anywhere yet.

3. If a branch in 'next' has a serious problem (like a license attribution problem, an accidental commit of a binary, or accidental touching of files unrelated to the purpose of your branch), then revert the merge to 'next' and rebase liberally to fix all issues.