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

21–30 of 50 posts

Re: Gitless: experimental version control system

#21

Post by br3w5 »

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…

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/...)

BUT separate steps for this is good because it allows for better inspection and the ability to recover

Re: Gitless: experimental version control system

#22

Post by jennings223 »

mikekchar wrote: post #17
jennings223 wrote: post #2

As a novice git user, I can't really tell how Gitless is really different from Git in daily use cases. Any explanations?

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. It would only result in one commit, which I feel is kinda nice coz you have a cleaner and more correct(time-wise) commit history. I don't know if this is the fundamental purpose of rebase. Advice welcome.

Re: Gitless: experimental version control system

#24

Post by faceplanter »

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

This so much. People consistently complain about PHPs' stdlib and how the naming and parameter order are not streamlined. Git is very similar to PHP in this case. It's not something that's going to keep people from using it but it is one of those warts that people just have accepted.

Re: Gitless: experimental version control system

#26

Post by pjc50 »

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…

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.

Re: Gitless: experimental version control system

#27

Post by br3w5 »

Lazare wrote: post #16
jennings223 wrote: post #2

As a novice git user, I can't really tell how Gitless is really different from Git in daily use cases. Any explanations?

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.

Re: Gitless: experimental version control system

#28

Post by icebraining »

pjc50 wrote: post #26
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…

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.

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 ; bzr commit; bzr unshelve".

Re: Gitless: experimental version control system

#29

Post by ddebernardy »

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…

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

Re: Gitless: experimental version control system

#30

Post by pja »

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 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.

Post reply on HN