Gitless: A simple version control system built on top of Git
gitless.com
gitless.com
I have heard people complain about the staging concept (personally I find it useful, because you can do 'git add -p' which allows you to craft intermediate commits or to-be-squashed fixup commits after you've finished some development), so it's removal in this tool is unsurprising. And it is nice to auto-stash on branch change (though personally I think that they should've made stashing a much better-supported concept in their Git wrapper -- I've never really liked how stashing was implemented in Git).
I do really like that they appear to have worked hard to remove all of the super-scary warnings that Git likes to spit out. As someone who has taught high-school students how to use Git (among other things), I've learned that the easiest way to scare away people from your project is to have bright-red warnings in response to a user doing something. Most students describe it as though the computer is effectively screaming at them. Some tools over-compensate for this is and spew emoji in response to user input, so I'm happy this tool has struck the right balance.
In any case, we are supposed to be professionals. Complaining that Git is hard to use is a bit like a machinist complaining that a CNC machine is hard to use. If you want to accomplish non-trivial things in any field, you have to be prepared to deal with some level of complexity. /rant
(I've used git extensively for years, just playing devil's advocate)
¹ Git can handle dozens of millions, as shown by the Linux kernel
Git is not a panacea for bad design. If you have interdependent repositories (I read that the same as a cyclical dependency, A needs B needs A), then you should fix that first. I mean, if you have the described setup, you will have other problems too...
Thank god I’ve never had to deal with a CNC machine like that. But git is that machine.
Secretly I think this is the true reason for gits popularity. It’s like vim, a wonderful tool once you get past the first hill, but I would never force a whole team to use vim, I know it would be a disaster productivity wise. But because of gits popularity it is indeed forced on almost every developer.
I think it became popular because it was written to solve the needs of the largest collaborative project in the history of mankind (Linux). It was objectively better for that job than any other tool that was available at the time (and thus for many such collaborative projects), and that's where the popularity came from.
Now, does it have warts? Yes. I don't agree that it requires very detailed knowledge to use effectively (if I was able to figure it out as a high-school student, I'm certain that it's not beyond the majority of developers). I think it's just that many developers don't feel the need to learn how to use their tools effectively, and if a tool isn't as-easy-as-possible for simple tasks (which I will admit is the case for Git -- the index concept appears to really throw people off) then it is seen as being "too hard".
In your scenario, using a CNC machine is a key part of their jobs as CNC operators -- so I would expect that learning how to use the CNC machine they use for their job would be an important part of working there. Similarly, developers who use git daily (and is a central part of their work) really should put the time into learning how to use it effectively (it wouldn't take more than a weekend with the right resources). I don't think it's reasonable to say that a developer whose job it is to use git should not have any burden to learn how to use their tools, and that it's the tools fault for being hard to use.
I don't disagree that the on-boarding with git and some of the UX (such as stashing) is quite bad. But it's nowhere near as hard as people make out, and at the end of the day if you want to use something you should learn how to use it -- just because you can get it to somewhat work after 10 minutes of bashing at your keyboard doesn't mean you shouldn't spend the few extra hours to actually understand what you're doing. git is a transferable skill, and the time taken to learn how to use it pays off very quickly.
It uses horribly unintuitive metaphors and has weird cryptic methods for doing common, simple tasks that practically require the use of google unless you've memorized the UI.
There's a reason that there is a plethora of wrappers around the system (most of them not very good, unfortunately :().
>In any case, we are supposed to be professionals. Complaining that Git is hard to use is a bit like a machinist complaining that a CNC machine is hard to use.
Gatekeeping is the real reason why git's shoddy UI is tolerated (possibly even celebrated). Knowing and memorizing its quirks is seen as the mark of a "true" professional software developer.
>If you want to accomplish non-trivial things in any field, you have to be prepared to deal with some level of complexity. /rant
I don't agree. 99% of git usage on a project involves a series of repetitive commands following one of about < 8 different workflows per project. I'd rather actually use a high level tool that allows you to build and use these workflows on a project by project basis, but sadly I've never really seen a good tool to do this.
Such a tool would also open up git to non-programmers, allowing easier collaboration. I'd love to see managers tweak configuration properties via git, designers push assets, copywriters push copy and translators push content. I wouldn't have to be the go-between on all of this stuff.
And then there is all the flags. Why in 2018 are we not writing full words?
Linus is a genius, but he makes things that works for him and without much consideration for others. This is just human nature I think.
You "push" to a repository, if it is yours, but you cannot just push to the repositories of others. You make a "pull request" for others to fetch changes from you.
Commit is a "commit" because you "commit a change" as in make something new which differs from the previous state.
"Rebase" just puts your commits on top of the other branch, using the other branch as a "base". (It helps to think of the graph structure)
"Branch" is a branch because what you have is a kind of tree of commits, often more or less a straight line if you've done it right (IMO), and when you make something to work with you deviate from this other history of commits by branching off from it.
I mean it is rather standard terminology, and most importantly, it makes sense. Don't get me started with e.g. Clearcase which frankly makes no sense and should be killed with atomic weapons from low Earth orbit (or any orbit as long as it does the job), just to be sure.
As for hard to use, I never understood this either... I usually use a handful of commands and get things done just fine. If I ever feel like absolutely having to use some kind exotic merge with --onto and looking up octopus merges and whatnot I am probably doing something wrong.
There are plenty of good Git resources available, for example https://git-scm.com/
Conceptually programmers having to mentally convert every line is poor ergonomics and will reduce speed and increase errors. Going to labels instead of numbers is an improvement even if shallow and able to improved upon further.
Back to the tutorial:
> you can only really use Git if you understand how Git works. Merely memorizing which commands you should run at what times will work in the short run, but it’s only a matter of time before you get stuck or, worse, break something.
> Half of the existing resources on Git, unfortunately, take just that approach: they walk you through which commands to run when, and expect that you should do fine if you just mimic those commands. The other half does go through all the concepts, but from what I have seen, they explain Git in a manner that assumes you already understand how Git works.
It should be noted that Git was not unique in its design. There were many source-control systems that had the same model that pre-dated Git, it's just that Git was fast and significantly easier to use than the other tools. The previous tools would not have been usable for developing Linux, and so Git was obviously necessary.
[1]: https://pijul.org/
My aliases do not work cleanly, so I don't want to advertise them. Still, a git wrapper which removes the index would be an improvement.
By the way, can we still call it "porcelain" or is that outdated?
How is that easier than the index and how do you undo changes?
If you use emacs and you find git difficult then please try out magit [2]. I actually really like the git cli, but I use magit a fair amount also. Plus, emacs is awsome :-P
First of all, to checkout a branch, you don't simply select its name. You need to write a freaking configuration file to tell CC what you want to checkout. And it is entirely possible to accidentally write that configuration file in such a way that you'll have half of repository checked out from one version of code, while the other half is checked out from another version of code.
Then there is history of changes. Or in case of ClearCase: histories of changes. Because there are many, in fact as many as there are files. Yes, each file has its own history of changes, completely independent from other files. So if you make a commit which changes 10 files, CC will create separate commit for each of those 10 files, each with the same commit message. Needless to say, browsing history with same commit messages repeated tens or hundred of times, is quite an adventure.
Oh, and because of that, it is not possible to simply checkout some old version of code. If you are lucky, you will have put labels on all files of needed version of code, so then you can checkout that label. Otherwise the only option is to checkout based on dates of commits, and hope that your provided date won't actually cut any commit in half.
Having to manage your config specs and the inability to go back to old versions of your software (or in fact just have something reproducible for your build servers) unless you meticulously label everything makes Clearcase of course barely useable. It gets extra interesting if you use multi-site Clearcase and your replicas stop synching.
I remember that the corruption was silent. That was bad. But nowhere as bad as Clearcase was in general.
Clearcase is like the bastard child of a barrel of horseshit and a mountain of self-inflicted hurt. One had to use "views" of which there were two types, and some kind of special mount point where the view loaded things from a source repository, given a "config specification" which defined from which versions (branches?) files should be loaded. Making a branch took a huge amount of time for a non-trivial source repository. It was "take a coffee" long time. Sometimes the views went bad. I don't luckily even remember all the problems, this was over 10 years ago.
The config specs seemed somehow to defy logic. Something always broke with them. Usually one just copied premade config specs made by someone with a transcended mind who seemed to have somehow figured out the underlying logic.
And... I can't just put to words how bad Clearcase was (is?). That is my experience with it, and I will without a doubt choose Git over VSS, SVN, CVS, RCS, Clearcase and whatnot any day.
By the way, I also have experienced Visual Source Safe silent corruption -- horrible!
In 1995, it was state of the art and revolutionary. Today a bit clunky and off the mainstream. Compared to CVS it was a very sophisticated tool.
The 'visual tree view' it provides is still very good, even today.
(note: i don't really like it and will not mind changing to a different system sometime this century)
But I have to admit, I mostly used it via Github and as a solo-dev.
I get that you can use it for partial commits of in flight work but that's never something I've needed in practice. Usually I just want to commit everything I'm working on at once.
That said, you could extend your argument such that you should always commit every touched file but that would be awful.
Using the index to stage and commit hunks separately lets you easily add and commit the unrelated TODO and FIXME comments separately from the code. A tool like Magit makes it trivially easy to do.
And since they're comments, they have no effect on tests or the code.
In other words, go ahead and break your builds six ways from Sunday, but they won't get merged until they pass based solely on the state of the repo.
Should I get those changes committed? I should. But that involves a lot more testing and thought, since it still has to work for other people with different local dev setups.
I'll often touch multiple files over the course of a few hours, sometimes for slightly unrelated changes, and then want to pull apart the changes into several smaller logical commits. Sometimes a couple hunks in a file might need to go into Commit A, while others go into Commit B.
You can do piecemeal adding of hunks via the CLI, but the interface is horrible. Being able to simply click "Add Hunk" in a GUI is incredibly valuable (or even in some cases shift-clicking a couple lines and "Add Lines").
I really don't understand what's so difficult about the index... It's just the stuff you will be inserting into the repository when you next commit. Having it separated enables a very convenient workflow that would've required manually using patch and diff when using tools that don't support you.
Git is more than just revision storage. I like to think of code as clay, and the index as a tool you use to mould that into the final construct that gets baked
As far as I can see the use case you describe is actually covered in gl commit.
Now, if you want to exclude certain files from a commit I will freely admit this is a pain. The easiest way, especially if you have loads of untracked files you don't want to commit, is to do:
% git commit -a && git reset HEAD~ <file> && git commit --amend
However staging is still a useful concept, and "gl commit" as far as I can tell doesn't really allow me to do something I do quite often ("git add -p" to add partial hunks of a change to staging for a commit). I recognise that I'm probably in the vast minority (outside of the kernel community) when it comes to my Git usage, but staging is definitely quite important for some Git usecases.
I don't quite understand the use of the command line for git or hg.
In my typical workflow before I commit I want to quickly review all the changes I just made. With the GUI you have a list of files and when a file is selected a diff of that file, without opening a new window. That means you can browse all the diffs in a few seconds just by moving the cursor along the changed files. If you see an unrelated change that doesn't have an impact you can just uncheck these lines to remove these changes from the commit. Or uncheck the file itself if all its changes are unrelated. I feel I'm much more confident of what ends up in the commit than using the cli.
I can see how a TUI/GUI for being able to quickly stage things from the UI is useful, but it doesn't make the concept of the index useless on the command line either.
Using git from the command line is second nature to me at this point, and the index is a large part of my workflow. When I use git for revision control (as opposed to eg. Subversion. Or anything that doesn't have lightweight branching, something akin to an index, and rebases), it feels like the tool is helping me organize my commits instead of just being a place to shove things after I'm done coding.
I use that everyday. Whatever you imagined we command line people use, it is just not accurate, IMO.
You might say this is trading one complexity (staging area) for another. But you need to be familiar with these commands anyway, so you might as well use the same things for other tasks. Plus, they're visualised on the same revision graph as everything else (e.g. "oh look, one month ago I saved that private commit").
Mercurial has a few properties that make this easier than in git. For example, there is no concept of detached head / garbage collection; when you save a commit, it is simply saved forever unless you choose to forcably remove it. (I have never found myself wishing for Git's refs and heads; they are just straight up unnecessary.) But I could imagine a git wrapper that had these properties too (e.g. when I checkout an old revision, it automatically creates a new branch with a special name that refs the commit I'm leaving behind).
(PS: Having said all of this, 90% of the time I just go ahead and commit and push everything, and 90% of rest of the time it suffices to just untick the checkboxes next to files that I don't want to commit before clicking the commit button in TortoiseHg. This is massively easier than any of these strategies, and it's opt-in. I'm sure there is a command line way to do this but I find a GUI is great for this task because it's quite visual.)
I don't get it. What does mercurial have instead of refs?
HEAD in git is just one kind of a ref; differentiated from a branch only by when the tooling updates it (ie. when you create a commit in the checked out branch, or when you check out another commit)
"branches" are mutable references. "remote" branches are just refs pointing at the commit that was the remote branch the last time you fetched it to your local repository. They're all the same thing in the end, though.
The way Mercurial branches seem to be a special thing instead of a property of the structure of a repository is partially why I prefer git.
In git, the fact that a "named branch" is actually just a ref to a particular commit that gets updated occasionally makes perfect sense to me. The way mercurial does it has never clicked; why does a branch have to be something special?
I mean, in git, a branch that has no ref pointing to it is still a branch, but if you have no reference to a commit, why would its existence matter? Sure, you can end up "losing" commits when working with rebase, but no-one actually leaves their repo that way if the commit was important; you just look it up from the reflog and give it a name again, and it won't get garbage collected.
And after a branch is merged, why would you keep around a named reference to a branch head that no longer matters? IIRC mercurial has a feature to "close" branches, but I don't understand why that even needs to be a thing? In git, you just delete unnecessary branches (that is, refs), and you're done.
Maybe I misunderstand how mercurial works, but I've not found a source explaining the rationale behind why it works this way.
When you switch branch in Mercurial, in principle it simply looks through all commits to determine the latest one with that branch name. In practice I'm sure there is a cache of this, which is the closest there is to git refs, but that is totally transparent. All commits must have a branch name, and the first commit’s branch name is usually "default" (equivalent to git's "master"). That close branch feature you mentioned is a special type of commit that stops that branch from being included in the list of branches, but the branch still exists because all previous commits to it still do.
This has a few consequences compared to Git's branches, which may be good or bad depending on the situation and your personal opinion. One is that a commit cannot be a member of more than one branch. Another is that branches are far less mutable than they are in Git; to change the branch that a commit is in you must actually destroy and re-create that commit (e.g. with rebase).
Another consequence is that it is fine for a branch to have multiple heads; just go back to a slightly older revision and commit again. Or, more commonly, pull after making your own commits and find someone else has committed to the same branch. (If you prefer: find that someone else has made some commits with the same "branch name" metadata.) Usually this situation is only transient because you would merge or rebase. Indeed, you cannot create multiple heads for a branch on a remote repo unless you force push, so you'd normally merge/rebase before pushing.
Another bit of commit metadata is state: public, draft or secret. Commits are draft when you create them, essentially meaning "not pushed". Public commits are ones that have been pushed to or pulled from a remote repo. In git, to see what things look like on the remote, you’d use the remote ref; in Mercurial, you’d look at the public commits. Admittedly you lose the ability to understand which remote repo a commit was seen on, whereas git supports multiple remotes. (During a push, Mercurial will still check whether “public” commits are on a remote repo and push them if necessary.) You can mark a commit as “secret” and then it will not be pushed unless you change its state back. This is what I use when I commit something for my own reference later on, which I was talking about in my previous comment. Often when I rebase, I leave the original commits behind and mark them as secret in case something goes wrong.
I can see you think branches are "something special" in Mercurial. Maybe in Git you could use refs to implement something totally different to branches, whereas in Mercurial you're stuck with that exact implementation. But refs seem like an unnecessary implementation detail to me. I never want to implement something similar but not quite the same as branches; I just want branches to work! And by not having any refs whatsoever the system seems quite a bit simpler.
In git, a branch is a branch by virtue of being an actual physical branch in the data structure.
To elaborate, I think a branch having multiple heads is not really a good thing, since that leads to the actual structure being one or more branches (each point of divergence results in a branch in the commit lineage), but only one name to refer to the collection of commits making up those branches. That abstraction doesn't agree with me.
Since a branch (a lineage of commits) is unambiguously defined by its head commit, having a named ref as the branch abstraction makes more sense to me. I don't know how it could be any simpler.
It looks like mercurial has a staging area, just that the default it to stage everything unless the user says so, rather than the other way as in git.
Funny that people are mostly unaware of mercurial supporting this - I would argue not using it by default it pretty user friendly, so long as you know it's there when you need it. I use it pretty often, but it's nice not having the boxes unchecked by default. I usually do want to commit everything.
Relatedly, totoisehg is the reason I don't use git for my personal projects. No git gui that works on Linux comes close.
Staging is quite useful if you want to create several commits (perhaps fixup commits, perhaps whole commits) based on the current repository state. This is why you can do "git add -p" to add parts of files to staging.
You mentioned later in the thread that you prefer stashing -- but Git doesn't let you stash certain files (you have to stash the entire state), and in addition stashing has a much more awful UX than commits (it's represented as a stack which means you have to pop elements off it -- and you've then lost that stack entry and you can't pop the stack with uncommitted changes). If there is one aspect of Git's UX that needs to be massively redesigned it would be "git stash".
Maybe there are other ways to do this but for me it's the perfect workflow.
first we had git, and anyone who cared to spend the time could pick it up and understand it well enough to use it. Then we got github and gitlab, which made remote branches more manageable but introduced and entirely new class of developers who only added code through the web interface and emailed/called when they needed a merge or just merged to master because you were sick of the hand-holding.
then we got the GUI clients for windows, which resulted in armies of programmers who didnt understand keys, or authentication, or why the gitlab/github server existed but just wanted to commit their code and as a result left the codebase with a graveyard of rebase --hard and reset head garbage that had to be explained later. supporting them became a nightmare of screen sharing and shouting.
finally we have gitless? and developers now have to keep straight gui, console, gitlab/hub and some asinine wrapper script between the teams? so when jack commits with his GUI and accidentally drags and drops 3 branches, while jills gitless command wiped half the unprotected master, how does it get sorted out?
I'm currently making source control recommendations for my new client. No one there is a full-time programmer, and they mostly do engineering and PLC work, but more recently they have to work with higher level languages from time to time. They absolutely need something they won't have to fight to learn. Other times I've recommended source control during my career include tutoring first-year/some second-year university students, who are often still only becoming familiar with programming and CLIs, and for whom Git seems both arcane and stress-inducing, two things you absolutely don't want from a source-control system.
I am adamant that in neither of these above cases would git be the right choice. I'm also not convinced its the right choice for many development companies, which often have staff of a range of skill levels. I'm lucky in that I've nearly always been working with passionate programmers, where we can and do happily make the choice to adopt git without a second thought.
Funnily enough your complaints also completely ignore what gitless actually is. It does not hide the underlying git structure, it just exposes it in a sane way. Check out the research papers. It's really well thought out. Same power with less exposed state is to me the definition of good software design.
I don't teach gitless to novices because all the rest of git tooling uses the original git vocab. Unfortunately we seem to be locked into using the bad interface design of the original git forever and ever, along with the chorus of people who claim it's perfectly intuitive (once you spent a few thousand hours debugging user errors).
My reason is that, while I'm a fan of git the technology, I think the default git CLI is an unmitigated fucking nightmare and I begrudge every neuron of space that I have to waste remembering how it works. Unfortunately, none of the graphical tools I've tried are as good. So I'm eager to try an alternative command line porcelain that's not so completely batshit insane. If it works out, maybe I can reclaim some of that wasted space.
Edit: wording.
- Command line switches are inconsistent. For example, to list remotes you use -v but to list branches you use -l
- Speaking of command line switches, how about that bizarre need to separate paths in certain commands with "--" so that the parser doesn't get confused? I can never remember when that's necessary.
- There's weird overlap between the porcelain commands that make them harder to learn than they should be. For example, git checkout can do the work of git branch. git pull usually does the work of git fetch. Some common operations get their own commands, while others require you to use switches on other commands. It really shows that git evolved organically from a bunch of shell scripts used by one particular dev team until it katamari damacy'd into a big agglomeration of random parts.
- Poor defaults, such as git push --force not having the behavior of --force-with-lease, and also git push pushing all branches at once by default.
- A bunch of commands are ridiculously overloaded or encumbered by historical limitations that don't make sense anymore. See https://redfin.engineering/two-commits-that-wrecked-the-user...
- Many of git's mechanisms are overly complex and lead to a depressing number of bewildered users. E.g. witness the confusion and conflicting advice at https://stackoverflow.com/questions/6089294/why-do-i-need-to... Another example is git reset, which is invariably a nightmare to explain to an intern or new developer who hasn't used git yet. Trying to learn what git reset does from reading the man page is like trying to learn calculus by examining the digits of pi.
- Speaking of man pages, the man pages are comically bad. I find the git man page generator endlessly amusing: https://git-man-page-generator.lokaltog.net/
Firstly, I agree that Git has a learning curve. However, trying to learn anything based on man pages alone is not a good idea, in my opinion man pages are for reference and not a substitute for more extensive documentation. Of course, sometimes man pages are the only document one has, but this is not so in the case of Git. I myself am not a Git expert, but after reading about what problems people have with Git, it feels like people should perhaps not go for the most exotic commands by default, and they should use a topic branch based workflow. And they should read the Pro Git book and I mean this in a good way :)
As for the switches, one can just as well use "git branch -v" to list branches, I usually pipe to grep if looking for a branch. For the "git remote", it actually does show you the remotes without any switches, but the URL of the remote is not the remote... To see the URLs you'll need the verbose switch. Maybe this is right, maybe not, I do think it makes sense.
The two dashes is actually not a Git peculiarity. It comes from getopt and POSIX.2 to signal the end of options. Compare with e.g. to rm a file that's called "-rf", you'll have to do "rm -- -rf" in the shell.
As for the intern, just tell them "Git reset moves backwards in commit history". Of course there are details (and you can get back to the future with e.g. git reflog), but it should be accurate enough description to an intern who is new to Git, since that's what "git reset" is mostly used for anyway. IMO "git reset -p" and such are somewhat advanced usage.
The problem with the Stack Overflow link is that Git is not tracking that upstream branch, just because the local and remote branches happen to have the same name after a push does not mean they are the same and should be tracked. I'd argue that if one works with topic branches, that kind of situation is kind of remedied automagically through the workflow... Anyway, Tzen's answer there is the correct one (when including the typofixes in the comments).
Also, thanks for the link to the Git man page generator, it's great!
You can always switch branches, without losing your working directory changes. In the common case, this amounts to automatic stashing and unstashing, enabling you to quickly move around to an alternative repository state to check something out (with real git, this is too annoying and I resort to browsing the history on github more often than not).
The second case illustrated in the comparison section is switching branches during a rebase, which git doesn't support without aborting the rebase.
My recommendation: if that seems like a killer feature to you, use gitless. Otherwise, the slight simplification of commands isn't worth adding a layer on top of git.
I use git in my CMS which auto-commits a template file (text) on save. Which works great in a browser editor online. (ie, editing files remotely)
But I am not seeing an advantage to "not staging" with local files. What does this save when working locally?
Is there some disadvantage to staging I am not seeing here? Changing to "not tracking" seems like you removed the file from the repo, which in my opinion goes against the grain on how git works, and in a sorta bad way.
A quick tl;dr of the referenced paper "Purposes, Concepts, Misfits, and a Redesign of Git" (https://spderosso.github.io/oopsla16.pdf):
> The changes made to Git’s concept model are:
> 1. The redefinition of “tracked” and “untracked,” and the elimination of “assume unchanged” and the “staging area.”
> 2. The redefinition of the concept of “branch,” and the elimination of “stash.”
> 3. The creation of the notion of a “current branch,” and the redefinition of “head.
I would agree that most of the delta from git represents an incremental improvement in usability; staging, stashing, and complex ignore rules are all things that are more likely to get in the way of novice to intermediate git users than help them. That being said, I'd classify those usability issues as minor in the overall picture. Most of them are trivial to smooth out either via git aliases or shell aliases - for example, I've had `ignore`, `show-ignored`, and `unignore` aliases for so long that seeing `git update-index --assume-unchanged foo` on the Gitless site made me realize I'd forgotten that that's what my `ignore` alias is actually doing under the hood.
By far the most complex & difficult aspect of using git (and source control in general) is merge conflict resolution. I'm not convinced Gitless offers much benefit in this aspect and in fact I suspect it may actually make things worse. Complex conflict resolution is when the ability to distinguish between staged and unstaged changes is most useful and sometimes even crucial. Furthermore, while Gitless offering capability to 'pause' a conflict resolution by switching to another branch is neat, I would say it's very rare that I need to ever do so in the middle of a conflict resolution. Difficult resolutions require full concentration - if I find myself needing to switch to another branch in the middle of one, the context switch usually renders me unable to pick up where I left off and I wind up starting over to make sure I'm working from a clean slate.
On the whole, I could see Gitless being valuable in academic environments to facilitate desparately-needed use of source control among researchers/postgrads/scientists. But I would steer clear of it in a software development career as I think it would stunt user's abilities to truly master a core tool of their profession in the long run.
I think the focus on stashing is that it’s basically an hidden state. If for instance you switch back to a branch after a while and you don’t remember you stashed, it will just be lost work. Overall I wish stashed were shown as candidate commits, I actually end up making temporary commits that I amend afterward, most of the time.
For the switching between branches during conflict resolution, it might be for people like me who check back and forth reference branches when merging code.
For instance a conflict can be between two feature branches I want to merge, and I’d need to check on master what is the current behavior. Or what’s the behavior on other branches that will need merging as well. Currently I’d just open github/gitlab on the other branches and compare from there, but I’d see the value in switching the local files.
All in all I feel git is too aggressive in making the user deal with all the details when it could have sane non destructive defaults
In other words, yes, this is useful.
How is that different from Git Desktop?
An advantage of gitless on one side, a statement about how to live life on the other side.
But there's lots of things you routinely want to do that aren't convenient this way. Still has some appeal.
(I'm definitely not going to start using this since I already know the real git, but I can understand where it is coming from)
function gl() { git $* }
Love this work!
Once you understand this, Git really does become simple. All you have to do is map each command to the actual operation on the DAG.
This video really explains it quite well, it's the one video that allowed me to fully grasp everything: https://www.youtube.com/watch?v=1ffBJ4sVUb4
So the next major step in VCS technology will most likely do something to help linearize our views and reduce the tangling that comes into play with any tree or graph structure.
a) Most people’s git workflow might as well be linear.
b) rebasing a development branch onto master literally linearizes it
Where git shines though of course is where you can’t get away witha linear model
So if you will pardon the paraphrase, I think the main problem is that many developers don’t take the time to simply learn git.
Git's use of a DAG is confusing and unfamilar for many programmers, though in reality it's beautiful and simple.
The difference relative to functional programming is that you get paid for one and the other is just a tool
Git is quite elegant if one has a good grasp of graph theory.
But this might be a good study in why Linux is not taking over the desktop, and unlikely to do so in foreseeable future.
You have two pills. Or you know few basic DAG concepts, or you need to know a lot of "semantic" VCS commands.
I bet you have no problem in remembering what git pull, git checkout, git add, git commit and git push do, isn't it? For everyday work it's enough. You have problem in mastering git, all these nifty logs, diffs, indexes, refs, heads, remotes and other stuff. Other VCS have complex concepts too besides checkins.
Whatever technical advantages of Git are (and technically it is good), I think it fails as a tool to let me do my job easier.
This is just 'your use-case is wrong'.
It is supposed to be, but I am not sure it delivers on that part. That’s another discussion, but for instance I wouldn’t bet on having a random 10 yo kid understand OO beyond the bare Cats and Dogs tutorial everyone goes through at first.
And that’s what I would say about git as well. Even after knowing the internals and how it is supposed to work, I still feel that for a tool it’s pretty unelegant and puts a significant burden on the user to know what needs to be done in what situations.
Excellent. I responded to the comment that claimed "deep problems in its conceptual design".
> have no idea how to get git to DO it.
Yes, the ergonomics of git could be significantly better. Branches vs tags, manipulating local refs vs remote refs, etc.
https://jneem.github.io/merging/
https://pijul.org/model/#why-care-about-patch-theory
Unfortunatly Gitless doesn't solve them.
But Pijul solve many problems of Git (and Darcs) and is easier to use.
I've basically given up on using early access pijul. I've had a problem with each of the last three versions, primarily pushing to Nest. It wouldn't be an issue if I could install pijul on NearlyFreeSpeech (because then I could self host on a known good version). I want pijul to succeed, its patching model sounds good. Clearly, it's working for some group of people. But I'm not one of them, and it's past where I feel like I'm wasting my time. I'll try again when they're v1.0
I think this is important because people are so quick to jump on the "git is bad" contrarian meme. Git is a fantastic piece of work and the CLI has a variety of issues. On top of this, git is conceptually unintuitive, so the CLI issues make for a worse experience.
Having commands for each DAG operation will just add more complexity and expose a structure which you shouldn't be handling manually.