I often use Sublime Merge to reword commits (edit commit message), or to split up commits (it undoes the commit and you get everything in the working directory), so I’m not sure if this table is entirely correct. (At least from a user point of view I can easily edit or reword).
One other nice feature is the squashing of two commits, ignoring the latters message (as a fixup). Not sure how to do that in one click or command with cli git…
Can you reword/split commits without having them checked out, or without touching the working directory? That’s what these criteria are about, and from your description, it doesn’t sound like you can do those directly in Sublime Merge.
The specific issue was already answered on the orange site, thanks for your comment there. Side note, I saw an interactive comment inside the article. That inline comment and the ability to select and then comment looks amazing, could you please elaborate on that a bit? How does that work, or what is the software called you use? I see discuss, but the inline comment links to GitHub?
Reword and preview are great ideas, and truly a shame most UIs don’t implement it.
I’m no so convinced split can be well implemented. If I can only split by file, not by line, it’s a crippled version of a real rebase. But I can’t really conceive of a ui to split by lines that would not let me make additional changes to the file, at least not of a good one.
Sync sounds horrible, but that’s surely a reflection of my own workflows. I’m sure other people have reasons to want it, and I’d just probably never use it.
I’m not sure why undo is better than revert, other than at the HEAD of a branch.
The large ops are self evidently good ideas, but I also think most UIs handle it reasonably well.
I’ve been using VSCode’s gitlens + another extension just for visualizing the commit tree.
From gitlens, what I like is the interface for git add -p: is pretty intuitive, only improvement I’d like is a better ui for composing commit messages.
The one thing git lens lacks is a good tree view. A good tree view is large, shows all branches, tags, stashes, allows renaming them, at the least, and gitlens gets maybe one of these right.
For a good tree view I’ve been using Ungit. It’s interface is a bit too spacious for my liking, but it gives you a ton of control over your branches. Could be better if it showed stashes in the same view as well, but it might grow a bit out of hand with it’s interface.
What I want is Git for Git. My Git history is a collaboratively created document that describes the creation of my software projects. Why can I only have one version of that document? Why can’t I make non-destructive edits to it and keep old versions of it?
I think the example workflows are a bit too… low-level?
Most users would never need “split” in their day-to-day workflow. Sync should be completely automatic 90% of the time and the user should only be aware of it in case of a merge conflict.
The downfall for most “git clients” is that it’s trying to be more “git”. Meanwhile, modern software development workflow mostly cares about shipping “changes”. There is a great distance between the 2 concepts and frankly, I think “changes” could be a lot simpler to design UX-wise.
It’s not clear to me what kind of edits you’d like to make and preserve, but Mercurial’s commit evolution feature is sometimes described as source control for your source control. My git-branchless tool linked in the article implements it as well. Jujutsu generalizes it with an “operation log”.
2 tools which vastly improved my git usage: git-revise helps with the edit and split of commits. git-absorb does automatic fixup commits.
And since v2.38 git can automatically rebase dependent branches, which I rely on too.
I often use Sublime Merge to reword commits (edit commit message), or to split up commits (it undoes the commit and you get everything in the working directory), so I’m not sure if this table is entirely correct. (At least from a user point of view I can easily edit or reword).
One other nice feature is the squashing of two commits, ignoring the latters message (as a fixup). Not sure how to do that in one click or command with cli git…
Can you reword/split commits without having them checked out, or without touching the working directory? That’s what these criteria are about, and from your description, it doesn’t sound like you can do those directly in Sublime Merge.
The specific issue was already answered on the orange site, thanks for your comment there. Side note, I saw an interactive comment inside the article. That inline comment and the ability to select and then comment looks amazing, could you please elaborate on that a bit? How does that work, or what is the software called you use? I see discuss, but the inline comment links to GitHub?
It’s custom. I’ve written this blog post for you: https://blog.waleedkhan.name/interactive-blogs/
This is neat, thank you!
Reword and preview are great ideas, and truly a shame most UIs don’t implement it.
I’m no so convinced split can be well implemented. If I can only split by file, not by line, it’s a crippled version of a real rebase. But I can’t really conceive of a ui to split by lines that would not let me make additional changes to the file, at least not of a good one.
Sync sounds horrible, but that’s surely a reflection of my own workflows. I’m sure other people have reasons to want it, and I’d just probably never use it.
I’m not sure why undo is better than revert, other than at the HEAD of a branch.
The large ops are self evidently good ideas, but I also think most UIs handle it reasonably well.
I’ve been using VSCode’s gitlens + another extension just for visualizing the commit tree.
From gitlens, what I like is the interface for git add -p: is pretty intuitive, only improvement I’d like is a better ui for composing commit messages.
The one thing git lens lacks is a good tree view. A good tree view is large, shows all branches, tags, stashes, allows renaming them, at the least, and gitlens gets maybe one of these right.
For a good tree view I’ve been using Ungit. It’s interface is a bit too spacious for my liking, but it gives you a ton of control over your branches. Could be better if it showed stashes in the same view as well, but it might grow a bit out of hand with it’s interface.
What I want is Git for Git. My Git history is a collaboratively created document that describes the creation of my software projects. Why can I only have one version of that document? Why can’t I make non-destructive edits to it and keep old versions of it?
I think the example workflows are a bit too… low-level?
Most users would never need “split” in their day-to-day workflow. Sync should be completely automatic 90% of the time and the user should only be aware of it in case of a merge conflict.
The downfall for most “git clients” is that it’s trying to be more “git”. Meanwhile, modern software development workflow mostly cares about shipping “changes”. There is a great distance between the 2 concepts and frankly, I think “changes” could be a lot simpler to design UX-wise.
It’s not clear to me what kind of edits you’d like to make and preserve, but Mercurial’s commit evolution feature is sometimes described as source control for your source control. My git-branchless tool linked in the article implements it as well. Jujutsu generalizes it with an “operation log”.