Git with a veneer on it, that if there are problems you can revert to git-proper... How is that different from Git Desktop?
You don't leave the command line
Gitless: A simple version control system built on top of Git
51–60 of 143 posts
Re: Gitless: A simple version control system built on top of Git
#52If anyone wants to know what it is like working with a "hard to use" revision control system then I highly recommend trying out IBM Rational ClearCase [1]. Or as I lovingly used to refer to it as Irrational ClearCase. To be fair, I have not used it since 2009, so perhaps it has been improved? If you use emacs and you find git difficult then please try out magit [2]. I actually really like the git cli, but I use magit…
I never really understood git until I used magit
Re: Gitless: A simple version control system built on top of Git
#53I must admit I'm a little bit confused. It opens with a discussion that people find Git hard to use, and a statement that these problems are likely more than skin-deep but then goes on to describe a wrapper around Git which is mostly a bunch of aliases. Don't get me wrong, I'm know that many people do find Git hard-to-use, but I don't see anything in the eventual project implementation which backs up the original cla…
I took a quick look at the list of commands and they looked so similar to the primary git commands I use that it seemed like a waste. Better to just learn how to use git.
Re: Gitless: A simple version control system built on top of Git
#54If anyone wants to know what it is like working with a "hard to use" revision control system then I highly recommend trying out IBM Rational ClearCase [1]. Or as I lovingly used to refer to it as Irrational ClearCase. To be fair, I have not used it since 2009, so perhaps it has been improved? If you use emacs and you find git difficult then please try out magit [2]. I actually really like the git cli, but I use magit…
No, it has not improved. I last used it around a year ago at a company where a lot of young engineers had to pick up a 20 year old code base. Suffice to say, the expertise for ClearCase really wasn't there and it was an absolute mess.
Re: Gitless: A simple version control system built on top of Git
#55Seems like a cool side project, but I don’t quite git it.
Re: Gitless: A simple version control system built on top of Git
#56Removing staging seems a little odd. To me staging, especially with a GUI like Sourcetree, is almost the best part of git.
Curious as to why - What usecases do you have for staging? Why does sourcetree make it better? To me it's just an inconvenience and a redundant step on the way to committing stuff. I get that you can use it for partial commits of in flight work but that's never something I've needed in practice. Usually I just want to commit everything I'm working on at once.
Incremental staging of the next commit is absolutely a valuable feature.
I'll often touch multiple files over the course of a few hours, sometimes for slightly unrelated changes, and then want to pull apart the changes into several smaller logical commits. Sometimes a couple hunks in a file might need to go into Commit A, while others go into Commit B.
You can do piecemeal adding of hunks via the CLI, but the interface is horrible. Being able to simply click "Add Hunk" in a GUI is incredibly valuable (or even in some cases shift-clicking a couple lines and "Add Lines").
Re: Gitless: A simple version control system built on top of Git
#57I must admit I'm a little bit confused. It opens with a discussion that people find Git hard to use, and a statement that these problems are likely more than skin-deep but then goes on to describe a wrapper around Git which is mostly a bunch of aliases. Don't get me wrong, I'm know that many people do find Git hard-to-use, but I don't see anything in the eventual project implementation which backs up the original cla…
I could never understand the complaint that Git is "hard to use". Having used a plethora of version control systems over many years, I never found Git to significantly more or less complicated than any other system. Version management includes many use cases, some of which are inherently complex. Therefore any version control tool must be able to perform both simple and complex tasks, and the latter ones will obvious…
Not everyone here is a 'professional' software developer. Git does have a steep learning curve.
(I've used git extensively for years, just playing devil's advocate)
Re: Gitless: A simple version control system built on top of Git
#58Earlier quoted context omitted.
Curious as to why - What usecases do you have for staging? Why does sourcetree make it better? To me it's just an inconvenience and a redundant step on the way to committing stuff. I get that you can use it for partial commits of in flight work but that's never something I've needed in practice. Usually I just want to commit everything I'm working on at once.
You might not use it to do partial commits but many others do.
Don't partial commits run the big risk of commiting code that may not work, since the partial commit on your own computer will be tested against your working tree, wheras after it's committed it run with a different view of the files?
Re: Gitless: A simple version control system built on top of Git
#59Earlier quoted context omitted.
You might not use it to do partial commits but many others do.
Don't partial commits run the big risk of commiting code that may not work, since the partial commit on your own computer will be tested against your working tree, wheras after it's committed it run with a different view of the files?
Just to play devil's advocate, to achieve this always-working guarantee you could: stage, commit, stash your working directory, test your code, and then unstash.
Re: Gitless: A simple version control system built on top of Git
#60After reading the referenced papers explaining the academic rationale, Gitless gets a big "meh" from me. A quick tl;dr of the referenced paper "Purposes, Concepts, Misfits, and a Redesign of Git" ( https://spderosso.github.io/oopsla16.pdf ): > The changes made to Git’s concept model are: > 1. The redefinition of “tracked” and “untracked,” and the elimination of “assume unchanged” and the “staging area.” > 2. The rede…
Good points overall, I don’t disagree but I’ll try to give another POV. I think the focus on stashing is that it’s basically an hidden state. If for instance you switch back to a branch after a while and you don’t remember you stashed, it will just be lost work. Overall I wish stashed were shown as candidate commits, I actually end up making temporary commits that I amend afterward, most of the time. For the switchin…
Yep, I basically agree with all of that. To clarify my main point, I don't think the marginal benefit that Gitless provides for working around these rough edges outweighs the disadvantage of not learning the underlying git functionality and thereby being unable to utilize advanced techniques that are inevitably required in the course of a serious software engineering career.