I feel like I have a pretty good understanding of git, but the problems these helpers are trying to solve make my head spin.<p>> git rebase --interactive can only repair linear series of commits, not trees. If you modify a commit with multiple children, then you have to be sure to rebase all of the other children commits appropriately.<p>Can someone explain (preferably with a sequence of git commands) how you end up in such a situation? When would you end up modifying a commit with multiple children?<p>Is this for a case where a bunch of people branch from master@HEAD (lets call this A), then you need to modify A, so you then need to rebase each branch that branched from A individually?<p>I guess the workflows I'm used too explicitly try to avoid doing things that cause the problems that these helpers try to solve. I'm so used to thinking in this current mode that I find it hard to imagine when these problems would arise.<p>'git undo' terrifies me though. I really hate when there's lots of magic going on and I don't know what state my git repo will end up when I run a command. I rather run N commands, where I'm pretty confident what will happen in each stage, than one command that just 'fixes' things. Because if it fails to fix something, I'll be in some unknown state without understanding how I got into it.
The biggest issue of working without branches is that virtually all code review tools nowadays work on a Pull Request basis (thus branches). Almost no tool allows adding individual commits to a code review, the only one I know is Upsource but that is unfortunately no longer being developed.<p>As my team does trunk based development we're struggling with that. Since we're not able to find a code review tool that is compatible with our workflow, I assume we are doing something wrong and trunk based development is no longer an industry practice - though it works very well for us.
Although GitHub offers a lot of features and generally makes Git tolerable, I’ll be pretty happy when Git gets supplanted by something else more popular and hopefully better. The latter should not be hard to do.<p>As someone who cut my teeth on Perforce, I’m still learning the ins and outs of Git and generally actively avoid Git features. Whereas with Perforce, I was writing custom applications using its API and powerful workspace concept in just a couple years. Perforce is just easier to understand, easier to customize, great visualization tools, and has more sane names for things.
I have a lot of trouble pipelining my commits when I get reviewer comments on an early branch, it's very error prone to squash the changes and distribute downstream to avoid merge problems later.<p>I think this tool is for me, am I able to adopt it without my team needing too?
This is kind of presented like a tool but it really is a workflow, I think presenting it in an e.g. gitflow manner woukd make it more clear on how it would work on an example project
Why should I want to use smartlog instead of something like tig?<p>While at it, I am amazed how much effort people put into not using git as intended due to some (often imaginary) corner case shortcomings<p>I do like the performance improvements and git sync however, maybe they could be merged into mainline git?