https://git-man-page-generator.lokaltog.net/
"git-eliminate-head eliminates all downstream heads for a few forward-ported non-counted downstream indices, and you must log a few histories and run git-pioneer-object --pose-file instead. [...]"
https://git-man-page-generator.lokaltog.net/
"git-eliminate-head eliminates all downstream heads for a few forward-ported non-counted downstream indices, and you must log a few histories and run git-pioneer-object --pose-file instead. [...]"
Thank you for sharing, this made my week.
but maybe that's due to the low bar that it's being compared to.
> To rev-parse an automatic FLOUNDER_LOG or diff the working subtrees, use the command git-link-submodule --retrieve-wrestle-change.
I often overlook this detail when trying to hulk smash some broken change I've made upstream (what the manual entry correctly refers to as RIP_OTHER_TIP).
[1] https://git-man-page-generator.lokaltog.net/#81394c8bf3806f9...
"To parse a staged SKIRT_SUBTREE and blame the working histories, use the command git-purchase-pack --snuggle-muster-branch, as after reapplying subtrees..."
Content Security Policy: The page’s settings blocked the loading of a resource at self (“script-src”).Git is one of the most amazing, powerful tools ever conceived, with one of the must byzantine and ridiculously designed 'interfaces' ever conceived.
People confuse the raw power of a tech, with how well it can be feasibly used. Sadly, due to the later issues, git will only ever be a shadow of what it could have been.
With all due respect to Linus, who'd be the first to admit he's not very good at UI stuff (I mean command line as well)... it's truly a sad thing.
This is a major 'problem that needs to be solved' I'm interested to see how it could evolve into something 'better'.
A better solution for prose was to always be merging with live multiple collaborator updates. Conflicts are visible in real-time. I can't see something like this would work with code. Hmm interesting... unless we only allow additions and refactorings to working checkpoints.
First - the UI is a mess, and that should have been fixed. It would make a big difference.
Second - is the inherent complexity. That's a good point, but I feel many things could be hidden or obfuscated.
Most poignantly, Git does something that most of us do not need: it was designed to work as a 'completely distributed system', i.e. for open source.
Almost none of us do that. 95% of uses cases related to you and I working collaboratively, on a project together.
The need to have repos which are essentially totally distinct from one another is a huge source of complexity and it simply doesn't need to exist in most cases.
So Git is basically an 'admin level tool' that is commonly used in scenarios for which it wasn't meant to be used, with a confusing interface.
It's costing a lot of time and money and headaches, I do believe someone may come along eventually and fix it.
This thread is essentially evidence of this - see how many people have difficult teaching what should essentially be a simple thing in most cases.
Way too many very smart people still spend too much time clustering around in git.
Nobody is complaining about there being too many features. People are complaining about the arcane incantations that one needs to conjure to call them.
That's just one example, but there definitely are people that think git's too featureful. As for more valid criticisms, I'd agree. I've heard the CLI compared to being in an abusive relationship. All that said, I can't really think of a better way to handle things without losing useful functions. In which case, I don't have any better ideas, and don't really know what I'm criticizing.