17 ms·

Gitless: A simple VCS built on top of Git

230 points by hosteur 3y ago

mtizim 3y ago
The gitless vs git section is lacking. I can see the diffrences, but you're not making any claims that it's better. I don't really know why I should use gitless from this page.
- chiefalchemist 3y ago
  This happen a lot (read: too often). That is, speaking to features instead of calling out benefits.
- wussboy 3y ago
  That’s not the impression I had. It was immediately clear that switching branches in Gitless did what Git always should have done and that was enough for me Unfortunately it doesn’t work on Windows.
graypegg 3y ago
Always thought there was a good use case for something like this, but as some embeddable library. If you have some software project that shouldn’t require a technical understanding of version control from your users, but should be able to handle version naming and collaboration, you might want something that abstracts away some of the messier parts of the git workflow and touches the file system less. (no merge headers injected in files for example) Bonus points if it just works over git so users could host it wherever.
wejick 3y ago
> Simple commit workflow The first point explanation is not so simple Though I will love the independent branches, not have to stash everytime moving between branch.
- lozenge 3y ago
  Start using worktrees, eg I have one for development, one for reviewing other people's code, and one for looking at another commit (usually main, using checkout --detach ). You could easily have more.
  - recursive 3y ago
    I tried this for a while but find it easier just to maintain multiple working folders.
2h 3y ago
no updates in two years: https://github.com/gitless-vcs/gitless https://github.com/gitless-vcs/gitless and no Windows support. no thank you.
- ayhanfuat 3y ago
  Yes, looks like mostly abandoned https://github.com/gitless-vcs/gitless/issues/248 https://github.com/gitless-vcs/gitless/issues/248
- kseistrup 3y ago
  https://github.com/goldstar611/gitless https://github.com/goldstar611/gitless claims to be a “maintained fork of the simple git interface”. Latest commit was in November 2022, though.
habosa 3y ago
Wow this is a timely post. Literally two days ago I thought "there should be an easier way to use git" and I went out and bought gitless.io ... I didn't even check what was on the .com! To the author: I think I'll need a new name for my tool (I was imagining something fairly different and UI based) so if you want the .io just let me know.
- avgcorrection 3y ago
  There’s also git-branchless so watch out for that “less” as well.
  - ChadNauseam 3y ago
    git branchless is awesome, I use it every day at work to quickly move commits around or rebase on top of master
IshKebab 3y ago
There's also Jujitsu that looks a bit more interesting IMO: https://github.com/martinvonz/jj https://github.com/martinvonz/jj Or Pijul if you want to give up on Git compatibility.
- ziml77 3y ago
  This seems to be the one to try. Gitless appears to be abandoned. And I like this idea of having an alternate model of interaction with git. It seems to fit well within the git design of having common plumbing and being able to swap out the porcelain.
  - leonim 3y ago
    Yes, agreed. This looks like it is being actively developed. It has some interesting ideas. I like the fact that conflicts are committed, and can be resolved later: """If an operation results in conflicts, information about those conflicts will be recorded in the commit(s). The operation will succeed. You can then resolve the conflicts later. One consequence of this design is that there's no need to continue interrupted operations."""
cupofjoakim 3y ago
I support this fully. Juniors and intermediate engineers I work with still struggle with git quite often and I personally know how that feels firsthand. Not sure if this solves the issue. I personally recommend using git, but keeping it simple by limiting the allowed operations. - git switch - git checkout - git add - git commit - git pull - git push - git rebase - git reset Note the absence of merge and and cherry pick. Most often when a junior has messed something up it seems to be because of merging in a weird order or cherry picking the wrong thing before merging or rebasing. Either my juniors have stopped asking me for advice (totally possible) or this recommendation helps. As I find myself very seldom needing those commands I hope and believe it's the latter :)
- kingdomforgit 3y ago
  I agree mostly but recommend avoiding rebase at all costs at all times always and always prefer merge. Rebase is pure evil plain and simple.
  - computerfriend 3y ago
    I rebase constantly and I love it. To each their own, I guess.
    - tylerscott 3y ago
      I do as well and I also cherry pick a lot specifically with —no-commit to pull together disparate ideas from various sources. I am always fascinated when git usage comes up in threads because there are so many ways people use it that differ from my own and we all seem to find value in it!
  - okeuro49 3y ago
    I use rebase to roll up all my commits before submitting a PR. Don't see what the big deal is.
    - quesera 3y ago
gregmac 3y ago
Is this more than a different client interface to git? "fuse" looks like rebase. "switch" with automatic stash is handy (is there more to it?). It's a feature that several popular GUI clients have had for years.
lozenge 3y ago
This is cool because Git is almost too popular, there are too many poorly written tutorials, and I have seen so many people get in trouble and Stack Overflow just gives them more commands that get them into an even stickier situation. Yeah, if you learn all its ins and outs then you will understand it, but that shouldn't be needed for a tool which is now so widely used. Git has improved a lot like erroring out if you try certain operations with unsaved changes, but even this has issues e.g. if you have a file which is untracked in one branch and committed or gitignored in another.
sesuximo 3y ago
Is git really so bad if you spend ~1 hour trying to understand it and have access to stack overflow?
- fulafel 3y ago
  Yes.
- visarga 3y ago
  Today we can also ask GPT-4 for targeted advice
dewey 3y ago
I always feel like the main issue with tools like that is that you'll then just have to learn a separate syntax that's not portable and will be even harder to find instructions for.
- iudqnolq 3y ago
  That's why I like that lazygit has a pane showing you the underlying git commands as it runs them.
  - namtab00 3y ago
    same with GitExtensions... never used the git CLI, never had to, but if I did, with GitExtensions all git commands are visibile and logged
