I'm comfortable git fooing w/e is necessary, but ever since we adopted this, git related conversations went to almost zero. It's great.
The notable features are: - Move commits up and down, fixup, drop - Rename commits from the editor (without having to stop for a reword during the rebase run) - Visualize modified files along commits - 'Explode' a commit ,creating a commit for each modified file (a thing I found myself doing quite often)
Feedbacks (both on the tool and the code) and contributions welcome, hope it could fit other people needs too !
I'm comfortable git fooing w/e is necessary, but ever since we adopted this, git related conversations went to almost zero. It's great.
And yet that’s not usually what the problem is with having your canonical history “over there” in a proprietary webapp.
But if the history is easily available on those PR refs then I guess it is (under doubt) fine.
Alternatively I could stick with git(1) which does all of this stuff out of the box. Instead of having to learn a superflouous (for the job) API.
I want the meaningful commits to be in the Git history. Because that’s a better place than the forge.
It’s not a requirement. I wrote in another thread[0] why I like this methodology, but to each project its own.
That is not sufficient. Which I explained here.