8 ms·

Git is pretty nice, but I'm sure there is something much better waiting to he invented. The CLI in particular could use a ton of improvements. And I feel it in

Git is pretty nice, but I'm sure there is something much better waiting to he invented. The CLI in particular could use a ton of improvements. And I feel it in my bones that there is a revolutionary GUI waiting to be invented. Why can't I drag a commit or set of commits from one branch to another? With safe, easy undo (reflog doesn't count) and super smooth conflict resolution? Etc etc. And of course there is the interesting rabbit hole of semanitc / language aware diff. Line diffs suck in many ways. It's one of the hundreds of of problems that I'd love to work on one day, but probably won't get a chance to. Sigh... :)

rk06 7y ago
https://gitless.com/ https://gitless.com/
- saagarjha 7y ago
  Can this tool make the commit history look like I'd like it to?
jayd16 7y ago
>and super smooth conflict resolution? Because the hardest part of conflicts is already the conflicting changes themselves and not the source control.
- IshKebab 7y ago
  Sure but I've never found a GUI or editor that lets me resolve conflicts in the way I want. For example say I change one line of code in a big function. I rebase and that function has moved. Conflict! I want a tool that says "here's what you changed, and here's the current state of the source". None of them do that though - they all just show the conflicts that git writes to disk - the code after you changed it, and the current code. You basically get two copies of the function, one with your change and one without and you have to manually (visually) diff them to work out what you changed (or go back and look at your commit) and then reapply that change to the moved function. It's really awkward and could definitely be better.
  - cozzyd 7y ago
    Have you tried a three-way-merge tool (e.g. vimdiff, meld, kdiff3, surely some emacs way of doing it)?
  - idoubtit 7y ago
    Even without plugin in a three-ways tool, Git's conflict can provide more information. [merge] # display 3 parts for each conflict, # including the common ancestor conflictstyle = diff3 There's also the option to use a semantic merge tool. AFAIK, there are only paying tools for this, and only a few languages are supported.
  - falsedan 7y ago
    I spent some time with `git mergetool` to help resolve conflicts. It's hideous but it's better than staring at inline conflict markers
  - rakoo 7y ago
    What you, and also I, want is a syntax-aware merge tool, i.e. one that can tell you the meaning of the change. If a function got moved to another place, or if 2 fields swapped places, I don't want it to have the same importance as na actual change in behavior. No importance, even. Git's only sense of syntax is recognizing lines, and it's just not enough in too many cases. Sadly in my (short) research everything I have found is either closed source or I can't afford to pay for it. It's even more saddening that git already has built-in bits for syntax related diffs.
  - aasasd 7y ago
    Three-way diff is (probably) what you want. E.g. Intellij Idea uses it by default, and likely plenty of other IDEs and editors do too. You see original code, you changes, and the other side's changes—and where exactly they conflict.
