13 ms·

Gitless: A simple version control system built on top of Git

181 points by jackbravo 8y ago

Piskvorrr 8y ago
Interesting. It seemed to be just git-renamed, but the concept of "no staging area, smart-add everything" and "autostash everything on branch change" looks useful. Not as powerful as git, but it's always possible to fall back to non-abstracted git.
hackpr 8y ago
Yes. Git is powerful, but sadly has deep problems in its conceptual design. This is the reason why even mid-level engineers don't understand it fully. Love this work!
- arximboldi 8y ago
  Can you elaborate on the deep problems? I personally find it relatively conceptually elegant.
  - fgonzag 8y ago
    I think the main problem is that many developers don't think of Git as a DAG, so they don't really understand at a fundamental level what the operations are actually doing. Once you understand this, Git really does become simple. All you have to do is map each command to the actual operation on the DAG. This video really explains it quite well, it's the one video that allowed me to fully grasp everything: https://www.youtube.com/watch?v=1ffBJ4sVUb4 https://www.youtube.com/watch?v=1ffBJ4sVUb4
    - bauerd 8y ago
      Yeah, but the question is whether a DAG is a good mental model for a VCS. Just because that's the underlying data structure doesn't mean it has to be the user interface too.
      - bachmeier 8y ago
        Exactly. This seems to be a point that the "Git is easy" crew doesn't understand. Not everyone (in fact, very few) find going into that depth for something that's nothing more than a tool to be reasonable. Reminds me of the Gentoo users that used to say compiling everything is a great idea for an OS.
        jungler 8y ago
        I find that people understand "linearized" concepts easier than other kinds(DAGs included). When elements are left-to-right or top-to-bottom, you can read what is going on at a glance. So the next major step in VCS technology will most likely do something to help linearize our views and reduce the tangling that comes into play with any tree or graph structure.
        __blockcipher__ 8y ago
        Don’t we already have that in some respects? a) Most people’s git workflow might as well be linear. b) rebasing a development branch onto master literally linearizes it Where git shines though of course is where you can’t get away witha linear model
    - ruseOps 8y ago
      A big part of learning anything is understanding - at a fundamental level - what operations are being executed by whichever tool is being utilized. So if you will pardon the paraphrase, I think the main problem is that many developers don’t take the time to simply learn git.
  - paulddraper 8y ago
    I compare it to 10-15 years ago, when functional programming was rather rare. Mid-level OO programmers would complain it was confusing and unfamilar, whereas in reality has beautiful and simple concepts. Git's use of a DAG is confusing and unfamilar for many programmers, though in reality it's beautiful and simple.
    - bachmeier 8y ago
      > Git's use of a DAG is confusing and unfamilar for many programmers, though in reality it's beautiful and simple. The difference relative to functional programming is that you get paid for one and the other is just a tool
      - adambyrtek 8y ago
        I would argue that functional programming is just a tool as well... Programmers are paid for solving problems and code is just a means to that end.
      - deleted 8y ago
        [deleted]
    - glitchc 8y ago
      Yup, second that. My old boss introduced the whole team to Scala and made us attend a weekly tutorial as part of training/team-building. Since then, I try to write stateless functions, methods and objects as much as possible regardless of language or platform. Git is quite elegant if one has a good grasp of graph theory.
      - Fins 8y ago
        Git is certainly great technically. But one should not need to know graph theory to source control files. And I believe that any version control system that does not follow the convention (that probably predates Linus' existence on Earth) that commit should actually commit changes to server, is, by definition, more4 hard to use than it has any reason to be. But this might be a good study in why Linux is not taking over the desktop, and unlikely to do so in foreseeable future.
  - apichat 8y ago
    I think that you can find good explanations of these problems here : https://jneem.github.io/merging/ https://jneem.github.io/merging/ https://pijul.org/model/#why-care-about-patch-theory https://pijul.org/model/#why-care-about-patch-theory Unfortunatly Gitless doesn't solve them. But Pijul solve many problems of Git (and Darcs) and is easier to use. https://pijul.org https://pijul.org
    - pantalaimon 8y ago
      It appears as https://nest.pijul.com/pijul_org/pijul https://nest.pijul.com/pijul_org/pijul is currently being hugged to death?
      - apichat 8y ago
        It's ok now. They published a new version of Pijul and it seems that it cause some problems. https://pijul.org/posts/2018-11-20-pijul-0.11/ https://pijul.org/posts/2018-11-20-pijul-0.11/ https://pijul.org/posts/2018-04-21-pijul-0.10/ https://pijul.org/posts/2018-04-21-pijul-0.10/
      - Nzen 8y ago
        It's a once a month / once a quarter occurance. I'm not sure if it's because of changes to the webservice or not enough financial backing. I've basically given up on using early access pijul. I've had a problem with each of the last three versions, primarily pushing to Nest. It wouldn't be an issue if I could install pijul on NearlyFreeSpeech (because then I could self host on a known good version). I want pijul to succeed, its patching model sounds good. Clearly, it's working for some group of people. But I'm not one of them, and it's past where I feel like I'm wasting my time. I'll try again when they're v1.0
- scrollaway 8y ago
  Gitless doesn't change anything about git's concepts, it just abstracts away some commands. So if you think this solves the problems, they're clearly not "conceptual" faults. I think this is important because people are so quick to jump on the "git is bad" contrarian meme. Git is a fantastic piece of work and the CLI has a variety of issues. On top of this, git is conceptually unintuitive, so the CLI issues make for a worse experience.
  - joshuamorton 8y ago
    The other half of the issue is that git's commands don't follow the abstraction. If each command mapped to a single dag operation, it might make more sense. But they don't (revert).
    - 4lch3m1st 8y ago
      They shouldn't. I'm not saying that Git doesn't have commands that can be hard to understand fully, but the whole point of any abstraction is to hide the "insides" of any operation so you don't have to think about them. Having commands for each DAG operation will just add more complexity and expose a structure which you shouldn't be handling manually.
      - sofal 8y ago
        I think in order to really feel comfortable with Git you have reverse that and think about the DAG as the actual interface and the CLI as the clunky implementation you use to modify the DAG.
- sigsergv 8y ago
  Git design is surprisingly clean and simple. The main issue of git is its CLI and commands naming. They are indeed unclear. But again, concept behind is absolutely amazing. You just need to understand that git repo is a series of snapshots and after that all other details become clear.
  - reacweb 8y ago
    Naming is difficult. Good names suggest the right metaphore to understand something. But for git, there is nothing similar in physical world. "push" "pull" and "merge" seem ok, but even "branch" is an original concept different of its usual meaning. Maybe git should have used non english words to avoid confusion.
    - icebraining 8y ago
      Branch seems to fit the dictionary definition: "something that extends from or enters into a main body or source". And in fact, it didn't originate with git, it's at least as old as CVS.
      - reacweb 8y ago
        http://lmgtfy.com/?q=git+what+is+a+branch http://lmgtfy.com/?q=git+what+is+a+branch "A branch in Git is simply a lightweight movable pointer to one of these commits." https://git-scm.com/book/en/v1/Git-Branching-What-a-Branch-Is https://git-scm.com/book/en/v1/Git-Branching-What-a-Branch-I...
Vanderson 8y ago
What I see this seems to be doing is auto-staging every file that changes? And beyond that it has a few aliases for some commands. Is anyone else getting the same thing? I use git in my CMS which auto-commits a template file (text) on save. Which works great in a browser editor online. (ie, editing files remotely) But I am not seeing an advantage to "not staging" with local files. What does this save when working locally? Is there some disadvantage to staging I am not seeing here? Changing to "not tracking" seems like you removed the file from the repo, which in my opinion goes against the grain on how git works, and in a sorta bad way.
maxxxxx 8y ago
Removing staging seems a little odd. To me staging, especially with a GUI like Sourcetree, is almost the best part of git.
- k__ 8y ago
  Coming from CVS I found Git rather simple. But I have to admit, I mostly used it via Github and as a solo-dev.
  - the_duke 8y ago
    As a solo dev you often don't use a lot of the more challenging Git features, like merge conflict resoluttion, rebasing, etc.
  - maxxxxx 8y ago
    If you keep it simple then git is pretty simple and straightforward. I think some people just get a little too obsessed about source control.
- davnicwil 8y ago
  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.
  - vthriller 8y ago
    I split file changes into multiple commits all the time. That alone makes many diffs much more readable and changes easier to follow, even if it results in occasional git-log clutter.
  - jayd16 8y ago
    You might not use it to do partial commits but many others do.
Shorel 8y ago
Sounds like something I would use, if I had not a bunch of git aliases that do similar things. In other words, yes, this is useful.
huntie 8y ago
I remember seeing gitless a while ago and thinking it was interesting, but I found it to be very slow due to Python's startup time.
cyphar 8y ago
I 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 claim that the problems are conceptual. I don't think it's possible to fix conceptual problems in a tool by just wrapping it. I have heard people complain about the staging concept (personally I find it useful, because you can do 'git add -p' which allows you to craft intermediate commits or to-be-squashed fixup commits after you've finished some development), so it's removal in this tool is unsurprising. And it is nice to auto-stash on branch change (though personally I think that they should've made stashing a much better-supported concept in their Git wrapper -- I've never really liked how stashing was implemented in Git). I do really like that they appear to have worked hard to remove all of the super-scary warnings that Git likes to spit out. As someone who has taught high-school students how to use Git (among other things), I've learned that the easiest way to scare away people from your project is to have bright-red warnings in response to a user doing something. Most students describe it as though the computer is effectively screaming at them. Some tools over-compensate for this is and spew emoji in response to user input, so I'm happy this tool has struck the right balance.
- deepspace 8y ago
  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 obviously require a more complicated syntax and conceptual model. In any case, we are supposed to be professionals. Complaining that Git is hard to use is a bit like a machinist complaining that a CNC machine is hard to use. If you want to accomplish non-trivial things in any field, you have to be prepared to deal with some level of complexity. /rant
  - saagarjha 8y ago
yarrel 8y ago
A simple text editor built on top of Emacs.
- gnulinux 8y ago
  Evil mode
- bendunatosia 8y ago
  2.50 per cent, that born in Asia by 4.47 per cent, that aged less than 15 years by only 0.46 per cent. Interstate annual population growth rates currently (1999–2000) vary between 1.7 per cent (Queensland) and –0.1 per cent (Tasmania), while massive differences exist in the direction, scale and components of population change in regions and communities. This paper takes the approach not so much of predicting the future as of exploring what will happen if demographic trends and tendencies evident in the mid- to late 1990s continue to evolve in the directions they seem to be moving in. No startling predictions are made of major reversals of trends. Instead the emphasis is placed on what seems likely given current trends and patterns in other developed societies. In many respects Australia’s current situation is in the middle among OECD nations, and seems to have further to go in some areas, including population distribution
not_kurt_godel 8y ago
After 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 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 redefinition of the concept of “branch,” and the elimination of “stash.” > 3. The creation of the notion of a “current branch,” and the redefinition of “head. I would agree that most of the delta from git represents an incremental improvement in usability; staging, stashing, and complex ignore rules are all things that are more likely to get in the way of novice to intermediate git users than help them. That being said, I'd classify those usability issues as minor in the overall picture. Most of them are trivial to smooth out either via git aliases or shell aliases - for example, I've had `ignore`, `show-ignored`, and `unignore` aliases for so long that seeing `git update-index --assume-unchanged foo` on the Gitless site made me realize I'd forgotten that that's what my `ignore` alias is actually doing under the hood. By far the most complex & difficult aspect of using git (and source control in general) is merge conflict resolution. I'm not convinced Gitless offers much benefit in this aspect and in fact I suspect it may actually make things worse. Complex conflict resolution is when the ability to distinguish between staged and unstaged changes is most useful and sometimes even crucial. Furthermore, while Gitless offering capability to 'pause' a conflict resolution by switching to another branch is neat, I would say it's very rare that I need to ever do so in the middle of a conflict resolution. Difficult resolutions require full concentration - if I find myself needing to switch to another branch in the middle of one, the context switch usually renders me unable to pick up where I left off and I wind up starting over to make sure I'm working from a clean slate. On the whole, I could see Gitless being valuable in academic environments to facilitate desparately-needed use of source control among researchers/postgrads/scientists. But I would steer clear of it in a software development career as I think it would stunt user's abilities to truly master a core tool of their profession in the long run.
- hrktb 8y ago
  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 switching between branches during conflict resolution, it might be for people like me who check back and forth reference branches when merging code. For instance a conflict can be between two feature branches I want to merge, and I’d need to check on master what is the current behavior. Or what’s the behavior on other branches that will need merging as well. Currently I’d just open github/gitlab on the other branches and compare from there, but I’d see the value in switching the local files. All in all I feel git is too aggressive in making the user deal with all the details when it could have sane non destructive defaults
dustfinger 8y ago
If 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 a fair amount also. Plus, emacs is awsome :-P [1] https://en.m.wikipedia.org/wiki/Rational_ClearCase https://en.m.wikipedia.org/wiki/Rational_ClearCase [2] https://en.m.wikipedia.org/wiki/GNU_Emacs#Extensibility https://en.m.wikipedia.org/wiki/GNU_Emacs#Extensibility
- celeritascelery 8y ago
  I never really understood git until I used magit
- sepen77 8y ago
  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.
- kruczek 8y ago
  I used ClearCase 3 years ago and this is spot on. ClearCase is little better than keeping revision history manually by zipping old versions of files. I sometimes wonder what kind of insane mind came up with its workflow. First of all, to checkout a branch, you don't simply select its name. You need to write a freaking configuration file to tell CC what you want to checkout. And it is entirely possible to accidentally write that configuration file in such a way that you'll have half of repository checked out from one version of code, while the other half is checked out from another version of code. Then there is history of changes. Or in case of ClearCase: histories of changes. Because there are many, in fact as many as there are files. Yes, each file has its own history of changes, completely independent from other files. So if you make a commit which changes 10 files, CC will create separate commit for each of those 10 files, each with the same commit message. Needless to say, browsing history with same commit messages repeated tens or hundred of times, is quite an adventure. Oh, and because of that, it is not possible to simply checkout some old version of code. If you are lucky, you will have put labels on all files of needed version of code, so then you can checkout that label. Otherwise the only option is to checkout based on dates of commits, and hope that your provided date won't actually cut any commit in half.
hyperpallium 8y ago
I like the idea of working with the simple datastore of git - immutable objects pointing to each other - and manipulate them with a programming language. But there's lots of things you routinely want to do that aren't convenient this way. Still has some appeal.
nimbius 8y ago
I feel like this is just another "git is hard so lets make it easier" program that makes collaborative development a pain. maybe its just my puritan work ethic. first we had git, and anyone who cared to spend the time could pick it up and understand it well enough to use it. Then we got github and gitlab, which made remote branches more manageable but introduced and entirely new class of developers who only added code through the web interface and emailed/called when they needed a merge or just merged to master because you were sick of the hand-holding. then we got the GUI clients for windows, which resulted in armies of programmers who didnt understand keys, or authentication, or why the gitlab/github server existed but just wanted to commit their code and as a result left the codebase with a graveyard of rebase --hard and reset head garbage that had to be explained later. supporting them became a nightmare of screen sharing and shouting. finally we have gitless? and developers now have to keep straight gui, console, gitlab/hub and some asinine wrapper script between the teams? so when jack commits with his GUI and accidentally drags and drops 3 branches, while jills gitless command wiped half the unprotected master, how does it get sorted out?
- pryce 8y ago
  Git was not first, and it arguably didn't achieve its dominance based on technical superiority. It almost certainly didn't achieve that dominance based on offering a better learning curve or a bizarre interface choice, even though I might personally understand and appreciate the relative tightness to its underlying systems. I also don't think we should defend a technology or tool by portraying it as a sort of null-hypothesis, a default automatically suitable for anyone except in special circumstances. I'm currently making source control recommendations for my new client. No one there is a full-time programmer, and they mostly do engineering and PLC work, but more recently they have to work with higher level languages from time to time. They absolutely need something they won't have to fight to learn. Other times I've recommended source control during my career include tutoring first-year/some second-year university students, who are often still only becoming familiar with programming and CLIs, and for whom Git seems both arcane and stress-inducing, two things you absolutely don't want from a source-control system. I am adamant that in neither of these above cases would git be the right choice. I'm also not convinced its the right choice for many development companies, which often have staff of a range of skill levels. I'm lucky in that I've nearly always been working with passionate programmers, where we can and do happily make the choice to adopt git without a second thought.
byteface 8y ago
so put this in my .bashrc? function gl() { git $* }
SlowRobotAhead 8y ago
Git with a veneer on it, that if there are problems you can revert to git-proper... How is that different from Git Desktop?
- fudged71 8y ago
  You don't leave the command line
  - erikb 8y ago
    > You don't leave the command line An advantage of gitless on one side, a statement about how to live life on the other side.
sealthedeal 8y ago
Seems like a cool side project, but I don’t quite git it.
bvrmn 8y ago
I recommend to visit https://learngitbranching.js.org/ https://learngitbranching.js.org/ to understand git better instead of using various wrappers.
black-tea 8y ago
This was bound to happen. The whole world moved to git without really understanding why. First we started to make "hubs" and bless their copies of the repo. Then people will start to strip and simplify git itself. Slowly but surely they will reinvent Subversion.
- kreetx 8y ago
  Does gitless really achieve the depths of subversion? Judging by the command list it looks like to add more easily understandable commands, some maskin the originals, ethers doing something more elaborate without requiring the use of flags, etc. (I'm definitely not going to start using this since I already know the real git, but I can understand where it is coming from)
- Certhas 8y ago
  gitless is just as expressive as git though. It's just a better interface with less state. Nor is it new. Check out their research paper.
  - kernelpicnic 8y ago
    It's not. They removed staging and haven't implemented all the features and flags the git CLI has.
bg4 8y ago
It's amazing the lengths people will go to avoid properly learning something.
- maxxxxx 8y ago
  Because they have a lot of other things to deal with. I have enough other things I have to learn and I simply don't have the time to become a git expert.
- brianpgordon 8y ago
  I have a fairly advanced knowledge of git (that is, at the level of porcelain and plumbing commands; I haven't touched the C codebase itself) and I intend to give gitless a try when I get back to work on Monday. My reason is that, while I'm a fan of git the technology, I think the default git CLI is an unmitigated fucking nightmare and I begrudge every neuron of space that I have to waste remembering how it works. Unfortunately, none of the graphical tools I've tried are as good. So I'm eager to try an alternative command line porcelain that's not so completely batshit insane. If it works out, maybe I can reclaim some of that wasted space.
  - jnurmine 8y ago
    Can you please give an example of the things you mean? Edit: wording.
    - brianpgordon 8y ago
      Sure, here are a few: - Command line switches are inconsistent. For example, to list remotes you use -v but to list branches you use -l - Speaking of command line switches, how about that bizarre need to separate paths in certain commands with "--" so that the parser doesn't get confused? I can never remember when that's necessary. - There's weird overlap between the porcelain commands that make them harder to learn than they should be. For example, git checkout can do the work of git branch. git pull usually does the work of git fetch. Some common operations get their own commands, while others require you to use switches on other commands. It really shows that git evolved organically from a bunch of shell scripts used by one particular dev team until it katamari damacy'd into a big agglomeration of random parts. - Poor defaults, such as git push --force not having the behavior of --force-with-lease, and also git push pushing all branches at once by default. - A bunch of commands are ridiculously overloaded or encumbered by historical limitations that don't make sense anymore. See https://redfin.engineering/two-commits-that-wrecked-the-user-experience-of-git-f0075b77eab1 https://redfin.engineering/two-commits-that-wrecked-the-user... - Many of git's mechanisms are overly complex and lead to a depressing number of bewildered users. E.g. witness the confusion and conflicting advice at https://stackoverflow.com/questions/6089294/why-do-i-need-to-do-set-upstream-all-the-time https://stackoverflow.com/questions/6089294/why-do-i-need-to... Another example is git reset, which is invariably a nightmare to explain to an intern or new developer who hasn't used git yet. Trying to learn what git reset does from reading the man page is like trying to learn calculus by examining the digits of pi. - Speaking of man pages, the man pages are comically bad. I find the git man page generator endlessly amusing: https://git-man-page-generator.lokaltog.net/ https://git-man-page-generator.lokaltog.net/
amelius 8y ago
My biggest problems with Git are that it doesn't handle large binary objects efficiently, and that it's difficult to treat multiple git repos as a single repo (useful for many things, including keeping versions coherent).
- lm2s 8y ago
  git-lfs doesn't solve the large binary issue?
  - amelius 8y ago
    It may, but it's a hassle to set up as it requires a separate server daemon (for which I don't understand the necessity, as a git repo itself can be stored on a server over ssh).
norswap 8y ago
Finally gave this a proper read. It's a bit disappointing indeed. Besides removing the index (which, as other commenters have pointed out, is questionable), there is one BIG change from Git to be noted: You can always switch branches, without losing your working directory changes. In the common case, this amounts to automatic stashing and unstashing, enabling you to quickly move around to an alternative repository state to check something out (with real git, this is too annoying and I resort to browsing the history on github more often than not). The second case illustrated in the comparison section is switching branches during a rebase, which git doesn't support without aborting the rebase. My recommendation: if that seems like a killer feature to you, use gitless. Otherwise, the slight simplification of commands isn't worth adding a layer on top of git.

181 points by jackbravo 8y ago

Interesting. It seemed to be just git-renamed, but the concept of "no staging area, smart-add everything" and "autostash everything on branch change" looks useful. Not as powerful as git, but it's always possible to fall back to non-abstracted git.

hackpr 8y ago

Yes. Git is powerful, but sadly has deep problems in its conceptual design. This is the reason why even mid-level engineers don't understand it fully. Love this work!

arximboldi 8y ago
Can you elaborate on the deep problems? I personally find it relatively conceptually elegant.
- fgonzag 8y ago
  I think the main problem is that many developers don't think of Git as a DAG, so they don't really understand at a fundamental level what the operations are actually doing. Once you understand this, Git really does become simple. All you have to do is map each command to the actual operation on the DAG. This video really explains it quite well, it's the one video that allowed me to fully grasp everything: https://www.youtube.com/watch?v=1ffBJ4sVUb4 https://www.youtube.com/watch?v=1ffBJ4sVUb4
  - bauerd 8y ago
    Yeah, but the question is whether a DAG is a good mental model for a VCS. Just because that's the underlying data structure doesn't mean it has to be the user interface too.
    - bachmeier 8y ago
      Exactly. This seems to be a point that the "Git is easy" crew doesn't understand. Not everyone (in fact, very few) find going into that depth for something that's nothing more than a tool to be reasonable. Reminds me of the Gentoo users that used to say compiling everything is a great idea for an OS.
      - jungler 8y ago
        I find that people understand "linearized" concepts easier than other kinds(DAGs included). When elements are left-to-right or top-to-bottom, you can read what is going on at a glance. So the next major step in VCS technology will most likely do something to help linearize our views and reduce the tangling that comes into play with any tree or graph structure.
        __blockcipher__ 8y ago
        Don’t we already have that in some respects? a) Most people’s git workflow might as well be linear. b) rebasing a development branch onto master literally linearizes it Where git shines though of course is where you can’t get away witha linear model
  - ruseOps 8y ago
    A big part of learning anything is understanding - at a fundamental level - what operations are being executed by whichever tool is being utilized. So if you will pardon the paraphrase, I think the main problem is that many developers don’t take the time to simply learn git.
- paulddraper 8y ago
  I compare it to 10-15 years ago, when functional programming was rather rare. Mid-level OO programmers would complain it was confusing and unfamilar, whereas in reality has beautiful and simple concepts. Git's use of a DAG is confusing and unfamilar for many programmers, though in reality it's beautiful and simple.
  - bachmeier 8y ago
    > Git's use of a DAG is confusing and unfamilar for many programmers, though in reality it's beautiful and simple. The difference relative to functional programming is that you get paid for one and the other is just a tool
    - adambyrtek 8y ago
      I would argue that functional programming is just a tool as well... Programmers are paid for solving problems and code is just a means to that end.
    - deleted 8y ago
      [deleted]
  - glitchc 8y ago
    Yup, second that. My old boss introduced the whole team to Scala and made us attend a weekly tutorial as part of training/team-building. Since then, I try to write stateless functions, methods and objects as much as possible regardless of language or platform. Git is quite elegant if one has a good grasp of graph theory.
    - Fins 8y ago
      Git is certainly great technically. But one should not need to know graph theory to source control files. And I believe that any version control system that does not follow the convention (that probably predates Linus' existence on Earth) that commit should actually commit changes to server, is, by definition, more4 hard to use than it has any reason to be. But this might be a good study in why Linux is not taking over the desktop, and unlikely to do so in foreseeable future.
- apichat 8y ago
  I think that you can find good explanations of these problems here : https://jneem.github.io/merging/ https://jneem.github.io/merging/ https://pijul.org/model/#why-care-about-patch-theory https://pijul.org/model/#why-care-about-patch-theory Unfortunatly Gitless doesn't solve them. But Pijul solve many problems of Git (and Darcs) and is easier to use. https://pijul.org https://pijul.org
  - pantalaimon 8y ago
    It appears as https://nest.pijul.com/pijul_org/pijul https://nest.pijul.com/pijul_org/pijul is currently being hugged to death?
    - apichat 8y ago
      It's ok now. They published a new version of Pijul and it seems that it cause some problems. https://pijul.org/posts/2018-11-20-pijul-0.11/ https://pijul.org/posts/2018-11-20-pijul-0.11/ https://pijul.org/posts/2018-04-21-pijul-0.10/ https://pijul.org/posts/2018-04-21-pijul-0.10/
    - Nzen 8y ago
      It's a once a month / once a quarter occurance. I'm not sure if it's because of changes to the webservice or not enough financial backing. I've basically given up on using early access pijul. I've had a problem with each of the last three versions, primarily pushing to Nest. It wouldn't be an issue if I could install pijul on NearlyFreeSpeech (because then I could self host on a known good version). I want pijul to succeed, its patching model sounds good. Clearly, it's working for some group of people. But I'm not one of them, and it's past where I feel like I'm wasting my time. I'll try again when they're v1.0
scrollaway 8y ago
Gitless doesn't change anything about git's concepts, it just abstracts away some commands. So if you think this solves the problems, they're clearly not "conceptual" faults. I think this is important because people are so quick to jump on the "git is bad" contrarian meme. Git is a fantastic piece of work and the CLI has a variety of issues. On top of this, git is conceptually unintuitive, so the CLI issues make for a worse experience.
- joshuamorton 8y ago
  The other half of the issue is that git's commands don't follow the abstraction. If each command mapped to a single dag operation, it might make more sense. But they don't (revert).
  - 4lch3m1st 8y ago
    They shouldn't. I'm not saying that Git doesn't have commands that can be hard to understand fully, but the whole point of any abstraction is to hide the "insides" of any operation so you don't have to think about them. Having commands for each DAG operation will just add more complexity and expose a structure which you shouldn't be handling manually.
    - sofal 8y ago
      I think in order to really feel comfortable with Git you have reverse that and think about the DAG as the actual interface and the CLI as the clunky implementation you use to modify the DAG.
sigsergv 8y ago
Git design is surprisingly clean and simple. The main issue of git is its CLI and commands naming. They are indeed unclear. But again, concept behind is absolutely amazing. You just need to understand that git repo is a series of snapshots and after that all other details become clear.
- reacweb 8y ago
  Naming is difficult. Good names suggest the right metaphore to understand something. But for git, there is nothing similar in physical world. "push" "pull" and "merge" seem ok, but even "branch" is an original concept different of its usual meaning. Maybe git should have used non english words to avoid confusion.
  - icebraining 8y ago
    Branch seems to fit the dictionary definition: "something that extends from or enters into a main body or source". And in fact, it didn't originate with git, it's at least as old as CVS.
    - reacweb 8y ago
      http://lmgtfy.com/?q=git+what+is+a+branch http://lmgtfy.com/?q=git+what+is+a+branch "A branch in Git is simply a lightweight movable pointer to one of these commits." https://git-scm.com/book/en/v1/Git-Branching-What-a-Branch-Is https://git-scm.com/book/en/v1/Git-Branching-What-a-Branch-I...

Vanderson 8y ago

What I see this seems to be doing is auto-staging every file that changes? And beyond that it has a few aliases for some commands. Is anyone else getting the same thing? I use git in my CMS which auto-commits a template file (text) on save. Which works great in a browser editor online. (ie, editing files remotely) But I am not seeing an advantage to "not staging" with local files. What does this save when working locally? Is there some disadvantage to staging I am not seeing here? Changing to "not tracking" seems like you removed the file from the repo, which in my opinion goes against the grain on how git works, and in a sorta bad way.

maxxxxx 8y ago

Removing staging seems a little odd. To me staging, especially with a GUI like Sourcetree, is almost the best part of git.

k__ 8y ago
Coming from CVS I found Git rather simple. But I have to admit, I mostly used it via Github and as a solo-dev.
- the_duke 8y ago
  As a solo dev you often don't use a lot of the more challenging Git features, like merge conflict resoluttion, rebasing, etc.
- maxxxxx 8y ago
  If you keep it simple then git is pretty simple and straightforward. I think some people just get a little too obsessed about source control.
davnicwil 8y ago
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.
- vthriller 8y ago
  I split file changes into multiple commits all the time. That alone makes many diffs much more readable and changes easier to follow, even if it results in occasional git-log clutter.
- jayd16 8y ago
  You might not use it to do partial commits but many others do.

Shorel 8y ago

Sounds like something I would use, if I had not a bunch of git aliases that do similar things. In other words, yes, this is useful.

huntie 8y ago

I remember seeing gitless a while ago and thinking it was interesting, but I found it to be very slow due to Python's startup time.

cyphar 8y ago

I 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 claim that the problems are conceptual. I don't think it's possible to fix conceptual problems in a tool by just wrapping it. I have heard people complain about the staging concept (personally I find it useful, because you can do 'git add -p' which allows you to craft intermediate commits or to-be-squashed fixup commits after you've finished some development), so it's removal in this tool is unsurprising. And it is nice to auto-stash on branch change (though personally I think that they should've made stashing a much better-supported concept in their Git wrapper -- I've never really liked how stashing was implemented in Git). I do really like that they appear to have worked hard to remove all of the super-scary warnings that Git likes to spit out. As someone who has taught high-school students how to use Git (among other things), I've learned that the easiest way to scare away people from your project is to have bright-red warnings in response to a user doing something. Most students describe it as though the computer is effectively screaming at them. Some tools over-compensate for this is and spew emoji in response to user input, so I'm happy this tool has struck the right balance.

deepspace 8y ago
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 obviously require a more complicated syntax and conceptual model. In any case, we are supposed to be professionals. Complaining that Git is hard to use is a bit like a machinist complaining that a CNC machine is hard to use. If you want to accomplish non-trivial things in any field, you have to be prepared to deal with some level of complexity. /rant
- saagarjha 8y ago

yarrel 8y ago

A simple text editor built on top of Emacs.

gnulinux 8y ago
Evil mode
bendunatosia 8y ago
2.50 per cent, that born in Asia by 4.47 per cent, that aged less than 15 years by only 0.46 per cent. Interstate annual population growth rates currently (1999–2000) vary between 1.7 per cent (Queensland) and –0.1 per cent (Tasmania), while massive differences exist in the direction, scale and components of population change in regions and communities. This paper takes the approach not so much of predicting the future as of exploring what will happen if demographic trends and tendencies evident in the mid- to late 1990s continue to evolve in the directions they seem to be moving in. No startling predictions are made of major reversals of trends. Instead the emphasis is placed on what seems likely given current trends and patterns in other developed societies. In many respects Australia’s current situation is in the middle among OECD nations, and seems to have further to go in some areas, including population distribution

not_kurt_godel 8y ago

After 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 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 redefinition of the concept of “branch,” and the elimination of “stash.” > 3. The creation of the notion of a “current branch,” and the redefinition of “head. I would agree that most of the delta from git represents an incremental improvement in usability; staging, stashing, and complex ignore rules are all things that are more likely to get in the way of novice to intermediate git users than help them. That being said, I'd classify those usability issues as minor in the overall picture. Most of them are trivial to smooth out either via git aliases or shell aliases - for example, I've had `ignore`, `show-ignored`, and `unignore` aliases for so long that seeing `git update-index --assume-unchanged foo` on the Gitless site made me realize I'd forgotten that that's what my `ignore` alias is actually doing under the hood. By far the most complex & difficult aspect of using git (and source control in general) is merge conflict resolution. I'm not convinced Gitless offers much benefit in this aspect and in fact I suspect it may actually make things worse. Complex conflict resolution is when the ability to distinguish between staged and unstaged changes is most useful and sometimes even crucial. Furthermore, while Gitless offering capability to 'pause' a conflict resolution by switching to another branch is neat, I would say it's very rare that I need to ever do so in the middle of a conflict resolution. Difficult resolutions require full concentration - if I find myself needing to switch to another branch in the middle of one, the context switch usually renders me unable to pick up where I left off and I wind up starting over to make sure I'm working from a clean slate. On the whole, I could see Gitless being valuable in academic environments to facilitate desparately-needed use of source control among researchers/postgrads/scientists. But I would steer clear of it in a software development career as I think it would stunt user's abilities to truly master a core tool of their profession in the long run.

hrktb 8y ago
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 switching between branches during conflict resolution, it might be for people like me who check back and forth reference branches when merging code. For instance a conflict can be between two feature branches I want to merge, and I’d need to check on master what is the current behavior. Or what’s the behavior on other branches that will need merging as well. Currently I’d just open github/gitlab on the other branches and compare from there, but I’d see the value in switching the local files. All in all I feel git is too aggressive in making the user deal with all the details when it could have sane non destructive defaults

dustfinger 8y ago

If 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 a fair amount also. Plus, emacs is awsome :-P [1] https://en.m.wikipedia.org/wiki/Rational_ClearCase https://en.m.wikipedia.org/wiki/Rational_ClearCase [2] https://en.m.wikipedia.org/wiki/GNU_Emacs#Extensibility https://en.m.wikipedia.org/wiki/GNU_Emacs#Extensibility

celeritascelery 8y ago
I never really understood git until I used magit
sepen77 8y ago
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.
kruczek 8y ago
I used ClearCase 3 years ago and this is spot on. ClearCase is little better than keeping revision history manually by zipping old versions of files. I sometimes wonder what kind of insane mind came up with its workflow. First of all, to checkout a branch, you don't simply select its name. You need to write a freaking configuration file to tell CC what you want to checkout. And it is entirely possible to accidentally write that configuration file in such a way that you'll have half of repository checked out from one version of code, while the other half is checked out from another version of code. Then there is history of changes. Or in case of ClearCase: histories of changes. Because there are many, in fact as many as there are files. Yes, each file has its own history of changes, completely independent from other files. So if you make a commit which changes 10 files, CC will create separate commit for each of those 10 files, each with the same commit message. Needless to say, browsing history with same commit messages repeated tens or hundred of times, is quite an adventure. Oh, and because of that, it is not possible to simply checkout some old version of code. If you are lucky, you will have put labels on all files of needed version of code, so then you can checkout that label. Otherwise the only option is to checkout based on dates of commits, and hope that your provided date won't actually cut any commit in half.

hyperpallium 8y ago

I like the idea of working with the simple datastore of git - immutable objects pointing to each other - and manipulate them with a programming language. But there's lots of things you routinely want to do that aren't convenient this way. Still has some appeal.

nimbius 8y ago

I feel like this is just another "git is hard so lets make it easier" program that makes collaborative development a pain. maybe its just my puritan work ethic. first we had git, and anyone who cared to spend the time could pick it up and understand it well enough to use it. Then we got github and gitlab, which made remote branches more manageable but introduced and entirely new class of developers who only added code through the web interface and emailed/called when they needed a merge or just merged to master because you were sick of the hand-holding. then we got the GUI clients for windows, which resulted in armies of programmers who didnt understand keys, or authentication, or why the gitlab/github server existed but just wanted to commit their code and as a result left the codebase with a graveyard of rebase --hard and reset head garbage that had to be explained later. supporting them became a nightmare of screen sharing and shouting. finally we have gitless? and developers now have to keep straight gui, console, gitlab/hub and some asinine wrapper script between the teams? so when jack commits with his GUI and accidentally drags and drops 3 branches, while jills gitless command wiped half the unprotected master, how does it get sorted out?

pryce 8y ago
Git was not first, and it arguably didn't achieve its dominance based on technical superiority. It almost certainly didn't achieve that dominance based on offering a better learning curve or a bizarre interface choice, even though I might personally understand and appreciate the relative tightness to its underlying systems. I also don't think we should defend a technology or tool by portraying it as a sort of null-hypothesis, a default automatically suitable for anyone except in special circumstances. I'm currently making source control recommendations for my new client. No one there is a full-time programmer, and they mostly do engineering and PLC work, but more recently they have to work with higher level languages from time to time. They absolutely need something they won't have to fight to learn. Other times I've recommended source control during my career include tutoring first-year/some second-year university students, who are often still only becoming familiar with programming and CLIs, and for whom Git seems both arcane and stress-inducing, two things you absolutely don't want from a source-control system. I am adamant that in neither of these above cases would git be the right choice. I'm also not convinced its the right choice for many development companies, which often have staff of a range of skill levels. I'm lucky in that I've nearly always been working with passionate programmers, where we can and do happily make the choice to adopt git without a second thought.

byteface 8y ago

so put this in my .bashrc? function gl() { git $* }

SlowRobotAhead 8y ago

Git with a veneer on it, that if there are problems you can revert to git-proper... How is that different from Git Desktop?

fudged71 8y ago
You don't leave the command line
- erikb 8y ago
  > You don't leave the command line An advantage of gitless on one side, a statement about how to live life on the other side.

sealthedeal 8y ago

Seems like a cool side project, but I don’t quite git it.

bvrmn 8y ago

I recommend to visit https://learngitbranching.js.org/ https://learngitbranching.js.org/ to understand git better instead of using various wrappers.

black-tea 8y ago

This was bound to happen. The whole world moved to git without really understanding why. First we started to make "hubs" and bless their copies of the repo. Then people will start to strip and simplify git itself. Slowly but surely they will reinvent Subversion.

kreetx 8y ago
Does gitless really achieve the depths of subversion? Judging by the command list it looks like to add more easily understandable commands, some maskin the originals, ethers doing something more elaborate without requiring the use of flags, etc. (I'm definitely not going to start using this since I already know the real git, but I can understand where it is coming from)
Certhas 8y ago
gitless is just as expressive as git though. It's just a better interface with less state. Nor is it new. Check out their research paper.
- kernelpicnic 8y ago
  It's not. They removed staging and haven't implemented all the features and flags the git CLI has.

bg4 8y ago

It's amazing the lengths people will go to avoid properly learning something.

maxxxxx 8y ago
Because they have a lot of other things to deal with. I have enough other things I have to learn and I simply don't have the time to become a git expert.
brianpgordon 8y ago
I have a fairly advanced knowledge of git (that is, at the level of porcelain and plumbing commands; I haven't touched the C codebase itself) and I intend to give gitless a try when I get back to work on Monday. My reason is that, while I'm a fan of git the technology, I think the default git CLI is an unmitigated fucking nightmare and I begrudge every neuron of space that I have to waste remembering how it works. Unfortunately, none of the graphical tools I've tried are as good. So I'm eager to try an alternative command line porcelain that's not so completely batshit insane. If it works out, maybe I can reclaim some of that wasted space.
- jnurmine 8y ago
  Can you please give an example of the things you mean? Edit: wording.
  - brianpgordon 8y ago
    Sure, here are a few: - Command line switches are inconsistent. For example, to list remotes you use -v but to list branches you use -l - Speaking of command line switches, how about that bizarre need to separate paths in certain commands with "--" so that the parser doesn't get confused? I can never remember when that's necessary. - There's weird overlap between the porcelain commands that make them harder to learn than they should be. For example, git checkout can do the work of git branch. git pull usually does the work of git fetch. Some common operations get their own commands, while others require you to use switches on other commands. It really shows that git evolved organically from a bunch of shell scripts used by one particular dev team until it katamari damacy'd into a big agglomeration of random parts. - Poor defaults, such as git push --force not having the behavior of --force-with-lease, and also git push pushing all branches at once by default. - A bunch of commands are ridiculously overloaded or encumbered by historical limitations that don't make sense anymore. See https://redfin.engineering/two-commits-that-wrecked-the-user-experience-of-git-f0075b77eab1 https://redfin.engineering/two-commits-that-wrecked-the-user... - Many of git's mechanisms are overly complex and lead to a depressing number of bewildered users. E.g. witness the confusion and conflicting advice at https://stackoverflow.com/questions/6089294/why-do-i-need-to-do-set-upstream-all-the-time https://stackoverflow.com/questions/6089294/why-do-i-need-to... Another example is git reset, which is invariably a nightmare to explain to an intern or new developer who hasn't used git yet. Trying to learn what git reset does from reading the man page is like trying to learn calculus by examining the digits of pi. - Speaking of man pages, the man pages are comically bad. I find the git man page generator endlessly amusing: https://git-man-page-generator.lokaltog.net/ https://git-man-page-generator.lokaltog.net/

amelius 8y ago

My biggest problems with Git are that it doesn't handle large binary objects efficiently, and that it's difficult to treat multiple git repos as a single repo (useful for many things, including keeping versions coherent).

lm2s 8y ago
git-lfs doesn't solve the large binary issue?
- amelius 8y ago
  It may, but it's a hassle to set up as it requires a separate server daemon (for which I don't understand the necessity, as a git repo itself can be stored on a server over ssh).

norswap 8y ago

Finally gave this a proper read. It's a bit disappointing indeed. Besides removing the index (which, as other commenters have pointed out, is questionable), there is one BIG change from Git to be noted: You can always switch branches, without losing your working directory changes. In the common case, this amounts to automatic stashing and unstashing, enabling you to quickly move around to an alternative repository state to check something out (with real git, this is too annoying and I resort to browsing the history on github more often than not). The second case illustrated in the comparison section is switching branches during a rebase, which git doesn't support without aborting the rebase. My recommendation: if that seems like a killer feature to you, use gitless. Otherwise, the slight simplification of commands isn't worth adding a layer on top of git.