23 ms·

Gitless: a version control system

516 points by antfarm 10y ago

chvid 10y ago
To me the really bad thing about git is its command-line interface. It has extremely verbose messages (writes out a lot of stuff that you don't need to know) and common use cases often requires multiple steps (ie. add, commit, push if you just want to send a change from your work machine a github repository). Compare this to subversion which is much less verbose, and in general just have one operation pr. use case.
- comboy 10y ago
  You can create aliases to execute multiple commands at once.
  - Klathmon 10y ago
    But why should each developer need to do that on each system they use? The whole point of this tool is to add a common set of things on top of git.
    - comboy 10y ago
      I don't see why each developer should. I'm perfectly fine with commands as they are by default. I'm just saying that if your problem is that you need to enter multiple commands instead of one, then instead of new VCS you may as well just put a config file in your home dir.
      - Klathmon 10y ago
        This isn't a new VCs though, its a layer on top of git. You can still use all git commands.
- jstimpfle 10y ago
  The CLI is indeed hard to learn. But the simplicity of git is not using it, it's its internal structures: http://eagain.net/articles/git-for-computer-scientists/ http://eagain.net/articles/git-for-computer-scientists/ If you understand these, then three stages to "commit to server" won't seem too many to you. (Often you don't need the index-building stage ("add"), and then you can say "git commit -a"). What people complain about is often the CLI's inconsistency. For example "git branch -d" vs "git remote rm" to delete things. Then some things you want to do can be achieved with more than one sub-command in totally non-obvious ways. And some sub-commands do more than "one thing", like "checkout".
  - masklinn 10y ago
    > But the simplicity of git is not using it, it's its internal structures: It's great that you can masturbate over it but I don't give a rat's ass, I just want to safely store and share my code with a VCS. I'd rather mercurial or darcs had won as they have sane (or even delightful) CLI, sadly the world disagreed. That git's porcelain is a giant abstraction leak of the internal structures and plumbing is not a feature.
  - philjohn 10y ago
    You shouldn't have to learn how the data structures of the tool work beneath the surface to successfully know how to use a tool.
    - zajd 10y ago
      You don't have to. The difference with git is that it's even possible.
      - cies 10y ago
        Why wouldn't it be possible with Gitless to learn the data structure?
    - jstimpfle 10y ago
      I think you should learn them, but ideally it should be obvious from using a tool what its internal data structures are. For persistent data structures simplicity, transparency and stability are very important.
- gbrown_ 10y ago
  Not sure why this appears to be been down voted. Git's command-line interface IS terrible. Certainly not unusable as most of interact with it every day. A somewhat satirical example of this is Steve Losh's Git Koans. http://stevelosh.com/blog/2013/04/git-koans http://stevelosh.com/blog/2013/04/git-koans That's not to say I don't think the underlying ideas of how Git works makes sense. I certainly think it's a lot better than RCS, CVS and SVN (never tired Mercurial).
  - SilasX 10y ago
    Love it! The hobgoblin one should mention "deleting a remote branch" in contrast to deleting a remote and deleting a local branch.
  - siberianbear 10y ago
    I realize that Hacker News generally frowns on "+1" types of comments. But those Koans are really funny. Every single one made me laugh out loud. I remember the pain of git. I hated git. Every time I used it I wanted to curl up in a soft, warm, dry space... like Perforce or SVN.
- tiborsaas 10y ago
  I disagree. It's one of the best command line tools I've seen. It detects errors, gives you suggestions and you can get along with a few basic commands. Yes, there are multiple steps, but that's okay because it can't figure out your intentions. Look: http://imgur.com/xY8dKWD http://imgur.com/xY8dKWD no verbosity here and this is 99% of my git workflow. Working in a team is more tricky, but you should use and IDE with built in git support. If you want to see a bad command line tool, try FFMPEG.
  - dom0 10y ago
    The progress displays for pushing and fetching are a bit verbose in my opinion, but otherwise I mostly agree.
  - drivingmenuts 10y ago
    FFMPEG is a case of a tool trying to do too much, although, trying to break it out into separate tools would probably be worse.
    - bobbyi_settv 10y ago
      Ffmpeg isn't a tool. It's a library to be used by programs who work with video and audio files. It has lots of features because different applications need different features. The ffmpeg command line program is basically a demo that exposes every one of those features directly. Having it "do less" would defeat the point.
  - zajd 10y ago
    It's simplicity and ubiquity are the only reason we keep seeing absurd programs like Gitless put forth. Imagine if someone came out with someone that "fixed the warts of QT" that was just a wrapper around QT. It's a joke. It's coffeescript vs javascript all over again and we saw how that played out. Don't like how git works? contribute. Don't make some stupid command line utility that just adds another entire layer of abstraction on top because people don't want to take an hour to read about git internals.
    - 10y ago
- patrickthebold 10y ago
  Well: git commit -am "message". Will add and commit. Pushing should be separate for a distributed vc.
- andydoan 10y ago
  Common use cases require multiple steps because that's how it's meant to be. Staging (adding), committing, and pushing are three fundamental operations of Git that, when combined in different ways, produce many use cases. Personally, I would rather have these operations exposed to me rather than having to memorize (or worse, have to search up) a different command every time for each use case.
- deleted 10y ago
  [deleted]
- wtetzner 10y ago
  I think part of the issue here is that the actions one wants to take isn't the same for everyone. For example, I basically never want to commit and then immediately push to some server. And for add, then commit, you can just do git commit -a. But being able to add and commit changes separately can be very useful.
- Pxtl 10y ago
  My pet peeve is how many steps it is to resolve a merge conflict on a branch I've pushed when were using controlled merges into dev branch. Stash or commit my work on the new feature branch I've started, then switch to dev, then pull, then switch back to my old conflicty feature branch, then merge from dev and resolve the conflicts, then push, then go to the server and complete the merge, then switch back to my old stashed branch so I can get back to work.
  - buerkle 10y ago
    No need to switch to dev: git co feature_branch git fetch origin dev git merge FETCH_HEAD
- meddlepal 10y ago
  Yea the Git CLI is a giant pile of steaming shit which is probably why there are plethora of visual tools for working with Git instead.
okket 10y ago
See also discussion about the Gitless paper: "Purposes, Concepts, Misfits, and a Redesign of Git" https://news.ycombinator.com/item?id=12612333 https://news.ycombinator.com/item?id=12612333 (1 day ago, 106 comments)
- Mithaldu 10y ago
  And it hits the most important point of: Gitless tries to do away with the staging area, thus completely misunderstands Git.
  - weberc2 10y ago
    It seems more plausible that Gitless just disagrees with its utility, or at least finds dancing around it overly cumbersome for the default case.
  - vesak 10y ago
    I've been using git professionally for a few years, and other distributed version controlling systems for more than a decade. This is the first time I see the phrase "staging area" in relation to VCS. Could you explain why it's an important concept?
    - nicky0 10y ago
      It's central to git. 'git add' puts changes in the staging area. Then 'git commit' commits the staged changes. The staging area is also known as the 'index' and the 'cache'. (Git has a consistency-of-naming problem.)
      - projektir 10y ago
        > (Git has a consistency-of-naming problem.) I wonder how many git usability issues could be solved just by addressing this and this alone.
    - Mithaldu 10y ago
      Please refer to the linked discussion. Various people ask about it and various people try to explain it (including me).
indolering 10y ago
I really wish Git came with some simplified version of dependency management, subrepo and subtree just don't cut it.
- qznc 10y ago
  Can you elaborate? What are you missing?
- supergreg 10y ago
  I've seen people recommend npm over submodules. You can give it a git repo as a package and tag/commit as the version so it's not just for JavaScript repositories and also pulls the submodule's own npm dependencies. Although I don't know if you can put it wherever you want or it will always go to the node_modules directory.
nhaehnle 10y ago
> Gitless is an experiment to see what happens if you put a simple veneer on an app that changes the underlying concepts. ... changes them how exactly? A big part of what I like about Git is that its underlying concepts are simple and clear and feel like the right building blocks for version control. So I'm curious to know how they believe they can improve on that.
- JohnKacz 10y ago
  It's not a quick answer but they cover this in the Gitless vs. Git section.[0] One main difference seems to be with branching "The main thing to understand is that in Gitless a branch is a completely independent line of development." [0] http://gitless.com/#vs http://gitless.com/#vs
  - arielb1 10y ago
    By that, AFAICT they mean "a branch, in addition to being a commit pointer, contains all the files in the working directory".
    - __david__ 10y ago
      And also the current merge state (though I'm not sure why I'd ever want to context switch away from a merge conflict resolution).
alexduros 10y ago
The approach of this experiment is interesting. But, as an experienced git user, I think it does not include easy access to very powerful and easy-to-learn features of git like "git * -p" which bring some interactivity in git commands.
- hobo_mark 10y ago
  I assumed all `git` commands would still be available even if one might prefer `gl` for some tasks, am I missing something?
  - MitchellCash 10y ago
    No, that's also my understanding. "Gitless is an experiment to see what happens if you put a simple veneer on an app that changes the underlying concepts. Because Gitless is implemented on top of Git (could be considered what Git pros call a "porcelain" of Git), you can always fall back on Git."
- taneq 10y ago
  As an experienced git user, are you not outside the target audience? From a quick read through, Gitless seems like it's designed for non-git-users who need git access.
- masklinn 10y ago
  The text specifically points to `commit -p`. It could also have a `checkout -p` (e.g. both mercurial and darcs have interactive reverts)
supergreg 10y ago
Auto stashing and restoring when moving branches or in the middle of a rebase seem like nice features. I'll definitely try it for that.
nbevans 10y ago
It seems inspired by Mercurial?
- masklinn 10y ago
  Not really. Mercurial doesn't use `checkout` in that way (it's an alias for `update` which updates the working copy to a specific changeset — or the tip of the current branch, the hg version of TFA's checkout is `revert`), prints a list of revisions with `log` and uses `add` and `remove` to track and untrack files. It doesn't match Darcs's CLI either.
  - nbevans 10y ago
    I meant more from the perspective that it wraps a more friendly CLI on top of a DAG of commits. Didn't mean that it's 1:1 copying Mercurial :)
    - masklinn 10y ago
      Well then it's copying more or less any DVCS which is not git, git(1) is the least friendly DVCS CLI I know of.
      - nbevans 10y ago
        Indeed.
xixixao 10y ago
It does seem in some ways similar to Mercurial, but changes things which both Mercurial and Git share (like having to resolve tracked modified files before switching branches/bookmarks). I think if you want to make a fast and simple interface though, you should go a step further towards gui (like https://github.com/xixixao/hg-sl-up https://github.com/xixixao/hg-sl-up ) and remove the concept of branches/bookmarks altogether (I stopped using bookmarks in mercurial). The repo is just a tree of changes, I already tag it with commit messages, shouldn't need to tag it again with branch/bookmark names. Would love to be able to leave the commits in WIP state though, that would be super convenient (shelving sucks).
- masklinn 10y ago
  That sounds a lot like Darcs's model, which is pretty fun to play with (and darcs has a really nice CLI). You may want to take a gander at it.
  - botexpert 10y ago
    Or pijul. https://pijul.org/ https://pijul.org/
    - masklinn 10y ago
      While in theory I appreciate what pijul is trying to do, I'm not going to plug it until it at the very least self-hosts. Two years in, still not there.
  - cm3 10y ago
    git and hg are somewhere between Subversion and Darcs/Pijul. You kinda deal with individual patches (commits) but not quite as prominently as in Darcs/Pijul. It's all a compromise, and even Subversion gained merge features, leaning more into the git/hg realm. Tracking patches has huge advantages, especially in open source work, whereas it's not really needed if you just commit to master/trunk all the time and merge with a tool and not by tracking patches. Darcs and Pijul are what would be a perfect fit for the patch queue model used by kernel maintainers.
NKCSS 10y ago
I wonder why there is no context-aware vcs; e.g. one that understanding the language and resolve diffs at a functional level. Would make change tracking and merging so much easier. Alternative would be to split each function into a separate file, for C# that would mean partials and the compiler just joins them.
- bunderbunder 10y ago
  Possibly because then you'd need a parser for every language someone might use. But, since you mention C#, see: https://www.semanticmerge.com https://www.semanticmerge.com
- mbrock 10y ago
  Git is intentionally stupid about file contents to make it simple and robust. Smalltalk has some systems like you describe. They're integrated with the compiler and Smalltalk makes that easy. Otherwise I think it's mostly that such systems are lots of work to make and maintain. Treating files as plain text has huge benefits when you consider simplicity and flexibility. The real "UNIX philosophy" is "worse is better": simpler, quicker, finished solutions are more likely to flourish (except X11).
- palunon 10y ago
  Git does support external diff and merge tools. I guess they don't want to support every language ever used directly inside the VCS.
rplst8 10y ago
When people say they don't like git, I lose a little faith in them as a programmer and/or engineer. This is probably due to my own biases of having worked with folks that just don't want to invest the time in learning it. That or they are afraid of branching/merging. To me this indicates intellectual laziness which isn't the kind of laziness that makes a good programmer (as is with the quote from Larry Wall and the kind of laziness he speaks of).
- cmrdporcupine 10y ago
  Or we've used other DVCS systems like Mercurial or Bazaar or Bitkeeper that had sane CLIs with consistent and self-explanatory user interfaces. Git is powerful. And also seems to have a powerfully elitist community around it, as evidenced from your comment.
- Certhas 10y ago
  I work with a whole bunch of scientists that program. Some mathematicians, some theoretical physicists. We run into git issues more often than we should. It's lazy to blame git issues on intellectual laziness. Any human designed system can be learned with enough effort but in git there seems to be significant superfluous effort. Effort that probably makes sense for some use-cases that git was developed for, but as it has become ubiquitous and now we all have to live with it, programmers or not. In my view, git has too much state. The state of my directory, the state of my branch, the staging area, the stash, etc.. these all interact in non-trivial ways when merging/branching. Gitless shows that it can be done with less state. And the design of the interface _is_ atrocious: http://stevelosh.com/blog/2013/04/git-koans/ http://stevelosh.com/blog/2013/04/git-koans/
  - zajd 10y ago
    It's really not though. And posting articles that pretend like "git rev-parse --abbrev-ref HEAD" is the best way to view what branch you're working on just makes you look dumber than you do for acting like git is difficult to work with. If people writing blog posts about "how bad the git interface is" and more time instructing newer programmers (the only ones who have any reason to complain about git) on how to correctly use the tools maybe we wouldn't have to hear so much whining about the tool. Anyone who has been in the field understands that for all it's tradeoffs git is an incredible breath of fresh air from systems like CVS/SVN.
whack 10y ago
Very cool. The idea which I liked most, is the ability to switch between branches, even though you still have uncommitted changes. With git, I'm forced to either make an extraneous commit, just to enable branch switching, or stash all my changes into a stack which I may later forget all about. Both of the solutions above are really cumbersome and prevent easy context switching. The only feature I noticed missing, is the ability to stash changes. I use this most often to move changes from one branch to another branch, without cluttering history with an extraneous commit. How would this work on gitless?
- m3kw9 10y ago
  Just use the normal git fallback command
  - gcb0 10y ago
    me nor my web search engine never heard of it
    - twic 10y ago
      Perhaps m3kw9 means that if there's something that you can't do in Gitless, you can fall back to the Git way of doing it, since both use the Git plumbing.
  - deleted 10y ago
    [deleted]
- iagooar 10y ago
  > Both of the solutions above are really cumbersome and prevent easy context switching. Too frequent context switching might actually be perjudicial for your productivity and health, while increasing stress levels. So git not making it trivial might not be a bad thing, in my opinion.
  - wreft 10y ago
    I don't think perjudicial is a word.
loup-vaillant 10y ago
Please please please support "zoom text only". First time in a while zooming caused a web site to have its text overlap with itself.
partycoder 10y ago
More accurate to call it a git client rather than a version control system. It is git. Then, many clients have tried to hide git complexity under some friendly UI. They might be productive in some cases (e.g: to manage your stage area), but for others at some moment they will end up confused and not knowing what to do.
achikin 10y ago
I don't see any improvement over git. Just another set of commands you'll need to learn from scratch. Some ideas seem not very good, like committing all changed files by default. If you find git commands too verbose - try 'tig' - the ncurses git client, it saves a lot of time and efforts being simple and straightforward at the same time.
- gcb0 10y ago
  wildly guessing from the clone to checkout name change, it probably started as a git for subversion users?
  - moonmusick 10y ago
    Removal of the staging area seems like a move in this direction too.
pqdbr 10y ago
I highly recommend GitX-dev, which is a free, open-source GUI for Git on the Mac. https://rowanj.github.io/gitx/ https://rowanj.github.io/gitx/ The ability to stage/unstage individual lines using a graphical interface is really nice, and after some years using it I can't think me going without it anymore. Nowadays I only use the command line when I want to do interactive rebase.
- gunn 10y ago
  Is there a better maintained version?
- dannysu 10y ago
  I knew that you can already interactively stage individual lines via the command line using git add -p, which is what I use. But you mentioned unstage as well which I've never done before, so I looked it up. Looks like if you want to do that on the command line it's git reset -p
popmystack 10y ago
This seems extremely pointless. At worst, this seems like the Gitless team doesn't understand what Git is doing internally, which is a pretty dangerous state to be in when you're trying to "improve" something. Git as a whole: * Makes it really hard for you to do something you really shouldn't be doing * Forces you to stay "clean" and guides you to working well with other repository copies (i.e. the whole point of Git). * Warns you and makes suggestions when you make a mistake, from silly typos to incorrect command flags. * Makes it easy to guess how the command should be formatted or how certain structures are formatted based on convention. They decided to rename certain features that not only give you the wrong idea of what's actually going on, but will no doubt make it extremely hard to research any errors if something goes wrong. A good example of thing is gitless' "fusing" feature. It's just rebasing stuff. Why rename it? Why rename "checkout" with "switch", when this semantic is used throughout git? And then you have completely brain-damaged concepts such as this: >(i.e., a file can be untracked on some branch but tracked on another and Gitless will remember this): Honestly? There was no better way to indicate to me that you're just trying to make git fit some erroneous concepts in your head, and that you don't really understand what you're doing. This combined with the "auto-save" feature seems like a terribly, terribly bad idea and is just begging for a lazy developer who didn't take the time to understand his tools to completely shit on the repository he's working on, locally or remotely. Take the time to understand your tools. Git is incredibly simple underneath. It's not complicated.
- ajkjk 10y ago
  You have such a toxic and arrogant attitude about people trying to make the world a better place. It's shameful.
  - popmystack 10y ago
    Uh, what? You respond to my post with some of the problems with this system in a hyperbolic, confronting manner without contributing anything. They are not "making the world a better place." Please don't post such non-sense here.
    - 10y ago
heisenbit 10y ago
Git is powerful. While the underlying architecture has beautifully simple aspects arguing that the complexity of the git tool-chain is simple is similar to arguing that TeX is simple as it is written in a simple language. Git is managing trees of file-sets in a distributed manner. It took many generations of configuration management systems to get there. Git is bottom up. Understand the inner workings and you know what you can do. But coming from a user perspective there is a gap - first one needs to wrap ones head around the tool. Git imho. is more a framework than a tool. On Stackoverflow simple questions yield different answers all yielding results but having various trade-offs. Usability is also about orthogonality and looking from a user perspective (not an implementation perspective) Git offers often quite a number of paths getting to a certain goal. Individuals, teams and tooling all trying to settle on certain workflows enabled by git effectively deciding to use only a subset. Particularly when it comes to teams agreeing on workflows becomes important. Git as a tool is here helpful in the sense that it enables almost everything. But for a team it takes more than agreeing on using Git. Other tools come with more comprehensive practices.
- KKKKkkkk1 10y ago
  As a tangent, I think calling git a distributed system is misleading. Git is primarily a history manager for a local directory tree that has commands to sync with remote machines. Having to type stuff like git remote add mothership ssh://foo@bar.baz git push mothership in order to sync is not what I usually associate with a distributed system. The word distributed conjures something that's more like dropbox, where things sync transparently.
  - deleted 10y ago
    [deleted]
  - deleted 10y ago
    [deleted]
  - qznc 10y ago
    Being distributed is essential for gits design. It explains why there are strange sha1 ids instead of incremental revision numbers like with svn, for example.
mundanevoice 10y ago
How is this any different from hub (https://github.com/github/hub https://github.com/github/hub). It provide useful command like aliases. Along with ghi(https://github.com/stephencelis/ghi https://github.com/stephencelis/ghi), I can do everything like creating new repo, sending PR, looking/creating/updating/commenting on issues with my command line.
jasonkester 10y ago
I think there will be a very small subset of developers who are confused by the Command Line Interface of Git, but not confused by the Command Line Interface of this thing. Sure, there are tons of developers who find Git confusing. But the solution they're looking for is something like Git Extensions that removes the silliness of memorizing and typing a bunch of commands in to a terminal. In terms of Global Confusion Index, this only drops us from 98 to 97. A simple GUI version of this same concept would seem a much better plan.
relics443 10y ago
Seems like a couple of well named aliases would achieve 99% of what gitless does.
kazinator 10y ago
Git needs the parent pointer equivalent of NIL. Whenever I start a blank new repo nowadays, I do a git commit --allow-empty -m "NIL" See, many git operations require a parent reference! For instance if you want to interactively rebase the top commit, it's actually "git rebase -i HEAD^": rebase back to (but excluding) HEAD's parent. The equivalent "git rebase -i HEAD~1" means the same thing: that ~1 actually spans two commits: it refers to the parent, but since the parent is the excluded delimiting endpoint you can think of that 1 as being the number of commits being rewritten. If all you have is a single commit with no parent, you cannot rebase it. If you have NIL there, it takes the HEAD^ reference; no problem. Essentially, git is a list manipulation system whose use cases fail when operations span the entire list, oops. You can tell it was designed by someone who never took a Lisp or Scheme course (or forgot all of it). Imagine if (remove 3 '(1 2 3)) failed because the suffix (3) has no CDR, haha. "Sorry, you can't "rebase" your (1 2 3) to (1 2) because 3 is the "root commit"! Just scrap the whole thing and build (1 2) in its place."
- twic 10y ago
  FWIW, Mercurial has this - there's a notional changeset called 'null' whose hash is all zeroes, which is the parent of every changeset which does not have a real parent. As a result, you can rebase a root changset. For example: $ hg init $ echo silver >colour $ hg add colour $ hg commit --message 'First commit' $ hg checkout null 0 files updated, 0 files merged, 1 files removed, 0 files unresolved $ echo liquid >state $ hg add state $ hg commit --message 'Second commit' created new head $ hg log --template '{rev} = {node|short} child of {p1node|short}: "{desc}" @ {date|isodate}\n' 1 = 99f1472f8a69 child of 000000000000: "Second commit" @ 2016-10-02 17:29 +0100 0 = 6433a3e95c3d child of 000000000000: "First commit" @ 2016-10-02 17:29 +0100 $ hg rebase --source 0 --dest 1 rebasing 0:6433a3e95c3d "First commit" saved backup bundle to /path/to/repo/.hg/strip-backup/6433a3e95c3d-331b8224-backup.hg $ hg log --template '{rev} = {node|short} child of {p1node|short}: "{desc}" @ {date|isodate}\n' 1 = b9951882336f child of 99f1472f8a69: "First commit" @ 2016-10-02 17:29 +0100 0 = 99f1472f8a69 child of 000000000000: "Second commit" @ 2016-10-02 17:29 +0100
  - kazinator 10y ago
k__ 10y ago
Git is, like many professional tools, something you simply got to learn. But like with many professinal tools, you don't need to know everything to get to work. I don't know all Photoshop or Ableton Live features, but I can improve my photos or create songs non the less. With these commands you can already start your own repo and work on it locally: git init // crate new repo git status // show which files are changed and which of them are staged git add -p // add "chunks" of changed files to the stage git commit -m "<commit_msg>" // commit everything added to the stage with a commit message git log // show a list of commits git checkout <file> // throw away all changes since the last commit (one file) git reset --hard // throw away all changes since the last commit (all files) If you want to work with a repo from somewhere else like Github etc., you need a few extra commands: git clone <repo_url> <target_dir> // clone a remote repository locally git pull // download and merge new commits in the remote repo that happened since the last clone/pull git push // uploading your own changes after a commit to the remote repo I think these 10 commands are all that is needed to get your own project into Git. Yes, the more people are working on a project, the more commands you need, like creating a new branch and getting commits from one branch to another, or amending commits because you forgot something etc. For a professional tool this isn't too much, I think. The 10 commands I mentioned will be remembered in less than a week. Most of the rest isn't needed often (maybe merge/rebase and branch depending on how you intend to use Git), but they shouldn't take too long either.
- vbtemp 10y ago
  > Git is, like many professional tools, something you simply got to learn. Nailed it.
  - rplst8 10y ago
    Agreed. I'm seeing terms like "elitist" being thrown around below for "git apologists" when it's simply a matter of learning a tool. Not everyone needs all the power of the git CLI and the complications it brings - but when you do need it, it's there to fix the dumb things we all do sometimes. I think if you look deep in the guts of Clearcase for example you will see nastiness that makes git look like the ls command.
X86BSD 10y ago
Git just is not my thing. I prefer Fossil SCM. Now that is a sweet little SCM.
- jrapdx3 10y ago
  I like Fossil too, and use it for many small projects. To some extent projects can be converted to/from git, but I haven't done much at all with that and I'm sure there are limits. Nonetheless, Fossil is an option with good usability that doesn't lock users in when there are reasons to convert repositories to other tools.
dahart 10y ago
My criteria for whether an interface to git is truly easier is whether artists can use it. I've worked in games alongside artists, with everyone using Perforce. At some point we switched to Perforce for the art, and git for the programmers, with a big janky glue system in-between. Git couldn't really handle all the binary assets, and the artists couldn't really handle git, so it made sense. When we switched, it also took a long time before the programmers could really handle git too, fwiw. I've long said I'd love to see something that's as nice a GUI as p4v, but with git under the hood. I haven't yet seen a git GUI that even approaches now nice p4v is, and git on the command line, once you learn it, is the best interface to git hands down. I can't tell, but does gitless look like it could make a simpler gui to anyone else? I love the idea of gitless, I'll have to try it, but I get the sense that I'd end up needing to switch to git for some things.
- rakpol 10y ago
  Re. GUIs for git, have you taken a look at GitKraken [1]? I haven't had the chance to put it through its paces, but it looks pretty good. [1]: https://www.gitkraken.com/ https://www.gitkraken.com/
  - novaleaf 10y ago
    I recently switched to GitKraken from SourceTree. SourceTree has better features and workflow, but SourceTree performance is very VERY terrible. I'm talking 2+ minutes to wait for some operations to complete. Not sure why GitKraken makes it so hard to add remote repositories and doesn't allow auto-push, and other niceties. But I use it for normal checkin / branch switching workflows and it's great.
  - dahart 10y ago
    I have. I've used all of the git GUIs. None are as good as p4v as far as a GUI goes, and none are particularly usable by artists. Especially powerful in p4v is the timelapse view, which nothing in any git client comes close to approaching.
- douche 10y ago
  As far as version-controlling art, I'd lean towards a system where checking a file out locks it from any other concurrent modifications. Unfortunately, trying to merge concurrent changes into an image file, for instance, is just about impossible. It's almost as bad trying to work with MS Office file types - I wish I could get people on my team to use something else that is more VCS friendly, like HTML or Markdown, but that's an uphill battle. Even better would be if we actually used the versioning and collaboration features that are built into some of the tools like Office 365 that we pay for, but can't seem to leverage...
caseymarquis 10y ago
I think tools like github desktop make this unnecessary. I've given some people a quick introduction to git using the desktop app, and they were up and running in about 20 minutes. Sometimes something goes horribly wrong, but it's a rarity. I think the worst case scenario encountered was: "No one knows what's wrong, so we'll use a comparison tool and manually merge in the changes from this branch with a bad repo state as a commit."
xenadu02 10y ago
The git CLI has gotten a lot better over the past few years. Making simple branch push the default was a good move. There are some things that could be improved (and any of these can be config options for those who want the old behavior): * switching branches should auto-stash changes, then auto-apply when switching back (apparently one of the things gitless does) * a rebase should leave a marker in the tree (with the old hashes) so if you force-push other clients can offer more intelligent options (e.g. Looks like these commits were rebased by a_user; rebase your changes skipping duplicate commits or merge?) * git still allows you to create branch names differing only by case which is a problem on macOS and Windows * cherry-pick -x should be the default and tools should do a better job of showing the relationships * tag sync should include the commit and update on pull so rewriting tags isn't such a PITA. Maybe we need movable vs static tags.
nardi 10y ago
In this thread, lots of people wanting to demonstrate their deep knowledge of an arcane tool, thus proving the whole point.
- tadfisher 10y ago
  Posted this upthread, but here's an apt Linus quote: > The first Git For Dummies and Git Visual Quickstart books are going to be out in a couple of months, and that is the beginning of the end as far as I’m concerned. Those books mean the end of git expertise and github reputation as reliable indicators of geek status. Once a technology is adopted by the masses the extreme geeks find something more esoteric. Look at what happened to Ruby on Rails. The people stumbling their way through Rails to-do list tutorials have never even heard of DHH.
  - laurentdc 10y ago
    That sounds like a very elitist approach. So the technology is good as long as it's arcane, but as soon as it becomes mainstream then it's "the beginning of the end"? ...do we even need a "reliable indicator of geek status"?
  - okket 10y ago
    It is not a quote by Linus but part of a satirical piece, see: http://typicalprogrammer.com/linus-torvalds-goes-off-on-linux-and-git/ http://typicalprogrammer.com/linus-torvalds-goes-off-on-linu...
Xeoncross 10y ago
I see gitless has a bunch of 'gl ____ -c foobar' as well. Why is the -c (create?) needed? Isn't it apparent that if that branch doesn't exist we need to create it? If that remote doesn't exist we need to create it? Convention over configuration?
- ggreer 10y ago
  > Isn't it apparent that if that branch doesn't exist we need to create it? It could just be misspelled. I've accidentally created quite a few misspelled branches in my time. E.g.: "bug-fix" vs "bug_fix" vs "bugfix".
- smitherfield 10y ago
  Yeah but then there's the issue of simple misspellings. Perhaps switching and creating should be separate commands.
  - ggreer 10y ago
    Exactly. It would be like if `cd pathname` was the equivalent of `mkdir -p pathname && cd pathname`. Even with tab completion, only a tiny minority of users want that behavior. To most, it invites mistakes.
projektir 10y ago
I don't know if this is not wholly rational, but over time, I became more and more cautious of using any tool for git that wasn't the pure git command line itself. I don't like how the command line was designed, but at least I know what's going on. With other tools (the latest culprit is Visual Studio sync), I often have a reaction of: "You did WHAT?"
admax88q 10y ago
ITT: People trying to justify all the time they spent becoming experts on git's esoteric interface.
maker1138 10y ago
I'm surprised at how many people are responding negatively to software that improves user experience. Suppose we had started out with the command UI that gitless has and someone came along and tried to sell us the current git cli UI. It would be completely ridiculed. The only thing possibly questionable about the gitless interface is that it does away with staging. However, you can always fall back to git for staging functionality if you like, and use gitless for most other commands. I think it is a win.
- gnuvince 10y ago
  I think the author address that point in the introduction: > Experts, who are deeply familiar with the product, have learned its many intricacies, developed complex, customized workflows, and regularly exploit its most elaborate features, are often defensive and resistant to the suggestion that the design has flaws. Having spent dozens, even hundreds, of hours learning the intricacies of the Git command-line, it must be extremely shocking and insulting when you are told that those efforts were in vain, because the original UI was not very good and an alternative can be grokked by people of varying levels of technical competence with only a fraction of the effort you put into the original thing. I think this is what we're seeing here: people will try and defend their time investment by arguing that a professional would learn the hard thing and not lower himself to easy-to-use tools, that the new UI hides some powerful features that are rarely used, etc.
  - austinjp 10y ago
    Indeed. Also known as "sunk cost fallacy".
    - cies 10y ago
      > "sunk cost fallacy" I like to spot those, did not see this one though, but indeed, sunk cost fallacy it is. Well spotted :)
    - IshKebab 10y ago
      I think it's a little different from that actually. That's normally about the merits of ongoing financial investment, but I get your analogy and there should be a name for it because you see it all the time from compsci types. How about "sunk knowledge fallacy" or something like that?
gsmethells 10y ago
Command-line and git aliases will get you most of what this has to offer unless I'm missing something.
varcharlie 10y ago
Do people really consider git hard to use? It's very easy to learn... In fact, if you can't learn git I would not be confident in your ability to learn any other important technology using the internet as your resource. You don't even need to have internet access as long as you have `man`.
varcharlie 10y ago
git init - create a new repo git clone - download an existing repo from the internet git status - show changes made in repository and any pending additions that haven't been committed git diff - show changes made to file that haven't been committed git pull - pull changes from remote repository git push - push changes to remote repository git log - show log of commits git mv - move a file while preserving diff git rm - remove a file git add - add a file git checkout - checkout a branch, file, etc git reset --hard origin/master` - undo all changes, reset to last commit in master git blame - show who is responsible for what in a specific file git fetch - download objects from another repo/branch git merge - merge two branches together ... etc.
nickhuh 10y ago
In my experience, making "gl commit" equivalent to "git commit -a" seems like a bad idea. When leading a team, especially of newer coders, one of the most effective ways I've found of keeping the git logs and the code base sane more generally, is to force people to review their own code at the time when they commit it. Individually adding each file with "git add -p" achieves this, and "git commit -a" squashes it. Reading the methodology used to develop gitless yesterday was interesting, but if I recall correctly, I think it left something out. They looked at how often a software design allowed users to complete their intention, but the tool ideally not only should allow users to complete their intention, but should encourage users towards practices that increase the quality of the end product. While people may struggle with staging at first, I think it in the end encourages better software, which is my biggest concern.
GutenYe 10y ago
I like, just that python is slow.
denfromufa 10y ago
Has anyone compared this to legit? https://github.com/kennethreitz/legit https://github.com/kennethreitz/legit Both seem to simplify the git workflow.
XorNot 10y ago
gitless looks pretty nice, and I'll be installing and using it on my work PC tomorrow to see how I get along the rest of the week with it. I'm curious to see how the experiment goes.
anarcat 10y ago
I am also pleasently surprised by this initiative. I consider myself an advanced git user so I am not sure I would use it myself, because my brain is hardwired to git's wicked commandline interface now. There is little that surprises me in git nowadays. I am used to give out simple "the 10 git commands you will ever need" tutorials to people, but it's true that it is confusing for people, even with that. gitless takes out significant confusion out of the daily grind of using git, so much that I may end up recommending it instead of git itself, especialy since they are interoperable. What I would love to see would be to have those commands percolate back into git itself. git's usability has improved significantly since it started, and while this project shows there's still a lot that can be improved, history has shown us that git can be improved. track, untrack, history, switch, resolve, publish, init's remote argument, all those could be added as commands into git and equivalent commands could be deprecated or just kept for the hardcores like me that don't want to be bothered learning a new simpler interface. Unfortunately, given the reaction on the mailing list, I am thinking this will not/never happen and gitless will remain a friendly fork: http://marc.info/?l=git&m=147527432403442&w=2 http://marc.info/?l=git&m=147527432403442&w=2
GirlsCanCode 10y ago
I don't know if this is a good idea. People say "programming's too hard" so we got Ruby and set the world back 10 years.
petre 10y ago
Why would I use this over Mercurial, other than being able to collaborate with others using git? You still need a Python interpreter to use it.

516 points by antfarm 10y ago

chvid 10y ago

To me the really bad thing about git is its command-line interface. It has extremely verbose messages (writes out a lot of stuff that you don't need to know) and common use cases often requires multiple steps (ie. add, commit, push if you just want to send a change from your work machine a github repository). Compare this to subversion which is much less verbose, and in general just have one operation pr. use case.

comboy 10y ago
You can create aliases to execute multiple commands at once.
- Klathmon 10y ago
  But why should each developer need to do that on each system they use? The whole point of this tool is to add a common set of things on top of git.
  - comboy 10y ago
    I don't see why each developer should. I'm perfectly fine with commands as they are by default. I'm just saying that if your problem is that you need to enter multiple commands instead of one, then instead of new VCS you may as well just put a config file in your home dir.
    - Klathmon 10y ago
      This isn't a new VCs though, its a layer on top of git. You can still use all git commands.
jstimpfle 10y ago
The CLI is indeed hard to learn. But the simplicity of git is not using it, it's its internal structures: http://eagain.net/articles/git-for-computer-scientists/ http://eagain.net/articles/git-for-computer-scientists/ If you understand these, then three stages to "commit to server" won't seem too many to you. (Often you don't need the index-building stage ("add"), and then you can say "git commit -a"). What people complain about is often the CLI's inconsistency. For example "git branch -d" vs "git remote rm" to delete things. Then some things you want to do can be achieved with more than one sub-command in totally non-obvious ways. And some sub-commands do more than "one thing", like "checkout".
- masklinn 10y ago
  > But the simplicity of git is not using it, it's its internal structures: It's great that you can masturbate over it but I don't give a rat's ass, I just want to safely store and share my code with a VCS. I'd rather mercurial or darcs had won as they have sane (or even delightful) CLI, sadly the world disagreed. That git's porcelain is a giant abstraction leak of the internal structures and plumbing is not a feature.
- philjohn 10y ago
  You shouldn't have to learn how the data structures of the tool work beneath the surface to successfully know how to use a tool.
  - zajd 10y ago
    You don't have to. The difference with git is that it's even possible.
    - cies 10y ago
      Why wouldn't it be possible with Gitless to learn the data structure?
  - jstimpfle 10y ago
    I think you should learn them, but ideally it should be obvious from using a tool what its internal data structures are. For persistent data structures simplicity, transparency and stability are very important.
gbrown_ 10y ago
Not sure why this appears to be been down voted. Git's command-line interface IS terrible. Certainly not unusable as most of interact with it every day. A somewhat satirical example of this is Steve Losh's Git Koans. http://stevelosh.com/blog/2013/04/git-koans http://stevelosh.com/blog/2013/04/git-koans That's not to say I don't think the underlying ideas of how Git works makes sense. I certainly think it's a lot better than RCS, CVS and SVN (never tired Mercurial).
- SilasX 10y ago
  Love it! The hobgoblin one should mention "deleting a remote branch" in contrast to deleting a remote and deleting a local branch.
- siberianbear 10y ago
  I realize that Hacker News generally frowns on "+1" types of comments. But those Koans are really funny. Every single one made me laugh out loud. I remember the pain of git. I hated git. Every time I used it I wanted to curl up in a soft, warm, dry space... like Perforce or SVN.
tiborsaas 10y ago
I disagree. It's one of the best command line tools I've seen. It detects errors, gives you suggestions and you can get along with a few basic commands. Yes, there are multiple steps, but that's okay because it can't figure out your intentions. Look: http://imgur.com/xY8dKWD http://imgur.com/xY8dKWD no verbosity here and this is 99% of my git workflow. Working in a team is more tricky, but you should use and IDE with built in git support. If you want to see a bad command line tool, try FFMPEG.
- dom0 10y ago
  The progress displays for pushing and fetching are a bit verbose in my opinion, but otherwise I mostly agree.
- drivingmenuts 10y ago
  FFMPEG is a case of a tool trying to do too much, although, trying to break it out into separate tools would probably be worse.
  - bobbyi_settv 10y ago
    Ffmpeg isn't a tool. It's a library to be used by programs who work with video and audio files. It has lots of features because different applications need different features. The ffmpeg command line program is basically a demo that exposes every one of those features directly. Having it "do less" would defeat the point.
- zajd 10y ago
  It's simplicity and ubiquity are the only reason we keep seeing absurd programs like Gitless put forth. Imagine if someone came out with someone that "fixed the warts of QT" that was just a wrapper around QT. It's a joke. It's coffeescript vs javascript all over again and we saw how that played out. Don't like how git works? contribute. Don't make some stupid command line utility that just adds another entire layer of abstraction on top because people don't want to take an hour to read about git internals.
  - 10y ago
patrickthebold 10y ago
Well: git commit -am "message". Will add and commit. Pushing should be separate for a distributed vc.
andydoan 10y ago
Common use cases require multiple steps because that's how it's meant to be. Staging (adding), committing, and pushing are three fundamental operations of Git that, when combined in different ways, produce many use cases. Personally, I would rather have these operations exposed to me rather than having to memorize (or worse, have to search up) a different command every time for each use case.
deleted 10y ago
[deleted]
wtetzner 10y ago
I think part of the issue here is that the actions one wants to take isn't the same for everyone. For example, I basically never want to commit and then immediately push to some server. And for add, then commit, you can just do git commit -a. But being able to add and commit changes separately can be very useful.
Pxtl 10y ago
My pet peeve is how many steps it is to resolve a merge conflict on a branch I've pushed when were using controlled merges into dev branch. Stash or commit my work on the new feature branch I've started, then switch to dev, then pull, then switch back to my old conflicty feature branch, then merge from dev and resolve the conflicts, then push, then go to the server and complete the merge, then switch back to my old stashed branch so I can get back to work.
- buerkle 10y ago
  No need to switch to dev: git co feature_branch git fetch origin dev git merge FETCH_HEAD
meddlepal 10y ago
Yea the Git CLI is a giant pile of steaming shit which is probably why there are plethora of visual tools for working with Git instead.

okket 10y ago

See also discussion about the Gitless paper: "Purposes, Concepts, Misfits, and a Redesign of Git" https://news.ycombinator.com/item?id=12612333 https://news.ycombinator.com/item?id=12612333 (1 day ago, 106 comments)

Mithaldu 10y ago
And it hits the most important point of: Gitless tries to do away with the staging area, thus completely misunderstands Git.
- weberc2 10y ago
  It seems more plausible that Gitless just disagrees with its utility, or at least finds dancing around it overly cumbersome for the default case.
- vesak 10y ago
  I've been using git professionally for a few years, and other distributed version controlling systems for more than a decade. This is the first time I see the phrase "staging area" in relation to VCS. Could you explain why it's an important concept?
  - nicky0 10y ago
    It's central to git. 'git add' puts changes in the staging area. Then 'git commit' commits the staged changes. The staging area is also known as the 'index' and the 'cache'. (Git has a consistency-of-naming problem.)
    - projektir 10y ago
      > (Git has a consistency-of-naming problem.) I wonder how many git usability issues could be solved just by addressing this and this alone.
  - Mithaldu 10y ago
    Please refer to the linked discussion. Various people ask about it and various people try to explain it (including me).

indolering 10y ago

I really wish Git came with some simplified version of dependency management, subrepo and subtree just don't cut it.

qznc 10y ago
Can you elaborate? What are you missing?
supergreg 10y ago
I've seen people recommend npm over submodules. You can give it a git repo as a package and tag/commit as the version so it's not just for JavaScript repositories and also pulls the submodule's own npm dependencies. Although I don't know if you can put it wherever you want or it will always go to the node_modules directory.

nhaehnle 10y ago

> Gitless is an experiment to see what happens if you put a simple veneer on an app that changes the underlying concepts. ... changes them how exactly? A big part of what I like about Git is that its underlying concepts are simple and clear and feel like the right building blocks for version control. So I'm curious to know how they believe they can improve on that.

JohnKacz 10y ago
It's not a quick answer but they cover this in the Gitless vs. Git section.[0] One main difference seems to be with branching "The main thing to understand is that in Gitless a branch is a completely independent line of development." [0] http://gitless.com/#vs http://gitless.com/#vs
- arielb1 10y ago
  By that, AFAICT they mean "a branch, in addition to being a commit pointer, contains all the files in the working directory".
  - __david__ 10y ago
    And also the current merge state (though I'm not sure why I'd ever want to context switch away from a merge conflict resolution).

alexduros 10y ago

The approach of this experiment is interesting. But, as an experienced git user, I think it does not include easy access to very powerful and easy-to-learn features of git like "git * -p" which bring some interactivity in git commands.

hobo_mark 10y ago
I assumed all `git` commands would still be available even if one might prefer `gl` for some tasks, am I missing something?
- MitchellCash 10y ago
  No, that's also my understanding. "Gitless is an experiment to see what happens if you put a simple veneer on an app that changes the underlying concepts. Because Gitless is implemented on top of Git (could be considered what Git pros call a "porcelain" of Git), you can always fall back on Git."
taneq 10y ago
As an experienced git user, are you not outside the target audience? From a quick read through, Gitless seems like it's designed for non-git-users who need git access.
masklinn 10y ago
The text specifically points to `commit -p`. It could also have a `checkout -p` (e.g. both mercurial and darcs have interactive reverts)

supergreg 10y ago

Auto stashing and restoring when moving branches or in the middle of a rebase seem like nice features. I'll definitely try it for that.

nbevans 10y ago

It seems inspired by Mercurial?

masklinn 10y ago
Not really. Mercurial doesn't use `checkout` in that way (it's an alias for `update` which updates the working copy to a specific changeset — or the tip of the current branch, the hg version of TFA's checkout is `revert`), prints a list of revisions with `log` and uses `add` and `remove` to track and untrack files. It doesn't match Darcs's CLI either.
- nbevans 10y ago
  I meant more from the perspective that it wraps a more friendly CLI on top of a DAG of commits. Didn't mean that it's 1:1 copying Mercurial :)
  - masklinn 10y ago
    Well then it's copying more or less any DVCS which is not git, git(1) is the least friendly DVCS CLI I know of.
    - nbevans 10y ago
      Indeed.

xixixao 10y ago

It does seem in some ways similar to Mercurial, but changes things which both Mercurial and Git share (like having to resolve tracked modified files before switching branches/bookmarks). I think if you want to make a fast and simple interface though, you should go a step further towards gui (like https://github.com/xixixao/hg-sl-up https://github.com/xixixao/hg-sl-up ) and remove the concept of branches/bookmarks altogether (I stopped using bookmarks in mercurial). The repo is just a tree of changes, I already tag it with commit messages, shouldn't need to tag it again with branch/bookmark names. Would love to be able to leave the commits in WIP state though, that would be super convenient (shelving sucks).

masklinn 10y ago
That sounds a lot like Darcs's model, which is pretty fun to play with (and darcs has a really nice CLI). You may want to take a gander at it.
- botexpert 10y ago
  Or pijul. https://pijul.org/ https://pijul.org/
  - masklinn 10y ago
    While in theory I appreciate what pijul is trying to do, I'm not going to plug it until it at the very least self-hosts. Two years in, still not there.
- cm3 10y ago
  git and hg are somewhere between Subversion and Darcs/Pijul. You kinda deal with individual patches (commits) but not quite as prominently as in Darcs/Pijul. It's all a compromise, and even Subversion gained merge features, leaning more into the git/hg realm. Tracking patches has huge advantages, especially in open source work, whereas it's not really needed if you just commit to master/trunk all the time and merge with a tool and not by tracking patches. Darcs and Pijul are what would be a perfect fit for the patch queue model used by kernel maintainers.

NKCSS 10y ago

I wonder why there is no context-aware vcs; e.g. one that understanding the language and resolve diffs at a functional level. Would make change tracking and merging so much easier. Alternative would be to split each function into a separate file, for C# that would mean partials and the compiler just joins them.

bunderbunder 10y ago
Possibly because then you'd need a parser for every language someone might use. But, since you mention C#, see: https://www.semanticmerge.com https://www.semanticmerge.com
mbrock 10y ago
Git is intentionally stupid about file contents to make it simple and robust. Smalltalk has some systems like you describe. They're integrated with the compiler and Smalltalk makes that easy. Otherwise I think it's mostly that such systems are lots of work to make and maintain. Treating files as plain text has huge benefits when you consider simplicity and flexibility. The real "UNIX philosophy" is "worse is better": simpler, quicker, finished solutions are more likely to flourish (except X11).
palunon 10y ago
Git does support external diff and merge tools. I guess they don't want to support every language ever used directly inside the VCS.

rplst8 10y ago

When people say they don't like git, I lose a little faith in them as a programmer and/or engineer. This is probably due to my own biases of having worked with folks that just don't want to invest the time in learning it. That or they are afraid of branching/merging. To me this indicates intellectual laziness which isn't the kind of laziness that makes a good programmer (as is with the quote from Larry Wall and the kind of laziness he speaks of).

cmrdporcupine 10y ago
Or we've used other DVCS systems like Mercurial or Bazaar or Bitkeeper that had sane CLIs with consistent and self-explanatory user interfaces. Git is powerful. And also seems to have a powerfully elitist community around it, as evidenced from your comment.
Certhas 10y ago
I work with a whole bunch of scientists that program. Some mathematicians, some theoretical physicists. We run into git issues more often than we should. It's lazy to blame git issues on intellectual laziness. Any human designed system can be learned with enough effort but in git there seems to be significant superfluous effort. Effort that probably makes sense for some use-cases that git was developed for, but as it has become ubiquitous and now we all have to live with it, programmers or not. In my view, git has too much state. The state of my directory, the state of my branch, the staging area, the stash, etc.. these all interact in non-trivial ways when merging/branching. Gitless shows that it can be done with less state. And the design of the interface _is_ atrocious: http://stevelosh.com/blog/2013/04/git-koans/ http://stevelosh.com/blog/2013/04/git-koans/
- zajd 10y ago
  It's really not though. And posting articles that pretend like "git rev-parse --abbrev-ref HEAD" is the best way to view what branch you're working on just makes you look dumber than you do for acting like git is difficult to work with. If people writing blog posts about "how bad the git interface is" and more time instructing newer programmers (the only ones who have any reason to complain about git) on how to correctly use the tools maybe we wouldn't have to hear so much whining about the tool. Anyone who has been in the field understands that for all it's tradeoffs git is an incredible breath of fresh air from systems like CVS/SVN.

whack 10y ago

Very cool. The idea which I liked most, is the ability to switch between branches, even though you still have uncommitted changes. With git, I'm forced to either make an extraneous commit, just to enable branch switching, or stash all my changes into a stack which I may later forget all about. Both of the solutions above are really cumbersome and prevent easy context switching. The only feature I noticed missing, is the ability to stash changes. I use this most often to move changes from one branch to another branch, without cluttering history with an extraneous commit. How would this work on gitless?

m3kw9 10y ago
Just use the normal git fallback command
- gcb0 10y ago
  me nor my web search engine never heard of it
  - twic 10y ago
    Perhaps m3kw9 means that if there's something that you can't do in Gitless, you can fall back to the Git way of doing it, since both use the Git plumbing.
- deleted 10y ago
  [deleted]
iagooar 10y ago
> Both of the solutions above are really cumbersome and prevent easy context switching. Too frequent context switching might actually be perjudicial for your productivity and health, while increasing stress levels. So git not making it trivial might not be a bad thing, in my opinion.
- wreft 10y ago
  I don't think perjudicial is a word.

loup-vaillant 10y ago

Please please please support "zoom text only". First time in a while zooming caused a web site to have its text overlap with itself.

partycoder 10y ago

More accurate to call it a git client rather than a version control system. It is git. Then, many clients have tried to hide git complexity under some friendly UI. They might be productive in some cases (e.g: to manage your stage area), but for others at some moment they will end up confused and not knowing what to do.

achikin 10y ago

I don't see any improvement over git. Just another set of commands you'll need to learn from scratch. Some ideas seem not very good, like committing all changed files by default. If you find git commands too verbose - try 'tig' - the ncurses git client, it saves a lot of time and efforts being simple and straightforward at the same time.

gcb0 10y ago
wildly guessing from the clone to checkout name change, it probably started as a git for subversion users?
- moonmusick 10y ago
  Removal of the staging area seems like a move in this direction too.

pqdbr 10y ago

I highly recommend GitX-dev, which is a free, open-source GUI for Git on the Mac. https://rowanj.github.io/gitx/ https://rowanj.github.io/gitx/ The ability to stage/unstage individual lines using a graphical interface is really nice, and after some years using it I can't think me going without it anymore. Nowadays I only use the command line when I want to do interactive rebase.

gunn 10y ago
Is there a better maintained version?
dannysu 10y ago
I knew that you can already interactively stage individual lines via the command line using git add -p, which is what I use. But you mentioned unstage as well which I've never done before, so I looked it up. Looks like if you want to do that on the command line it's git reset -p

popmystack 10y ago

This seems extremely pointless. At worst, this seems like the Gitless team doesn't understand what Git is doing internally, which is a pretty dangerous state to be in when you're trying to "improve" something. Git as a whole: * Makes it really hard for you to do something you really shouldn't be doing * Forces you to stay "clean" and guides you to working well with other repository copies (i.e. the whole point of Git). * Warns you and makes suggestions when you make a mistake, from silly typos to incorrect command flags. * Makes it easy to guess how the command should be formatted or how certain structures are formatted based on convention. They decided to rename certain features that not only give you the wrong idea of what's actually going on, but will no doubt make it extremely hard to research any errors if something goes wrong. A good example of thing is gitless' "fusing" feature. It's just rebasing stuff. Why rename it? Why rename "checkout" with "switch", when this semantic is used throughout git? And then you have completely brain-damaged concepts such as this: >(i.e., a file can be untracked on some branch but tracked on another and Gitless will remember this): Honestly? There was no better way to indicate to me that you're just trying to make git fit some erroneous concepts in your head, and that you don't really understand what you're doing. This combined with the "auto-save" feature seems like a terribly, terribly bad idea and is just begging for a lazy developer who didn't take the time to understand his tools to completely shit on the repository he's working on, locally or remotely. Take the time to understand your tools. Git is incredibly simple underneath. It's not complicated.

ajkjk 10y ago
You have such a toxic and arrogant attitude about people trying to make the world a better place. It's shameful.
- popmystack 10y ago
  Uh, what? You respond to my post with some of the problems with this system in a hyperbolic, confronting manner without contributing anything. They are not "making the world a better place." Please don't post such non-sense here.
  - 10y ago

heisenbit 10y ago

Git is powerful. While the underlying architecture has beautifully simple aspects arguing that the complexity of the git tool-chain is simple is similar to arguing that TeX is simple as it is written in a simple language. Git is managing trees of file-sets in a distributed manner. It took many generations of configuration management systems to get there. Git is bottom up. Understand the inner workings and you know what you can do. But coming from a user perspective there is a gap - first one needs to wrap ones head around the tool. Git imho. is more a framework than a tool. On Stackoverflow simple questions yield different answers all yielding results but having various trade-offs. Usability is also about orthogonality and looking from a user perspective (not an implementation perspective) Git offers often quite a number of paths getting to a certain goal. Individuals, teams and tooling all trying to settle on certain workflows enabled by git effectively deciding to use only a subset. Particularly when it comes to teams agreeing on workflows becomes important. Git as a tool is here helpful in the sense that it enables almost everything. But for a team it takes more than agreeing on using Git. Other tools come with more comprehensive practices.

KKKKkkkk1 10y ago
As a tangent, I think calling git a distributed system is misleading. Git is primarily a history manager for a local directory tree that has commands to sync with remote machines. Having to type stuff like git remote add mothership ssh://foo@bar.baz git push mothership in order to sync is not what I usually associate with a distributed system. The word distributed conjures something that's more like dropbox, where things sync transparently.
- deleted 10y ago
  [deleted]
- deleted 10y ago
  [deleted]
- qznc 10y ago
  Being distributed is essential for gits design. It explains why there are strange sha1 ids instead of incremental revision numbers like with svn, for example.

mundanevoice 10y ago

How is this any different from hub (https://github.com/github/hub https://github.com/github/hub). It provide useful command like aliases. Along with ghi(https://github.com/stephencelis/ghi https://github.com/stephencelis/ghi), I can do everything like creating new repo, sending PR, looking/creating/updating/commenting on issues with my command line.

jasonkester 10y ago

I think there will be a very small subset of developers who are confused by the Command Line Interface of Git, but not confused by the Command Line Interface of this thing. Sure, there are tons of developers who find Git confusing. But the solution they're looking for is something like Git Extensions that removes the silliness of memorizing and typing a bunch of commands in to a terminal. In terms of Global Confusion Index, this only drops us from 98 to 97. A simple GUI version of this same concept would seem a much better plan.

relics443 10y ago

Seems like a couple of well named aliases would achieve 99% of what gitless does.

kazinator 10y ago

Git needs the parent pointer equivalent of NIL. Whenever I start a blank new repo nowadays, I do a git commit --allow-empty -m "NIL" See, many git operations require a parent reference! For instance if you want to interactively rebase the top commit, it's actually "git rebase -i HEAD^": rebase back to (but excluding) HEAD's parent. The equivalent "git rebase -i HEAD~1" means the same thing: that ~1 actually spans two commits: it refers to the parent, but since the parent is the excluded delimiting endpoint you can think of that 1 as being the number of commits being rewritten. If all you have is a single commit with no parent, you cannot rebase it. If you have NIL there, it takes the HEAD^ reference; no problem. Essentially, git is a list manipulation system whose use cases fail when operations span the entire list, oops. You can tell it was designed by someone who never took a Lisp or Scheme course (or forgot all of it). Imagine if (remove 3 '(1 2 3)) failed because the suffix (3) has no CDR, haha. "Sorry, you can't "rebase" your (1 2 3) to (1 2) because 3 is the "root commit"! Just scrap the whole thing and build (1 2) in its place."

twic 10y ago
FWIW, Mercurial has this - there's a notional changeset called 'null' whose hash is all zeroes, which is the parent of every changeset which does not have a real parent. As a result, you can rebase a root changset. For example: $ hg init $ echo silver >colour $ hg add colour $ hg commit --message 'First commit' $ hg checkout null 0 files updated, 0 files merged, 1 files removed, 0 files unresolved $ echo liquid >state $ hg add state $ hg commit --message 'Second commit' created new head $ hg log --template '{rev} = {node|short} child of {p1node|short}: "{desc}" @ {date|isodate}\n' 1 = 99f1472f8a69 child of 000000000000: "Second commit" @ 2016-10-02 17:29 +0100 0 = 6433a3e95c3d child of 000000000000: "First commit" @ 2016-10-02 17:29 +0100 $ hg rebase --source 0 --dest 1 rebasing 0:6433a3e95c3d "First commit" saved backup bundle to /path/to/repo/.hg/strip-backup/6433a3e95c3d-331b8224-backup.hg $ hg log --template '{rev} = {node|short} child of {p1node|short}: "{desc}" @ {date|isodate}\n' 1 = b9951882336f child of 99f1472f8a69: "First commit" @ 2016-10-02 17:29 +0100 0 = 99f1472f8a69 child of 000000000000: "Second commit" @ 2016-10-02 17:29 +0100
- kazinator 10y ago

k__ 10y ago

Git is, like many professional tools, something you simply got to learn. But like with many professinal tools, you don't need to know everything to get to work. I don't know all Photoshop or Ableton Live features, but I can improve my photos or create songs non the less. With these commands you can already start your own repo and work on it locally: git init // crate new repo git status // show which files are changed and which of them are staged git add -p // add "chunks" of changed files to the stage git commit -m "<commit_msg>" // commit everything added to the stage with a commit message git log // show a list of commits git checkout <file> // throw away all changes since the last commit (one file) git reset --hard // throw away all changes since the last commit (all files) If you want to work with a repo from somewhere else like Github etc., you need a few extra commands: git clone <repo_url> <target_dir> // clone a remote repository locally git pull // download and merge new commits in the remote repo that happened since the last clone/pull git push // uploading your own changes after a commit to the remote repo I think these 10 commands are all that is needed to get your own project into Git. Yes, the more people are working on a project, the more commands you need, like creating a new branch and getting commits from one branch to another, or amending commits because you forgot something etc. For a professional tool this isn't too much, I think. The 10 commands I mentioned will be remembered in less than a week. Most of the rest isn't needed often (maybe merge/rebase and branch depending on how you intend to use Git), but they shouldn't take too long either.

vbtemp 10y ago
> Git is, like many professional tools, something you simply got to learn. Nailed it.
- rplst8 10y ago
  Agreed. I'm seeing terms like "elitist" being thrown around below for "git apologists" when it's simply a matter of learning a tool. Not everyone needs all the power of the git CLI and the complications it brings - but when you do need it, it's there to fix the dumb things we all do sometimes. I think if you look deep in the guts of Clearcase for example you will see nastiness that makes git look like the ls command.

X86BSD 10y ago

Git just is not my thing. I prefer Fossil SCM. Now that is a sweet little SCM.

jrapdx3 10y ago
I like Fossil too, and use it for many small projects. To some extent projects can be converted to/from git, but I haven't done much at all with that and I'm sure there are limits. Nonetheless, Fossil is an option with good usability that doesn't lock users in when there are reasons to convert repositories to other tools.

dahart 10y ago

My criteria for whether an interface to git is truly easier is whether artists can use it. I've worked in games alongside artists, with everyone using Perforce. At some point we switched to Perforce for the art, and git for the programmers, with a big janky glue system in-between. Git couldn't really handle all the binary assets, and the artists couldn't really handle git, so it made sense. When we switched, it also took a long time before the programmers could really handle git too, fwiw. I've long said I'd love to see something that's as nice a GUI as p4v, but with git under the hood. I haven't yet seen a git GUI that even approaches now nice p4v is, and git on the command line, once you learn it, is the best interface to git hands down. I can't tell, but does gitless look like it could make a simpler gui to anyone else? I love the idea of gitless, I'll have to try it, but I get the sense that I'd end up needing to switch to git for some things.

rakpol 10y ago
Re. GUIs for git, have you taken a look at GitKraken [1]? I haven't had the chance to put it through its paces, but it looks pretty good. [1]: https://www.gitkraken.com/ https://www.gitkraken.com/
- novaleaf 10y ago
  I recently switched to GitKraken from SourceTree. SourceTree has better features and workflow, but SourceTree performance is very VERY terrible. I'm talking 2+ minutes to wait for some operations to complete. Not sure why GitKraken makes it so hard to add remote repositories and doesn't allow auto-push, and other niceties. But I use it for normal checkin / branch switching workflows and it's great.
- dahart 10y ago
  I have. I've used all of the git GUIs. None are as good as p4v as far as a GUI goes, and none are particularly usable by artists. Especially powerful in p4v is the timelapse view, which nothing in any git client comes close to approaching.
douche 10y ago
As far as version-controlling art, I'd lean towards a system where checking a file out locks it from any other concurrent modifications. Unfortunately, trying to merge concurrent changes into an image file, for instance, is just about impossible. It's almost as bad trying to work with MS Office file types - I wish I could get people on my team to use something else that is more VCS friendly, like HTML or Markdown, but that's an uphill battle. Even better would be if we actually used the versioning and collaboration features that are built into some of the tools like Office 365 that we pay for, but can't seem to leverage...

caseymarquis 10y ago

I think tools like github desktop make this unnecessary. I've given some people a quick introduction to git using the desktop app, and they were up and running in about 20 minutes. Sometimes something goes horribly wrong, but it's a rarity. I think the worst case scenario encountered was: "No one knows what's wrong, so we'll use a comparison tool and manually merge in the changes from this branch with a bad repo state as a commit."

xenadu02 10y ago

The git CLI has gotten a lot better over the past few years. Making simple branch push the default was a good move. There are some things that could be improved (and any of these can be config options for those who want the old behavior): * switching branches should auto-stash changes, then auto-apply when switching back (apparently one of the things gitless does) * a rebase should leave a marker in the tree (with the old hashes) so if you force-push other clients can offer more intelligent options (e.g. Looks like these commits were rebased by a_user; rebase your changes skipping duplicate commits or merge?) * git still allows you to create branch names differing only by case which is a problem on macOS and Windows * cherry-pick -x should be the default and tools should do a better job of showing the relationships * tag sync should include the commit and update on pull so rewriting tags isn't such a PITA. Maybe we need movable vs static tags.

nardi 10y ago

In this thread, lots of people wanting to demonstrate their deep knowledge of an arcane tool, thus proving the whole point.

tadfisher 10y ago
Posted this upthread, but here's an apt Linus quote: > The first Git For Dummies and Git Visual Quickstart books are going to be out in a couple of months, and that is the beginning of the end as far as I’m concerned. Those books mean the end of git expertise and github reputation as reliable indicators of geek status. Once a technology is adopted by the masses the extreme geeks find something more esoteric. Look at what happened to Ruby on Rails. The people stumbling their way through Rails to-do list tutorials have never even heard of DHH.
- laurentdc 10y ago
  That sounds like a very elitist approach. So the technology is good as long as it's arcane, but as soon as it becomes mainstream then it's "the beginning of the end"? ...do we even need a "reliable indicator of geek status"?
- okket 10y ago
  It is not a quote by Linus but part of a satirical piece, see: http://typicalprogrammer.com/linus-torvalds-goes-off-on-linux-and-git/ http://typicalprogrammer.com/linus-torvalds-goes-off-on-linu...

Xeoncross 10y ago

I see gitless has a bunch of 'gl ____ -c foobar' as well. Why is the -c (create?) needed? Isn't it apparent that if that branch doesn't exist we need to create it? If that remote doesn't exist we need to create it? Convention over configuration?

ggreer 10y ago
> Isn't it apparent that if that branch doesn't exist we need to create it? It could just be misspelled. I've accidentally created quite a few misspelled branches in my time. E.g.: "bug-fix" vs "bug_fix" vs "bugfix".
smitherfield 10y ago
Yeah but then there's the issue of simple misspellings. Perhaps switching and creating should be separate commands.
- ggreer 10y ago
  Exactly. It would be like if `cd pathname` was the equivalent of `mkdir -p pathname && cd pathname`. Even with tab completion, only a tiny minority of users want that behavior. To most, it invites mistakes.

projektir 10y ago

I don't know if this is not wholly rational, but over time, I became more and more cautious of using any tool for git that wasn't the pure git command line itself. I don't like how the command line was designed, but at least I know what's going on. With other tools (the latest culprit is Visual Studio sync), I often have a reaction of: "You did WHAT?"

admax88q 10y ago

ITT: People trying to justify all the time they spent becoming experts on git's esoteric interface.

maker1138 10y ago

I'm surprised at how many people are responding negatively to software that improves user experience. Suppose we had started out with the command UI that gitless has and someone came along and tried to sell us the current git cli UI. It would be completely ridiculed. The only thing possibly questionable about the gitless interface is that it does away with staging. However, you can always fall back to git for staging functionality if you like, and use gitless for most other commands. I think it is a win.

gnuvince 10y ago
I think the author address that point in the introduction: > Experts, who are deeply familiar with the product, have learned its many intricacies, developed complex, customized workflows, and regularly exploit its most elaborate features, are often defensive and resistant to the suggestion that the design has flaws. Having spent dozens, even hundreds, of hours learning the intricacies of the Git command-line, it must be extremely shocking and insulting when you are told that those efforts were in vain, because the original UI was not very good and an alternative can be grokked by people of varying levels of technical competence with only a fraction of the effort you put into the original thing. I think this is what we're seeing here: people will try and defend their time investment by arguing that a professional would learn the hard thing and not lower himself to easy-to-use tools, that the new UI hides some powerful features that are rarely used, etc.
- austinjp 10y ago
  Indeed. Also known as "sunk cost fallacy".
  - cies 10y ago
    > "sunk cost fallacy" I like to spot those, did not see this one though, but indeed, sunk cost fallacy it is. Well spotted :)
  - IshKebab 10y ago
    I think it's a little different from that actually. That's normally about the merits of ongoing financial investment, but I get your analogy and there should be a name for it because you see it all the time from compsci types. How about "sunk knowledge fallacy" or something like that?

gsmethells 10y ago

Command-line and git aliases will get you most of what this has to offer unless I'm missing something.

varcharlie 10y ago

Do people really consider git hard to use? It's very easy to learn... In fact, if you can't learn git I would not be confident in your ability to learn any other important technology using the internet as your resource. You don't even need to have internet access as long as you have `man`.

varcharlie 10y ago

git init - create a new repo git clone - download an existing repo from the internet git status - show changes made in repository and any pending additions that haven't been committed git diff - show changes made to file that haven't been committed git pull - pull changes from remote repository git push - push changes to remote repository git log - show log of commits git mv - move a file while preserving diff git rm - remove a file git add - add a file git checkout - checkout a branch, file, etc git reset --hard origin/master` - undo all changes, reset to last commit in master git blame - show who is responsible for what in a specific file git fetch - download objects from another repo/branch git merge - merge two branches together ... etc.

nickhuh 10y ago

In my experience, making "gl commit" equivalent to "git commit -a" seems like a bad idea. When leading a team, especially of newer coders, one of the most effective ways I've found of keeping the git logs and the code base sane more generally, is to force people to review their own code at the time when they commit it. Individually adding each file with "git add -p" achieves this, and "git commit -a" squashes it. Reading the methodology used to develop gitless yesterday was interesting, but if I recall correctly, I think it left something out. They looked at how often a software design allowed users to complete their intention, but the tool ideally not only should allow users to complete their intention, but should encourage users towards practices that increase the quality of the end product. While people may struggle with staging at first, I think it in the end encourages better software, which is my biggest concern.

GutenYe 10y ago

I like, just that python is slow.

denfromufa 10y ago

Has anyone compared this to legit? https://github.com/kennethreitz/legit https://github.com/kennethreitz/legit Both seem to simplify the git workflow.

XorNot 10y ago

gitless looks pretty nice, and I'll be installing and using it on my work PC tomorrow to see how I get along the rest of the week with it. I'm curious to see how the experiment goes.

anarcat 10y ago

I am also pleasently surprised by this initiative. I consider myself an advanced git user so I am not sure I would use it myself, because my brain is hardwired to git's wicked commandline interface now. There is little that surprises me in git nowadays. I am used to give out simple "the 10 git commands you will ever need" tutorials to people, but it's true that it is confusing for people, even with that. gitless takes out significant confusion out of the daily grind of using git, so much that I may end up recommending it instead of git itself, especialy since they are interoperable. What I would love to see would be to have those commands percolate back into git itself. git's usability has improved significantly since it started, and while this project shows there's still a lot that can be improved, history has shown us that git can be improved. track, untrack, history, switch, resolve, publish, init's remote argument, all those could be added as commands into git and equivalent commands could be deprecated or just kept for the hardcores like me that don't want to be bothered learning a new simpler interface. Unfortunately, given the reaction on the mailing list, I am thinking this will not/never happen and gitless will remain a friendly fork: http://marc.info/?l=git&m=147527432403442&w=2 http://marc.info/?l=git&m=147527432403442&w=2

GirlsCanCode 10y ago

I don't know if this is a good idea. People say "programming's too hard" so we got Ruby and set the world back 10 years.

petre 10y ago

Why would I use this over Mercurial, other than being able to collaborate with others using git? You still need a Python interpreter to use it.