anujsharmax 7y ago
If you use Emacs, give magit (https://magit.vc https://magit.vc) a try. It is so much better than Git CLI, which probably is too low level for daily usage.
- jolmg 7y ago
  I use the CLI for my daily work just fine, thank you. I sometimes turn to magit when I want to navigate a file's history through git-blame, though.
  - tomjakubowski 7y ago
    You're missing out on the lightning fast pull, interactive rebase, staging and commit capabilities of magit-status. The key bindings are intuitive and excellent.
    - jolmg 7y ago
      They are intuitive and excellent, but I don't think they make things that much faster if at all. There's not much difference in speed between doing `C-x g s c -a c` and typing `git ci -a`.
  - aldanor 7y ago
    CLI is fine until you acquire a habit of committing things chunk-wise and line-wise. E.g., I have these 20 files modified, but I'll quickly skim through and add/commit the lines/chunks that are done, and then continue working on the rest. CLI promotes a different kind of workflow, like "ok, I'm done, add/commit it all, and then move on".
    - drchickensalad 7y ago
      What do you feel the UI does better than git add -p? The main concession I have is picking arbitrary files, but I feel like I've achieved 90%+ of what I want with '.cs' or 'Controller*' etc.
gritzko 7y ago
swarmdb has CRDT-based merge and causal branching which is "super smooth". Lets you recombine changesets rather freely, or at least supposed to. https://github.com/gritzko/ron-cxx/tree/master/db https://github.com/gritzko/ron-cxx/tree/master/db (the project is in its early stages) Regarding language-aware AST-based diffs, I know of one serious full-time effort. Even for Java, it turned way too complex, so guys gave up.
batisteo 7y ago
> Git is pretty nice, but I'm sure there is something much better waiting to he invented. It is indeed being invented. It’s called Pijul: http://pijul.org/ http://pijul.org/ This tool is based on strong mathematical theory of patches, instead of snapshot/commit-based. It seems simpler to reason with, but we’d have to unlearn a lot from Git. It’s not suitable for big projects yet, but it’s already used by Pijul itself and other Rust components. And it already have its own „Github” called the Nest (because pijul is a bird). Pretty promising imho.
- afiori 7y ago
  I really like the promise of pijul, but it is early to say if it is better. Conventions and tooling will be a decisive factor in the ease of use. That said I do share your optimism.
- gbersac 7y ago
  Exactly the kind of program which will benefit from being wrote in rust.
- stevekemp 7y ago
  I had a sudden flashback to using darcs, which was also based upon patches instead of commits. darcs was nice, up until you hit the exponential merge problem.
  - afureta 7y ago
    I don't know about Pijul, but it claims to have solved the exponential merge problem. https://pijul.org/faq/ https://pijul.org/faq/
  - pmeunier 7y ago
    I'm one of the authors. Pijul is indeed heavily inspired by Darcs, but we solved that problem completely. All our algorithms are in time at most log of the size of history, which is a double-exponential improvement over Darcs' worst case complexity.
- dahart 7y ago
IshKebab 7y ago
I agree. I did find one GUI that at least lets you drag & drop branch labels (GitX) but it's a bit buggy and Mac-only. It doesn't let you rebase via drag & drop, or cherry-pick via copy & paste. Those are pretty obvious mappings and would make Git way more obvious.
afiori 7y ago
> Why can't I drag a commit or set of commits from one branch to another? It was disappointing to me that web interfaces do not offer something like this
rusk 7y ago
The Git support in the Jetbrains IDEs is very good. I'll often fire up IntelliJ if I'm too tired to try and figure out how to figure out what's going on.
aasasd 7y ago
I feel like Git's concepts got tied into a mess in its cli tools. Like the devs maybe tried to imagine what would be the proper interface for a person not deeply familiar with the innards, but failed, and e.g. `git-show` is the result. So I get this vague feeling that someone could build a better human-oriented suite of CLI tools on top of Git's internals―with the internals better mapped to people's more casual understanding of the concepts and their aims. But that someone isn't me, yet.
andrewla 7y ago
> And I feel it in my bones that there is a revolutionary GUI waiting to be invented. Why can't I drag a commit or set of commits from one branch to another? With safe, easy undo (reflog doesn't count) and super smooth conflict resolution? Etc etc. The model of git feels very nice and intuitive once you grasp the central architecture -- an immutable append-only content-addressed file system. The changes mentioned here in particular just don't really fit the model. You can certainly argue that we need a better model, but in order to move commits between branches in anything other than a mechanical manner, you would have to deal with the fact that often in source code repositories there are semantic connections between unrelated changes -- one file has a change to update its interface, the other file changes to use the old interface, and now you have something that no general-purpose version control software can reasonable reconcile or even identify as an issue. Arguable there's a space for merging tools that build on the git model and contain language semantic information, so it can actually highlight conflicts that are deeper than patch-based, but until then I'd prefer that the version control system not try to be too smart and let me repair things after it does its mechanical actions. > The CLI in particular ... Line diffs suck in many ways These are changes that I think are in line with what I see in the future of git -- because git just contains a series of snapshots of a hierarchical tree, diffs are a secondary thing that an external tool can be brought to bear on very easily -- rather than trying to merge patches to create a diff, you actually have two fully realized files, together, potentially, with their common ancestor, which is all the information necessary to create a fully semantics-aware diff between files or trees. I would almost want git to double-down on the grammar of tree changes; commands like "checkout" and "reset" are very basic manipulations with fairly clear idioms. But since those words are also English words that carry a whole bunch of connotations, it makes it confusing when you use "reset" to do something that does not involve returning something to its original state. Having a "worse" command line interface, with some commands like "git make-my-working-tree-look-like-this-ref" and "git point-this-ref-to-this-other-ref" would break the connection with traditional version control systems while allowing us to use the full power of the git model.
JohnFen 7y ago
> I'm sure there is something much better waiting to he invented. I think that's fair to say. I think that's always fair to say.
gatherhunterer 7y ago
> Why can't I drag a commit or set of commits from one branch to another? GitKraken might be for you, there is a nice drag-and-drop feature demonstration at https://www.gitkraken.com/git-client https://www.gitkraken.com/git-client. I don't think you can drag commits because a commit itself is a snapshot that describes changes to a branch so it is the branch itself that can be merged, rebased, pushed, etc. by drag-and-drop.
aeorgnoieang 7y ago
I used this semantic diff tool before (with Git) and it worked pretty well: - [SemanticMerge](https://www.semanticmerge.com/ https://www.semanticmerge.com/)

rk06 7y ago

https://gitless.com/ https://gitless.com/

saagarjha 7y ago
Can this tool make the commit history look like I'd like it to?

jayd16 7y ago

>and super smooth conflict resolution? Because the hardest part of conflicts is already the conflicting changes themselves and not the source control.

IshKebab 7y ago
Sure but I've never found a GUI or editor that lets me resolve conflicts in the way I want. For example say I change one line of code in a big function. I rebase and that function has moved. Conflict! I want a tool that says "here's what you changed, and here's the current state of the source". None of them do that though - they all just show the conflicts that git writes to disk - the code after you changed it, and the current code. You basically get two copies of the function, one with your change and one without and you have to manually (visually) diff them to work out what you changed (or go back and look at your commit) and then reapply that change to the moved function. It's really awkward and could definitely be better.
- cozzyd 7y ago
  Have you tried a three-way-merge tool (e.g. vimdiff, meld, kdiff3, surely some emacs way of doing it)?
- idoubtit 7y ago
  Even without plugin in a three-ways tool, Git's conflict can provide more information. [merge] # display 3 parts for each conflict, # including the common ancestor conflictstyle = diff3 There's also the option to use a semantic merge tool. AFAIK, there are only paying tools for this, and only a few languages are supported.
- falsedan 7y ago
  I spent some time with `git mergetool` to help resolve conflicts. It's hideous but it's better than staring at inline conflict markers
- rakoo 7y ago
  What you, and also I, want is a syntax-aware merge tool, i.e. one that can tell you the meaning of the change. If a function got moved to another place, or if 2 fields swapped places, I don't want it to have the same importance as na actual change in behavior. No importance, even. Git's only sense of syntax is recognizing lines, and it's just not enough in too many cases. Sadly in my (short) research everything I have found is either closed source or I can't afford to pay for it. It's even more saddening that git already has built-in bits for syntax related diffs.
- aasasd 7y ago
  Three-way diff is (probably) what you want. E.g. Intellij Idea uses it by default, and likely plenty of other IDEs and editors do too. You see original code, you changes, and the other side's changes—and where exactly they conflict.

anujsharmax 7y ago

If you use Emacs, give magit (https://magit.vc https://magit.vc) a try. It is so much better than Git CLI, which probably is too low level for daily usage.

jolmg 7y ago
I use the CLI for my daily work just fine, thank you. I sometimes turn to magit when I want to navigate a file's history through git-blame, though.
- tomjakubowski 7y ago
  You're missing out on the lightning fast pull, interactive rebase, staging and commit capabilities of magit-status. The key bindings are intuitive and excellent.
  - jolmg 7y ago
    They are intuitive and excellent, but I don't think they make things that much faster if at all. There's not much difference in speed between doing `C-x g s c -a c` and typing `git ci -a`.
- aldanor 7y ago
  CLI is fine until you acquire a habit of committing things chunk-wise and line-wise. E.g., I have these 20 files modified, but I'll quickly skim through and add/commit the lines/chunks that are done, and then continue working on the rest. CLI promotes a different kind of workflow, like "ok, I'm done, add/commit it all, and then move on".
  - drchickensalad 7y ago
    What do you feel the UI does better than git add -p? The main concession I have is picking arbitrary files, but I feel like I've achieved 90%+ of what I want with '.cs' or 'Controller*' etc.

gritzko 7y ago

swarmdb has CRDT-based merge and causal branching which is "super smooth". Lets you recombine changesets rather freely, or at least supposed to. https://github.com/gritzko/ron-cxx/tree/master/db https://github.com/gritzko/ron-cxx/tree/master/db (the project is in its early stages) Regarding language-aware AST-based diffs, I know of one serious full-time effort. Even for Java, it turned way too complex, so guys gave up.

batisteo 7y ago

> Git is pretty nice, but I'm sure there is something much better waiting to he invented. It is indeed being invented. It’s called Pijul: http://pijul.org/ http://pijul.org/ This tool is based on strong mathematical theory of patches, instead of snapshot/commit-based. It seems simpler to reason with, but we’d have to unlearn a lot from Git. It’s not suitable for big projects yet, but it’s already used by Pijul itself and other Rust components. And it already have its own „Github” called the Nest (because pijul is a bird). Pretty promising imho.

afiori 7y ago
I really like the promise of pijul, but it is early to say if it is better. Conventions and tooling will be a decisive factor in the ease of use. That said I do share your optimism.
gbersac 7y ago
Exactly the kind of program which will benefit from being wrote in rust.
stevekemp 7y ago
I had a sudden flashback to using darcs, which was also based upon patches instead of commits. darcs was nice, up until you hit the exponential merge problem.
- afureta 7y ago
  I don't know about Pijul, but it claims to have solved the exponential merge problem. https://pijul.org/faq/ https://pijul.org/faq/
- pmeunier 7y ago
  I'm one of the authors. Pijul is indeed heavily inspired by Darcs, but we solved that problem completely. All our algorithms are in time at most log of the size of history, which is a double-exponential improvement over Darcs' worst case complexity.
dahart 7y ago

IshKebab 7y ago

I agree. I did find one GUI that at least lets you drag & drop branch labels (GitX) but it's a bit buggy and Mac-only. It doesn't let you rebase via drag & drop, or cherry-pick via copy & paste. Those are pretty obvious mappings and would make Git way more obvious.

afiori 7y ago

> Why can't I drag a commit or set of commits from one branch to another? It was disappointing to me that web interfaces do not offer something like this

rusk 7y ago

The Git support in the Jetbrains IDEs is very good. I'll often fire up IntelliJ if I'm too tired to try and figure out how to figure out what's going on.

aasasd 7y ago

I feel like Git's concepts got tied into a mess in its cli tools. Like the devs maybe tried to imagine what would be the proper interface for a person not deeply familiar with the innards, but failed, and e.g. `git-show` is the result. So I get this vague feeling that someone could build a better human-oriented suite of CLI tools on top of Git's internals―with the internals better mapped to people's more casual understanding of the concepts and their aims. But that someone isn't me, yet.

andrewla 7y ago

> And I feel it in my bones that there is a revolutionary GUI waiting to be invented. Why can't I drag a commit or set of commits from one branch to another? With safe, easy undo (reflog doesn't count) and super smooth conflict resolution? Etc etc. The model of git feels very nice and intuitive once you grasp the central architecture -- an immutable append-only content-addressed file system. The changes mentioned here in particular just don't really fit the model. You can certainly argue that we need a better model, but in order to move commits between branches in anything other than a mechanical manner, you would have to deal with the fact that often in source code repositories there are semantic connections between unrelated changes -- one file has a change to update its interface, the other file changes to use the old interface, and now you have something that no general-purpose version control software can reasonable reconcile or even identify as an issue. Arguable there's a space for merging tools that build on the git model and contain language semantic information, so it can actually highlight conflicts that are deeper than patch-based, but until then I'd prefer that the version control system not try to be too smart and let me repair things after it does its mechanical actions. > The CLI in particular ... Line diffs suck in many ways These are changes that I think are in line with what I see in the future of git -- because git just contains a series of snapshots of a hierarchical tree, diffs are a secondary thing that an external tool can be brought to bear on very easily -- rather than trying to merge patches to create a diff, you actually have two fully realized files, together, potentially, with their common ancestor, which is all the information necessary to create a fully semantics-aware diff between files or trees. I would almost want git to double-down on the grammar of tree changes; commands like "checkout" and "reset" are very basic manipulations with fairly clear idioms. But since those words are also English words that carry a whole bunch of connotations, it makes it confusing when you use "reset" to do something that does not involve returning something to its original state. Having a "worse" command line interface, with some commands like "git make-my-working-tree-look-like-this-ref" and "git point-this-ref-to-this-other-ref" would break the connection with traditional version control systems while allowing us to use the full power of the git model.

JohnFen 7y ago

> I'm sure there is something much better waiting to he invented. I think that's fair to say. I think that's always fair to say.

gatherhunterer 7y ago

> Why can't I drag a commit or set of commits from one branch to another? GitKraken might be for you, there is a nice drag-and-drop feature demonstration at https://www.gitkraken.com/git-client https://www.gitkraken.com/git-client. I don't think you can drag commits because a commit itself is a snapshot that describes changes to a branch so it is the branch itself that can be merged, rebased, pushed, etc. by drag-and-drop.

aeorgnoieang 7y ago

I used this semantic diff tool before (with Git) and it worked pretty well: - [SemanticMerge](https://www.semanticmerge.com/ https://www.semanticmerge.com/)