Reinventing the Git Interface (2014)(tonsky.me)
tonsky.me
Reinventing the Git Interface (2014)
http://tonsky.me/blog/reinventing-git-interface/
78 comments
This is spot on. I have observed this very thing happen with co-workers who abuse git aliases to "avoid git complexity." They have an alias for, say, "add everything, commit and push" and they end up committing all kinds of random files to the repository. Or with another alias, they manage to merge random branches into their working branch and they don't understand how that happened.
Another example is the VS Code "git sync" button. I'm never quite sure what's going to happen if I press it. Will my branch get merged with upstream? Or rebased? Am I going to end up with the working tree in the unpredictable state?
This is where the Python guideline "explicit is better than implicit" applies to git perfectly. Git already does a substantial amount of work under the hood with porcelain commands. There is no benefit of stripping git off the fundamental concepts like branches, remotes and staging. It doesn't simplify the conceptual understanding of git, but only obscures the git behavior.
Another example is the VS Code "git sync" button. I'm never quite sure what's going to happen if I press it. Will my branch get merged with upstream? Or rebased? Am I going to end up with the working tree in the unpredictable state?
This is where the Python guideline "explicit is better than implicit" applies to git perfectly. Git already does a substantial amount of work under the hood with porcelain commands. There is no benefit of stripping git off the fundamental concepts like branches, remotes and staging. It doesn't simplify the conceptual understanding of git, but only obscures the git behavior.
> VS Code "git sync"
pull† + push, that's it, nothing more.
† that is fetch + merge or fetch + rebase depending on the branch.<branchname>.rebase git config entry
pull† + push, that's it, nothing more.
† that is fetch + merge or fetch + rebase depending on the branch.<branchname>.rebase git config entry
Strongly disagree, the software should always list/show the files being commited in a little pop-up, if you see it is comitting a lot of files or something very big you should be able to press a "cancel" button; you know, like a regular OS file-copying dialog works.
That's fine but the article doesn't mention any popups. It just makes it sound like all of this will happen in the background without bothering the user.
Having worked with people who use these types of magic GUI tools that "hide the complexity" of $VCS, this shit happens all the time.
When they exist, popups are clicked through and ignored just as they are in every other computing context. And in the end, these tools are just a shorthand for "I don't have the time, desire, and/or motivation to understand how to operate the tools I rely on for work."
Not to argue that that perspective is bad or wrong, it just is what it is. And when someone doesn't understand a tool that operates an inherently complex system, it will inevitably lead to misuse.
When they exist, popups are clicked through and ignored just as they are in every other computing context. And in the end, these tools are just a shorthand for "I don't have the time, desire, and/or motivation to understand how to operate the tools I rely on for work."
Not to argue that that perspective is bad or wrong, it just is what it is. And when someone doesn't understand a tool that operates an inherently complex system, it will inevitably lead to misuse.
I'm sure this has been posted before, but regardless it's still extremely relevant.
It's been almost 3 years now since this article was written, and I've still yet to see a git UI which is anywhere near as good as the one proposed here in terms of functionality and UX.
If a GUI like this is ever implemented, I might finally be able to use something besides the CLI for my git client.
It's been almost 3 years now since this article was written, and I've still yet to see a git UI which is anywhere near as good as the one proposed here in terms of functionality and UX.
If a GUI like this is ever implemented, I might finally be able to use something besides the CLI for my git client.
GitKraken [1] has quite a few features that are very similar to what is shown in the article:
* Switching branches with dirty working copy does an auto stash/pop (also stashes are shown visually in the timeline attached to the branch)
* You can do a commit by editing the placeholder text in the timeline (though there's still a distinction between working copy and staged)
* You can shift+click multiple commits and squash merge them
* You can cherry pick by right-clicking, but not drag-and-drop
* You can merge or rebase by dragging branches to each other (just found that out, I usually right-click)
* It's a UI, so there's a visual DAG tree (and it's fairly nice looking)
I have no affiliation with the company, I've just been using it for the past several months.
[1] https://www.gitkraken.com/features
* Switching branches with dirty working copy does an auto stash/pop (also stashes are shown visually in the timeline attached to the branch)
* You can do a commit by editing the placeholder text in the timeline (though there's still a distinction between working copy and staged)
* You can shift+click multiple commits and squash merge them
* You can cherry pick by right-clicking, but not drag-and-drop
* You can merge or rebase by dragging branches to each other (just found that out, I usually right-click)
* It's a UI, so there's a visual DAG tree (and it's fairly nice looking)
I have no affiliation with the company, I've just been using it for the past several months.
[1] https://www.gitkraken.com/features
> I'm sure this has been posted before
Original discussion (41 points, 12 comments):
https://news.ycombinator.com/item?id=7906511
Original discussion (41 points, 12 comments):
https://news.ycombinator.com/item?id=7906511
Git has `git log --gra.....` actually no nevermind that's far too obscure and useless. Just use `tig`. TUIs are generally more useful than GUIs in my experience anyway.
> Git has `git log --gra.....`
I have an alias `git lg` which does basically that. The only problem is that once I run that command and have that nice, pretty DAG, I can't manipulate any of those commits directly; I'm stuck manipulating the commit graph indirectly by typing out commands and copy-pasting commit hashes into the terminal. A decent GUI like the one described in this article would fix that.
I have an alias `git lg` which does basically that. The only problem is that once I run that command and have that nice, pretty DAG, I can't manipulate any of those commits directly; I'm stuck manipulating the commit graph indirectly by typing out commands and copy-pasting commit hashes into the terminal. A decent GUI like the one described in this article would fix that.
Ha, I also use that alias. Simple operations can be done directly in gitk (moving branches etc.) but a real solution that'd make `git lg` editable would be an incredible boon.
meh. I'm starting to hate using GUIs reaching out for the mouse is almost as irritating as clicking it. Since my hands are already on the keyboard, I may as well type... Maybe that's why this is unimplemented. Maybe I'm not alone.
The way I see it, the git DAG is fundamentally a graphical data structure, so it makes perfect sense to be able to manipulate it using a graphical interface. The only problem is there aren't really any UIs that take full advantage of git's nature as a DAG yet (at least, AFAIK).
While I've yet to find a git GUI which approaches the same level of functionality the git CLI possesses, I think something like the UI proposed here might be good enough to finally get me to switch.
While I've yet to find a git GUI which approaches the same level of functionality the git CLI possesses, I think something like the UI proposed here might be good enough to finally get me to switch.
> Maybe I'm not alone
Come on, you're on HN afterall.
I personally work a lot better with git when using a GUI. It's faster for me to click-click-click the files I want to include in my commit, type up my message in a box and hit commit than it is to stop and think about adding each file and the syntax I need to use when commiting and should I push as well for this project?
On top of that, the client interface I have is in-built diff that makes it easy to navigate files and folders for differences with colour-coded boxes and icons to quickly tell what it is I'm doing in this commit.
That's not to say I don't understand the value of CLI tools and I don't love some of them a lot more than any GUI counterpart, but different tools call for different ways of use. And for me and git - git CLI is only for headless boxes, automated tools and servers I'm working on.
Come on, you're on HN afterall.
I personally work a lot better with git when using a GUI. It's faster for me to click-click-click the files I want to include in my commit, type up my message in a box and hit commit than it is to stop and think about adding each file and the syntax I need to use when commiting and should I push as well for this project?
On top of that, the client interface I have is in-built diff that makes it easy to navigate files and folders for differences with colour-coded boxes and icons to quickly tell what it is I'm doing in this commit.
That's not to say I don't understand the value of CLI tools and I don't love some of them a lot more than any GUI counterpart, but different tools call for different ways of use. And for me and git - git CLI is only for headless boxes, automated tools and servers I'm working on.
I do feel this way. I use mosh+tmux+emacs and do everything on the command line. My MBP is a very egregious machine that lets me use it as a very social, very smart terminal connecting into a cloud server. If my team adopts this tool, I probably would opt-out.
However, my thinking and feeling about this has also been shifting in the past year. I've been slowly accepting more leadership functions where I work. My sense of myself as the heroic developer is eroding. I, as a single person, do not scale as well as a team. I'm learning about neurodiversity, how to be inclusive, what its advantages are. I'm learning about architecture in a different way -- understanding it as the empty space where best practices will naturally arise. So a lot of things are shifting in that, a year ago, I would not only feel this way about the tool, I would dismiss it as well. Now, I'm thinking of how this would benefit the team.
Being the person on my team called in to perform git black magic, I've watched different people struggle with git. Having used git a lot, many of the basic git operations are practiced to the point of effortlessness. I don't really think much about the basics, and as such, I can compose those basics in higher-level operations. Many of the people on my team have not gotten to that point yet. By simplifying unnecessary concepts, someone would be able to use that version control to express higher level things.
This proposed design covers many of the pain points. This includes writing it as a web backend (gitup will not work for our team and our tooling). I think it also enables collaboration I'd like my team to have (auto syncing branches for the whole team? hell yeah), but right now, is not doing so because git is too hard to use. I'm thinking of "empty space" here: I think this tooling shapes the empty space such that, the "best practice" is also "least effort", so people will naturally do the right things when it comes to version control and sharing code.
For that, I'd support its use. Maybe not enough for me to give it up on my own workflow, but even that might change.
I hope the author will develop this tool. The design is thoughtful and brilliant. Our team can sure use it.
However, my thinking and feeling about this has also been shifting in the past year. I've been slowly accepting more leadership functions where I work. My sense of myself as the heroic developer is eroding. I, as a single person, do not scale as well as a team. I'm learning about neurodiversity, how to be inclusive, what its advantages are. I'm learning about architecture in a different way -- understanding it as the empty space where best practices will naturally arise. So a lot of things are shifting in that, a year ago, I would not only feel this way about the tool, I would dismiss it as well. Now, I'm thinking of how this would benefit the team.
Being the person on my team called in to perform git black magic, I've watched different people struggle with git. Having used git a lot, many of the basic git operations are practiced to the point of effortlessness. I don't really think much about the basics, and as such, I can compose those basics in higher-level operations. Many of the people on my team have not gotten to that point yet. By simplifying unnecessary concepts, someone would be able to use that version control to express higher level things.
This proposed design covers many of the pain points. This includes writing it as a web backend (gitup will not work for our team and our tooling). I think it also enables collaboration I'd like my team to have (auto syncing branches for the whole team? hell yeah), but right now, is not doing so because git is too hard to use. I'm thinking of "empty space" here: I think this tooling shapes the empty space such that, the "best practice" is also "least effort", so people will naturally do the right things when it comes to version control and sharing code.
For that, I'd support its use. Maybe not enough for me to give it up on my own workflow, but even that might change.
I hope the author will develop this tool. The design is thoughtful and brilliant. Our team can sure use it.
This. By the time you get good enough at Git to make a reasonable GUI, you don't need/want it anymore.
GUI doesn't mean it has to be handled by mouse, good GUIs (for devs) support keyboard-only input, e.g. ctrl+b shows a branch selection list. The graphical part can be used only for better understanding of state and history of the repo.
That's why I switched to Fossil and now spend more time writing code than trying to deal with Git CLI weirdness.
How is fossil? I've really wanted to use that.
magit[0] solves many of the issues identified here. It's the first tool I've used that makes git feel like a paint brush rather than a camera.
[0] https://magit.vc/
[0] https://magit.vc/
I've been waiting for someone to mention magit. It is the only UI I know of that is more than just a git shell. Real thought went into it and it shows. It is faster and more convenient than the command line, which says a lot.
It's still not as fast as vim-fugitive for example. I know magit does more in nicer ways but the delay when staging, for example, is noticeable and can be annoying over time.
I'm not sure I follow. I hit s on my file in the Magit buffer and it's staged instantly; what delay are you referring to?
On my machine it takes like 400ms until it's staged.
When working in vim, staging really instant.
I stopped following magit closely after the big rewrite, but magit is goldmine, so lean and so mean.
I use CLI for almost everything except git after discovering gitup.
> Everything is a commit. Treat working copy and staging area as commits, allow regular commit operations to be applied to them
That… silly. No. That doesn't make any sense at all.
That… silly. No. That doesn't make any sense at all.
Why not?
A commit is essentially just a snapshot of the state of files in the repository, so IMO it makes perfect sense to treat the staging area and working copy the same as commits.
A commit is essentially just a snapshot of the state of files in the repository, so IMO it makes perfect sense to treat the staging area and working copy the same as commits.
For one, I try to keep my commits as "atomic units of functionality", not just state snapshots. I often have three or four commits' worth of changes in my working copy, and sort through them carefully when one is complete to create a commit of only that small piece of functionality.
Right... now your working copy is just a commit named WIP that sits at the top of the branch and is updated (--amend style) in real time. Wait! let me finish:
So now you decide you want to move a part of the delta from WIP into a real commit. So split it and move some of the delta from WIP into the split and rename the split. It's the same workflow!
So now you decide you want to move a part of the delta from WIP into a real commit. So split it and move some of the delta from WIP into the split and rename the split. It's the same workflow!
But surely "your workflow can be re-implemented in this different interface" is merely an argument that the different interface has not lost power, rather than necessarily that it is as good as (or even better than) the existing interface?
I'd prefer to phrase it as "this different interface also supports your workflow".
Whether the different interface is better or not is completely independent from when it was developed in relation to an existing interface. For example, I find debit cards a much preferable interface to the "pay for things from your bank account" workflow over writing checks, and checks were developed much earlier. :)
An interface is only as good as the power it gives you. Recall that power is work/time, so you can increase power by increasing work or decreasing time [1]. It's better if it's easier or faster to use and you can overcome the transition/initial learning costs. I'd guess that the vast majority of typical users of git have to pull up the git man pages (or stackoverflow) to do most of the actions shown in this article, hinting that such an interface may both save time and increase work (users often just not do stuff that they have to research to accomplish).
[1]: Ok, I might be stretching the physics analogy a bit. :P
Whether the different interface is better or not is completely independent from when it was developed in relation to an existing interface. For example, I find debit cards a much preferable interface to the "pay for things from your bank account" workflow over writing checks, and checks were developed much earlier. :)
An interface is only as good as the power it gives you. Recall that power is work/time, so you can increase power by increasing work or decreasing time [1]. It's better if it's easier or faster to use and you can overcome the transition/initial learning costs. I'd guess that the vast majority of typical users of git have to pull up the git man pages (or stackoverflow) to do most of the actions shown in this article, hinting that such an interface may both save time and increase work (users often just not do stuff that they have to research to accomplish).
[1]: Ok, I might be stretching the physics analogy a bit. :P
> For one, I try to keep my commits as "atomic units of functionality", not just state snapshots. I often have three or four commits' worth of changes in my working copy, and sort through them carefully when one is complete to create a commit of only that small piece of functionality.
Given that this is not a universal working model, your explication of your working model, and why it makes the proposed interface not appropriate for you, seems like a much more useful comment than "That… silly. No. That doesn't make any sense at all."
Given that this is not a universal working model, your explication of your working model, and why it makes the proposed interface not appropriate for you, seems like a much more useful comment than "That… silly. No. That doesn't make any sense at all."
To you, mayhaps. You'd be surprised in how many different ways people use tools.
This is the first time I've read a complaint/discussion/review/whatever of git's UI and thought 'wow yeah I actually agree this would be useful'.
I would still use the command line, a lot, but the times that I open `gitk --all --date-order` and a terminal side by side and refresh the gitk whenever I do a command to see what happens? THOSE are the times I would use this.
I would still use the command line, a lot, but the times that I open `gitk --all --date-order` and a terminal side by side and refresh the gitk whenever I do a command to see what happens? THOSE are the times I would use this.
Hi,
Have you given a try to: http://gitup.co/
There not everything you wanted, but maybe...
gitup looks neat, but unfortunately macOS only.
It is Mac only, but it is open source (Obj-C). Some enterprising developer could port it to Windows or Linux.
https://github.com/git-up/GitUp
https://github.com/git-up/GitUp
> You may have noticed that Git warns you a lot. Rebase is dangerous, headless state is dangerous, don’t do push -f, are you sure, think twice, you’re not supposed to do that, stuff like that
Hmmm…
> Remove warnings as Git repo is immutable and cannot lose data
Ok this is a great response!
There's also this wishlist/proposals for git log[0], which are extremely exciting to think about; it's from 2012, so even older than the article…
[0]: https://gist.github.com/datagrok/4221767
Hmmm…
> Remove warnings as Git repo is immutable and cannot lose data
Ok this is a great response!
There's also this wishlist/proposals for git log[0], which are extremely exciting to think about; it's from 2012, so even older than the article…
[0]: https://gist.github.com/datagrok/4221767
It's not completely true, you can easily lose data in Git by accident. Here's an example. Suppose we have a single "master" branch, pointing to commit A. You create a new "feature" branch, making commits B, and then C. You realize that B and C are actually unrelated, so you want each of them to have separate branches. You git rebase --interactive onto master, picking only commit C. This way feature branch has commit C with parent A. Now, you git checkout commit B, which should put you into detached HEAD state, from which you plan to create a second feature branch. Alas, something has triggered git gc in the meantime, and commit B has been garbage collected, as it was no longer pointed to by anything.
Something like this happened to me, breaking the whole Chromium repo for half an hour. Definitely not fun.
Something like this happened to me, breaking the whole Chromium repo for half an hour. Definitely not fun.
> You git rebase --interactive onto master, picking only commit C.
So during an interactive rebase you drop one commit, and pick the other, then are upset at git for dropping your commit? It did exactly what you asked of it.
This would have easily been avoided if you had branched off your feature branch into a new one and did the interactive rebase there. Your old feature branch is still present, which you could rebase interactively, or drop HEAD so you only have the other commit, or whatever other thing to meet its needs.
So during an interactive rebase you drop one commit, and pick the other, then are upset at git for dropping your commit? It did exactly what you asked of it.
This would have easily been avoided if you had branched off your feature branch into a new one and did the interactive rebase there. Your old feature branch is still present, which you could rebase interactively, or drop HEAD so you only have the other commit, or whatever other thing to meet its needs.
Sure, I know now exactly what happened, and what I should have done in order to avoid it. My point here is that "Git repo is immutable and cannot lose data" is a lie, and people who believe it (like I did at the time -- hey, if anything breaks on rebase, I can always git reflog and reset to good state, right?) will have a bad time at some point down the line, so it's better to stop this lie from spreading.
That's odd. gc shouldn't be collecting anything less than 2 weeks old by default.
That's not exactly what happened, but the idea is the same. You can add a 2 week vacation in the meantime if it helps you imagine it.
I would recommend taking advantage of git's incredibly cheap branches and drop a lifesaving breadcrumb on all the commits I was planning to keep. One of the first steps I tell people when showing the rebase workflow is leaving behind a 'safe' marker, and how to reset back to it if the rebase gets too hairy.
This is a great UX rethink along actual user needs. It's unusual to see someone with more-than-superficial knowledge of git that also has enough product sense to come up with something like this.
My team has varying levels of git skill, including product owners and testers. I am usually called in to do the git black magic -- and I only know a fraction of what is available on git. My git magic doesn't scale. Further, because we are using our dev environment in a VM, a remote client is harder to work with. Making this web-based would work out very well for us. (And power users can still use the command line tool instead).
I hope this comes to fruition. My team can sure use it.
My team has varying levels of git skill, including product owners and testers. I am usually called in to do the git black magic -- and I only know a fraction of what is available on git. My git magic doesn't scale. Further, because we are using our dev environment in a VM, a remote client is harder to work with. Making this web-based would work out very well for us. (And power users can still use the command line tool instead).
I hope this comes to fruition. My team can sure use it.
Now I'm wishing GitUp had this selection tool. Sadly you can only do operations one commit/branch at a time.
Just stop using Git. Jeez. I don't get it. It is a fundamentally broken tool. Why do people insist on using it? I have been confused about this for years. Just use something else. ANYTHING else.
I understand the usefulness (and popularity) of GitHub. It is a great tool for collaboration. Its just too bad that it uses git as the underlying vcs. I wish there was a decent competitor to GitHub with a different vcs so we could see if people would make the switch. Oh well. Maybe someday.
I understand the usefulness (and popularity) of GitHub. It is a great tool for collaboration. Its just too bad that it uses git as the underlying vcs. I wish there was a decent competitor to GitHub with a different vcs so we could see if people would make the switch. Oh well. Maybe someday.
Usually when giving out criticism it is wise to be specific.
In this case, git can be awkward to use, but the underlying architecture is sound and it's a welcome change to centralised version control systems (CVS/SVN/Perforce).
Not saying you're wrong of course, but as far as I currently understand it's objectively better on all fronts except UX for DVCS. Perforce is undoubtedly better but it relies on a constant connection to a server.
In this case, git can be awkward to use, but the underlying architecture is sound and it's a welcome change to centralised version control systems (CVS/SVN/Perforce).
Not saying you're wrong of course, but as far as I currently understand it's objectively better on all fronts except UX for DVCS. Perforce is undoubtedly better but it relies on a constant connection to a server.
Don't play coy. The ergonomic shortcomings of git 'porcelain' are discussed here and elsewhere so often that if you don't know what people are talking about you either have a vested interest in deflecting, or you have actually been living under a rock.
If the latter, save yourself, don't read the newspaper. It's too late for the rest of us.
If the latter, save yourself, don't read the newspaper. It's too late for the rest of us.
Most people moved from something like CVS/SVN/Perforce to Git. There are also a lot of people who started using Git at their first job. And most of these developers think of it as the same thing as GitHub. As others have said on this thread, you could try Mercurial. It is pretty nice. More user friendly than Git. But it does not do branching well. The original design did not include "named" branches, it was added later. Because of this it feels like it.
The usual way that people work in Mercurial is to make a clone - which is a whole copy. If you were working in SVN you would probably make a branch first (on the server), and then check out that branch. When you are done with your branch, you get up to date with trunk, then merge it in. And, this is the important part, your merge is treated as one commit. Pretty normal stuff. Mercurial though threads all your local commits into the log. So even though you make one merge, you can't find that merge in the log. All the commits are shown stuffed in there by date. And everyone is sad.
Now, you can change that if you use named branches instead of cloning. But it has other problems. The biggest one is you get "multiple heads." If I make a branch and you make a branch and we both commit, they both get stored in the index. But they get stored as different heads. So when I do a "pull" I get this strange warning about multiple heads - the "trunk" and your branch. I'm actually still not sure how to unwind it actually. I'm not enough of an expert.
So I try to user Bazaar wherever I go. It doesn't always happen - it is hard to change people's minds or have a company that is flexible enough to try different solutions. And, because Git is so popular, there is an integration with just about everything. For a 3-rd party candidate like Bazaar IDE integration is half-baked. So is Jira integration. Actually, just about all integrations. I'm considering becoming a committer on like 10 different Bazaar-related projects. :)
Check this out: https://duckrowing.com/2014/04/25/git-vs-mercurial-vs-bazaar... Yes GitHub is popular. But out there in the non-Opensource world, Git is WAY behind SVN. Which is totally fine. Use what works. If you have a centralized development organization, and everyone sits near each other and talks all the time, why do you need distributed VCS? And if everyone at the company knows how to use a tool and there aren't constant mistakes - just use it. It gets easy to not be able to see the forest for the trees when you spend 6 hours trying to figure out how to rewind a busted git repo.
The usual way that people work in Mercurial is to make a clone - which is a whole copy. If you were working in SVN you would probably make a branch first (on the server), and then check out that branch. When you are done with your branch, you get up to date with trunk, then merge it in. And, this is the important part, your merge is treated as one commit. Pretty normal stuff. Mercurial though threads all your local commits into the log. So even though you make one merge, you can't find that merge in the log. All the commits are shown stuffed in there by date. And everyone is sad.
Now, you can change that if you use named branches instead of cloning. But it has other problems. The biggest one is you get "multiple heads." If I make a branch and you make a branch and we both commit, they both get stored in the index. But they get stored as different heads. So when I do a "pull" I get this strange warning about multiple heads - the "trunk" and your branch. I'm actually still not sure how to unwind it actually. I'm not enough of an expert.
So I try to user Bazaar wherever I go. It doesn't always happen - it is hard to change people's minds or have a company that is flexible enough to try different solutions. And, because Git is so popular, there is an integration with just about everything. For a 3-rd party candidate like Bazaar IDE integration is half-baked. So is Jira integration. Actually, just about all integrations. I'm considering becoming a committer on like 10 different Bazaar-related projects. :)
Check this out: https://duckrowing.com/2014/04/25/git-vs-mercurial-vs-bazaar... Yes GitHub is popular. But out there in the non-Opensource world, Git is WAY behind SVN. Which is totally fine. Use what works. If you have a centralized development organization, and everyone sits near each other and talks all the time, why do you need distributed VCS? And if everyone at the company knows how to use a tool and there aren't constant mistakes - just use it. It gets easy to not be able to see the forest for the trees when you spend 6 hours trying to figure out how to rewind a busted git repo.
It's a broken tool if you think of it as an evolution of traditional revision control system (rcs/cvs and svn).
Once you realize that git is a beast of a different taxonomy class - file system with history awareness (or more precisely, a content addressable storage), then all of a sudden things could make sense.
I highly recommend starting with Git From The Bottom Up or Git From The Inside Out early while learning git. Even better if you can spare the time - Pro Git (https://git-scm.com/book).
Once you realize that git is a beast of a different taxonomy class - file system with history awareness (or more precisely, a content addressable storage), then all of a sudden things could make sense.
I highly recommend starting with Git From The Bottom Up or Git From The Inside Out early while learning git. Even better if you can spare the time - Pro Git (https://git-scm.com/book).
What's fundamentally wrong with it? I haven't used anything else, and therefore don't have great context. Haven't felt like anything about it is horrible, though.
If you had enough time to kill to read the original post above and you have some more time to kill, this is a really good write-up about git/hg/bzr.
https://duckrowing.com/2013/12/26/bzr-init-a-bazaar-tutorial...
Bazaar's model is based around branches. Make a branch, change stuff, commit, merge. Merges are like top-level things. When you read the log you get only the commits to that branch (like, say, "trunk"). If all you ever do is merge to trunk, you only see merges. Fancy trick - you can show nested commits in the log. So "bzr log -n3" shows you the merges, but all the commits that went into that merge. It really is super nice and very easy to use. And a lot of that ease of use is because the mental model makes sense.
Oh, and branches are stored as paths - that's right, folders. Instead of storing multiple versions of code in an "index" that you can't actually see, Bazaar just uses folders.
/workspace/my-project /trunk/ /the-thing-with-the-stuff/
So comparing files means... comparing two files. I don't actually have to use the VCS's commands to compare things. I could - I just don't have to. You can get diffs between a particular revision of a file (or folder). Or you could make a new branch (folder) at a particular revision. Then you can just actually look at all the files.
I know SVN does this too. And CVS. And probably Perforce. I just think people have forgotten how reasonable some of the older tools actually were/are. Bazaar does a good job keeping that ease while also being distributed.
https://duckrowing.com/2013/12/26/bzr-init-a-bazaar-tutorial...
Bazaar's model is based around branches. Make a branch, change stuff, commit, merge. Merges are like top-level things. When you read the log you get only the commits to that branch (like, say, "trunk"). If all you ever do is merge to trunk, you only see merges. Fancy trick - you can show nested commits in the log. So "bzr log -n3" shows you the merges, but all the commits that went into that merge. It really is super nice and very easy to use. And a lot of that ease of use is because the mental model makes sense.
Oh, and branches are stored as paths - that's right, folders. Instead of storing multiple versions of code in an "index" that you can't actually see, Bazaar just uses folders.
/workspace/my-project /trunk/ /the-thing-with-the-stuff/
So comparing files means... comparing two files. I don't actually have to use the VCS's commands to compare things. I could - I just don't have to. You can get diffs between a particular revision of a file (or folder). Or you could make a new branch (folder) at a particular revision. Then you can just actually look at all the files.
I know SVN does this too. And CVS. And probably Perforce. I just think people have forgotten how reasonable some of the older tools actually were/are. Bazaar does a good job keeping that ease while also being distributed.
What VCS do you use?
I try to use Bazaar. :) Don't laugh. You probably have never heard of it. If you have you probably forgot about it soon afterwards. It is distributed VCS just like Git and Mercurial. But the model of how data is stored and accessed just feels nicer. It doesn't just feel nicer, it is nicer. Special bonus, the commands make sense and are similar to commands you may have been used to with SVN.
> This brings very important addition to the table — ability to explicitly checkout STAGED version. Git’s index won’t allow you that.
Of course it will. In fact, that's very much what `git checkout` does if you don't give a revision but give a path, e.g. `git checkout .`. (but then you lose any unstaged changes)
Of course it will. In fact, that's very much what `git checkout` does if you don't give a revision but give a path, e.g. `git checkout .`. (but then you lose any unstaged changes)
I recently discovered the magical incantation:
It's perfect if you need to find an old commit to undo a rebase, or if you accidentally deleted a branch. It really should be a button in GUIs called "show all commits" or something". I even posted a bug in gitx suggesting they add the feature: https://github.com/gitx/gitx/issues/78
Source: http://stackoverflow.com/a/91795/3408
gitk --all $( git fsck --no-reflog | awk '/dangling commit/ {print $3}' )
It's perfect if you need to find an old commit to undo a rebase, or if you accidentally deleted a branch. It really should be a button in GUIs called "show all commits" or something". I even posted a bug in gitx suggesting they add the feature: https://github.com/gitx/gitx/issues/78
Source: http://stackoverflow.com/a/91795/3408
have u heard about tig? try it
>You may think auto-sync will completely ruin your familiar “commit now, restructure later” workflow. It will not. As you’re working in your branch, you can still reorganise, restructure, reorder and rename commits in your branch. These changes will be incrementally synced to all other peoples’ machines as you go. They’ll initially see your mess, but then they’ll see all the changes you’re doing to make your branch look pretty. All happening without any manual button clicking/remotes selections/any other decisions from them. As this branch is yours, it’s a perfectly safe and does not require any human intervention.
One of the biggest missed opportunities with git is metadata about rebase and history-rewrite operations. If git stuck that information into the log it would be trivial for clients to understand that these commits appear to have different hashes only due to a rebase. The client could even compute the deltas from both tress to compare the supposedly "common" commits, validating that they really are the same (or maybe allow slightly differences to account for rebasing). If the commits claim to have the same ancestry but different deltas it would be up to you to accept your peer's work or to go review/merge.
No more "2 down / 5 up" commits because of a rebase; instead you'd see "3 new (2 rebased)".
One of the biggest missed opportunities with git is metadata about rebase and history-rewrite operations. If git stuck that information into the log it would be trivial for clients to understand that these commits appear to have different hashes only due to a rebase. The client could even compute the deltas from both tress to compare the supposedly "common" commits, validating that they really are the same (or maybe allow slightly differences to account for rebasing). If the commits claim to have the same ancestry but different deltas it would be up to you to accept your peer's work or to go review/merge.
No more "2 down / 5 up" commits because of a rebase; instead you'd see "3 new (2 rebased)".
> One of the biggest missed opportunities with git is metadata about rebase and history-rewrite operations. If git stuck that information into the log it would be trivial for clients to understand that these commits appear to have different hashes only due to a rebase. The client could even compute the deltas from both tress to compare the supposedly "common" commits, validating that they really are the same (or maybe allow slightly differences to account for rebasing). If the commits claim to have the same ancestry but different deltas it would be up to you to accept your peer's work or to go review/merge.
This is ripe for flaming, but this is how mercurial handles rebasing under changeset evolution, and it's pretty much the biggest area where hg gets something right that git got wrong. Basically, it keeps around the old changeset of the rebase and adds a new kind of edge to indicate the update of the rebase, as well as keeping the obsolete changesets from being seen by most users while maintaining them internally. This means that normal rebase operations can see the old and new versions of a changeset as if they were regular changesets. Combined with phases, it's also easy to set up your repositories so that you can never accidentally rebase your master branch.
This is ripe for flaming, but this is how mercurial handles rebasing under changeset evolution, and it's pretty much the biggest area where hg gets something right that git got wrong. Basically, it keeps around the old changeset of the rebase and adds a new kind of edge to indicate the update of the rebase, as well as keeping the obsolete changesets from being seen by most users while maintaining them internally. This means that normal rebase operations can see the old and new versions of a changeset as if they were regular changesets. Combined with phases, it's also easy to set up your repositories so that you can never accidentally rebase your master branch.
Some of the points mentioned are covered by the Ungit tool: https://github.com/FredrikNoren/ungit In terms of how your intended changes are visualized in the DAG model.
I stopped using this tool after getting a beter understanding of Git core and how the commands manipulate the database. But I do still think the changes suggested in the post are valuable. I'm not inline with the whole GUI idea. But I like the concept of 'everything is a commit' and reducing the 'delta algebra' to their basic forms. As my biggest struggle with Git is always to make the translation of my intended change to the database into an abstract Git command.
I stopped using this tool after getting a beter understanding of Git core and how the commands manipulate the database. But I do still think the changes suggested in the post are valuable. I'm not inline with the whole GUI idea. But I like the concept of 'everything is a commit' and reducing the 'delta algebra' to their basic forms. As my biggest struggle with Git is always to make the translation of my intended change to the database into an abstract Git command.
This is especially funny considering the huge discussion recently about rewriting curl and then the entire world in Rust, but imagine you lived in a world where the magical "better tool" already existed and all you had to do was discover it.
Leaving fantasy-land aside for a moment, this morning you woke up in the real world. In the real world, that tool does already exist, and it's called Mercurial.
If you try command-line Mercurial for long enough to get past the initial "oh no Windows/macOS/Linux got updates and moved all my icons" muscle-memory-refresh phase (and especially if you last long enough to get into revsets and templates), you'll find it extraordinarily difficult to go back to using command-line git. Your power grows with Mercurial as you learn more about it because you aren't constantly fighting the complete absence of idioms and opaque "man-page" style of documentation that puts a slab of inscrutable text front and centre and neglects to provide simple examples for common problems (apparently we have a perfectly good Stack Overflow for that).
The git boosters will respond to this by saying, as they always do, "yes, but the real power of git is in the model of the information under the hood. The CLI is just an interface, if you don't like it you should spend months studying the internals and build your own workflow on top of git". Again, back in the real world, who has time for that? Or the interest? Especially when, as I already mentioned, that tool does already exist and it's called Mercurial and you can get started with it right now.
Both tools can do close to exactly the same things under the hood with differences that won't make a lick of difference to the vast majority of users. The user-facing differences are where it really matters: one tool has an excellent CLI which is clear, concise and discoverable; the other has github. Damn. Lousy network effects.
Leaving fantasy-land aside for a moment, this morning you woke up in the real world. In the real world, that tool does already exist, and it's called Mercurial.
If you try command-line Mercurial for long enough to get past the initial "oh no Windows/macOS/Linux got updates and moved all my icons" muscle-memory-refresh phase (and especially if you last long enough to get into revsets and templates), you'll find it extraordinarily difficult to go back to using command-line git. Your power grows with Mercurial as you learn more about it because you aren't constantly fighting the complete absence of idioms and opaque "man-page" style of documentation that puts a slab of inscrutable text front and centre and neglects to provide simple examples for common problems (apparently we have a perfectly good Stack Overflow for that).
The git boosters will respond to this by saying, as they always do, "yes, but the real power of git is in the model of the information under the hood. The CLI is just an interface, if you don't like it you should spend months studying the internals and build your own workflow on top of git". Again, back in the real world, who has time for that? Or the interest? Especially when, as I already mentioned, that tool does already exist and it's called Mercurial and you can get started with it right now.
Both tools can do close to exactly the same things under the hood with differences that won't make a lick of difference to the vast majority of users. The user-facing differences are where it really matters: one tool has an excellent CLI which is clear, concise and discoverable; the other has github. Damn. Lousy network effects.
The team I am on uses git because we want clean and linear commit history.
This means "master" and private branches are very different:
- private branches have lots of random commits which no one will care about once feature is done: "start on feature", "fix typo", "add test", "fix feature", "add interface to foobar", "fix a bug", "fix it for real", "add another function to foobar interface".. and so on
- "master" has a nice, clean history. The corresponding commits would be : "add interfaces to foobar", "add feature"
This means the developers are actually expected to squash/merge/reword their commits before submitting to master. The submit scripts also enforce ff-only merges, so the master is fully linear.
We like this workflow because it has advantages of both SVN -- linear, easy-to-read history, and of git -- you can commit as often as you want and you can share your work easily.
Now, we have users struggle with git periodically, but it looks that trying to use Mercurial in our workflow will be even worse -- most of the Mercurial references seem to disapprove of rebasing in general. Example: http://stackoverflow.com/questions/2672351/hg-how-to-do-a-re...
I understand that this is somewhat unusual workflow; but it illustrates the power of git. You can have a huge variety of the workflows, while Mercurial (and many others) push people towards a single preferred one. And sure, modern hg has "rebase" and "histedit", but they just seem like second-class citizens, and they are much less polished than git's (for example, histedit's man page says " If you drop a change, it's gone forever". Scary! I think I will just use git instead)
This means "master" and private branches are very different:
- private branches have lots of random commits which no one will care about once feature is done: "start on feature", "fix typo", "add test", "fix feature", "add interface to foobar", "fix a bug", "fix it for real", "add another function to foobar interface".. and so on
- "master" has a nice, clean history. The corresponding commits would be : "add interfaces to foobar", "add feature"
This means the developers are actually expected to squash/merge/reword their commits before submitting to master. The submit scripts also enforce ff-only merges, so the master is fully linear.
We like this workflow because it has advantages of both SVN -- linear, easy-to-read history, and of git -- you can commit as often as you want and you can share your work easily.
Now, we have users struggle with git periodically, but it looks that trying to use Mercurial in our workflow will be even worse -- most of the Mercurial references seem to disapprove of rebasing in general. Example: http://stackoverflow.com/questions/2672351/hg-how-to-do-a-re...
I understand that this is somewhat unusual workflow; but it illustrates the power of git. You can have a huge variety of the workflows, while Mercurial (and many others) push people towards a single preferred one. And sure, modern hg has "rebase" and "histedit", but they just seem like second-class citizens, and they are much less polished than git's (for example, histedit's man page says " If you drop a change, it's gone forever". Scary! I think I will just use git instead)
Our team uses Mercurial for exactly the same thing, a clean linear history, with features like phases, and histedit it's very easy to achieve and works great.
We use RhodeCode to manage pull requests for Mercurial. This has also a feature to rebase commits on merge.
We use RhodeCode to manage pull requests for Mercurial. This has also a feature to rebase commits on merge.
Actually, Mercurial keeps all the deleted changesets in .hg/strip-backup. They will stay there forever, unless you delete them by hand.
Mercurial is nowhere near the idilic interface you imply.
E.g. I challenge you to figure out how to use its interface to delete a branch.
http://stackoverflow.com/questions/41968796/how-to-delete-a-...
E.g. I challenge you to figure out how to use its interface to delete a branch.
http://stackoverflow.com/questions/41968796/how-to-delete-a-...
This has nothing to do with the interface and everything with the policy choice of not having mutable history on the server.
If you do enable mutable history (with evolve), then you do it with:
If you do enable mutable history (with evolve), then you do it with:
hg prune <revisions you want to remove>
hg pushYou can close a branch, which makes it stop appearing in the UI unless you explicitly ask for closed branches. You can never fully delete a branch since the branch is part of the commit metadata (as it should be, IMO).
not to mention that a git branch is NOT your typical VCS branch. It's an ephemeral named head, nothing more than a tag (that lives outside of the normal tag interface).
FWIW, the re-written in Rust option is Pijul (https://pijul.org/), not Mercurial. It's still very nascent, but has a lot of promise.
The graphical manipulation stuff sounds cool until you think about what happens when it causes merge conflicts. I mean the graph stuff is still cool but it does very little for the hard problems.
The automatic committing for WIP and "magic" pushing/fetching sounds cool until someone switches branches and accidentally commits 3.1TB of junk files they left lying around and it automatically syncs to EVERYONE else on the project.
People complain now that Git is "too complex" just wait until it's automagically doing shit like that.