[skrebbel]

Am I the only one here who's frustrated by this entire discussion? I've a very strong underbelly feeling that we should simply build tooling that make these entire discussions unnecessary.

I don't mean a non-sucky CLI for git. I mean something more fundamental, something that connects with common programming workflows so well that we can stop discussing the tool altogether.

I'm not sure what that would be, but I hope that one day someone smarter than me will invent it.

[StavrosK]

I've been using bzr for years and its porcelain is much, much more intuitive. I'm amazed how much we're willing to put up with with git because it's popular.

Bzr just does what you mean. Revert reverts, pull pulls, merge merges. I don't have to remember whether I need a soft or hard reset or which takes a file as an argument or which doesn't or which can potentially destroy my changes (also, no command in bzr ever destroys your changes, not even hard reset, it keeps backups you must delete yourself).

[rbehrends]

The main benefit of Bzr in this context is that it inherited Arch's concept of strictly linear, physically separate branches [1] rather than dealing with an arbitrary DAG.

This makes for a simpler mental model and also makes it simpler to keep separate things separate (it also has its downsides, but life is full of trade-offs). It also makes it easier to visualize the revision history and allows one to identify versions globally via branch + serial number rather than a hash.

It is rather unfortunate that Bzr development has stagnated and that DAG-based tools (Git and Mercurial) are the only major players left. Different workflows and organizational requirements benefit from different tools, and the Git/HG monoculture has started to worry me a bit.

[1] To be clear, Bzr has added co-located branches as an option since then on its own.

[dexen]

You mean Darcs [0], which kind-of-sort-of does the rebase automagically. Whenever it can, at least.

Fortunately, Git does 99% of that, and with rebase it's just the right for the job. Especially with git-rerere enabled.

As far as I am concerned, the need to (sometimes!) do rebase by hand is artifact of Git's commit history being strictly ordered by time. But just try to remove that constraint, and whomever considered rebase complex, will go completely crazy ^^

[0] http://darcs.net/

[seliopou]

Came here to say this, and drop this video[1] as well. It explains the differences between git and darcs/camp using an example editing session with both tools.

[1]: http://projects.haskell.org/camp/unique

[aidenn0]

But what about changes that depend on each other that don't happen to edit the same line? Neither git nor camp will be able to detect that (since it relies on semantic knowledge of your application). Merge conflicts are places where the VCS can't even be wrong about what to do, not places where it won't be right.

[Argorak]

Yep. Sadly, camp seems pretty much dead.

[Argorak]

I found darcs quite intuitive to use and not crazy at all. Yes, its not ordered by time, and so is your rewritten history.

[js2]

Git's commit history being strictly ordered by time

That's the default of git log output but can be adjusted via --topo-order and --date-order. It's also worth pointing out that git commits have two timestamps, the author timestamp which is not normally affected by rebasing/amending, and the commit timestamp which is reset by rebasing/amending. Git log (again by default) shows the author timestamp but orders by commit timestamp.

[andybak]

This. I get a similar feeling when I read about the latest javascript workflow innovation.

It signals to me that these tools are complicated in a way that will irritate me and that I should avoid these topics until the smart people have fixed the problem and reached a consensus.

Hey. It worked for CSS. I avoided it for a couple of years and most of the problems have been solved for me. ;-)

[qznc]

Are you still waiting until the vim vs emacs vs Sublime Text 2 debate reaches consensus? Or the Eclipse vs IntelliJ vs IDEA vs VisualStudio debate?

Workflows are very specific and personal. I do not believe that there will be any consensus.

[exclipy]

The problem that --rebase patches up is the ugliness of merge bubbles in git. As soon as you have a merge bubble, tools like gitk won't tell you which is the actual mainline because it's not recorded, and you end up trying to make sense of a tangled mess of a tree. It would all be a non-issue if git could tell which side of the merge bubble was some developer's private commits and hide them away.

Bazaar is one revision control system that does this right. Each commit is tagged with the branch to which it belongs, so any visualization of the commit graph will by default hide all the side commits. History appears neat and linear at first, but if you need to track something down to the original commits, you can expand the merges to see the exact order in which commits were made.

[Murk]

Nobody uses beta max anymore except me. git rulez! etc.

[jules]

Agreed. Git rebase is patching the problem at the wrong end. The problem of elaborate history trees should be solved by grouping & summarizing or hiding sets of commits at the display end, not by rewriting history. Once you have a way of summarizing commits, you can start to do things like integrating version control with the undo of the text editor (with every keystroke being a commit). Another problem with current version control is that it does not understand the structure of code, which makes merges involve much more manual effort than necessary.

[sanderjd]

I have a different reading of the discussion. What I see is that lots of people have different philosophies and workflows, all of which are being supported by git, which is a good thing. What happens when your one-right-tool picks a workflow that I don't like?

[robryan]

The question is, are there better abstractions that would give us all the power we need while simplifying things? Or is to simplify a straight trade on how many use cases the tool will support?

[skrebbel]

i suspect the latter, but i also suspect that there exists an abstraction that makes things significantly simpler while allowing, say, the 95% most common workflows.

These suspicions aren't really based on anything, though.

[rahoulb]

I may be wrong (and I'm too lazy to search) but didn't Linus say that the git command-line is basically a series of dev tools for someone to build a "proper" interface over the top of?

[lloeki]

> Am I the only one here who's frustrated by this entire discussion? I've a very strong underbelly feeling that we should simply build tooling that make these entire discussions unnecessary.

This feeling lasted about five minutes. Then I moved on doing real work.

PS: you won't be able to pry rebase -i and --onto from my cold, dead hands because I'll be clinging on them all the way into whatever form of afterlife.

[dfc]

What is a "strong underbelly feeling"?

[gagege]

It exists and it's called Mercurial :p

[the1]

yah, programs should read programmers' mind and do what we want automagically.