- doublepg23 3y ago
  This is why I personally use ed(1), the standard text editor. I never have to worry about portability.
memefrog 3y ago
Git is easy to use if you just read the manual.
adontz 3y ago
I'm teaching Git in University. For all those who think that Git is easy, it's not. It takes a student about 20-30 hours to really understand all usual Git commands. I'm not talking about something bizarre like ls-remote, but really understand merge, rebase, bisect. Not just syntax, but all the consequences. For instance, why rebasing something already pushed to public often leads to false merge conflicts, how does stash really work, etc.
- deleted 3y ago
  [deleted]
- quadrifoliate 3y ago
  I don't think Git is easy at all. But 20 hours seems a worthwhile investment to me for something they will likely use for at least the next decade of any serious work with software? I'm assuming that this doesn't mean literally 20 hours of instruction.
  - Certhas 3y ago
    There are a lot of people who could benefit from git (or who are forced to interact with it sporadically) for whom this is a real problem. The problem is also, if you don't use it daily git knowledge decays fast. There is a piece of advise that was making the rounds (unironically) at the research institute where I worked before: "Before you do anything with git, first make a local backup copy."
    - bombcar 3y ago
      That’s the idea behind https://xkcd.com/1597/ https://xkcd.com/1597/ and it’s more true than people will admit.
      - jeltz 3y ago
        Can't agree. While learning git isn't trivial it is still easier than it was learning Subversion and at all places I have worked at a decent share of the devs understood git. If a dev cannot grasp git I would not trust them with any non-trivial code base.
g4zj 3y ago
Does this somehow eliminate the need to learn the basics of git? If so, is learning the basics of this abstraction easier enough to justify _not_ learning git — an immensely widely-adopted tool? If not, how is this preferable to a series command line aliases that the user in question finds more convenient and/or intuitive?
- hedora 3y ago
  I don’t think so. This is just cleaning up the cli commands. Their branch fuse is the same thing as a rebase. Once you understand merge vs rebase, you understand how git is implemented under the hood, and the rest is dealing with wonky cli syntax.
animal_spirits 3y ago
I'll continue to plug Lazygit https://github.com/jesseduffield/lazygit https://github.com/jesseduffield/lazygit - I wasn't able to grok git until I started using this tool
deleted 3y ago
[deleted]
wseqyrku 3y ago
Unfortunately, copilot for cli will make git easy.
Certhas 3y ago
I would have loved for gitless to become a mainstream way of using git. Unfortunately it did not... Maybe one could implement the gitless workflow in VSCode to help it take off? I still think their basic analysis and the reduction in state that the resulting system has is spot on (and I believe it is also aligned well with what works in Mercurial/Sappling).
aeturnum 3y ago
I think tools like these are fantastic and I do not think that git "is easy" or anything like that. Lots of people do not need to understand the details of the git model and should not have to use git directly. That said - if you are a senior on a project using git flow or something like it - you should treat understanding git as a concern of the first order. The commands are somewhat obtuse, but the tool is a pretty reasonable attempt to grapple with the underlying challenges of managing disparate work from different people going at different speeds. It is challenging to understand because it is fundamentally quite difficult. Don't under-rate the importance of this to your overall process! Learning git will help you understand the challenges of distributed development (and visa-versa) - they are real and not simply an artifact of bad UX.
- deleted 3y ago
  [deleted]
deleted 3y ago
[deleted]
deleted 3y ago
[deleted]
Aerbil313 3y ago
I don’t know git besides pull and push (never needed it, not an employed SWE). Should I learn it or should I learn shinier and supposedly easier alternatives like jujutsu? I only code for myself.
- the_white_oak 3y ago
  No, most of the git troubles come out wheen collaborating.
softwaredoug 3y ago
90% of my git problems I’ve solved with two aliases: “git publish” and “git synced” Publish pushes to the remote (doing the right thing to safety update it, force push with lease). Synced updates the local branch with the trunkiest-trunk (upstream preferred over origin, using whichever one of main or master exists). It rebases against that remote branch. https://github.com/softwaredoug/idiot-proof-git https://github.com/softwaredoug/idiot-proof-git (With handy shortcuts to create a PR and go to the repos URL)
- jmholla 3y ago
  I believe your synced alias can also largely be solved by adding this to your `.gitconfig`: [pull] rebase = true
mihaic 3y ago
Every single time I see one of these attempts at simplifying Git, I'm reminded of how bad source control is when forced to use in a terminal. Entering commands in a terminal means you always have have a mental view of the state you're operating in, and having better affordances that are equally as powerful would have made a world of a difference to beginners. No wonder Git is like C++, where many argue a subset of it would be best to use, but nobody agrees on the exact subset.
- thunderbong 3y ago
  Have you tried fossil? https://fossil-scm.org/ https://fossil-scm.org/
lopkeny12ko 3y ago
This entire project seems to be a workaround for the fact that junior developers are not willing to learn Git.
- jedberg 3y ago
  It does admittedly have some nice syntactic sugar for things that are annoying in git but come up often, like the easy include/exclude of files and being able to switch branches without having to stash or resolve merge conflicts.
- SkyPuncher 3y ago
  Git is not particularly hard to learn. Learning how to handle common edges cases is incredibly frustrating and challenging. It's rarely obvious what's wrong and how you're expected to fix a problem. Even worse, the stakes feel incredibly high. If you do something wrong, you risk loosing your work. Or, even worse, messing up someone else's work.
