> <i>So to relieve some of that tension and ease up the final merge you’re heading towards, you decide to perform a control merge now and then: a merge of master into your own branch, so that without polluting master you can see what conflicts are lurking, and figure out whether they’re hard to fix.<p>It is indeed useful, and just so you won’t have to fix these later, you would be tempted to leave that control merge in the tree once you’re done with it, instead of rolling it back with, say, a git reset --hard ORIG_HEAD and keep your graph pristine.</i><p>if you use git "linear history" style and will do a rebase at the end anyway, why not do "control rebases" immediately, instead of control merges?<p>At least from my experience, a rebasing on a branch that has substantially diverged can get painful quickly, however doing many small rebases and trying to keep up with master usually works without many problems.
Once I read "this is ugly and pollutes your history graph" as a justification for any git feature, I'm immediately turned off.<p>What really is wrong with having a graph that actually reflects the real history of changes as they were made at the time?<p>Why not keep things simple and improve git-log so that anything you find ugly or that looks like pollution can be hidden while viewing the history of a repo? In this case, for example, would it not be far more ergonomic to add a "--hide-control-merges" flag to git-log?<p>This rerere feature described looks like a lot of the foot-guns git provides.<p>I know I'm in a minority here - I've given up arguing with collegues that it's possible to have a branch&merge work-flow without constant re-basing. Allowing the history graph to be manipulated and changed seems to have become part of the most popular git work-flows even though it's a recipe for serious pain in a distributed VCS.<p>(This isn't a criticism of the article btw - more of the git design/philosophy.)
What is the problem with the graph in the first figure?<p>Apart from looking a little bit more complicated than one without the merges, will a history like that actually cause any probelms?
I'm doing that successfully for years. But I added more: <a href="https://github.com/perl11/cperl/blob/master/pod/perlcperl.pod" rel="nofollow">https://github.com/perl11/cperl/blob/master/pod/perlcperl.po...</a><p>The .git/cache is a submodule, so others can easily rebase also. And a lot of helper scripts to rebase and pull --rebase all work branches automatically. All current branches are constantly rebased to master, others default to pull --rebase (aliased to lb), with the shared. git/cache there are no conflicts for years.<p>I'm also doing this for several forks automatically, like adding patches and CI smokes to popular repos like clisp, libffi, openssl, pcre2, coreutils and many more. These are rebased hourly, conflicts appear maybe once a year.
This was a nice read; git rerere is one of the git features that has been a tad mysterious for me, I thought it was on by default.<p>I’m pretty sure I’ve used it, probably because I read somewhere, just like this article says, that it should be turned on by default. What I didn’t know and wondered while reading is how to clear a rerere, and it looks like you can “git rerere [clear|forget]”. <a href="https://git-scm.com/docs/git-rerere" rel="nofollow">https://git-scm.com/docs/git-rerere</a> I have resolved a conflict and then discovered later that I screwed it up, so needed to do it again.