Branchless Workflow for Git
github.com
github.com
> 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.
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?
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?
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.
'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.
Mainly it's for when you branch from A multiple times, and then modify A. This can happen if you have some base work that you build multiple features on top of. I routinely do this as part of rapid prototyping, as described here: https://github.com/arxanas/git-branchless/wiki/Workflow:-div...
`git undo` shows a list of operations it'll execute, which you have to confirm before accepting. Of course, it's ultimately a matter of trust in the tools you use.
> `git undo` shows a list of operations it'll execute, which you have to confirm before accepting. Of course, it's ultimately a matter of trust in the tools you use.
Nice! I guess it's time to setup rust and check this out. Are you the author? I hope my comments did not come across as too negative. It's more a matter of me living in a git bubble and failing to appreciate the tool.
> I hope my comments did not come across as too negative.
Not at all!
> guess it's time to setup rust and check this out
It's also available on many package managers, such as Homebrew and Nix, although you'd have to build from source for the latest development version.
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.
There are currently two options:
1. Add new commits to an existing branch. Any reviewier always needs the context from the earlier commits.
2. Overwrite the whole branch (force push). Older comments, and generally the delta between different versions of the change request, get lost or are at least very hard to see (e.g., might get mixed with changes from a rebate).
Working with the patch/commit as artifact (as, e.g., Gerrit does it) seems so much more usable for code review that I can only speculate why no big tool offers it. Presumably, it requires too much internal knowledge about git to implement the backend correctly.
You could try tools like https://graphite.dev/ or https://reviewable.io/, or Meta's Sapling + ReviewStack.
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.
https://docs.plasticscm.com/gitsync/plastic-scm-version-cont...
> ridiculously slow in comparison
That can’t true. Perforce is definitely much faster, especially with files that aren’t just small text files. One of my biggest complaints of Git is how slow it is. There’s a reason why game studios use Perforce or Plastic SCM.
But if you're just dealing with text files, git is much faster in many cases compared to perforce. Switching/creating branches in git is instant, it can take a while in perforce. Doing a 'git status' is instant, 'p4 status' can take minutes to return in a large repo with many files.
I'm not a game developer: Text files are all I care about.
I think this tool is for me, am I able to adopt it without my team needing too?
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
I do like the performance improvements and git sync however, maybe they could be merged into mainline git?
> git log --graph only shows commits which have branches attached with them. If you prefer to work without branches, then git log --graph won't work for you.
This seems to be about working with commits, including branched trees/graphs, without creating a named branch..?
That's correct.