gigatexal 3y ago
I'm the git guy on the team and even I get a bit nervous when having to resolve conflicts or figure stuff out in out branching strategy. 95% of the time I am fine and so is the team but it's when things involve many teams and many commits on the same subset of files that things get hairy. I will say this: I find git much better than Microsoft's Team Foundation Server (I know it can be setup to use git now) but I like git overall a lot more. Does anyone think any of the competitors to Git will take off? I hesitate to move to something else because inertia is a thing: all my stuff is on github, the team and all my colleagues at work know it, guides exist for it online, but then again ... if I could master a better tool I could teach everyone... hmm.
lcall 3y ago
Another git-compatible, simpler VCS is "got" (about which I don't know enough to compare well). It's targeted to OpenBSD devs but ported to various *nix platforms. https://gameoftrees.org/ https://gameoftrees.org/
timetraveller26 3y ago
I don't like this, if you are too lazy to learn git how can you expect to become a competent developer? /s
woudsma 3y ago
I used to be opposed to git GUI’s, but after a few years and working in larger codebases, I love the way they visualize everything. Especially when dealing with hundreds of branches. Sure I’ll use the git CLI from time to time but GitKraken works really well for me. I feel pretty safe seeing my stashes in front of me, etc.
- kelahcim 3y ago
  I tried GitKraken once. Then, I switched to Sublime Merge and stopped worrying about all these fancy branches in my projects :)
taink 3y ago
I haven't used Gitless before but usually these types of abstractions fall short for me. It never helped me as much as truly learning git. I learned so much about the commands that intimidated me by playing "Oh My Git!"[1]. It's an open source game that presents commands as quick-to-understand concepts and lets you experiment with them by using playing cards on the visual rendition of a repository. I was honestly surprised nobody else mentioned it here, maybe it's not that well known. Of course it's not completely accurate all the time in its descriptions but it sure helps understanding the underlying workings a bit more, and it pushed me into actually reading the manual. [1] https://ohmygit.org/ https://ohmygit.org/
- perdomon 3y ago
  This sounds like a great tool, but I'm not sure anything could push me to read the Git documentation. It's written by someone too brilliant for me. I prefer to find a Stack Overflow answer where someone has dumbed it down a bit.
  - dreamcompiler 3y ago
    The Git docs are horrible, but that's not because the author is smarter than you. It's because the author is a lousy communicator.
    - Aeolun 3y ago
      I mean, I’m a lousy communicator, I can’t exactly blame them. But I still don’t want to read their documentation.
- Antipode 3y ago
  I'm curious as to why the windows version is 8x the file size of the mac/ linux ones
  - Hamuko 3y ago
    Maybe it contains a segment about installing git on Windows.
Jacky4Chan 3y ago
BIG PROBLEM with git is that it works in terms of editor lines and not in language constructs. It should instead track changes in terms of language constructs. For example, tracking the history of a class individually, an interface, etc... changes could be logged automatically. For this to work it would, of course, require to be adapted for each language. Furthermore, it could work in architecture terms, such as an MVC files that could be tracked as an individual unit. The architecture for a file system could be defined and enforced in a git file, it could spot missing pieces. Also, it needs dependency management for these units.
- G3rn0ti 3y ago
  > It should instead track changes in terms of language constructs. This does not generalize very well. On top of GIT‘s core data structures and file management facilities you would also need parser plugins for all languages now and additional commands to manage language constructs. This would make it even more difficult to grasp. I would say version control of text files in general is not an easy problem. GIT‘s complexity arises from the complexity of the problem it solves. Perhaps the user interfaces of subversion or mercurial are easier but I don’t think they lift the burden of understanding version control and why it is necessary from beginners …
- lolinder 3y ago
  I can see two ways to implement something like this: 1. Completely alter the paradigm for editing software: from editing text to editing the AST (or a projection of it). See Unison [0]. This gives you fine-grained understanding of every aspect of the development flow, but requires rewriting most of the tooling that developers are already using. 2. Layer the smart features on top of the existing text streams. This gives you less control and is more resource intensive, but you don't throw away the entire developer ecosystem. If we choose #1, we waste millions of man-hours building these tools for every new language. If we choose to layer our language-specific features on top of text, then why does this need to happen at the Git level instead of at a higher level of abstraction? IntelliJ, for example, can already use the git history to tell you who wrote a given method and when. This kind of functionality could, in principle, be extended to following the history of a method when it's moved or renamed. Is there any benefit gained by having the VCS itself do the language-aware processing instead of having language-aware tooling layered on top of the VCS? [0] https://www.unison-lang.org/ https://www.unison-lang.org/
dang 3y ago
Related: Gitless: A simple version control system built on top of Git - https://news.ycombinator.com/item?id=18512854 https://news.ycombinator.com/item?id=18512854 - Nov 2018 (138 comments) Gitless: a version control system - https://news.ycombinator.com/item?id=12621837 https://news.ycombinator.com/item?id=12621837 - Oct 2016 (372 comments) Gitless – An experimental version control system built on top of Git - https://news.ycombinator.com/item?id=9144160 https://news.ycombinator.com/item?id=9144160 - March 2015 (47 comments) Gitless: experimental version control system - https://news.ycombinator.com/item?id=9019892 https://news.ycombinator.com/item?id=9019892 - Feb 2015 (48 comments) Gitless: an experimental version control system built on top of Git - https://news.ycombinator.com/item?id=6927485 https://news.ycombinator.com/item?id=6927485 - Dec 2013 (46 comments)
tomas789 3y ago
For quite some time now I believe there should be a better alternative to git. I have never thought of building it on top of git. Neat. What I think should be there is a daemon doing autocommity and automatic sync with server. Even if you work from multiple machines.
locusofself 3y ago
After this many years (and previously using cvs, svn etc) .. I really don't want to switch again.. git is great IMO. There is no way that learning to use git is more difficult than say, calculus or basic algorithms.
- Kinrany 3y ago
  Calculus is older and better designed than git, so I don't find it surprising!
