5 ms·

Git is pretty atrocious, so I like the idea here, but I'm not sure it goes far enough. My main complaints about git are probably having to commit changes manu

Git is pretty atrocious, so I like the idea here, but I'm not sure it goes far enough. My main complaints about git are probably having to commit changes manually (I haven't had to do this in Dropbox) terrible history and branch navigation (chrome does a better job and that's not even like an important feature of a browser) confusing command structure and options history rewriting and the resulting issues no merge tool (I feel like kaleidoscope is the minimum here) submodules Gitless seems to address #3 there but not the others. Actually making a tool that improves git to where it could be would probably be a huge undertaking, and most people do alright with git so maybe it's not worth it. Or maybe there's some graphical git client like tower that fixes all this stuff.

jsprogrammer 12y ago
I wonder if there are any benchmarks or case-studies on very large git repos? Ideally you'd want to track (commit) every change to files and allow the user to place tags at certain places in the graph (similar to how commits are currently used) to represent aggregated logical changes. It would also be nice to have a visualization of the graph that could easily be 'seeked' through like a video. Putting this on top of the existing git CLI code might not be feasible though.
- nulltype 12y ago
  Nice! Yeah that's along the lines I was thinking. There have been attempts at visualizations, like I remember clearcase had one that was probably pretty advanced 30 years ago. I think it's very doable without any serious R&D, and you could build it on top of git/maybe github. The real question to me is: is it worth the effort, and would anyone actually pay for it. People pay for tower and kaleidoscope so I assume it's possible. I think this is totally something GitHub should make but they seem to be focussing on other things.
  - jsprogrammer 12y ago
    Conceptually it is very simple. Integrating it with existing tools is where the real work is. Ideally, I think you'd want it integrated with your text editor and it should be useful not only for code, but more general composition (I'm thinking scientific literature) as well. Of course, getting this to work in real-time with your collaborators is probably the holy grail and has been implemented to some extent over the years in quite a few products.
br3w5 12y ago
Keeping branches up to date can be a pain i.e. pull master into local feature branch then push up to remote feature branch (although gpp command in the preszto git module gets around this a little but you still need to update your working copy https://github.com/sorin-ionescu/prezto/tree/master/modules/git https://github.com/sorin-ionescu/prezto/tree/master/modules/...) BUT separate steps for this is good because it allows for better inspection and the ability to recover
pjc50 12y ago
Manual commit is important because of the commit message, which is really the thing that distinguishes VCS from sync. Manual add-before-commit is more of an optional design decision, although without it there would still be demands for a way to exclude just this particular file from a commit.
- icebraining 12y ago
  there would still be demands for a way to exclude just this particular file from a commit. Arguably, git already has that with stash; it just needs a simple way of stashing whole files. In bazaar, which doesn't have add-before-commit for existing files, I often do "bzr shelve <file>; bzr commit; bzr unshelve".
ddebernardy 12y ago
For history and branch navigation, you can create an alias for something like the one suggested here: https://coderwall.com/p/euwpig/a-better-git-log https://coderwall.com/p/euwpig/a-better-git-log
pja 12y ago
At least some of these are what makes git awesome. * commit changes manually - I find my self picking individual changes out of the current state of my source & committing them individually all the time, so this is just perfect. * history & branch navigation. - Um. Not sure what the problem is here. I can checkout anything I like, hop around the history at will, tag any version with meaningful names etc. Am I missing something? * confusing command structure. - Yeah, have to give you this one. It is (slowly) getting more consistent over time at least. * history rewriting - this means I can hack & commit away then rewrite my changes into a logically consistent series of changesets that make sense individually before pushing to the main repo. I rewrite history all the time before pushing. * no merge tool - but is happy to use whatever merge tool you plug into it, which works pretty well in my experience. (See the git-mergetool manpage.) * submodules - Yeah, these are mostly awful. I think git (or mercurial for that matter) is great for people who see having a clean, well documented change history where every commit makes sense in and of itself as a worthwhile thing to have. If you're the kind of developer who just uses a VCS as a sort of 'source code backup' and your revision history consists mostly of a long series of "Update" comments then all the extra power that git has is just extra complexity that you don't need.
- nulltype 12y ago
  Git makes it way harder than necessary to do all these things and has a steep learning curve (generally a euphemism for bad design). I'm proposing that you can get all the benefits you talk about but in a far more usable manner. I like a clean master branch with atomic sensible commit messages as much as the next man. Git just makes it a real chore to get there. You seemed confused about the history and branch navigation, so maybe I can explain that one better. What I want is to visually view the history of a file, and trace, for instance, a function as it moves through my project, into different files, etc. I also want to easily find code that I deleted in the past to use as a reference for implementing a new version of the code, rather than keeping it in some "obsolete" folder in source control. I have seen people who do that. There are ways to do these things now involving searching git logs and viewing diffs or checking out old branches, but the interface is very poor. Even the interface on Time Machine is better than git, and that thing isn't build to source code. But perhaps you are correct. Maybe most people use git primarily as a backup service for code. If so I guess git should make that a way better process. I will point out that github actually offers a way better interface to git than git does. It just still has a long way it can go.

jsprogrammer 12y ago

I wonder if there are any benchmarks or case-studies on very large git repos? Ideally you'd want to track (commit) every change to files and allow the user to place tags at certain places in the graph (similar to how commits are currently used) to represent aggregated logical changes. It would also be nice to have a visualization of the graph that could easily be 'seeked' through like a video. Putting this on top of the existing git CLI code might not be feasible though.

nulltype 12y ago
Nice! Yeah that's along the lines I was thinking. There have been attempts at visualizations, like I remember clearcase had one that was probably pretty advanced 30 years ago. I think it's very doable without any serious R&D, and you could build it on top of git/maybe github. The real question to me is: is it worth the effort, and would anyone actually pay for it. People pay for tower and kaleidoscope so I assume it's possible. I think this is totally something GitHub should make but they seem to be focussing on other things.
- jsprogrammer 12y ago
  Conceptually it is very simple. Integrating it with existing tools is where the real work is. Ideally, I think you'd want it integrated with your text editor and it should be useful not only for code, but more general composition (I'm thinking scientific literature) as well. Of course, getting this to work in real-time with your collaborators is probably the holy grail and has been implemented to some extent over the years in quite a few products.

