Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Gitless: experimental version control system

people.csail.mit.edu

Post reply on HN
Print view View original

41–50 of 50 posts

Re: Gitless: experimental version control system

#41

Post by e12e »

viraptor wrote: post #14
hbogert wrote: post #10

A lot of people want to use powerful tools but want it through an iPad-ish interface. If I'm using a space-rocket to get to the moon, I'm certainly going to learn how this shit is working and not fooling myself that if I just know what the buttons should do,I understand the system. GIT is marvelous if you understand the data-structures, people are too fixated on the commands and think everyone one of them is like mag…

Well, you can understand the data-structures and still not like git's interface. The data structures or your familiarity with the git internals don't change the fact that the CLI is annoyingly inconsistent. Learning more of internals won't save you from memorising which variation of the option is being used this time. For example: git remote add/rename/remove git add/mv/rm git tag /?/-d git branch /-m/-d

Very much my main reason for preferring mercurial to git. Has there been any real talk in re-factoring the UI for a major-version of git? Clearly it would break some things, but simple stuff, like settling on rm or remove or delete etc... seems like a good idea?

On the other hand, I suppose the git-plugin[1] for mercurial is good enough, that there's really no reason to use git for those that feel strongly about the UI?

[1] http://hg-git.github.io/

Re: Gitless: experimental version control system

#42

Post by StavrosK »

viraptor wrote: post #14
hbogert wrote: post #10

A lot of people want to use powerful tools but want it through an iPad-ish interface. If I'm using a space-rocket to get to the moon, I'm certainly going to learn how this shit is working and not fooling myself that if I just know what the buttons should do,I understand the system. GIT is marvelous if you understand the data-structures, people are too fixated on the commands and think everyone one of them is like mag…

Well, you can understand the data-structures and still not like git's interface. The data structures or your familiarity with the git internals don't change the fact that the CLI is annoyingly inconsistent. Learning more of internals won't save you from memorising which variation of the option is being used this time. For example: git remote add/rename/remove git add/mv/rm git tag /?/-d git branch /-m/-d

Exactly. Git's porcelain is just amazingly inconsistent and really badly designed. I wonder why nobody has come up with a better design yet, I can't imagine it would be that hard to do... Maybe I'll give it a shot.

Re: Gitless: experimental version control system

#43

Post by Lazare »

br3w5 wrote: post #27
Lazare wrote: post #16

Earlier quoted context omitted.

Merges and simplifies a lot of common cases. For example, creating a new blank repo in gitless is: gl init And getting a local copy of a remote repo in gitless is: gl init Whereas in git, it's: git init and: git clone Similarly, the operations to switch to (and create) a new branch, switch to an existing branch, and list branches, in git, is: git checkout -b newbranch git checkout oldbranch git branch In gitless, its…

So is gitless against working with hunks of files because the docs say that having files with parts in multiple states is a problem? But this actually gives more flexibility. Yes it's more complex but that's the trade-off.

I'm not sure I'd say gitless is "against" it so much as it's focused on making the tasks people do every day easier. I use git every day, but I think I ended up staging individual hunks of files maybe...twice in the past year?

(And you can still drop back to git if you do need that functionality. As the docs note, gitless and git are entirely compatible.)

Re: Gitless: experimental version control system

#44

Post by Lazare »

StavrosK wrote: post #42
viraptor wrote: post #14

Earlier quoted context omitted.

Well, you can understand the data-structures and still not like git's interface. The data structures or your familiarity with the git internals don't change the fact that the CLI is annoyingly inconsistent. Learning more of internals won't save you from memorising which variation of the option is being used this time. For example: git remote add/rename/remove git add/mv/rm git tag /?/-d git branch /-m/-d

Exactly. Git's porcelain is just amazingly inconsistent and really badly designed. I wonder why nobody has come up with a better design yet, I can't imagine it would be that hard to do... Maybe I'll give it a shot.

Well, there's gitless. :)

Re: Gitless: experimental version control system

#45

Post by StavrosK »

Lazare wrote: post #44
StavrosK wrote: post #42

Earlier quoted context omitted.

Exactly. Git's porcelain is just amazingly inconsistent and really badly designed. I wonder why nobody has come up with a better design yet, I can't imagine it would be that hard to do... Maybe I'll give it a shot.

Well, there's gitless. :)

That is true. Last I tried it, it wasn't very mature. I'll give it another go and see if it's changed.

Re: Gitless: experimental version control system

#46

Post by br3w5 »

Lazare wrote: post #43
br3w5 wrote: post #27

Earlier quoted context omitted.

So is gitless against working with hunks of files because the docs say that having files with parts in multiple states is a problem? But this actually gives more flexibility. Yes it's more complex but that's the trade-off.

I'm not sure I'd say gitless is "against" it so much as it's focused on making the tasks people do every day easier. I use git every day, but I think I ended up staging individual hunks of files maybe...twice in the past year? (And you can still drop back to git if you do need that functionality. As the docs note, gitless and git are entirely compatible.)

true...i guess for me it's another potential option for working with git like the prezto git module and git plugins for vim

Re: Gitless: experimental version control system

#48

Post by nulltype »

pja wrote: post #30
nulltype wrote: post #7

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 to…

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…

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.

Re: Gitless: experimental version control system

#49

Post by riquito »

Mathiasdm wrote: post #33

I wish Git would have used a different name than 'branch'. It's completely at odds with branches in any other version control system and only adds confusion for people switching to/from Git. Mercurial uses the term 'bookmarks' for Git-style branches, I feel that would have been a much better choice.

cvs, svn, bazaar use "branch". 'Bookmark' is way more awkward to me.

Re: Gitless: experimental version control system

#50

Post by mikekchar »

jennings223 wrote: post #22
mikekchar wrote: post #17

Earlier quoted context omitted.

As an experienced git user, as far as I can tell s/git/gl ;-) I couldn't really see any differences at all from the documentation. Perhaps I missed something. An overview of the differences would be very nice. The one thing that concerns me is the inclusion of rebase. If a wrapper is supposed to change difficult underlying concepts in git, why keep the most difficult concept: rebase. I like rebase, but for many commo…

I got the exact feeling as yours at first. :) My understanding of your concern of rebase is that if they are gonna change that (or get rid of that), it will be a change of the workflow instead of just a simplification of it. I used to rely on merge other than rebase when my local tree is diverted. That usually ended up with two commits (one for my local changes, one for the merge). But later I learned to use rebase.…

This was a long time ago, so maybe you won't see this reply :-) Rebase is awesome as long as you never publish the branch before you rebase. If anyone uses your branch, then the history will not match up and they will not be able to merge their changes because Git will not be able to determine the order of the commits. I have gone through this more than once and it is not fun at all.

Rebase works extremely well for what is was designed for: You have a lot of people working completely independently and you want to submit your changes to a central maintainer. You rebase your branch so that the changes appear to be applied directly onto their branch. It makes it much, much easier to review. If the change is accepted then it is merged and everybody uses the merged version. If not, the branch is destroyed (of course you still have your changes in your repository). As long as nobody makes any changes to (or branches off of) a branch that will be rebased, then there will be no problem.

Because the vast majority of people use git as kind of a "better SVN", with a centralized repository and published branches (using Github or the like), most people should never, ever use rebase. Especially if you are trying to design a simple workflow for neophytes, then you should almost certainly not make rebase easy to reach.

Like I said, I like rebase, but it is not something that fits well in a collaborative office environment. It works much better in a hugely distributed open source project, or a personal project (if you are being very careful).

Post reply on HN