- spencerchubb 3y ago
  Most CS professors at my school do not know how to use git. The department insists that professors use git in the classroom, which is probably a good idea given the ubiquity of git. My professors are forced to try and teach it to students without really understanding it themselves, so it's a struggle for everyone. Perhaps my professors don't know git because they got their PhD before git was invented (2005), and they never needed to learn it.
julien040 3y ago
Shameless plug: I've tried to build an alternative CLI for Git [1]. I think it's just too hard to create a new abstraction. Git seems too widespread and many people won't switch if they already have muscle memory of the commands. Perhaps we haven't found the correct abstraction yet. [1] https://github.com/julien040/gut https://github.com/julien040/gut
harha_ 3y ago
There is nothing wrong with Git.
- totallywrong 3y ago
  There's plenty wrong with git from a usability standpoint. We've all grokked it over time but it's far from having a good UX.
  - harha_ 3y ago
    I've used git for the last 7 years and I've had no problems with it. If a developer is not willing to invest their time into learning simple basic git commands and concepts then I think they're in the wrong business.
    - ptx 3y ago
      Have you tried Mercurial? The Git user interface is a mess in comparison, since it evolved from a collection of loosely related scripts rather than being cohesively designed. Git does the same things and works fine once you learn it, but there's a lot of unnecessary inconsistencies to learn.
      - devnullbrain 3y ago
        I've moved from Git to Mercurial and I hate it. It's just baby duck syndrome.
    - waboremo 3y ago
      I'm sorry but someone who is unable to determine problems with a tool they've used for 7 years is a huge red flag. That sort of blindness to frustrations is legitimately a massive problem in this field.
      - pwdisswordfishc 3y ago
        If you find that easy, please list some specific flaws of git. None of that "it's like, confusing, man".
nathants 3y ago
ff-only is the real git superpower. a linear, immutable, series of commits in the only branch that is suffered to exist. git, the good parts. it also pairs well with a simplified remote[1]. 1. https://github.com/nathants/git-remote-aws https://github.com/nathants/git-remote-aws
nathants 3y ago
what threads like these show is not that git is hard, but that collaborative software implementation is still an experimental and challenging approach. in absence of a tyrannical dictator, it may not even be possible.
whatscooking 3y ago
Why does git need to be any more simplified? Makes no sense
jerpint 3y ago
I like the suggestion of not having to worry about stashing changes when going back and forth between branches, this is definitely a point of friction for me with git. Not sure I’d be ready to learn a whole new workflow just for that though
askvictor 3y ago
When I was teaching computing at high school a few years ago, I was constantly perplexed why there was no 'simple' VCS built into beginner IDEs/editors/online IDEs. As a starting point, nothing more than being able to save a version (number, label description), and revert to and earlier one. Looking at how a lot of students learn by trial and error, being able to be a little more verbose on what they're trying/have tried would make this trial and error so much easier, and also be more descriptive/conscious of what they're doing. Having effectively gotten rid of the save button with auto-save, why didn't we replace it with a 'tag' button?
- cdogl 3y ago
  I’m not sure how long it’s been included, but a non-technical colleague of mine noticed this week that VS Code now has built-in “history” for files in a project. Highly limited compared to a VCS, but very useful for basic change history and reversion.
  - askvictor 3y ago
    That's been there for a while, also in PyCharm/IntelliJ suite, but for the purposes of teaching and learning, I've been looking for something that's more deliberate - where you actively say what you've done/are doing. History is nice, but you end up with a lot of it, and it's kind of useless to go back through to find that one specific edit that worked better than the others but now everything's broken.
sedatk 3y ago
"gl track - start tracking changes to files" That tracking concept is worse than Git's staging area. It expects you to know what to track before making your changes which is almost never the case. Maybe you can track after the fact; then, it just becomes an alias for `git add`. Why confuse people with this? How is this simpler? "You can stop tracking changes to a tracked file with the gl untrack command" Does that mean if I stop tracking, the rest of my changes will be ignored, or that file will be excluded from the upcoming commit? What happens if I track a file for a brief period of time, but edit it before and after tracking? What would I be committing then? Am I expected to understand how this works in order to keep a decent commit history? "You can always revert a file back to some previous version with the gl checkout command." So, use a command that's entirely different ("checkout") than the intention ("reverting"). Sounds like Git to me. How is this better? Git CLI is bad, yes, this seems to be no improvement whatsoever.
lionkor 3y ago
Maybe im daft but where is rebase?! In general this seems like it was done by somebody with not more than a very basic understanding of git...? This looks like you will get a lot of "Merge main into main". Learn git properly. It took me a few weeks in my first job, and it was done. I dont understand how people can sit here and lean a million intricate rules of css, rust lifetimes, or whatever else, and refuse to use a tool that works very, very well once learned. Its not easy, its not fun, but its IMO the smart way to do it. You dont unlearn git, you learn it once, and you use it.
lionkor 3y ago
Anyone reading this, I recommend learning two things if you use git: Learn to use `git rebase` and learn to use `git commit -p`.

