On Tue, Jul 29, 2014 at 4:38 PM, Philip Oakley <philipoak...@iee.org> wrote: > From: "Nico Williams" <n...@cryptonector.com> >> That workflow works just fine with git. > > I'm not saying that it isn't a good technique and can work well. Rather I'm > saying we should be tolerant of the rules and techniques of others who do > [...]
Sure. I was just giving advice as to how to avoid any problems at pull time w.r.t. local merge commits. Better merge commit handling at pull time might be great (I'd not know; I avoid local merge commits!), but I would still strongly recommend keeping all local commits on top because otherwise you lose local history. Even if you use -m to set a better commit message, you might prefer to have kept the original N local -now rebased- commits around so you can tell what each discrete change was, even if you'll eventually squash them (you might not squash them all into one). >> It worked really well at Sun >> (with thousands of engineers working on Solaris alone). And it should >> work well for anyone who doesn't have two or more forked upstreams to >> follow. > > I'm just cautious of an accidental one size fits all approach, so the > ability to rebase lines of development which contain merge commits should be > possible (with an appropriate and documented option) without hidden traps. Thus far the only case I've seen where this approach doesn't work _at all_ is the case where you have multiple forked upstreams. The only other case where it doesn't work is a social problem: rebase allergy. For the repos I maintain I insist on contributed commits applying as fast forward merges, or I'll rebase them myself if need be. Nico -- -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
