On Wed, Sep 23, 2015 at 6:29 PM, Ted Dunning <[email protected]> wrote:
> > Cherry picking (in my experience) works very much as desired. The fact > that a commit exists on two branches doesn't seem to cause any trouble at > all at merge time. > That's good to hear. I have definitely had bad experiences when dealing with cherry-picked commits, but I have not been able to pin down a specific case where they don't do what you might hope. I'm not sure how the git magic works, but it would certainly be compelling if it did work. > Rebasing interactively is another case. I routinely use this to make my > local history more sensible. Within reason, it allows me to squash and > re-order my own commits so that there appears to be more order in the > historical record than was in my head at the time I did the work. > Yes, this is a good strategy that we would definitely want to encourage if we were to stop doing the full-squash at commit time. The golden rules IMHO are: 1. Don't rewrite history (which includes squashing or amending commits and force pushes) on a branch that has been shared to anyone else. 2. Ensure that the commits which are ultimately pushed to master are sensible, self-contained, well-documented, etc. There's a small amount of tension between those two rules, but it can be handled. Ceej aka Chris Hillery