230 points by hosteur 3y ago

The gitless vs git section is lacking. I can see the diffrences, but you're not making any claims that it's better. I don't really know why I should use gitless from this page.

chiefalchemist 3y ago
This happen a lot (read: too often). That is, speaking to features instead of calling out benefits.
wussboy 3y ago
That’s not the impression I had. It was immediately clear that switching branches in Gitless did what Git always should have done and that was enough for me Unfortunately it doesn’t work on Windows.

graypegg 3y ago

Always thought there was a good use case for something like this, but as some embeddable library. If you have some software project that shouldn’t require a technical understanding of version control from your users, but should be able to handle version naming and collaboration, you might want something that abstracts away some of the messier parts of the git workflow and touches the file system less. (no merge headers injected in files for example) Bonus points if it just works over git so users could host it wherever.

wejick 3y ago

> Simple commit workflow The first point explanation is not so simple Though I will love the independent branches, not have to stash everytime moving between branch.

lozenge 3y ago
Start using worktrees, eg I have one for development, one for reviewing other people's code, and one for looking at another commit (usually main, using checkout --detach ). You could easily have more.
- recursive 3y ago
  I tried this for a while but find it easier just to maintain multiple working folders.

2h 3y ago

no updates in two years: https://github.com/gitless-vcs/gitless https://github.com/gitless-vcs/gitless and no Windows support. no thank you.

ayhanfuat 3y ago
Yes, looks like mostly abandoned https://github.com/gitless-vcs/gitless/issues/248 https://github.com/gitless-vcs/gitless/issues/248
kseistrup 3y ago
https://github.com/goldstar611/gitless https://github.com/goldstar611/gitless claims to be a “maintained fork of the simple git interface”. Latest commit was in November 2022, though.

habosa 3y ago

Wow this is a timely post. Literally two days ago I thought "there should be an easier way to use git" and I went out and bought gitless.io ... I didn't even check what was on the .com! To the author: I think I'll need a new name for my tool (I was imagining something fairly different and UI based) so if you want the .io just let me know.

avgcorrection 3y ago
There’s also git-branchless so watch out for that “less” as well.
- ChadNauseam 3y ago
  git branchless is awesome, I use it every day at work to quickly move commits around or rebase on top of master

IshKebab 3y ago

There's also Jujitsu that looks a bit more interesting IMO: https://github.com/martinvonz/jj https://github.com/martinvonz/jj Or Pijul if you want to give up on Git compatibility.

ziml77 3y ago
This seems to be the one to try. Gitless appears to be abandoned. And I like this idea of having an alternate model of interaction with git. It seems to fit well within the git design of having common plumbing and being able to swap out the porcelain.
- leonim 3y ago
  Yes, agreed. This looks like it is being actively developed. It has some interesting ideas. I like the fact that conflicts are committed, and can be resolved later: """If an operation results in conflicts, information about those conflicts will be recorded in the commit(s). The operation will succeed. You can then resolve the conflicts later. One consequence of this design is that there's no need to continue interrupted operations."""

cupofjoakim 3y ago

I support this fully. Juniors and intermediate engineers I work with still struggle with git quite often and I personally know how that feels firsthand. Not sure if this solves the issue. I personally recommend using git, but keeping it simple by limiting the allowed operations. - git switch - git checkout - git add - git commit - git pull - git push - git rebase - git reset Note the absence of merge and and cherry pick. Most often when a junior has messed something up it seems to be because of merging in a weird order or cherry picking the wrong thing before merging or rebasing. Either my juniors have stopped asking me for advice (totally possible) or this recommendation helps. As I find myself very seldom needing those commands I hope and believe it's the latter :)

kingdomforgit 3y ago
I agree mostly but recommend avoiding rebase at all costs at all times always and always prefer merge. Rebase is pure evil plain and simple.
- computerfriend 3y ago
  I rebase constantly and I love it. To each their own, I guess.
  - tylerscott 3y ago
    I do as well and I also cherry pick a lot specifically with —no-commit to pull together disparate ideas from various sources. I am always fascinated when git usage comes up in threads because there are so many ways people use it that differ from my own and we all seem to find value in it!
- okeuro49 3y ago
  I use rebase to roll up all my commits before submitting a PR. Don't see what the big deal is.
  - quesera 3y ago

gregmac 3y ago

Is this more than a different client interface to git? "fuse" looks like rebase. "switch" with automatic stash is handy (is there more to it?). It's a feature that several popular GUI clients have had for years.

lozenge 3y ago

This is cool because Git is almost too popular, there are too many poorly written tutorials, and I have seen so many people get in trouble and Stack Overflow just gives them more commands that get them into an even stickier situation. Yeah, if you learn all its ins and outs then you will understand it, but that shouldn't be needed for a tool which is now so widely used. Git has improved a lot like erroring out if you try certain operations with unsaved changes, but even this has issues e.g. if you have a file which is untracked in one branch and committed or gitignored in another.

sesuximo 3y ago

Is git really so bad if you spend ~1 hour trying to understand it and have access to stack overflow?

fulafel 3y ago
Yes.
visarga 3y ago
Today we can also ask GPT-4 for targeted advice

dewey 3y ago

I always feel like the main issue with tools like that is that you'll then just have to learn a separate syntax that's not portable and will be even harder to find instructions for.

