Gitless – An experimental version control system built on top of Git
gitless.com
gitless.com
The first paragraph says that git has usability issues, but no attempt is made to explain the reasoning and convince the reader that gitless solves these.
I also have a UI nitpick: long parameters should have two dashes instead of one so that short parameters can be freely combined; switches like -exc, -inc and -su go needlessly against common convention. You should also not do such arbitrary truncation... --exc and --inc match --exclude and --include unambiguously, so you get shortened forms for free if you simply do a prefix search.
The index allows you to have partially staged commits. This is most important during merges. The merged changes are staged. The unmerged ones are left in the file system. So the diffs are small.
Every other VCS I've used doesn't handle that case. Merge conflict? Here's a 2000 line diff, of which only 2-3 lines are in conflict. Where are they? Have fun finding them!
Arg.
Hiding the index makes git easier for newcomers. It also hides a new workflow, unique to git. That workflow is better and more efficient than the ones for other VCS.
I am not sure what you're talking about. Every semi-popular VCS I know of allows you to differentiate between files with and without (or with resolved) merge conflicts.
Examples (in alphabetical order, because people can get religious here, and I don't want to appear to favor one over the other):
Bazaar: Integrated in bzr status and also available as a separate bzr conflicts command.
Fossil: Part of fossil status and fossil changes; will display files with conflicts with a CONFLICT rather than EDITED marker.
Mercurial: Here, hg resolve --list or hg resolve -l will list merged files, both resolved snd unresolved (marked with R and U, respectively).
Monotone: Monotone has mtn show_conflicts and mtn conflicts show_remaining and in general a fairly sophisticated (or complicated, depending on who you ask) set of commands for analyzing and resolving merge conflicts [1].
Subversion: Conflicts are marked with "C" in svn status.
(I've excluded Darcs, which has a model that's quite different from the traditional merge command, but for the same reason has fairly extensive machinery for dealing with conflicts, for better or worse.)
This is actually why I consider the index an anti-feature. It not only allows you to do partial commits (practically every VCS does), but encourages it and there's a good chance that you may do it wrong by accident.
This can result in broken revisions (because you're committing a state that may have never actually existed on your disk, let alone did compile or passed tests) and create problems for anything from "git bisect" to nightly builds.
The proper way, as far as I'm concerned, is to do the inverse: use "git stash" instead to remove all changes that you do not need, then compile and test what is in your working tree and only then commit the tested version. Afterwards, apply the stashed changes to get the working tree back to its original state. This way you can minimize the risk of broken commits.
git allows you to package commits up with the interactive rebase before you push them upward to the source. What you commit now isn't necessarily what gets pushed upward. It doesn't matter if you broke the compile with the commit, you still have a chance to fix it before a push. If it hasn't been pushed, no one will necessarily ever know or see it.
The whole point of git is that you can break the crap out of your local repo/branch and still have a chance to fix it before the changes ripple outward and become permanent. It also sounds like you're describing a workflow that entails working off master instead of using feature branches, which is going to create a lot more pain than there needs to be.
Now, the issue with the compile and testing can be real, but I have an easy workaround.
I have another working copy/checkout of the repository, called <repository>-ro. I never edit files in the read only copy, unless it's to fix a merge conflict. All tests and merges are done in this other copy.
Any revision does eventually exists on disk, in this copy.
bzr/fossil/git/hg/mtn/svn commit path1 ... pathn
The biggest problem with the staging area is that (1) it can happen accidentally that you forgot to "git add" a file or (2) it really only gives you any advantage over selective commits when you stage a non-trivial selection of files, which is exactly where things have a chance of going wrong.
Also, with 'git add -i' you can stage individual hunks of a change instead of the whole change. This can be useful when you need to break up changes into multiple commits. I don't think you can 'git stash' your way out of that situation.
That seems... very wrong?
Unfortunately, I don't think stashing helps much either. It's still too cumbersome to stash only some changes. If you're successful on the first shot, awesome. But much like the partial commit case, if the changes you left unstashed don't actually compile or pass tests, adjusting the partition between the changes to commit and not to commit is still a huge pain.
Gitless does not make it clear to me how to work with it in only a handful of sentences. By that measure, it doesn't seem easier than git.
You say: " We think the problem lies deeper than the user interface, in the concepts underlying Git"
But it seems to me that you just rely on the same concepts, but rename them or do nothing at all with them.
One of the concepts underlying git is a history made of unique deltas that can be referred to at any point in time (+ some change). It'd be cool if you made it easier to navigate or make those unique deltas (commits), rather than put a thin wrapper around them.
I'm not really aware of any problems with mercurial's git-support[1]. It might not really be "working with git", but does support working with (as in pushing and pulling) git repos. And while I think there'll never be a consensus on mercurial versus git -- I find that the interface is much cleaner in mercurial, than with git.
So if by "easier" you mean "easier command line use", I think mercurial is worth a look. If not, perhaps look at various guis -- but I've not got any experience with them.
hg help git
Working with Git Repositories
"""""""""""""""""""""""""""""
Basic Use
---------
You can clone a Git repository from Hg by running "hg
clone <url> [dest]".
For example, if you were to run:
$ hg clone git://github.com/schacon/hg-git.git
Hg-Git would clone the repository and convert it to an
Hg repository for you.
(...)
If you are starting from an existing Hg repository,
you have to set up a Git repository somewhere that
you have push access to, add a path entry
for it in your .hg/hgrc file, and then run "hg push
[name]" from within your repository. For example:
$ cd hg-git # (an Hg repository)
$ # edit .hg/hgrc and add the target Git URL in
# the paths section
$ hg push
(And I suspect that if I could do that reliably I would have internalised enough git to use that natively.)
However, after forking a repo on github, everything seems to work fine for me:
hg clone git+ssh://git@github.com:e12e/QuickTun.git qt.hg
cd qt.hg
echo "Mercurial hg-git test." > test
hg add test
hg ci -m "Just a test of hg-git push/pull to github."
hg push
# outputs:
pushing to git+ssh://git@github.com:e12e/QuickTun.git
Warning: Permanently added the RSA host key for IP
address '192.30.252.131' to the list of known hosts.
searching for changes
adding objects
added 1 commits with 1 trees and 1 blobs
updating reference refs/heads/master
> it doesn't seem to help you with some of the more horrible git interactions, such as doing a pull from upstream to your forked github repository.
Continuing from above, nothing stops you from:
hg pull git+ssh://git@github.com:UCIS/QuickTun.git
Eg adding:
upstream = git+ssh://git@github.com:UCIS/QuickTun.git
hg pull upstream
hg push upstream
hg tags
tip 59:b6067e2362b5
default/master 59:b6067e2362b5
upstream/master 58:e5d10c76fcad
That said, if you want to/have to work with github-based repositories, you might be better off just sticking with git.
I saw it the other day and learned to use it with only a page's worth of reading. Why are so many people confused?
Okay.
> Personally, I don't like and barely ever use the index
And there's why.
A lot of us actually like and use the index a lot. It's incredibly powerful; one of git's most powerful features in fact.
I agree that git is insanely inconsistent. I could talk about this for hours. I'd love a better porcelain. But gitless is removing some pretty critical stuff here.
On the positive side, I really like the rest of their UI. I especially like the usage of "track" and "untrack" as core words.
I agree with you that the removal of the index was a bit orthogonal to the end goal of making gitless more consistent. I do agree with their decision (because I don't find the index that useful), but you're right in that they dumped the baby out with the bathwater by going with simplicity rather than just consistency.
I identified several points where gitless' UI is in fact worse than git and as such am not likely to switch, but I am still interested in the rationale behind gitless' UI decisions.
I often see people disparaging git's UI, but honestly, I can't see the problem anymore. Certainly there are weird bits (eg. git diff --cached) in the UI that I've learned by heart now, but I've also learned git's internals -- which doesn't require much investment at all since git is extremely simple -- and in light of that knowledge, git's behaviour is consistent and easily predictable.
That's the thing, if you've learnt them, gitless is useless to you. I'm not interested in learning whether a branch is deleted with -d or -D or git rm branch or whichever one they used for that specific command, so gitless making them all consistent is definitely an improvement.
The documentation doesn't do anything to convince the reader that gitless' UI is more consistent than git's.
Let's pretend I'm a newbie. All I see in the documentation are a list of commands that have pretty much 1:1 mappings in git. How is it better?
It's much more geared towards actions rather than commands.
gitless remotes look exactly the same as git remotes as far as I can tell. Why are they saner?
git init vs. git clone is a triviality, though I'll grant you that init works for both use cases
publish is just a synonym for push, and pull is what gitless seems to call merge. gitless seems to outright ignore the fetch/merge distinction. How do I fetch commits from a remote repository without merging them?
Overall the impression I get from that single web page of documentation is that gitless is a porcelain that misses the point on many things. I realize I might be completely wrong, but gitless' documentation neither answers my questions nor encourages me to try it out.
You're seeing negative comments wondering about gitless' purpose because the introduction fails to offer any motivation.
Here are the commands I use with Git, they're not that different:
- git co branchNameHere
- pull
- git st
- git add -all
- git commit -m "Message here"
- git push
I am not sure where Gitless would save me time based on what I'm seeing, it looks like a simplification of Git. What might save me time would be more features for managing and applying stashes from the command-line, or making it easier to check the changes I've made (git diff).
Here is my all-time favorite Git command, and I've created an alias called 'showtree' for it, but it helps me to understand where different branches are:
git log --all --graph --decorate --oneline --simplify-by-decorationThis seems like it would be annoying when you misspell a branch name. Maybe something like "gl branch -c/--create"?
Like what? And how can you solve "fundamental" conceptual issues by creating a thin layer on top of git?
If you wanna drive stick, you've gotta learn how to use a clutch and gearshift. You can't expect all of the power without being willing to put in some sweat equity to learning it.
You're defending VCS in general. Git is a single VCS implementation, and a shitty one at that.
Git is hacked together from C, Shell, Tcl (which tbh, I've never even heard of), Python, and C++. Mercurial, by comparison, is Python and C.
Git has an awful UI out of the box. Why? There's no reason other than fuck you. Mercurial's UI out of the box is similar to every project that has tried to make Git easier to use. It's for _people_ to use, not Linux kernel developers. [Humor on this topic: http://homes.cs.washington.edu/~asampson/blog/git.html]
Git's documentation also sucks. Suppose you don't understand rebasing. Try running `git help rebase` and you'll get this back: "git-rebase - Forward-port local commits to the updated upstream head". WHAT THE FUCK DOES THAT MEAN?
Another example: `git help push` returns "git-push - Update remote refs along with associated objects". Why is this so goddamn complicated? It's almost like it was written by developers that have no idea what it's like to not understand how git works. Oh wait.
Mercurial on the other hand, has simple explanations at first, with more in-depth explanations if you look further. `hg help push` returns "push changes to the specified destination". Which is how someone would explain VCS pushing to another human being.
Linus Torvalds isn't running `git help`, people that don't understand git are. Documentation should be written for them.
> Git has an awful UI out of the box. Why? There's no reason other than fuck you.
Lovely.
When most people talk about the git workflow, they are thinking of the workflow of a feature developer - which is one of the simpler use cases. Let's think about git, however, as a tool for automating existing workflows, though:
Person #1 is a developer. His workflow looks something like "git fetch public; git checkout -b new-branch public/master; $EDITOR; git commit; git push incoming new-branch". His 'incoming' remote goes to a repository of everyone's unreviewed feature branches, and each feature is parented from the last commit that was in the public repository.
Person #2 is a reviewer. He has two remotes, "incoming" and "reviewed". His workflow is "git fetch incoming; git checkout incoming/branch-to-review; git log --stat; $VIEWER; git push reviewed branch-to-review"
Person #3 is an integrator who's responsible for the state of the 'master' branch on the 'public' repository which is visible to everyone. He only wants to merge reviewed branches. His workflow is "git fetch reviewed; git checkout master; git merge reviewed/branch1 reviewed/branch2 reviewed/branch3; $BUILD_AND_TEST; git push public master".
This is the sort of real-world use of Git that goes on in large organizations. It's actually harder to think about using Git in a single-developer project, because one person is playing the role of developer/reviewer/integrator, and typically doesn't think consciously about what role he's in at any one point in time: so his workflow is sort of a mix of all of the above, which ends up being overly complex.
Tools like SourceTree really don't help the situation either, because they try to give you a graphical interface to git commands in general (since they don't have any insight into the development process for a particular project).
http://lucumr.pocoo.org/2015/2/17/ui-and-hidden-consistency/
Among other things, I hadn't seen anyone call git consistent before. Still, it made a good case for a project like gitless - because the data structures that back git are very well defined and well specified, the standard command set is more of a suggestion than a necessity.
1. The common version control task (e.g. make a new branch and switch to it)
2. How it's accomplished with Git (e.g. git checkout -b my_new_branch)
3. How it's accomplished (ostensibly more easily) with Gitless (e.g. gl branch my_new_branch)