br3w5 12y ago

Keeping branches up to date can be a pain i.e. pull master into local feature branch then push up to remote feature branch (although gpp command in the preszto git module gets around this a little but you still need to update your working copy https://github.com/sorin-ionescu/prezto/tree/master/modules/git https://github.com/sorin-ionescu/prezto/tree/master/modules/...) BUT separate steps for this is good because it allows for better inspection and the ability to recover

pjc50 12y ago

Manual commit is important because of the commit message, which is really the thing that distinguishes VCS from sync. Manual add-before-commit is more of an optional design decision, although without it there would still be demands for a way to exclude just this particular file from a commit.

icebraining 12y ago
there would still be demands for a way to exclude just this particular file from a commit. Arguably, git already has that with stash; it just needs a simple way of stashing whole files. In bazaar, which doesn't have add-before-commit for existing files, I often do "bzr shelve <file>; bzr commit; bzr unshelve".

ddebernardy 12y ago

For history and branch navigation, you can create an alias for something like the one suggested here: https://coderwall.com/p/euwpig/a-better-git-log https://coderwall.com/p/euwpig/a-better-git-log

pja 12y ago

At least some of these are what makes git awesome. * commit changes manually - I find my self picking individual changes out of the current state of my source & committing them individually all the time, so this is just perfect. * history & branch navigation. - Um. Not sure what the problem is here. I can checkout anything I like, hop around the history at will, tag any version with meaningful names etc. Am I missing something? * confusing command structure. - Yeah, have to give you this one. It is (slowly) getting more consistent over time at least. * history rewriting - this means I can hack & commit away then rewrite my changes into a logically consistent series of changesets that make sense individually before pushing to the main repo. I rewrite history all the time before pushing. * no merge tool - but is happy to use whatever merge tool you plug into it, which works pretty well in my experience. (See the git-mergetool manpage.) * submodules - Yeah, these are mostly awful. I think git (or mercurial for that matter) is great for people who see having a clean, well documented change history where every commit makes sense in and of itself as a worthwhile thing to have. If you're the kind of developer who just uses a VCS as a sort of 'source code backup' and your revision history consists mostly of a long series of "Update" comments then all the extra power that git has is just extra complexity that you don't need.

nulltype 12y ago
Git makes it way harder than necessary to do all these things and has a steep learning curve (generally a euphemism for bad design). I'm proposing that you can get all the benefits you talk about but in a far more usable manner. I like a clean master branch with atomic sensible commit messages as much as the next man. Git just makes it a real chore to get there. You seemed confused about the history and branch navigation, so maybe I can explain that one better. What I want is to visually view the history of a file, and trace, for instance, a function as it moves through my project, into different files, etc. I also want to easily find code that I deleted in the past to use as a reference for implementing a new version of the code, rather than keeping it in some "obsolete" folder in source control. I have seen people who do that. There are ways to do these things now involving searching git logs and viewing diffs or checking out old branches, but the interface is very poor. Even the interface on Time Machine is better than git, and that thing isn't build to source code. But perhaps you are correct. Maybe most people use git primarily as a backup service for code. If so I guess git should make that a way better process. I will point out that github actually offers a way better interface to git than git does. It just still has a long way it can go.