iudqnolq 3y ago
That's why I like that lazygit has a pane showing you the underlying git commands as it runs them.
- namtab00 3y ago
  same with GitExtensions... never used the git CLI, never had to, but if I did, with GitExtensions all git commands are visibile and logged
doublepg23 3y ago
This is why I personally use ed(1), the standard text editor. I never have to worry about portability.

memefrog 3y ago

Git is easy to use if you just read the manual.

adontz 3y ago

I'm teaching Git in University. For all those who think that Git is easy, it's not. It takes a student about 20-30 hours to really understand all usual Git commands. I'm not talking about something bizarre like ls-remote, but really understand merge, rebase, bisect. Not just syntax, but all the consequences. For instance, why rebasing something already pushed to public often leads to false merge conflicts, how does stash really work, etc.

deleted 3y ago
[deleted]
quadrifoliate 3y ago
I don't think Git is easy at all. But 20 hours seems a worthwhile investment to me for something they will likely use for at least the next decade of any serious work with software? I'm assuming that this doesn't mean literally 20 hours of instruction.
- Certhas 3y ago
  There are a lot of people who could benefit from git (or who are forced to interact with it sporadically) for whom this is a real problem. The problem is also, if you don't use it daily git knowledge decays fast. There is a piece of advise that was making the rounds (unironically) at the research institute where I worked before: "Before you do anything with git, first make a local backup copy."
  - bombcar 3y ago
    That’s the idea behind https://xkcd.com/1597/ https://xkcd.com/1597/ and it’s more true than people will admit.
    - jeltz 3y ago
      Can't agree. While learning git isn't trivial it is still easier than it was learning Subversion and at all places I have worked at a decent share of the devs understood git. If a dev cannot grasp git I would not trust them with any non-trivial code base.

g4zj 3y ago

Does this somehow eliminate the need to learn the basics of git? If so, is learning the basics of this abstraction easier enough to justify _not_ learning git — an immensely widely-adopted tool? If not, how is this preferable to a series command line aliases that the user in question finds more convenient and/or intuitive?

hedora 3y ago
I don’t think so. This is just cleaning up the cli commands. Their branch fuse is the same thing as a rebase. Once you understand merge vs rebase, you understand how git is implemented under the hood, and the rest is dealing with wonky cli syntax.

animal_spirits 3y ago

I'll continue to plug Lazygit https://github.com/jesseduffield/lazygit https://github.com/jesseduffield/lazygit - I wasn't able to grok git until I started using this tool

deleted 3y ago

[deleted]

wseqyrku 3y ago

Unfortunately, copilot for cli will make git easy.

Certhas 3y ago

I would have loved for gitless to become a mainstream way of using git. Unfortunately it did not... Maybe one could implement the gitless workflow in VSCode to help it take off? I still think their basic analysis and the reduction in state that the resulting system has is spot on (and I believe it is also aligned well with what works in Mercurial/Sappling).

aeturnum 3y ago

I think tools like these are fantastic and I do not think that git "is easy" or anything like that. Lots of people do not need to understand the details of the git model and should not have to use git directly. That said - if you are a senior on a project using git flow or something like it - you should treat understanding git as a concern of the first order. The commands are somewhat obtuse, but the tool is a pretty reasonable attempt to grapple with the underlying challenges of managing disparate work from different people going at different speeds. It is challenging to understand because it is fundamentally quite difficult. Don't under-rate the importance of this to your overall process! Learning git will help you understand the challenges of distributed development (and visa-versa) - they are real and not simply an artifact of bad UX.

deleted 3y ago
[deleted]

deleted 3y ago

[deleted]

deleted 3y ago

[deleted]

Aerbil313 3y ago

I don’t know git besides pull and push (never needed it, not an employed SWE). Should I learn it or should I learn shinier and supposedly easier alternatives like jujutsu? I only code for myself.

the_white_oak 3y ago
No, most of the git troubles come out wheen collaborating.

softwaredoug 3y ago

90% of my git problems I’ve solved with two aliases: “git publish” and “git synced” Publish pushes to the remote (doing the right thing to safety update it, force push with lease). Synced updates the local branch with the trunkiest-trunk (upstream preferred over origin, using whichever one of main or master exists). It rebases against that remote branch. https://github.com/softwaredoug/idiot-proof-git https://github.com/softwaredoug/idiot-proof-git (With handy shortcuts to create a PR and go to the repos URL)

jmholla 3y ago
I believe your synced alias can also largely be solved by adding this to your `.gitconfig`: [pull] rebase = true

mihaic 3y ago

Every single time I see one of these attempts at simplifying Git, I'm reminded of how bad source control is when forced to use in a terminal. Entering commands in a terminal means you always have have a mental view of the state you're operating in, and having better affordances that are equally as powerful would have made a world of a difference to beginners. No wonder Git is like C++, where many argue a subset of it would be best to use, but nobody agrees on the exact subset.

thunderbong 3y ago
Have you tried fossil? https://fossil-scm.org/ https://fossil-scm.org/

lopkeny12ko 3y ago

This entire project seems to be a workaround for the fact that junior developers are not willing to learn Git.

jedberg 3y ago
It does admittedly have some nice syntactic sugar for things that are annoying in git but come up often, like the easy include/exclude of files and being able to switch branches without having to stash or resolve merge conflicts.
SkyPuncher 3y ago
Git is not particularly hard to learn. Learning how to handle common edges cases is incredibly frustrating and challenging. It's rarely obvious what's wrong and how you're expected to fix a problem. Even worse, the stakes feel incredibly high. If you do something wrong, you risk loosing your work. Or, even worse, messing up someone else's work.

