I'm not sure if you misread my comment, but my point was that it's far too easy to accidentally introduce bugs in merge commits that go unnoticed for a long time.
I've never seen a rebase gone awry introduce production bugs, but I've known multiple gnarly bugs caused by errant merges. YMMV.
as always, different circumstances can generate different results.
In a merge, you solve conflicts once. Whereas in a rebase, those conflicts will turn into incremental conflicts.
If the branch history is "tidy", with discrete, purposeful commits, this can be easier. Especially if incrementally rebasing.
The main difference is one rewrites history and the other does not. A rebase is by nature destructive and as such can introduce subtle changes in the process, especially if commits are reordered / modified in the process
It's not really destructive, though! That's not really the main difference.
The main difference is that a merge sticks around in your repo forever, a commit that people assume has no real code changes in it but actually sometimes it does. A rebase is done once, and then your git history doesn't have to deal with it ever again.
Yes, you raise a fair point that if you've dug yourself into a deep pit already with long-lived branches and overlapping work, it might be slightly easier to extract yourself from the pit with a merge. But then you're leaving that fetid pit in your repository forever.
When I said destructive, I meant in the literal sense, in that it rewrites history.
Don't get me wrong, I _often_ rebase, about a dozen times a day and it's been a core part of my workflow for 2 years. In that time I have learnt a lot, silently lost changes and ended up in a few mishaps.
I am in no way against the idea of rebasing, I frequently do. And personally, I often rebase && merge --no-ff. But, IMHO it's far too easy to mess up too that I'd adopt it as a dogma.
I also question the notion that VC history is best thought of in linear terms. I'd argue it's fundamentally flawed to force a DAG into a more linear structure.
In my experience, the desire to do this is to construct a DAG that's pretty in log viewer XYZ, rather than anything else. I consider this highly overrated. Just look at the DAG of the git project. Yes, it's intense, but the primary purpose of the history DAG isn't to immediately present a simple linear history.
Rather, it's to preserve a common, shared, decentralized history where it's easy to go back to a precise moment and see what was done to what and why. A dogmatic always rebase history is in my experience often a relatively pointless pursuit of constructing a git log --graph that's "simple" by default. Ie, rather than solving for the problem of "How to overview a DAG", the solution is to reformulate the DAG in a linear way which often conforms better to how we humans like to overview information.
Again, this is a personal viewpoint and I don't mean to pass judgement but I often find that such approaches, which one might liken to treating symptoms instead of curing the cause, is better solved the other way around. It's a real joy to delve into the git projects history, despite the fact that it's _littered_ with merge commits.
Basically, I think the quest for a "simpler" looking history DAG is somewhat overrated and not something I'd personally recommend pursuing.
First time I've seen aliases using other chars other than a-z; care to share your dotfiles?
It's a neat trick to explode your alias namespace, since you'll never see a tool published named `ls-` So you have reserved a huge "address block" for your personal aliases :)
Thank-you. I collected some from kristopolous recently [1] too.
I see d- there, so the one use of dash is used sparingly. There's a lot of git functionality I'm leaving on the table, looks like.
Currently, I'm using a shell script to help with a git conflict resolution flow that does something like
read -p 'Conflict. Resolve and press [Enter]'
And fix in a separate tmux window (git add, git cherry-pick --continue).
TUIs and autocomplete popups are nice, but there's opportunity for a deeper understanding writing one's own tools. So I'm hoping to combine ZZ and `read -p` (or similar) to coax nvi (Keith Bostic) to something for Java stuff. Or at least build some primitives around that.
Encountering the equivalent of "flash of unstyled content" when switching from text editor to a--for example--Java method chooser feels like the philosophical difference between "Let's SPA" versus "Click flashes between pages is fine."
The flow would be something like
1. In nvi, keystroke equivalent of
Ctrl-Space brings up an Intellisense
tool.
2. The tool loads up a list of
autocomplete methods as well as its
own hotkeys.
3. Pressing up and down manipulates a
temporary text file that just prepends
">" next to the line, for example.
4. And Enter somehow brings back nvi with
the method added, right after the
period (with our partial typing
replaced).
All this to say, dotfiles and git config are no big deal, but in CLI it's an escape hatch to molding a custom environment.