gigatexal 3y ago

I'm the git guy on the team and even I get a bit nervous when having to resolve conflicts or figure stuff out in out branching strategy. 95% of the time I am fine and so is the team but it's when things involve many teams and many commits on the same subset of files that things get hairy. I will say this: I find git much better than Microsoft's Team Foundation Server (I know it can be setup to use git now) but I like git overall a lot more. Does anyone think any of the competitors to Git will take off? I hesitate to move to something else because inertia is a thing: all my stuff is on github, the team and all my colleagues at work know it, guides exist for it online, but then again ... if I could master a better tool I could teach everyone... hmm.

lcall 3y ago

Another git-compatible, simpler VCS is "got" (about which I don't know enough to compare well). It's targeted to OpenBSD devs but ported to various *nix platforms. https://gameoftrees.org/ https://gameoftrees.org/

timetraveller26 3y ago

I don't like this, if you are too lazy to learn git how can you expect to become a competent developer? /s

woudsma 3y ago

I used to be opposed to git GUI’s, but after a few years and working in larger codebases, I love the way they visualize everything. Especially when dealing with hundreds of branches. Sure I’ll use the git CLI from time to time but GitKraken works really well for me. I feel pretty safe seeing my stashes in front of me, etc.

kelahcim 3y ago
I tried GitKraken once. Then, I switched to Sublime Merge and stopped worrying about all these fancy branches in my projects :)

taink 3y ago

I haven't used Gitless before but usually these types of abstractions fall short for me. It never helped me as much as truly learning git. I learned so much about the commands that intimidated me by playing "Oh My Git!"[1]. It's an open source game that presents commands as quick-to-understand concepts and lets you experiment with them by using playing cards on the visual rendition of a repository. I was honestly surprised nobody else mentioned it here, maybe it's not that well known. Of course it's not completely accurate all the time in its descriptions but it sure helps understanding the underlying workings a bit more, and it pushed me into actually reading the manual. [1] https://ohmygit.org/ https://ohmygit.org/

perdomon 3y ago
This sounds like a great tool, but I'm not sure anything could push me to read the Git documentation. It's written by someone too brilliant for me. I prefer to find a Stack Overflow answer where someone has dumbed it down a bit.
- dreamcompiler 3y ago
  The Git docs are horrible, but that's not because the author is smarter than you. It's because the author is a lousy communicator.
  - Aeolun 3y ago
    I mean, I’m a lousy communicator, I can’t exactly blame them. But I still don’t want to read their documentation.
Antipode 3y ago
I'm curious as to why the windows version is 8x the file size of the mac/ linux ones
- Hamuko 3y ago
  Maybe it contains a segment about installing git on Windows.

Jacky4Chan 3y ago

BIG PROBLEM with git is that it works in terms of editor lines and not in language constructs. It should instead track changes in terms of language constructs. For example, tracking the history of a class individually, an interface, etc... changes could be logged automatically. For this to work it would, of course, require to be adapted for each language. Furthermore, it could work in architecture terms, such as an MVC files that could be tracked as an individual unit. The architecture for a file system could be defined and enforced in a git file, it could spot missing pieces. Also, it needs dependency management for these units.

G3rn0ti 3y ago
> It should instead track changes in terms of language constructs. This does not generalize very well. On top of GIT‘s core data structures and file management facilities you would also need parser plugins for all languages now and additional commands to manage language constructs. This would make it even more difficult to grasp. I would say version control of text files in general is not an easy problem. GIT‘s complexity arises from the complexity of the problem it solves. Perhaps the user interfaces of subversion or mercurial are easier but I don’t think they lift the burden of understanding version control and why it is necessary from beginners …
lolinder 3y ago
I can see two ways to implement something like this: 1. Completely alter the paradigm for editing software: from editing text to editing the AST (or a projection of it). See Unison [0]. This gives you fine-grained understanding of every aspect of the development flow, but requires rewriting most of the tooling that developers are already using. 2. Layer the smart features on top of the existing text streams. This gives you less control and is more resource intensive, but you don't throw away the entire developer ecosystem. If we choose #1, we waste millions of man-hours building these tools for every new language. If we choose to layer our language-specific features on top of text, then why does this need to happen at the Git level instead of at a higher level of abstraction? IntelliJ, for example, can already use the git history to tell you who wrote a given method and when. This kind of functionality could, in principle, be extended to following the history of a method when it's moved or renamed. Is there any benefit gained by having the VCS itself do the language-aware processing instead of having language-aware tooling layered on top of the VCS? [0] https://www.unison-lang.org/ https://www.unison-lang.org/

dang 3y ago

Related: Gitless: A simple version control system built on top of Git - https://news.ycombinator.com/item?id=18512854 https://news.ycombinator.com/item?id=18512854 - Nov 2018 (138 comments) Gitless: a version control system - https://news.ycombinator.com/item?id=12621837 https://news.ycombinator.com/item?id=12621837 - Oct 2016 (372 comments) Gitless – An experimental version control system built on top of Git - https://news.ycombinator.com/item?id=9144160 https://news.ycombinator.com/item?id=9144160 - March 2015 (47 comments) Gitless: experimental version control system - https://news.ycombinator.com/item?id=9019892 https://news.ycombinator.com/item?id=9019892 - Feb 2015 (48 comments) Gitless: an experimental version control system built on top of Git - https://news.ycombinator.com/item?id=6927485 https://news.ycombinator.com/item?id=6927485 - Dec 2013 (46 comments)

tomas789 3y ago

For quite some time now I believe there should be a better alternative to git. I have never thought of building it on top of git. Neat. What I think should be there is a daemon doing autocommity and automatic sync with server. Even if you work from multiple machines.

locusofself 3y ago

After this many years (and previously using cvs, svn etc) .. I really don't want to switch again.. git is great IMO. There is no way that learning to use git is more difficult than say, calculus or basic algorithms.

Kinrany 3y ago
Calculus is older and better designed than git, so I don't find it surprising!
spencerchubb 3y ago
Most CS professors at my school do not know how to use git. The department insists that professors use git in the classroom, which is probably a good idea given the ubiquity of git. My professors are forced to try and teach it to students without really understanding it themselves, so it's a struggle for everyone. Perhaps my professors don't know git because they got their PhD before git was invented (2005), and they never needed to learn it.

julien040 3y ago

Shameless plug: I've tried to build an alternative CLI for Git [1]. I think it's just too hard to create a new abstraction. Git seems too widespread and many people won't switch if they already have muscle memory of the commands. Perhaps we haven't found the correct abstraction yet. [1] https://github.com/julien040/gut https://github.com/julien040/gut

harha_ 3y ago

There is nothing wrong with Git.

totallywrong 3y ago
There's plenty wrong with git from a usability standpoint. We've all grokked it over time but it's far from having a good UX.
- harha_ 3y ago
  I've used git for the last 7 years and I've had no problems with it. If a developer is not willing to invest their time into learning simple basic git commands and concepts then I think they're in the wrong business.
  - ptx 3y ago
    Have you tried Mercurial? The Git user interface is a mess in comparison, since it evolved from a collection of loosely related scripts rather than being cohesively designed. Git does the same things and works fine once you learn it, but there's a lot of unnecessary inconsistencies to learn.
    - devnullbrain 3y ago
      I've moved from Git to Mercurial and I hate it. It's just baby duck syndrome.
  - waboremo 3y ago
    I'm sorry but someone who is unable to determine problems with a tool they've used for 7 years is a huge red flag. That sort of blindness to frustrations is legitimately a massive problem in this field.
    - pwdisswordfishc 3y ago
      If you find that easy, please list some specific flaws of git. None of that "it's like, confusing, man".

nathants 3y ago

ff-only is the real git superpower. a linear, immutable, series of commits in the only branch that is suffered to exist. git, the good parts. it also pairs well with a simplified remote[1]. 1. https://github.com/nathants/git-remote-aws https://github.com/nathants/git-remote-aws

nathants 3y ago

what threads like these show is not that git is hard, but that collaborative software implementation is still an experimental and challenging approach. in absence of a tyrannical dictator, it may not even be possible.

whatscooking 3y ago

Why does git need to be any more simplified? Makes no sense

jerpint 3y ago

I like the suggestion of not having to worry about stashing changes when going back and forth between branches, this is definitely a point of friction for me with git. Not sure I’d be ready to learn a whole new workflow just for that though

askvictor 3y ago

When I was teaching computing at high school a few years ago, I was constantly perplexed why there was no 'simple' VCS built into beginner IDEs/editors/online IDEs. As a starting point, nothing more than being able to save a version (number, label description), and revert to and earlier one. Looking at how a lot of students learn by trial and error, being able to be a little more verbose on what they're trying/have tried would make this trial and error so much easier, and also be more descriptive/conscious of what they're doing. Having effectively gotten rid of the save button with auto-save, why didn't we replace it with a 'tag' button?

cdogl 3y ago
I’m not sure how long it’s been included, but a non-technical colleague of mine noticed this week that VS Code now has built-in “history” for files in a project. Highly limited compared to a VCS, but very useful for basic change history and reversion.
- askvictor 3y ago
  That's been there for a while, also in PyCharm/IntelliJ suite, but for the purposes of teaching and learning, I've been looking for something that's more deliberate - where you actively say what you've done/are doing. History is nice, but you end up with a lot of it, and it's kind of useless to go back through to find that one specific edit that worked better than the others but now everything's broken.

sedatk 3y ago

"gl track - start tracking changes to files" That tracking concept is worse than Git's staging area. It expects you to know what to track before making your changes which is almost never the case. Maybe you can track after the fact; then, it just becomes an alias for `git add`. Why confuse people with this? How is this simpler? "You can stop tracking changes to a tracked file with the gl untrack command" Does that mean if I stop tracking, the rest of my changes will be ignored, or that file will be excluded from the upcoming commit? What happens if I track a file for a brief period of time, but edit it before and after tracking? What would I be committing then? Am I expected to understand how this works in order to keep a decent commit history? "You can always revert a file back to some previous version with the gl checkout command." So, use a command that's entirely different ("checkout") than the intention ("reverting"). Sounds like Git to me. How is this better? Git CLI is bad, yes, this seems to be no improvement whatsoever.

lionkor 3y ago

Maybe im daft but where is rebase?! In general this seems like it was done by somebody with not more than a very basic understanding of git...? This looks like you will get a lot of "Merge main into main". Learn git properly. It took me a few weeks in my first job, and it was done. I dont understand how people can sit here and lean a million intricate rules of css, rust lifetimes, or whatever else, and refuse to use a tool that works very, very well once learned. Its not easy, its not fun, but its IMO the smart way to do it. You dont unlearn git, you learn it once, and you use it.

lionkor 3y ago

Anyone reading this, I recommend learning two things if you use git: Learn to use `git rebase` and learn to use `git commit -p`.