Git is, like many professional tools, something you simply got to learn.
But like with many professinal tools, you don't need to know everything to get to work.
I don't know all Photoshop or Ableton Live features, but I can improve my photos or create songs non the less.
With these commands you can already start your own repo and work on it locally:
git init // crate new repo
git status // show which files are changed and which of them are staged
git add -p // add "chunks" of changed files to the stage
git commit -m "<commit_msg>" // commit everything added to the stage with a commit message
git log // show a list of commits
git checkout <file> // throw away all changes since the last commit (one file)
git reset --hard // throw away all changes since the last commit (all files)
If you want to work with a repo from somewhere else like Github etc., you need a few extra commands:
git clone <repo_url> <target_dir> // clone a remote repository locally
git pull // download and merge new commits in the remote repo that happened since the last clone/pull
git push // uploading your own changes after a commit to the remote repo
I think these 10 commands are all that is needed to get your own project into Git.
Yes, the more people are working on a project, the more commands you need, like creating a new branch and getting commits from one branch to another, or amending commits because you forgot something etc.
For a professional tool this isn't too much, I think. The 10 commands I mentioned will be remembered in less than a week. Most of the rest isn't needed often (maybe merge/rebase and branch depending on how you intend to use Git), but they shouldn't take too long either.
git checkout <file> // throw away all changes since the last commit (one file)
git reset --hard // throw away all changes since the last commit (all files)
This is a perfect illustration of why git needs a better UI. Two different commands to do exactly the same thing, with the only difference being that one is for one file and the other is for many files? If you tried to design a hard-to-use UI you could hardly do better than that.
[NOTE: these two commands actually don't do quite the same thing, which is part of the problem.]
They do different things, anyway. `git checkout <file>` will restore files from the _index_, which means it actually discards changes since the last `git add`. It can also be used on the entire tree as `git checkout .`. (As an aside, I think that the different branch vs. tree behaviors for `git checkout` are the biggest UX wart in git.)
`git reset --hard` discards the index _and_ any unindexed changes. You can think of it as essentially `git reset` (which discards the index) followed by a `git checkout .`
I think a lot of the murkiness of git's usability comes from the fact that many commands have collected convenience flags that replicate the behavior of other commands. The rest comes from the fact that `git checkout` and `git reset` can affect any or all of 1) the contents of the working directory 2) the contents of the index 3) the contents of repository metadata like branch tips and HEAD, and you pretty much just have to learn what does what.
Yes, all this is exactly my point. It is nearly impossible to explain the current git UI in a way that isn't embarrassing at best and wrong at worst. And then it's nearly impossible to remember. The number of things you actually want to do 90% of the time is small, so I think there is value in designing a veneer that makes that 90% easy to explain and remember.
I use Mercurial as a client for git, using the hg-git extension. It works absolutely fine for my use case (small numbers of developers on github, mostly). There are a few rough edges when you want to do things that git doesn't like, like moving tags, and the bidirectional branch<->bookmark syncing isn't quite as robust as it should be, but it saves me having to touch git at all.
At $dayjob we have a mixed bag of hg and git. I found that while git makes great distinction between local and remote (and working directory), hg is more similar to centralized VCSes. Any other remote action than "sync local with remote" requires Blak Magick Mumbojumbo™. Some "common" (as seen by original authors. Local throwaway branch is not such) tasks are sure easier than git, but stepping out of the beaten path becomes cryptic. Git, on the other hand, is of average difficulty for most of the tasks. Your mileage may vary.
I'm curious, what other remote action do you miss with hg? Push and pull (to different remote repos if needed) are sufficient for me. What am I missing?
But they don't do "exactly the same thing, with the only difference being..." unless you ignore the index, which is one of the extremely powerful abstractions that sets git apart. Sure, git could expose a simplified lowest-common-denominator interface that plasters over its differences, but the same interface would (and gitless does) plaster over its strengths and encourage people not to learn them.
I agree with TFA: this isn't a UI issue, it's an abstraction issue. Several of git's abstractions only make cost/benefit sense in a distributed environment. Unbundling the cost of learning dVCS abstractions would make git a better fit for the Cathedral and a worse fit for the Bazaar. This might be what you want, but you should at least be able to understand why other people do not want it.
They don't do the same thing implementation wise, but they do the same thing ux wise. This difference causes all discussions like the above: it seems as if some people like ux "plaster", while others like bare-metal tools.
They only do the same thing if you haven't previously used `git add`. If you have, `git checkout` will use the contents of the index, not the contents of the last commit.
How so? You're the one proposing they do the same thing when they fundamentally do not. To posit so is less of git's "ux problem" and more of just needing to grok git.
I share your concerns for consistent tooling, but the idea of becoming proficient in something without putting in the effort is not reality.
This is very close to the result of the study that was I believe he reason to write gitless:
- Most people use git by learning a set of a few commands
- A minority actually understands git on a deeper level
But both groups form a mental model of how git works, and that model is apparently usually wrong, which results in those cases were you get stuck and just start with a fresh checkout and manually reapplying the changes you wanted to commit.
No, but there's a book called "Pro Git" by Scott Chacon and Ben Straub that popped up on HN not too long ago. It does explain git on the lower level without going into the git source code.
This book is over 500 pages, but chapters 1 to 3 will get you up and efficient within 2 hours. Especially chapter 3 (I skipped to it, I kinda knew the basic git commands from "experience"), which goes over branching and how it works. It explains how snapshots are handled and what points to what, which make working with multiple branches locally and remotely a pleasure actually.
It's honestly not to hard to get decent at git. Although I never realized how much of a tool git was until I heard about people writing 500 page long books about it.
I never realized how much of a tool git users were before I knew there are 500 page books about it....
This whole thread is evidence of two opposing viewpoints: "git is too hard" and "git is powerful, professional tool and that requires some effort".
I believe those making the latter point misunderstand the first group (to which I belong): I'm not opposed to putting in some time to learn a tool that's central to my craft.
But git seems to often be complicated not because of the complexity of the underlying problems, but because of choices made in its implementation.
Consider: If you have a decent understand of information theory, you'll be able to use any database system within a short time, even if you never had heard of SQL before. Indeed, with a few years of SQL, you'll quickly understand NoSQL systems as well – coming from Postgres, I was productive in Redis within half an hour.
But no amount of experience with VCSs will allow you dive into git without hitting a brick wall.
Everybody who's ever forked a project on GitHub is using it as distributed version control, and that's a lot of people, so I don't know why you say almost no one actually does distributed version control.
I'm quite certain most of these are sure they are using github and see no difference between it and Git; and "version control" term gives them headaches in same way as "currying" or "first-class function".
I think a lot of tutorials spend a lot of time teaching you the index/staging (a non-trivial concept that beginners don't need) but don't teach you how to survive merge conflicts and other common tricky situations which beginners are likely to run into if they're collaborating.
Your list is all you need...until you try to `git pull` and it says
> Cannot pull with rebase: You have unstaged changes.
You're only option with your list is commit your changes, but I think it's better to `git stash` then `git pull` then `git stash pop`
Though when you `git pull` you can get a merge conflict and there's two different ways to resolve it depending on if you used the `--rebase` flag or not.
Once you're done resolving those conflicts, you run `git stash pop` and could possibly get yet-another merge conflict that needs to get resolved.
Basically, I'd add `git stash` to your collaborative list. You can't `git pull` without it.
Sure, but my guess is it's just as easy to shoot yourself in the foot with rebase -i. Beginners are still going to have a hard time recovering mistakes with rebase -i, even if it's theoretically possible to recover.
Plus, now you need to use `git diff origin` rather than `git diff` to see your changes.
> Sure, but my guess is it's just as easy to shoot yourself in the foot with rebase -i.
No. rebase -i goes in the reflog. stashes don't. The rebase man page does not have the same safety warning that the stash man page does. I have personally witnessed a lot of stash accidents, and not many rebase accidents.
With a rebase, if you have a bad merge conflict, you can abort. With a stash you can't. If you've committed your changes and have problems either forgetting what you're doing, or with merge conflicts, or with being in the wrong branch. All of these cases have more undo options with commits. In the worst case, you still have the safety net of the reflog with commit. With stashes, your only safety net is hunting for dangling blobs using fsck.
I mean it's just as easy to make a mistake in the first place with rebase -i. Even though one is theoretically possible to recover with rebase -i, it's going to be very hard to recover for a beginner. (You need to know the reflog command, etc.)
I don't think those commands are remotely sufficient to work with git. You're forgetting about merging, traversing history, branch creation, remotes, grokking the staging area, etc. I'm sure I'm missing a lot as well, because those of us who have worked with git for a long time take these things for granted. And it does frustrate me that it's so complex, because Mercurial shows us it doesn't have to be this way. Unfortunately, Mercurial never took off (presumably because it never had a good GitHub analog).
The examples I mentioned were taken from notes I made myself when I was learning git (whenever I had an "aha" moment, I would make a note so I wouldn't forget how to work around it later, since I didn't know the git jargon and thus couldn't Google effectively). Maybe my experience is atypical, but at the time I didn't think I was doing anything novel.
How are they forgetting merging, remotes, etc? The commands are literally on the front page. The only thing it doesn't have is a staging area, which is a conscious decision that I happen to agree with.
I'm quite comfortable with git now but I also remember what a pain it was to learn. This included making mistakes and diving deep into git's internals to recover. The question is whether we should make things easier for new versus experienced developers?
If switching to gitless became a thing I'd have to learn something new, but if it made things significantly easier for beginners, maybe my personal inconvenience isn't that important.
Version control is arguably confusing for beginners, but building a shim instead of learning the tool isn't the answer in my head.
I always struggle with "lowering the barrier of entry" and it's not a "I did it they need too do it" it's more of a "Usually high barriers mean it's complex, and learning how to understand complex things is important."
If this was some new novel way to version that wasn't just pretty git, I'd be a lil more excited.
In my previous job, I taught darcs to a designer/graphics artist. It took about half an hour to go through the CLI, and after that he used it successfully and asked me maybe a pair of questions ever.
Now the guy was pretty technical (part of his job was AS development), but he was not a developer.
Darcs's and Git's fundamentals are not that different[0], but Darcs's CLI actually makes sense in and of itself independent from the implementation details, and when it diverges from the older standard (e.g. SVN) it's so that commands make more sense, not less. Meanwhile Git has taken pretty much the opposite tack.
Git's porcelain is a giant steaming roasted turd sandwich, no other DVCS has such a complex, hostile and nonsensical CLI that people tell you you're supposed to learn it from the storage model up and then it'll make sense.
Don't try to shift the buck to VCS/DVCS concepts, while they are complex Git's CLI goes a great way towards making them nonsensical to beginners and non-beginners alike. I routinely used three different DVCS before I had to take the plunge into Git, and it was still a fucking pain in the ass. And that's a problem at every level of resolutions, just compare the hot mess that is gitrevisions(7) to mercurial's (more powerful, more flexible, more readable and more regular) revsets. It's not like revsets are a genius's flash of inspiration either, "hey I'm trying to manipulate sets of revisions, how about I manipulate them as sets?" We're not talking turing award worthy discovery here.
[0] well they kinda are, but by and large the fundamental differences are irrelevant to basic day-to-day use.
That's why we picked fossil over git. The interface is really sane and you can also do stuff from the browser. It gets out of your way. You do not need Python, it can be statically linked easily. It also works on Windows. The usability experience is akin to Mercurial, but even easier to use. Unfortunately it doesn't quie work for bigger projoects (think the Linux kernel or the FreeBSD ports tree) and it can also get slower once you have a lot of history. The repo is esentially a SQLite db.
> Version control is arguably confusing for beginners
NO IT IS NOT. <smack to back of head> That kind of thinking is broken.
Most people who have been around computers on Windows long enough eventually adopt it. They start creating zip files of directories and they put date codes on them. You laugh, but it works.
As such, it's really easy for me to explain Mercurial to them. I simply explain it that Mercurial holds those zip files with some extra information and a pretty GUI. It takes me 30 minutes, max, and they get it.
They have one branch. They occasionally share things with other people. And, very occasionally, they have to merge something--which generally gets resolved by taking this file or that file--but rarely actually merging content.
Things only start to go bad when you start adding concepts that require the user to keep state of the repository in their head. If the end user has to think about the DAG, yeah, THAT'S complicated. And that's broken.
I've now been using git and hg for so long that I know both. I now know enough about git that I have been able to unwedge my teams without just copying the repo (cue xkcd link: https://xkcd.com/1597/). I don't need to spend hours of Googling anymore, I just need quick reminders of "Oh, yeah, that stupid flag."
And, you know what, I have never, ever been in a situation where I thought "Gee, I really wish I was in git rather than Mercurial." The converse, however, happens at least once a week.
Perhaps one day my teams or my repos will be complicated enough that the light dawns. The fact that the *BSD guys still operate using CVS and Subversion makes me skeptical.
For me the problems are always merge conflicts. Don't know why, in SVN I wasn't afraid of merge conflicts, I just opened a GUI, clicked on some arrows, picked the parts I want and parts I don't want, save and done. In Git, even with gui tools, I often end up with a mess of .BASE, .LOCAL, .REMOTE files, then I can't merge it all properly, and even if I do it asks me to commit the changes again and it's a mess, so I just clone the repo again and copy the files (xkcd #1597).
If you think merging in svn is easier than git then you haven't seen the pathological cases of svn merges. The problem is svn has no concept of a repo root or branches, it only has directories, so sooner or later things get very very broken.
I don't understand this rationale. Are you saying that Git's UI is perfect, and there's no improving it? It's not, and gitless does, indeed, improve on it.
We should be celebrating better UIs over important tools, not saying "I made great effort to learn it, therefore learning it with less effort is inferior". No. If it does everything Git does, but more easily, it is strictly superior.
Well-said. We also know that git was originally hacked together in two weeks after Torvalds had to ditch the better-designed product they were using, Bitkeeper. It's almost as if a bunch of Linux developers kept hacking stuff into it with no concern for UX and telling people they were idiots if they didn't like mastering unnecessary complexity.
Meanwhile, unlike Git, I understood most of Gitless's commands before the tutorial started explaining them. Opposite experience I got with Git tutorials where I kept questioning why it would be done a certain, unintuitive way. This is definitely an improvement.
Git's UI will never beat Git's command line. Not even close. It may be easy, but the command line is far more powerful, and way faster. Basic git usage is around 10 simple commands or less, and it's not like it's not well documented.
What I'm saying is, Gitless is cool, BUT beginners are always looking for ways to cheat the effort. My point is, this is a great tool if you understand git, and want to use a shim, but for beginners, going straight to the shim is not good.
>If it does everything Git does, but more easily, it is strictly superior.
In the abstract I agree, but if an junior dev goes "oh, I just use gitless because it's easier" and DOESN'T understand git, it's a problem. That's my point.
I'm always suspicious of arguments like this, because they have a Luddite quality to them. Isn't sending email versus handwritten postal mail "cheating the effort" of communication?
git is a lot of effort to learn because its command line is inconsistent and it is frequently unclear what it has done, why and how to recover from it. It is worth asking if this is really necessary.
If a system has a high percentage of beginners pressing the wrong button and losing time and effort as a result, maybe someone should move the buttons?
This is spot on, thank you. The git porcelain is very inconsistent between commands, and that really muddies the view of the underlying model. I would argue that a cleaner porcelain would lead to more easily building a mental model of the data structures.
I think there's a difference between learning something that's necessarily complex and learning something with an overly complex design. According to their analysis, the design changes they've made do away with unnecessary complexity.
Eclipse has stuff like workspaces with multiple projects and others have simply projects. What to do with these workspaces?
Same goes with Git. Simple VCS have central repositories and a working copy. Git has multiple repositories and every one of them can have a working copy. Other VCS don't have a stage, you simply commit your changes directly into your repository.
It's not only that these tools have different commands and stuff like Mercurial or Subversion has easier commands etc. but they really have different concepts that need to be considered while working with these tools on a daily basis.
But you don't have to internalize them on your first week or month working with them. When you got your project in the System it's mostly save and if you don't have complex workflows you can still reap the benefits of VCS with Git without knowing everything.
The problem is better solved with good tutorials. Cutting corners is a bad idea here so encouraging newbies to do that is more hurting than helping them.
I persist in using git mostly because it doesn't also mean I need to have python installed everywhere.
I recognize this may be a minority reason, but that is a significant one. The rest amount to being able to rebase/reorder my commits.
At no point does "linus used it" factor in. What genuine technical points about git besides "doesn't suck" are you espousing as reasons I should switch?
Note, my workplace:
a: uses git
b: is about as likely to switch to hg as a pig would be to fly
c: follows linux upstream closely (we do kernel stuff)
I know of the following things that would be reasons to move to hg, however they're more in the "nice to have" rather than "need" category.
a: evolve extension
b: more consistent ui
If I were to list out all the cons for hg from my current perspective, here would be my top 5:
a: have to unlearn fetch/pull as they are not the same between tools, which is right is academic at this point
b: have to unlearn a lot of git use over the past 8 years, not against it but I need a good carrot to bother
c: now I have to install python on some low power systems, honestly this is dumb needing to install a scripting language just to use a VCS, and I use python daily, but its extra bloat that really shouldn't be needed.
d: last I looked (~6 months ago), i'd need to install extensions to recreate most of my workflow, again, this boils down to more effort than sticking with the status quo which by and large works out of the box.
e: would be nice if hg proponents would stop with the "git users are brain damaged by bad ui" posts, it honestly just makes me roll my eyes and move on, not rethink my position, SHOW ME WHY IT IS BETTER, stop berating as that isn't helping and at best is making me think people are treating VCS choice as a religion or political affiliation, which is easily dismissed and not at all worth my time to reply.
> I persist in using git mostly because it doesn't also mean I need to have python installed everywhere.
That is a perfectly valid objective reason. It surprises me, given that I do embedded development and have yet to be in a position where Python in my toolchain is an issue, but I'm happy to concede it.
> c: follows linux upstream closely (we do kernel stuff)
Then git is your horse, full stop. Even as a Mercurial person, if I was following kernel stuff I'd use git, that's just common sense.
> e: would be nice if hg proponents would stop with the "git users are brain damaged by bad ui" posts, it honestly just makes me roll my eyes and move on, not rethink my position, SHOW ME WHY IT IS BETTER
You do realize that the UI is more than the majority of the tool, right?
People have done what you ask for. Repeatedly. Including the parent post. Git power users have written extensively of the various UI brain damage and the problems it causes for non-power users.
Git people concede the UI sucks and still persist in starting new projects with git. How should that be classified?
> If I were to list out all the cons
Do be cognizant that with the exception of objecting to python, most of your list of cons is: "I've used git and optimized for it so changing is difficult". If Microsoft/Oracle were attempting via network effects to foist such a broken tool on the open source community instead of Linus/github, people would be screaming.
Personally, I can use either now. Also, personally, I now consider Mercurial to be a not-so-secret productivity advantage (well integrated with Windows, no wedged repositories, no wasted time recovering, can explain how to use it to neophytes so executive level people and non-programmers can use it, etc.). I know that my Mercurial teams won't waste 5% of their time fighting their source code system every single week--they won't even think about their source code system.
My beef is that beginners think "Oh, everybody uses git so git is fine so let's use git". And then, once they've made that mistake, now they feel they have to defend it. And that's not cool.
> It surprises me, given that I do embedded development and have yet to be in a position where Python in my toolchain is an issue, but I'm happy to concede it.
Admittedly its weak but I've used it to run things like git on some really small systems. I'd rather not have to try to get python running on something like an AVR. But to each their own. Not sure what embedded development is meaning here exactly but no matter.
> You do realize that the UI is more than the majority of the tool, right?
> People have done what you ask for. Repeatedly. Including the parent post. Git power users have written extensively of the various UI brain damage and the problems it causes for non-power users.
I'm looking more for what advantage hg itself gives me, less about how much git sucks which is at this point beating a dead horse.
> Do be cognizant that with the exception of objecting to python, most of your list of cons is: "I've used git and optimized for it so changing is difficult". If Microsoft/Oracle were attempting via network effects to foist such a broken tool on the open source community instead of Linus/github, people would be screaming.
Indeed, but that just points to after 8-9 years of using git, minor gains in using hg just don't seem as warranted. To date most of what I have seen with hg hasn't shown me what I will gain from switching will be greater than moving. Perhaps thats due to not having to use hg constantly but with things like magit I really don't notice the git ui a lot unless I choose to drop into the command line.
> Also, personally, I now consider Mercurial to be a not-so-secret productivity advantage (well integrated with Windows, no wedged repositories, no wasted time recovering, can explain how to use it to neophytes so executive level people and non-programmers can use it, etc.). I know that my Mercurial teams won't waste 5% of their time fighting their source code system every single week--they won't even think about their source code system.
For my work I've no real need to integrate with windows, not sure what wedged repositories is referring to. Recovering is vague but as a worst case the reflog has always been an emergency fixer. I've not really experienced this to be honest and I'm basically the go to guy for git with my team.
> My beef is that beginners think "Oh, everybody uses git so git is fine so let's use git". And then, once they've made that mistake, now they feel they have to defend it. And that's not cool.
Thats fine, but a bit different than the original statement of Linus uses it therefore we must. It is more git is widely used, ignoring it or not knowing how to at least basically use it isn't a tenable position imo. But to each their own.
git wasn't designed to be used by humans. I can't find the quote, but Torvalds said at one point that intention of Git was to provide a content-addressable graph that more human-friendly tools could build upon for different use cases.
Those 10 commands are the beginning of the iceberg when you actually start using git with teams. Where are `rebase`, `merge`, `branch`, etc? These are all commands I use daily, they are complicated, and it's trivial to shoot yourself in the foot.
The problem is that you can learn those 10 commands and things will work, until they don't, and you as a beginner are now spending hours trawling StackOverflow to figure out how to, say, pull a commit from one branch to another (you might not know that such a process is called "cherry-picking").
It's telling that Torvalds said this more recently about git:
> The first Git For Dummies and Git Visual Quickstart books are going to be out in a couple of months, and that is the beginning of the end as far as I’m concerned. Those books mean the end of git expertise and github reputation as reliable indicators of geek status. Once a technology is adopted by the masses the extreme geeks find something more esoteric. Look at what happened to Ruby on Rails. The people stumbling their way through Rails to-do list tutorials have never even heard of DHH.
I could be wrong, but I think the article that the Torvalds quote came from was purely satirical [1]. If you look at the tags it says it was posted under satire. Got me at first too!
Git wasn't originally designed to be used by humans. There was a separate "porcelain" built on top of git, but I no longer remember what it was called. But enough people wanted to just use git proper without the porcelain that the git core commands evolved into a porcelain themselves, and the separate porcelain layer was deprecated.
After having used git for a few years, I identified what commands I use most frequently and have created two-letter aliases for these;
alias st='git status' # STatus
alias dp='git diff' # Diff Pending
alias aa='git add .' # Add All
alias di='git diff --cached' # DIff
alias cm='git commit -m' # CoMmit
alias pu='git push' # PUsh
I've added comments above to show you what I think in my head when I type the two-letter alias in question.
I have a few other two-letter aliases for git as well but the ones above cover about 80% of my use I think.
For the remaining 20% I usually type the command out fully even if I have an alias for it, because those less-frequently used commands are harder to remember the aliases for, whereas the aliases that cover the 80%, I have those in my fingers now without having to think about it.
For the specific aliases I have, the only one that needs an argument is commit and you can't auto-complete a commit message anyway ;) For the aliases that I sometimes specify a file path for, bash is still able to tab-complete that. So for me, shell aliases are actually the best.
> I think git's concepts are simple and worth learning
For what purpose? The reason for using a VCS is to get your job done. If gitless does that, why should I need to learn the concepts of a content-addressable graph storage and traversal format?
For instance, git has a notion of staging area (the index) where you collect the changes that go into a commit. In gitless, all changes to tracked files are committed. The index goes a long way towards making nice commits that can be understood by other team members, pass tests, etc.
Similarly, the stash that allows you to save your uncommitted changes before switching branches is also quite worthwhile.
For all intents and purposes, gitless has an index too. It lets you specify upto hunk-level granularity what you want to include in (and exclude from) each commit.
$ gl checkout foo.py
You have uncommitted changes in foo.py that would be
overwritten by checkout. Do you wish to continue? (y/N)
> y
A cheat sheet with those 10 commands are enough to get started, but Git takes a bit to grok properly ( https://xkcd.com/1597/ ). More importantly, it doesn't have to be user hostile. Professional tools in manufacturing are very expensive and last decades. Software lifecycles are shorter and easier and far cheaper to replace.
True. But the argument breaks down (for me) when you consider all the computing power we have, what we're building (i.e., lack of dog fooding), etc. and this must learn tool is the best we got.
NO ONE would use Photoshop or Ableton if they're were as messy as Git. Nuff said.
The problem is the world isn't just git. There are thousands of other things to master at any given moment. Putting a veneer over something you aren't interested in mastering and using that seems like a valid strategy.
I just use Git GUI. Click click and I'm done. For more complex tasks I open up Git Bash eg. git merge --no-ff <branch> which is the equivalent of "gl merge" command in gitless
Yep, that's pretty much my git repertoire! I would add branch and merge to this list - conceptually simple, but they add another dimension to version control.
Agreed. I'm seeing terms like "elitist" being thrown around below for "git apologists" when it's simply a matter of learning a tool. Not everyone needs all the power of the git CLI and the complications it brings - but when you do need it, it's there to fix the dumb things we all do sometimes.
I think if you look deep in the guts of Clearcase for example you will see nastiness that makes git look like the ls command.
" I'm seeing terms like "elitist" being thrown around below for "git apologists" when it's simply a matter of learning a tool."
Some tools people encounter seem unintuitive and have a steep learning curve. Others that do the same thing are super easy to understand and learn. Git vs Gitless is a good example where Gitless instantly clicked with hardly a thought. That means it was a superior interface. That also means anyone telling people they need to suck it up and just accept bad interfaces that smart people were able to learn with enough wasted energy is a bad idea.
Reminds me of those guys when I first started dealing with Linux who told me I was just being slow or lazy for expecting an installer that just required a little bit of input like I had with Windows. Anyone should know everything about handling partitions, configuration of low-level graphics, init systems, whatever. These days, the installers are point-and-click for average case while including options for others. So, why did the Linux people tell me that early on? They were elitist snobs peddling bad UI's and seeing no value in good ones. That simple.
No-one is disputing the power of git. People are merely pointing out that it's textual user interface is clunky and inconsistent. Just because it won the DVCS wars doesn't mean the conversation needs to end and we have to accept this is as good as it gets. It won despite it's CLI not because of it.
> Git is, like many professional tools, something you simply got to learn.
No. Why do people think "professional" has to mean "poorly designed"?
But then, the rest of your post seems to miss the point of this thing entirely. You go on to say that you basically only need 10 commands...which is pretty much the insight that lead to Gitless in the first place.
"Professional" doesn't mean "Poorly designed". It means "designed so that people with lots of domain knowledge and experience with the tool find that it never gets in their way."
In that sense, git is a professional tool. If you know everything about it, it doesn't get in your way. The problem is when you don't know everything about it..
In this sense, trivially, every tool is a "professional" tool, since if you just rote-memorize every aspect of it you know how to do everything it can do.
The problem with git is the lack of coherence in its default UI. Multiple ways to accomplish the same task, git commands which perform incredibly different functions depending on (invisible) context, inability to decide whether commands or flags should act as the highest-level switches...
It is simply the case that, no matter how beautifully and cleanly designed git's internals might be, the interface it presents to them has zero conceptual integrity.
No, trivially, there can be tools that you know inside out which still present roadblocks to perfectly ordinary tasks and be a bad fit for the domain they operate in.
Visual SourceSafe springs to mind here...
Git, by comparison, is very flexible and allows you to do an awful lot, when you've learned it. You can learn SourceSafe inside out and still have it be a total pain in the arse.
Again: git as some sort of Platonic ideal of an implementation of a DAG I don't care to argue about. But git's default user interface I will argue about until I'm out of breath, then keep arguing about.
Nothing in that interface is designed to aid in learning. Nothing in it is designed so that mastering one task provides discoverability or intuitability of how to perform another task. It is a complex mess of inconsistencies, discontinuities and obscurities which point more to a lack of design or even of someone with authority to perform design than to anything else. It can only be "mastered" through rote memorization, and bears no necessary or useful relationship to the underlying data models and structures whatsoever.
Eh. Fair enough, my pedant mode just kicked in when you said any tool could be a 'professional' tool in the sense the parent poster said.
I have no particular view on how good or bad git's command line is - I have greatly enjoyed using SourceTree though, and the underlying DVCS seemed not to get in the way.
I think this is because the commands are poorly named and badly organised. Professionals will use it frequently enough that they remember everything they need and find it easy from that point forward, but for beginners the unintuitive commands are a double-whammy. It's hard to find the command you want, and the poor naming is a hinderence to building a good mental model of the system.
The burden of having to know everything about it, is precisely what gets in your way. Granted, I use an actual tool (sourcetree) that abstracts away the BS that is the git commandline.
This idea that 'if you don't like the tool, it's because you're not good enough to use it, because you don't know everything about it' is elitist hokum.
yes. and that's why as new planes are being produced, both commercial and small planes, they are replacing the older cockpits with fully electronic modern cockpit controls (with non-electronic secondary controls for power failure use)
many NTSB studies show that even master pilots with thousands of hours of training and flight time make (often fatal) mistakes due to confusion in understanding the cockpit readings
Fully electronic "modern" solves nothing without training. Part of the reason Air France 447 crashed was because the crew did not react correctly to the instruments, even though it was an Airbus with all its gee-whiz electronic stuff. Boeing has been more conservative.
There's a standard tech-nerd bias that assumes that technology will always save us, but just throwing electronics at the problem doesn't necessarily solve anything.
For example, the Army found that using glass cockpits doubled or quadrupled the accident rates in UH-60 and OH-58 aircraft respectively, increased it by ~30% in the AH-64, and reduced it by ~40% in the CH-47.
A five-year NTSB study found that although glass cockpits had twice the incidence rate of fatal accidents. The study concluded that glass cockpits do not show a safety benefit. This remains the position of the NTSB.
The reality is that simpler is sometimes better. Mechanical instruments each do one thing and they do it well. Vacuum-driven systems are simple and extremely reliable. You cannot fly a 100% glass cockpit, period.
What glass cockpits really do well is information integration. That makes it easier to surface relevant information for the pilot but it also means that pilots have to handle more complex systems that are throwing more information at them, and yet also may not be throwing the right information at them.
This is an inherently one-way street, the reason we have the instruments we do is because they're relevant, you can't go hiding relevant information from the pilot. As such, NASA recgonizes that glass cockpits and cockpit automation impose a higher cognitive load on pilots. It's very simple and straightforward to interact with a traditional cockpit, but with a more advanced cockpit you also need to have a correct mental model of what's happening in the background, otherwise "cognitive mismatch" will result.
Just like any other abstraction - it's nice when they work but all abstractions are "leaky" to some degree or other and you need to know how it works and be able to route around the problem to fix the cases where it fails.
The long and short here is that experience and frequent training are the key factors in aviation safety and glass cockpits actually increase the requirements in this area. They're nice when they work but they certainly are no panacea.
Professional means it doesn't sacrifice functionality in favour of making things easy for newbies. This is a philosophy I approve of for all software. Vim is great because it offers power at the expense of having a little bit of a learning curve. A shell gives you unlimited power compare to a stripped down and locked down GUI.
GUIs and "UX" are generally antithetical to making a computer do what it does best (automate things instead of creating more busywork).
> GUIs and "UX" are generally antithetical to making a computer do what it does best
I agree with you, but although CLIs are explicitly automatable, they are almost never are because most operations are one time deals. If you have evet set up a Linux server I think you'll understand what I mean. The CLI is also a usability nightmare with no discoverability.
I use configuration management tools to set up multiple nearly identical Linux servers with nearly identical configurations. It's totally repeatable. Look into Ansible, Chef, Puppet, or SaltStack.
Bash is what I miss in iOS, I used to jailbreak just for getting a shell.
Now, I use pythonista as a python-shell. Being able to chain a couple of commands and fix a good-enough solution saves a lot of time in many cases such as web scraping on-the-go.
I know this may be an extreme use case, but if iPad is going to be a laptop replacement we need to be able to get a way to speak with it without immidiate access to a laptop.
"False equivalence. We wouldn't have billions of users if there were no other agents than users. You can't create an iphone using an iphone."
It's not a false equivalence at all.
The necessity of lower-level technology in the creation of higher-level technology does not imply that the lower-level technology is somehow 'better' or 'superior'.
You are using a UX right now to read and respond to this.
It's crazy to posit that 'UXs are inferior'. Positively wrong.
In the vast majority of cases, UX's are superior to shells. Maps, news, social media, browsing/buying things, listening to music, making music, photo editing - there are actually very few use-cases wherein the shell is advantageous. Even emacs is a UX of sorts.
Well, first off: I didn't claim that "UXs are inferior", whatever that means. Every interface is a UX. I assume from context you're talking about polished GUI:s.
GUI:s are superior for the specific (limited) use cases they are designed for, inherently since they were designed to excel at those use cases. They are however less optimal when you want to diverge from those use cases and create something new. This is where malleability/modability comes in, and where CLI:s, bash, scripting, programming comes in, and you can't use limited-scope apps for that.
All tools are best at what they were designed for, I agree with you there. I'm however not sure how I in your mind was wrong before. The two are intrinsically bound, but it's undeniable that apps can't exist without tools, but tools sure can exist without apps.
Hell yes. Why does [established practice] have to mean [best practice]?
With all the security concerns and regulation regarding flight, it's easy to imagine how hard it is to move forward and innovate in usability.
I'm not saying upending git for something better would be trivial, but I don't want to constrain my imagination by thinking it's not possible.
If you can coherently explain what you need [git replacement] to do, and explain it simpler than you would explain git itself, then you have an outline of a superior tool.
I'm surprised at how many people are responding negatively to software that improves user experience.
Suppose we had started out with the command UI that gitless has and someone came along and tried to sell us the current git cli UI. It would be completely ridiculed.
The only thing possibly questionable about the gitless interface is that it does away with staging. However, you can always fall back to git for staging functionality if you like, and use gitless for most other commands. I think it is a win.
I think the author address that point in the introduction:
> Experts, who are deeply familiar with the product, have learned its many intricacies, developed complex, customized workflows, and regularly exploit its most elaborate features, are often defensive and resistant to the suggestion that the design has flaws.
Having spent dozens, even hundreds, of hours learning the intricacies of the Git command-line, it must be extremely shocking and insulting when you are told that those efforts were in vain, because the original UI was not very good and an alternative can be grokked by people of varying levels of technical competence with only a fraction of the effort you put into the original thing. I think this is what we're seeing here: people will try and defend their time investment by arguing that a professional would learn the hard thing and not lower himself to easy-to-use tools, that the new UI hides some powerful features that are rarely used, etc.
I think it's a little different from that actually. That's normally about the merits of ongoing financial investment, but I get your analogy and there should be a name for it because you see it all the time from compsci types.
How about "sunk knowledge fallacy" or something like that?
Using artificially complex, unfriendly tools is a form of honest signaling. [0]
Making tools complex and painful, denying their complexity, and scoffing at the very notion of allowing a non-expert to accomplish what before required esoteric knowledge is the way the tribe of self-styled Real Programmers protects its integrity.
> "dumbed down" only improves the user experience of new users. It hurts power users and is rarely useful to anyone other than newbs.
That's only true if the power users perform a completely different group of tasks from the new users, or if the "new user" interface is made wholly incompatible with the "power user" interface.
If the power users still needs to perform the same basic tasks, the simplified and easier interface will likely make those tasks more efficient for the power user as well.
Git is powerful. While the underlying architecture has beautifully simple aspects arguing that the complexity of the git tool-chain is simple is similar to arguing that TeX is simple as it is written in a simple language. Git is managing trees of file-sets in a distributed manner. It took many generations of configuration management systems to get there.
Git is bottom up. Understand the inner workings and you know what you can do. But coming from a user perspective there is a gap - first one needs to wrap ones head around the tool. Git imho. is more a framework than a tool. On Stackoverflow simple questions yield different answers all yielding results but having various trade-offs. Usability is also about orthogonality and looking from a user perspective (not an implementation perspective) Git offers often quite a number of paths getting to a certain goal.
Individuals, teams and tooling all trying to settle on certain workflows enabled by git effectively deciding to use only a subset. Particularly when it comes to teams agreeing on workflows becomes important. Git as a tool is here helpful in the sense that it enables almost everything. But for a team it takes more than agreeing on using Git. Other tools come with more comprehensive practices.
As a tangent, I think calling git a distributed system is misleading. Git is primarily a history manager for a local directory tree that has commands to sync with remote machines. Having to type stuff like
in order to sync is not what I usually associate with a distributed system. The word distributed conjures something that's more like dropbox, where things sync transparently.
"Distributed" means something other than what you think it does. Dropbox is not a distributed system. In fact it is a good example of a centralised system.
Being distributed is essential for gits design. It explains why there are strange sha1 ids instead of incremental revision numbers like with svn, for example.
Very cool. The idea which I liked most, is the ability to switch between branches, even though you still have uncommitted changes. With git, I'm forced to either make an extraneous commit, just to enable branch switching, or stash all my changes into a stack which I may later forget all about. Both of the solutions above are really cumbersome and prevent easy context switching.
The only feature I noticed missing, is the ability to stash changes. I use this most often to move changes from one branch to another branch, without cluttering history with an extraneous commit. How would this work on gitless?
> With git, I'm forced to either make an extraneous commit...
You only need to commit or stash if there are conflicts, and many time there aren't, so you can first try to switch branches without stashing.
> The only feature I noticed missing, is the ability to stash changes. I use this most often to move changes from one branch to another branch
I started a big ol thread on stash yesterday, but there are a bunch of safer alternatives to stash. You never have to clutter history, you can always move things around and still keep it clean. Problem with stash is it circumvents git's normal systems, so it's a little dangerous (which the stash man page mentions.)
If there are conflicts, you could do this instead:
$ git checkout -b work
$ git commit -am "WIP"
$ git checkout another_branch
$ git cherry-pick work
$ git branch -D work
Exact same effect as stash with no clutter left over in the history, and much safer. The advantage here is your changes are put multiple places and referenced by git, so if anything ever goes wrong it's in the recent reflog. With stash, if you have problems, your only option is to use fsck.
Given that the whole point of gitless is to avoid super confusing and intimidating commands like fsck, especially for beginners, it makes sense to me they chose not to include stash.
The whole advantage of stash, the way I see it, is that you don't need to type out a whole bunch of commands to stick something into another branch and deal with remembering where you put it and what you called it and so on.
I started out using secondary branches since that was the intuitive way of doing things, and I had issues with stash before, but after a while I went back to using stash again because it's just so much faster to stash my config differences, do all the necessary merges or pulls or switches, and then just stash pop. A large part of the advantage is that stash is a bit orthogonal to the usual workflow, so it goes in a specially defined place in my brain vs being yet another branch, especially if I already have work/dev/backup branches for other purposes.
I agree that I wouldn't recommend using the stash to beginners, though, it does really odd things at times if you are not clean with it. First time I used stash, I lost all my code and nobody could figure out how to get it back. :P
But that the thing - I never stash crucial code, just things like settings that are special to me and not other developers, so they'll probably never be pushed.
Stash for you is fine, you obviously know what you're doing, and you use it carefully. And if you're comfortable with fsck, you really don't have to worry.
OTOH, the alternative workflows are really not that hard, it's really not a ton of commands compared to using stash. The single most common use case I've heard so far is switching branches, and for that you can skip stash the majority of the time, many people don't seem to know that.
Your example was stash during a pull, if you do that, your workflow is:
Not only is it the same number of commands, and safer, it's also less to remember because you don't have to use the stash subsystem at all. Commit, pull, and reset are commands you have to know regardless, you can't avoid them. Stash isn't one you have to know to use git. Stash is adding to the things you have to remember, or taking up space in your head that could be used to learn flexible ways of making temporary commits & branches.
I don't know if I really know what I'm doing... feel free to correct me if something feels off.
I'm not following your alternative. Did you mean "git pull --rebase"? Because this will result in there being a WIP commit in the middle. I try to pretty much never do pulls like this, I'm in the "rebase everything to smithereens camp".
I don't want accidental merges. I do not want to have to rebase because I got a commit in the middle and it's named funny. And what I also don't want is having to deal with merge conflicts in the rebase or merge in case incoming changes don't like the changes in the WIP commit.
It's a lot cleaner to just not have the stuff in there at all, pull, and put it back on top. (like the stack that stash presents)
Yes, I am that lazy.
This is not really the way I used to do it. An example is just an example, the situations are many. Maybe I want to pull. Maybe I need to rebase my stuff. Maybe I need to switch to another branch to show something to a coworker.
I'd have to make a special branch, commit to it, and then grab the commit hash and cherry-pick that whenever I needed it. Because I would need it in all sorts of different situations. So part of the issue was keeping track of the hash. But the bigger problem was how much work I'd needed to do if I ever needed to bring those changes up to speed again. With stash, I get a merge conflict and I resolve it, and that's my new stash again, I don't even have to do anything. With a commit or cherry-pick, I have to undo it, fix it, commit it, and now manage a new hash.
I find stash easier to manage in my head specifically because it's a separate thing on the side so it doesn't get mixed up with all my other branching. It's very little headspace at this point, and mostly a decision tree in the form of:
- is the staging area empty and I want to start doing work? stash pop;
- is the staging area currently holding my stash changes and I want to do some things with git? stash.
> Because this will result in there being a WIP commit in the middle
No. Your WIP commit will always land at the end. Anything you pull will rebase to before your WIP commit.
Doing a commit+pull+reset will always work exactly as easily as stashing.
It's no less clean to commit & later reset than it is to stash & later pop. The difference is that if you commit you have a bigger safety net than if you stash.
I totally understand that stash feels easier, a lot of people agree with you. But I don't think it's true once you dig down and learn how to not use stash. And stash is more dangerous when something unexpected happens.
Stash is not a general purpose solution. You don't ever need to stash. There is nothing you can do with stashes that you can't do with core git commands, and the reverse is not true. Git could eliminate the stash command tomorrow without any loss of functionality.
What if you already committed your config changes to branch X, and your coworker wants them in Y? What if you you're working along and you have commits, staged changes, unstaged changes, and you need to branch 3 commits ago instead? Stash doesn't help with either of those, and the workflow I'm advocating - just use commits and branches for temporary work - does.
Stash really only helps you if you don't like to commit often, and you spend most of your time with unstaged changes in your working tree. Nothing wrong with that, if that's how you like to work, but I think if you spend some time getting used to committing more frequently you may find it much more flexible and much safer and more forgiving than trying to keep everything straight in the working tree alone.
If you have uncommitted changes in X, and you want in Y instead, then you can:
$ git checkout Y
$ git commit -am "config changes"
If you get merge conflicts, or if you want to keep the change in X too, you can:
$ git commit -am "config changes"
$ git checkout Y
$ git cherry-pick X
The first case is fewer steps than stash, the second is just as easy as stash.
Popping a stash and cherry-picking a commit have the same process if there's a merge conflict, except that with a commit, you have undo capability if you merge incorrectly, and you have a safety net if you get lost or screw up in the middle of the resolution. With stash, you're stuck with a bad merge, and if you lose your stash -- and it happens -- you have to hunt for it by searching for dangling blobs.
You made a big deal out of having to create and remember and lookup hashes, and I don't see that as being an issue at all, and it's not a problem in my experience. You're comparing this to stash, after all, and stash only works on uncommitted changes, so there is never a case where you'll need a hash, because the stash equivalent is always at the tip of the branch, you can always use the branch name instead of a hash.
I didn't call it a general purpose solution in that context, nor did I call it a general purpose solution for everything. I am saying that I needed a general purpose solution for a situation that occurs often in many variants. For my situation, without stash, that was creating a commit and cherry-picking it places. Stash makes that case a lot easier to manage.
I don't use stash for cases where it doesn't make sense. I use stash for cases where, for me, it makes sense. For a special set of config changes that are never pushed. They're not part of my usual work, they're config changes. In this context, your 2nd paragraph makes no sense. I don't have to arbitrarily choose one or the other "workflow", I use both, and I simply use stash for the general case of reapplying configs on random branches. There are other ways to do it but they all require more headspace and are harder to track than stash and stash pop.
I'm not saying I need to stash or that I can't do it without stash. Have you not seen my earlier post?
It has nothing to do with being comfortable with commits. I'm already comfortable with commits. I've even said, before, that I did it with commits. It's just slower to do it with commits, and it means I have to manage commits for something I'll never, ever push. Every time I make something a commit, that's extra work for me later to make sure I don't push it out. If I make commits after that commit it's extra work for me to rebase it.
I don't put things in my stash where I care about a bad merge with them or that I'm even going to bother searching for the blob, I'll just redo the changes if that ever happens, because they're minor. They're things like: "Point to my database instead of the standard dev database". I just don't want to do them by hand every single time and I don't want to track a hash that changes every time I actually do want to change my configs.
You're the one making a big deal out of something, honestly, and you do not seem to be reading my posts very carefully because you're still making a lot of incorrect assumptions.
> You're the one making a big deal out of something, honestly, and you do not seem to be reading my posts very carefully because you're still making a lot of incorrect assumptions.
I'm sorry you feel like I wasn't listening to you. I was, and I read all your posts. You're absolutely right, I have made a big deal out of it. Despite the long discussion, I think we're in nearly full agreement, and FWIW, thank you for engaging.
I did misread your pull --rebase comment. I thought that was sorted now, but I'd be happy to address any other bad assumptions I'm making. It wasn't clear to me until just now that your config changes are small changes you never push. If you stated that before, I'm sorry.
Given your use case I agree with you, this is not an either-or proposition. And anyway, it's perfectly fine to leave all of this as my stupid opinion, and I don't want you to feel like you need to defend your use of stash. You clearly understand the issues and know how to use it.
In my mind, the only thing wrong with stash is how it's implemented, not its interface. I wish it had easier ways to recover, and I bet you did too that first time you used it.
Maybe the funniest part of this is I've been avoiding stash completely for years, but the threads for the last two days have convinced me there are some nice uses of stash that I may start adopting. A couple of them even increase safety! I do keep config changes around, and I like to name them with a tag or a branch, but I'm going to try stash and see if I prefer it.
> But that the thing - I never stash crucial code, just things like settings that are special to me and not other developers, so they'll probably never be pushed.
I don't know if that wasn't very clear.
Nothing wrong with opinions, there's a reason we share them, and I agree that stash could have probably been implemented a better way underneath. I have been recommended to use stash by another developer without any sort of warning, and with the implication that it's really safe and easy to use, which is rather funny in retrospect. Git's documentation page doesn't really talk about the dangers, either.
Huh? I don't get what you're doing there, or why you reset unstaged changes 3 times in a row... If you're trying to get rid of a commit, a single reset --hard will do. But why are you trying to get rid of a commit, and how is this more work that using stash? If you have unstaged changes you don't want, you have to reset either way, this is orthogonal to comparing stash vs no-stash workflows.
> why doesn't "-" work for merge/cherry-pick/reset like it does for checkout?
I don't know what a single dash does for you. On my git, I get a command line error with a single dash. Maybe you were thinking double-dash?
A double-dash is used to separate flags to your git command from path arguments, just in case a file you put on the command line starts with a dash. (Pro-tip: don't name files that start with dashes.) Running "git checkout -- ." at the top level of your repo will do the same thing as "git reset --hard HEAD".
Merge, cherry-pick and reset all work on refs, not on paths, so when you add a -- to one of those commands you may get an error like this:
fatal: Cannot do hard reset with paths
The -- is optional to checkout, if the path is unambiguous. You can reset unstaged changes from your repo root by using "git checkout ."
> Huh? I don't get what you're doing there, or why you reset unstaged changes 3 times in a row... If you're trying to get rid of a commit, a single reset --hard will do. But why are you trying to get rid of a commit, and how is this more work that using stash? If you have unstaged changes you don't want, you have to reset either way, this is orthogonal to comparing stash vs no-stash workflows.
I accidentally made changes while on X when I wanted to make them on Y. I don't want to just "git checkout Y" in case that conflicts. If I do as you suggested and commit them (on X) and then cherry-pick that commit onto Y, I then have to go back to X to remove the commit I made, otherwise I have the changes on X as well.
> I don't know what a single dash does for you. On my git, I get a command line error with a single dash
"git checkout -" switches to the previous branch. Which is great, but it's frustrating that I can't do e.g. "git merge -" to merge the previous branch - logically that should be the same kind of thing.
> "git checkout -" switches to the previous branch.
OH, that's very nice, I want that. Guess I need to upgrade my git. Okay, that invalidates my entire previous post. Sorry! ;)
So, if you made changes on X but wanted them on Y...
The thing about the "git checkout Y" is that there's no harm in trying, and it'll work most of the time. If it does work, you only have to commit, and you're done in less time than it takes to stash & pop.
If you're just not the gambling type, here's one way to avoid branch ping-pong. I'm sure there are others.
$ git checkout -b Z
$ git commit -a "config changes"
$ git checkout Y
$ git cherry-pick Z
$ git branch -D Z
I admit that's a tiny bit more work than with stash, in this case, but it's safer than stash, that's why I prefer it and advocate it. It is demonstrably harder to screw up if bad things happen in the middle. This workflow is also more general - you can use it if you have commits in X already. Stash doesn't help you there.
I've personally witnessed too many stash accidents. BUT, if you are comfortable with using fsck if anything goes wrong, you really have no reason to consider my opinion at all.
I'm painting a picture that is more anti-stash than I actually am. My main safety concern with stash is how it's implemented, not how easy it is. The git authors could have used something like the above commands under the hood to implement stash, but they chose to circumvent the reflog for reasons I don't know, and that choice leads to frequent accidents. Git is supposed to be your safety net, not something that gets you into trouble.
That said, a lot of people seem to think stash is many times easier than the alternative, and I think if you really look at the alternatives fairly, using commits is most of the time not more difficult than stash, and occasionally one or two extra commands. It's just not that hard to avoid stash, and there are significant benefits.
What's the way that one screws up with stash that doesn't happen with other approaches? I don't think I've seen stash accidents, though most of my colleagues don't seem to use stash much. If an attempt to pop conflicts, can't you just abort it?
I wish git would deprecate stash and replace it with something like this, that doesn't have any magic and just uses the existing branch system.
It would generate a new temp branch every time using a counter system, e.g. "stash1" "stash2", so all the temp branches effectively form a stack. The stash popping behaviour can still be supported this way (popping would cherry-pick and delete the highest numbered branch).
It would be easy enough to script as a side project too.
Yeah, exactly. I don't understand why stash wasn't done this way. They didn't have to circumvent the reflog, it was a choice, and one that bites a lot of people.
> You only need to commit or stash if there are conflicts
Unless you're wanting to take a look at the other branch clean, then you have to stash or do the extraneous commit. Most of the time I change branches to check someone else's work, or compare something that isn't working to develop/master. The stash/commit dance is a regular annoyance for me
This is true, you have to stash or commit, if you want to go to another clean branch.
But, your code is going to be committed & rebased later in your own branch anyway, right? If you commit some partial changes & later come back, make some more commits, and rebase/squash before pushing, you haven't done anything extra you wouldn't have done anyway.
By stashing, going away, then coming back, popping, working, committing, rebasing & pushing, you've added extra steps to the general case by involving stash, and you've added an extra failure point. If you commit instead, your changes are already there when you come back, and they stay associated with your branch while you're gone. It's harder to forget what you were doing, and it's much harder to lose your work accidentally if you commit.
I've witnessed the exact scenario you describe go bad several times when people go code review or test someone else's code, and the forget what they were doing. Sometimes people will stash again while working in someone else's branch, making it hard to keep track of which stash is which. That can lead to accidentally dropping stashes, or to popping the wrong stash.
Try only using 'git commit -am "WIP"' as a git stash replacement for a while and see if it really is any harder than stashing. To uncommit a WIP commit (which is always optional -- you could wait until you rebase -i) just 'git reset --soft HEAD^'.
gitless gives each branch its own separate worktree (see `git worktree`), and saves/restores them when you switch branches.
Also, there's no harm in creating "temp" commits. If you are having multiple branches, you probably want to give your current state a name - which is what a "temp" commit is.
Perhaps m3kw9 means that if there's something that you can't do in Gitless, you can fall back to the Git way of doing it, since both use the Git plumbing.
> Both of the solutions above are really cumbersome and prevent easy context switching.
Too frequent context switching might actually be perjudicial for your productivity and health, while increasing stress levels. So git not making it trivial might not be a bad thing, in my opinion.
To me the really bad thing about git is its command-line interface.
It has extremely verbose messages (writes out a lot of stuff that you don't need to know) and common use cases often requires multiple steps (ie. add, commit, push if you just want to send a change from your work machine a github repository).
Compare this to subversion which is much less verbose, and in general just have one operation pr. use case.
Not sure why this appears to be been down voted. Git's command-line interface IS terrible. Certainly not unusable as most of interact with it every day.
A somewhat satirical example of this is Steve Losh's Git Koans.
That's not to say I don't think the underlying ideas of how Git works makes sense. I certainly think it's a lot better than RCS, CVS and SVN (never tired Mercurial).
I realize that Hacker News generally frowns on "+1" types of comments. But those Koans are really funny. Every single one made me laugh out loud. I remember the pain of git.
I hated git. Every time I used it I wanted to curl up in a soft, warm, dry space... like Perforce or SVN.
I disagree. It's one of the best command line tools I've seen. It detects errors, gives you suggestions and you can get along with a few basic commands. Yes, there are multiple steps, but that's okay because it can't figure out your intentions.
Look: http://imgur.com/xY8dKWD no verbosity here and this is 99% of my git workflow. Working in a team is more tricky, but you should use and IDE with built in git support.
If you want to see a bad command line tool, try FFMPEG.
This is not objective. Git CMD has terrible flaws that are easily spotted as soon as you start teaching git, because you can see people struggling on difficulties purely created by a bad design.
As a professional trainer, here are the most commong problems:
- git checkout does so many different things. Git check file, git checkout branch, git checkout commit all do different stuff, and don't get me started on the option flags.
- git is context dependant. If you don't know the context, espcially the state your repo is in, you will struggle. And nothing in the tool gives you enough context if you don't explicitly ask for it, which supposes you need to know you need it, and what "it" is.
- branch switching is a hard. see article.
- stashing is dangerous. I've seen many students loosing work with a stash pop requiring a merge which ended badly.
- the whole syntax is impossible to discover, even for very common tasks: git checkout HEAD^ /file/path, git rm --cached, etc.
- git assumes you know what you are doing. Which means it let you destroy history with rebase, loose stuff with stash pop, create detached head, make force push, and all it all put yourself in many situations a beginer won't understand, and above all won't need.
Now I don't blame git designers for those. They made the tool they wanted to use.
What we need is a good UI on top of that. It can solve 99% of those problems.
The github one is not so bad compared to all the ones I tried (yes I tried yours), but it's still not it. What you need is someone that look at the most done tasks and questions, and provide safe, fast buttons for that.
> - stashing is dangerous. I've seen many students loosing work with a stash pop requiring a merge which ended badly.
Yes!! Stash has a problem that it's attractive to beginners, and its easier than other commands to hose yourself. It's a separate system for managing changes outside of commits, I don't get it. They could have made shortcuts to branch & commit. Mystifying.
> What we need is a good UI on top of that.
Srsly. But, wouldn't having a consistent & clean command line interface enable that? I haven't seen a good git GUI yet, they are all crippled because they stick to git's terminology. None of the UIs have been able to escape the foundation of the git command line, and I'm starting to think it's not possible.
> Yes!! Stash has a problem that it's attractive to beginners, and its easier than other commands to hose yourself. It's a separate system for managing changes outside of commits, I don't get it.
It isn't a separate system "outside of commits". Stashes are literal commits. If you were to write a script that made little WIP commits it would probably end up looking a lot like git-stash (which is literally just a shell script wrapper around other git commands).
> - stashing is dangerous. I've seen many students losing work with a stash pop requiring a merge which ended badly.
I've seen this assertion before, I don't understand it. If `stash pop` has conflicts and it gets confusing, you can always just `git reset --hard` and `git stash pop` again. The stash does not disappear if there are conflicts.
The only time you can lose data is if you explicitly `git stash drop`. So don't do that. And even then, the data is sitting in the git repo and can be recovered with `git fsck`. It's really hard to lose data with git.
Having just been in this situation, I think you are missing the problem. The problem is that after "git stash pop" has conflicts, the user does not know the state that of the system, and thus does not know how to react.
In my case, I temporarily changed a number of tracked "build" files that are custom my system and that I do not intend to check in for others to use. I was then asked to test a branch that someone else had checked in. My desire was to stash my local changes, check out their branch, and reapply my local changes to build it. But after "git stash pop" failed I had trouble figuring out the state of the system. I couldn't make any sense out of the messages that appeared, and fell back on Googling for answers.
My expectation was that the stash would have been popped, that I would open the build files, find some lines about merge conflicts, that I would manually fix them in an editor, and then I would rebuild. Instead, it does "something else", and hard part was figuring out what that "something else" was. There are probably excellent reasons for the exact behavior, but I'd ask: where is it made clear to the user what happens when "git stash pop" experiences conflicts? Where does it say to do what you suggest?
Separately, if you happen to know, how should I best deal with this personally frequent situation that I have a small "patch set" that I want to be able to apply to arbitrary branches, but that I have no intention of ever making visible to other users? I'm sometimes tempted to fall back on "git diff > patch.local" and manage it manually, but there must be a better way.
In particular, git violates the universal *nix convention that you can operate on a file using a full or relative path regardless of your current directory.
>git checkout does so many different things. Git check file, git checkout branch, git checkout commit all do different stuff, and don't get me started on the option flags.
I'm curious, how would you redesign git checkout to handle each of those different types of inputs? For me, while it appears cumbersome, understanding that a file is different from a branch and commit head seems to alleviate this problem.
Let me just start by saying that while gitless seems fine, it tries to hide the index and thus encourages bad habits in git users.
The index is by far one of the best features git has in comparison to other VCS, and trying to hide it because it can be confusing to users is doing them a disservice.
EDIT: editing this to expand on why I think the index is essential:
Being able to use the VCS tool to fashion a commit separately from what is in the worktree allows you to create changesets that make sense, instead of them being "this is what happened". Exact history is not interesting, it is the logical progression of the codebase (via changes applied to it) which really matters.
Furthermore, when resolving conflicts, the index is extremely useful because you can work through a conflict (which often can span multiple files) piece-by-piece and easily tell whether you've already fixed everything, run diffs on what's resolved and what isn't, etc. I find myself missing the index whenever I need to do anything nontrivial with other VCS (which is most often Subversion)
I've seen some people argue that they don't want to commit something that has not been tested, but I don't understand this argument. Why would you test something that isn't committed? Committing (or even pushing) something does not mean the code is instantly in production, but it means you have an unambiguous way to refer to what is being tested, instead of whatever state your worktree and system happened to be in. How could you be sure you're really testing what you will be committing?
Certainly, creating separate commits after-the-fact can cause commits where the tests don't pass, but it's up to you to decide whether the merge points are what should be tested, or each individual changeset.
Let's go through that list
- git checkout does one thing: it updates your worktree to match whatever you want to check out, be that a commit, a branch (which actually is just a named commit) or a file in a branch. Why is this difficult for beginners, and how would you refactor/name the operations so that they make sense?
- I'm not sure what you mean with context-dependency. Obviously it's context-dependent in that your worktree and repository may be in a state where certain commands do different things eg. because they have the current checked out branch as an implicit parameter. I don't think it's at all different from most other VCS
- I'm not sure I'm convinced by the article's argument that branch switching is hard, but I guess I'll grant that.
- Huh. I don't use stash that often, so this is a maybe. Teach people to use stash apply instead?
- git rm --cached is weird, but mostly because git can't choose just one thing to call the index.
- You can never accidentally destroy history with a rebase. Nothing short of manually wiping files destroys history in git once something has been committed. I don't really see why detached heads would be a problem (just create a branch?) and if you force push, you're basically telling git "I know what I'm doing, shut up" in which case the tool doesn't assume you're an idiot and will do what you want. You can't call it bad UI when you explicitly have to use a --force flag to do potentially destructive things. Not being able to do it at all is worse.
Really though, other than minor gripes with terminology and maybe sometimes confusing command line switches, what is a good (hypothetical) UI for git that doesn't just ignore all the good things?
> The index is by far one of the best features git has in comparison to other VCS, and trying to hide it because it can be confusing to users is doing them a disservice.
I can't disagree more. The index is entirely unnecessary, as umpty thousands of happy Mercurial users can testify.
> Being able to use the VCS tool to fashion a commit separately from what is in the worktree allows you to
... record states which never existed, and haven't been tested. It's an antipattern. If you are doing this a lot, you are doing development wrong. In the rare occasions where you do want to do it, Gitless and Mercurial, like every other source control tool, give you a way to fine-tune the set of files which go into the commit. They don't need an index to do it.
> Furthermore, when resolving conflicts, the index is extremely useful because you can work through a conflict (which often can span multiple files) piece-by-piece and easily tell whether you've already fixed everything, run diffs on what's resolved and what isn't, etc.
Again, you don't need the index for this, you need to track conflict state. As Mercurial does:
> I've seen some people argue that they don't want to commit something that has not been tested, but I don't understand this argument. Why would you test something that isn't committed?
This is a very interesting perspective! It doesn't immediately sound immensely practical, though. Say i want to test a fraction of the current working tree's state; i commit, and then ... what? Create a fresh clone of that state somewhere so that i can run tests on it?
Sure you can make do without the index, that doesn't mean it's better not to have it.
I personally don't feel comfortable with mercurial, but that may be because I don't understand it. It's been a long time since I last touched it, but I remember thinking that the way it does branches was just needlessly complicated and cumbersome. Why does closing a branch even need to be a thing?
> you don't need the index for this, you need to track conflict state
This is what the index does. You don't need the index in mercurial, because you have something that is like the index, but not called the index.
Maybe the UI is better because "add" is called resolve, but that is really just an alias away.
> and then ... what?
Then you push it to remote somewhere and a CI system runs tests for you. Maybe you can do something productive in the meantime.
If you're just testing locally, then there's little difference, but I would still prefer testing a committed state, knowing it's safe in the repository and I can't clobber it afterwards.
> it tries to hide the index and thus encourages bad habits in git users.
I'm curious what you mean by this. What are good & bad habits wrt the index?
It makes sense the index is there for conflict resolution, and it seems really convenient for interactive adds & rebases. But I could imagine implementing those things without having an explicit staging area. Are there other more important requirements for the index? It mostly seems like a convenience that it's exposed, but not something that provides either more safety or better practice.
Many VCSs that predate git don't have an index because they don't need one, and having one wouldn't encourage better habits. Git has an index and rebasing almost entirely as a result of it's strict enforcement of lineage, which older VCSs didn't have. In Perforce you can create and manage multiple changes before you push, and you can push them in any order. Because git enforces order, it basically needs rebase and an index to make using git sane. In that sense, these things can be seen as a UI disadvantage over other VCSs. Of course we know there are much bigger advantages that come with strict lineage, so we learn to stage, rebase, etc.
What other benefits does the index provide that I'm missing?
> stashing is dangerous. I've seen many students loosing work with a stash pop requiring a merge which ended badly.
`pop` will no longer drop the stash if there is an error applying it; it did in the past.
There is a point where it is worth having at least one person on a team study the internals of Git vs. struggling with it constantly and possibly losing work---it will save time, energy, and work in the long run.
In the stash case, `git reflog` would immediately allow you to recover the lost stash. If you're in deep shit, `git fsck` is valuable until the commits are GC'd. Even if you don't remember the commands, you'll know where to look for them, or what to search for to find it. Or even understand that it's _possible_.
> nothing in the tool gives you enough context if you don't explicitly ask for it, which supposes you need to know you need it, and what "it" is.
There are numerous PS1-augmenting scripts available; git even comes with one. But I agree that it otherwise would be incredibly frustrating for beginners.
> branch switching is a hard
I've heard many criticisms when watching others learn Git and teaching others, but this is one of the only things that never comes up once they've done it a couple times. Stash and switch. Or commit WIP and switch.
> the whole syntax is impossible to discover, even for very common tasks: git checkout HEAD^ /file/path, git rm --cached, etc.
I learned pretty much everything I know about Git from experimentation and, most importantly, the manpages. If someone is unaware of manpages, the documentation is online. Failing to read is failing to discover, yes.
> git assumes you know what you are doing. Which means it let you destroy history with rebase, loose stuff with stash pop, create detached head, make force push, and all it all put yourself in many situations a beginner won't understand, and above all won't need.
Yes, this is fair. But also essential. I have recovered from more fucked situations that I could have imagined, and have helped others do the same---situations where I would have otherwise lost work.
But it's a matter of teaching someone fallbacks. If you accidentally screw up everything with a rebase on <branch>, `git reset --hard origin/<branch>`. If you can't remember that, open tig / gitk / a web interface / etc, find the hash, and reset to it. If you are on a detached head, check out a branch. You shouldn't be force pushing, but that's nothing the manpage can't help with.
It all comes back to the basic understand that nothing is ever deleted in Git until garbage collection. There is always a hash to recover. Sometimes I just lazily scroll up in my terminal and grab it.
But your first point:
> git checkout does so many different things. Git check file, git checkout branch, git checkout commit all do different stuff, and don't get me started on the option flags
Yes, this is unfortunate.
tl;dr: Research your tools! Poke around the manpages or online. Know what you don't know so that you know where to look later. And there is always e.g. gitk to fall back on for certain things---I see others on my team do that as well.
This is a great post! I have only one minor point:
> In the stash case, `git reflog` would immediately allow you to recover the lost stash.
Stashes don't go in the reflog, you cannot recover them with git reflog, so you're automatically in the 'deep shit' category if you lose them. Hence the statement that stashes are dangerous.
You do still have the safety net of fsck, and knowing that it's possible matters, as you point out. But, my experience with people who mess up stashes has been that fsck is so intimidating they'd rather re-create their changes. Silly, but true.
The thing is, once you learn the UI, it's very productive. I'm not sure we should be optimizing for ease of learning. People are only beginners for a little while. They spend much more time as intermediate/advanced users.
This really depends on how frequently and how deeply you use git. If you're using many of its advanced features a lot, then yes, you'll probably learn it well just by doing that.
But many people don't use it very deeply most of the time, and only occasionally have need to do something out of the ordinary, at which point it can be a pain to discover the Right Way to do what they need, and easy to shoot themselves in the foot.
Ffmpeg isn't a tool. It's a library to be used by programs who work with video and audio files. It has lots of features because different applications need different features.
The ffmpeg command line program is basically a demo that exposes every one of those features directly. Having it "do less" would defeat the point.
Not really, while I'm not sure what 50% of that means, it's just reassuring that after push I see that 5 lines and a percentage counter. I can also copy the commit hash and refer to it in a ticket.
The first 5 lines in that image could be replaced with a simple progress bar and no one, except for git developers, would lose anything worth keeping. That stuff in a normal CLI tool would only pop up if you use --verbose/-v, it's almost irrelevant to the average user.
It's simplicity and ubiquity are the only reason we keep seeing absurd programs like Gitless put forth. Imagine if someone came out with someone that "fixed the warts of QT" that was just a wrapper around QT. It's a joke.
It's coffeescript vs javascript all over again and we saw how that played out.
Don't like how git works? contribute. Don't make some stupid command line utility that just adds another entire layer of abstraction on top because people don't want to take an hour to read about git internals.
I tend to agree with you that most people don't need that power but I think the problem is just that it IS a CLI interface, not that it's a particularly bad one. A GUI is the perfect tool to deal with discoverability and providing an easier interface for non-technical users. A CLI wrapper is just making things more confusing. I don't really understand what problem gitless seems to be solving...
I disagree; `hg` is a CLI as well, but it's far simpler and safer than `git`. That said, I have far more experience with git than hg. Further, gitless itself is a cli, and it's also simpler than git.
If simplicity was the goal of command line interfaces they wouldn't exist. This is not ls or cat, nor is it trying to be. hg might have a better CLI than git, but it still doesn't justify something like gitless.
You need a really compelling reason to layer another level of abstraction on top of git and from what I can tell, having branches be full sets of working files isn't really a good enough reason to make that switch.
Where are the improvements in Gitless exactly? Pretty telling they don't even list them in anywhere.
If you understand these, then three stages to "commit to server" won't seem too many to you. (Often you don't need the index-building stage ("add"), and then you can say "git commit -a").
What people complain about is often the CLI's inconsistency. For example "git branch -d" vs "git remote rm" to delete things. Then some things you want to do can be achieved with more than one sub-command in totally non-obvious ways. And some sub-commands do more than "one thing", like "checkout".
I think you should learn them, but ideally it should be obvious from using a tool what its internal data structures are. For persistent data structures simplicity, transparency and stability are very important.
Common use cases require multiple steps because that's how it's meant to be. Staging (adding), committing, and pushing are three fundamental operations of Git that, when combined in different ways, produce many use cases. Personally, I would rather have these operations exposed to me rather than having to memorize (or worse, have to search up) a different command every time for each use case.
My pet peeve is how many steps it is to resolve a merge conflict on a branch I've pushed when were using controlled merges into dev branch. Stash or commit my work on the new feature branch I've started, then switch to dev, then pull, then switch back to my old conflicty feature branch, then merge from dev and resolve the conflicts, then push, then go to the server and complete the merge, then switch back to my old stashed branch so I can get back to work.
I don't see why each developer should. I'm perfectly fine with commands as they are by default.
I'm just saying that if your problem is that you need to enter multiple commands instead of one, then instead of new VCS you may as well just put a config file in your home dir.
I've been using git for a few years, and often wished I could eliminate the staging area. It's an extra step for every commit, and creates extra complexity for no benefit I've been able to see. I haven't seen a practical example of a use case that's improved by having separate add and commit.
By your statement, I also completely misunderstand git. That's entirely possible, but if git is so hard to understand that daily use for years doesn't lead to understanding, maybe it's ok to misunderstand git.
> I haven't seen a practical example of a use case that's improved by having separate add and commit.
Well, I frequently see random things to fix while I'm working on a problem.
When I 'm ready to commit, I run `git status` and notice there's a file that's been modified that's unrelated to what I'm trying to commit.
A quick `git diff` later and I see what I did: fixed an unrelated issues. So I add that one file to the index, commit it with a relevant commit message, and then proceed to do a second commit—the one I had expected to do—also with a relevant commit message.
>there's a file that's been modified that's unrelated to what I'm trying to commit
What if those unrelated changes are in the same file as a bunch of related changes that you've already made? Do you undo all the changes you've made in that file apart from the random bug fix and then commit, or leave them intact resulting in that bug fix commit containing changes that are unrelated to the fix?
In that case you'd want to use "git add -p" which allows you to pick only parts of a file to stage for a commit. It can be crucial in crafting a really solid project / commit history.
For even more complex cases you could use "git add -i"; however, that command can be tricky to work with and I find it's usually not to helpful to get that far into the weeds.
I've been using git professionally for a few years, and other distributed version controlling systems for more than a decade. This is the first time I see the phrase "staging area" in relation to VCS. Could you explain why it's an important concept?
I don't see any improvement over git. Just another set of commands you'll need to learn from scratch. Some ideas seem not very good, like committing all changed files by default. If you find git commands too verbose - try 'tig' - the ncurses git client, it saves a lot of time and efforts being simple and straightforward at the same time.
In my experience, making "gl commit" equivalent to "git commit -a" seems like a bad idea. When leading a team, especially of newer coders, one of the most effective ways I've found of keeping the git logs and the code base sane more generally, is to force people to review their own code at the time when they commit it. Individually adding each file with "git add -p" achieves this, and "git commit -a" squashes it.
Reading the methodology used to develop gitless yesterday was interesting, but if I recall correctly, I think it left something out. They looked at how often a software design allowed users to complete their intention, but the tool ideally not only should allow users to complete their intention, but should encourage users towards practices that increase the quality of the end product. While people may struggle with staging at first, I think it in the end encourages better software, which is my biggest concern.
I am also pleasently surprised by this initiative.
I consider myself an advanced git user so I am not sure I would use it myself, because my brain is hardwired to git's wicked commandline interface now. There is little that surprises me in git nowadays.
I am used to give out simple "the 10 git commands you will ever need" tutorials to people, but it's true that it is confusing for people, even with that. gitless takes out significant confusion out of the daily grind of using git, so much that I may end up recommending it instead of git itself, especialy since they are interoperable.
What I would love to see would be to have those commands percolate back into git itself. git's usability has improved significantly since it started, and while this project shows there's still a lot that can be improved, history has shown us that git can be improved. track, untrack, history, switch, resolve, publish, init's remote argument, all those could be added as commands into git and equivalent commands could be deprecated or just kept for the hardcores like me that don't want to be bothered learning a new simpler interface.
Unfortunately, given the reaction on the mailing list, I am thinking this will not/never happen and gitless will remain a friendly fork: http://marc.info/?l=git&m=147527432403442&w=2
Posted this upthread, but here's an apt Linus quote:
> The first Git For Dummies and Git Visual Quickstart books are going to be out in a couple of months, and that is the beginning of the end as far as I’m concerned. Those books mean the end of git expertise and github reputation as reliable indicators of geek status. Once a technology is adopted by the masses the extreme geeks find something more esoteric. Look at what happened to Ruby on Rails. The people stumbling their way through Rails to-do list tutorials have never even heard of DHH.
That sounds like a very elitist approach. So the technology is good as long as it's arcane, but as soon as it becomes mainstream then it's "the beginning of the end"?
...do we even need a "reliable indicator of geek status"?
My criteria for whether an interface to git is truly easier is whether artists can use it. I've worked in games alongside artists, with everyone using Perforce. At some point we switched to Perforce for the art, and git for the programmers, with a big janky glue system in-between.
Git couldn't really handle all the binary assets, and the artists couldn't really handle git, so it made sense. When we switched, it also took a long time before the programmers could really handle git too, fwiw.
I've long said I'd love to see something that's as nice a GUI as p4v, but with git under the hood. I haven't yet seen a git GUI that even approaches now nice p4v is, and git on the command line, once you learn it, is the best interface to git hands down.
I can't tell, but does gitless look like it could make a simpler gui to anyone else? I love the idea of gitless, I'll have to try it, but I get the sense that I'd end up needing to switch to git for some things.
As far as version-controlling art, I'd lean towards a system where checking a file out locks it from any other concurrent modifications. Unfortunately, trying to merge concurrent changes into an image file, for instance, is just about impossible.
It's almost as bad trying to work with MS Office file types - I wish I could get people on my team to use something else that is more VCS friendly, like HTML or Markdown, but that's an uphill battle. Even better would be if we actually used the versioning and collaboration features that are built into some of the tools like Office 365 that we pay for, but can't seem to leverage...
My wife is a math teacher and trying to figure out a good workflow for her team has been illuminating. Only the one true desktop Word has a good formula editor, so they have to use that... and only SharePoint provides a good "open and save" workflow. So SharePoint it is. Anything to get them off timeshares.
Yeah, exactly. Perforce has file locking, and the need to file-lock binary assets is a great example of why a central server setup has advantages over a DVCS in some cases.
The alternative to file locking could be a rule set for who or which branches win when there are conflicts in binary data. Then again, as an artists you would rather know if someone's touching an asset before you dig in. With art & binary assets, it's more important than with mergeable code that your team and work is properly organized in a way that avoids multiple people touching the same file.
I have. I've used all of the git GUIs. None are as good as p4v as far as a GUI goes, and none are particularly usable by artists. Especially powerful in p4v is the timelapse view, which nothing in any git client comes close to approaching.
I recently switched to GitKraken from SourceTree. SourceTree has better features and workflow, but SourceTree performance is very VERY terrible. I'm talking 2+ minutes to wait for some operations to complete.
Not sure why GitKraken makes it so hard to add remote repositories and doesn't allow auto-push, and other niceties. But I use it for normal checkin / branch switching workflows and it's great.
I think there will be a very small subset of developers who are confused by the Command Line Interface of Git, but not confused by the Command Line Interface of this thing.
Sure, there are tons of developers who find Git confusing. But the solution they're looking for is something like Git Extensions that removes the silliness of memorizing and typing a bunch of commands in to a terminal. In terms of Global Confusion Index, this only drops us from 98 to 97.
A simple GUI version of this same concept would seem a much better plan.
It does seem in some ways similar to Mercurial, but changes things which both Mercurial and Git share (like having to resolve tracked modified files before switching branches/bookmarks). I think if you want to make a fast and simple interface though, you should go a step further towards gui (like https://github.com/xixixao/hg-sl-up ) and remove the concept of branches/bookmarks altogether (I stopped using bookmarks in mercurial). The repo is just a tree of changes, I already tag it with commit messages, shouldn't need to tag it again with branch/bookmark names. Would love to be able to leave the commits in WIP state though, that would be super convenient (shelving sucks).
While in theory I appreciate what pijul is trying to do, I'm not going to plug it until it at the very least self-hosts. Two years in, still not there.
git and hg are somewhere between Subversion and Darcs/Pijul. You kinda deal with individual patches (commits) but not quite as prominently as in Darcs/Pijul. It's all a compromise, and even Subversion gained merge features, leaning more into the git/hg realm. Tracking patches has huge advantages, especially in open source work, whereas it's not really needed if you just commit to master/trunk all the time and merge with a tool and not by tracking patches. Darcs and Pijul are what would be a perfect fit for the patch queue model used by kernel maintainers.
> You kinda deal with individual patches (commits) but not quite as prominently as in Darcs/Pijul.
Darcs patches and git commits are markedly different. A git commit is a snapshot. A Darcs patch is a set of changes (that is, the difference between two snapshot). Any similarity necessarily comes from the ability to recover a snapshot from sets of changes, or deduce a set of changes from two snapshots.
As far as I know, subversion only deals with a linear history. Its way of doing branching and merging is necessarily a kludge on top of this: branching and tagging actually perform a copy. Which explains the original difficulties with merging: a mere copy makes it harder to recover the most recent common ancestor required for a 3-way merge.
Ah, such a misnomer: you don't cherry pick a commit, you cherry pick the patch that lies between the selected commit and its parent.
It may feel like nitpicking, but it's quite important when trying to understand the differences and commonalities between various version control systems.
Huh? That command just turns the working copy into a commit, and mark it as the unique descendent as the commit currently pointed to by HEAD. Worst case, you just created another branch (happens if HEAD happens to point to something other than the last commit of an existing branch).
You wouldn't happen to try and save the state of one branch in the working copy, then using that working copy to update another branch, right? That's just asking for trouble: done naively, it'd cancel all changes made in that another branch.
If you know anyone who did this kind of mistake, do them a favour and explain the difference between a commit and a patch.
Oh my, I was confusing git commit -am with git am. Didn't know about that last one.
Knowing that, it is very strange that the two methods should yield different results: the patch file is supposed to rely on a parent commit that should be accessible on the local repository, just like a local series of commits. That somehow the associated info/environment differs indicates there's a bug somewhere —or at least yet another poorly thought out corner of the UI.
I can't find anything in the manpage about git-am checking the patch file's parent(s), but a patch file is accepted by git-apply as well, and then it's certainly not expected to consider a parent. That said, I've had git-am fail while git-merge or git-rebase would do the right thing, so git-am is probably, judging by the docs as well, not taking the history into account. If it does and I forgot to tell it how, I didn't know what options it is.
Whenever I start a blank new repo nowadays, I do a
git commit --allow-empty -m "NIL"
See, many git operations require a parent reference! For instance if you want to interactively rebase the top commit, it's actually "git rebase -i HEAD^": rebase back to (but excluding) HEAD's parent. The equivalent "git rebase -i HEAD~1" means the same thing: that ~1 actually spans two commits: it refers to the parent, but since the parent is the excluded delimiting endpoint you can think of that 1 as being the number of commits being rewritten.
If all you have is a single commit with no parent, you cannot rebase it.
If you have NIL there, it takes the HEAD^ reference; no problem.
Essentially, git is a list manipulation system whose use cases fail when operations span the entire list, oops. You can tell it was designed by someone who never took a Lisp or Scheme course (or forgot all of it). Imagine if (remove 3 '(1 2 3)) failed because the suffix (3) has no CDR, haha. "Sorry, you can't "rebase" your (1 2 3) to (1 2) because 3 is the "root commit"! Just scrap the whole thing and build (1 2) in its place."
FWIW, Mercurial has this - there's a notional changeset called 'null' whose hash is all zeroes, which is the parent of every changeset which does not have a real parent. As a result, you can rebase a root changset. For example:
> If all you have is a single commit with no parent, you cannot rebase it.
Well, of course what you want to do here depends. You can squash onto it, edit it, or reorder it. You're commonly going to have conflicts if your first commit created a file and the rest edit it. If you reorder you can't edit a file that doesn't exist yet.
I meant, "what are you setting out to do?" as in "I'm trying to reorder commits" not "I'm trying to `git rebase -i commit`" (the ultimate aim, rather than the path you choose). My instinct is that you can get where you want to go fairly easily with the `git rebase -i --root` I mentioned earlier.
If you plant a NIL commit in your repo before doing anything else, and tag it as NIL, then absolutely all git commands that take a ref (including ones you don't even know yet) will Just Work without any special arguments or modifications for the root case. You don't need to memorize yet more special cases for yet one more corner case in git.
In existing old repos or other people's repos that do not have NIL, I don't need it, because I won't be rewriting their history (let alone all of it back from the empty state!)
It's handy, when a repo is brand new, to be able to massage the newly created master branch using the same workflows that are rehearsed daily, rather than special cases.
When people say they don't like git, I lose a little faith in them as a programmer and/or engineer. This is probably due to my own biases of having worked with folks that just don't want to invest the time in learning it. That or they are afraid of branching/merging. To me this indicates intellectual laziness which isn't the kind of laziness that makes a good programmer (as is with the quote from Larry Wall and the kind of laziness he speaks of).
I work with a whole bunch of scientists that program. Some mathematicians, some theoretical physicists. We run into git issues more often than we should.
It's lazy to blame git issues on intellectual laziness. Any human designed system can be learned with enough effort but in git there seems to be significant superfluous effort. Effort that probably makes sense for some use-cases that git was developed for, but as it has become ubiquitous and now we all have to live with it, programmers or not.
In my view, git has too much state. The state of my directory, the state of my branch, the staging area, the stash, etc.. these all interact in non-trivial ways when merging/branching. Gitless shows that it can be done with less state.
It's really not though. And posting articles that pretend like "git rev-parse --abbrev-ref HEAD" is the best way to view what branch you're working on just makes you look dumber than you do for acting like git is difficult to work with. If people writing blog posts about "how bad the git interface is" and more time instructing newer programmers (the only ones who have any reason to complain about git) on how to correctly use the tools maybe we wouldn't have to hear so much whining about the tool.
Anyone who has been in the field understands that for all it's tradeoffs git is an incredible breath of fresh air from systems like CVS/SVN.
That's not an argument. Especially vis a vis the detailed reasoning behind gitless. In my view gitless has a superior experience without losing any power.
Also no one is comparing git to CVS/SVN. It can stand miles above these and still have severe usability flaws.
It's not an argument because that Koans article is horrible satire that people are trying to pass off as a legitimate argument. I detailed in my post one direct example as to why that post shouldn't be taken seriously.
Now, if you have some legitimate gripes about git's usability I'd love to respond to them and have a real discussion, but Gitless doesn't make those arguments, it's just a wrapper around git (which could all be done with aliases) that adds an additional layer of abstraction for no benefit (or at least none that they've felt confident mentioning)
It wasn't entirely obvious what you were responding to in my post exactly. That article is satire, but if you don't even want to accept that maybe the git commands are badly named (and besides your one bad example, there are plenty of real examples in the satire) I don't see much point in having a discussion.
It being "just a wrapper around git" is an excellent argument that the user interface and usability are problematic. Nobody is arguing with the mathematical model underlying git. Gitless manages to expose a lot less state by default. That's a usability win. It's still there when you need it. There is no expressiveness lost. I find the examples they give on their website very persuasive:
Thank you so much for posting that pdf, that really should be posted somewhere on that site because without the context just throwing out "it's git without a staging area" seems like a pretty poor argument. After reading the whitepaper I would still say that I'm not sure there's much value in the project, that being said they did manage to simplify the "mental model"... although honestly not by much. I'm not sure the cost is worth the benefit here.
No problem, BTW, in my mind it's getting rid of the (need to) stash and improved management of untracked files that are the major simplifications, not staging.
In my workflow I also see no cost, but I am happy to accept that that's because we don't have very sophisticated needs.
Is there a gentle introduction, comparable to hginit.com for mercurial? When I first started version control I was trying to choose between hg and git. The site hginit was huge for getting me to swing towards hg.
Atlassian has put some great "mind abstractions" on top of git to help people understand how to use it.
It's definitely fashionable these days to hate on complicated tools. I wonder if the same is true in other professions. Simple tools are easy to use, yes. But anyone who as worked on a Bicycle or other equipment that requires specialized tools knows that the having the correct, often more complicated tool beats the hell out of wacking on it with the wrong type of wrench.
Software allows a better abstraction of a problem than anything in the mechanical world. Progression in software craftsmanship has shown us that powerful functionality can be hidden behind a simple interface, if sufficient thought and design is put into it.
Our expectations of how we interact with software have risen over the years, and that's a good thing.
Right tool definitely wins. Mecurial is excellent, though; it solves all of my problems. But I feel like I should at least know some git basics. And I want to start at the simple beginning just in case I have some misunderstandings about what I'm doing in hg.
I use git all the time and prefer it for all types of workflow as a VCS, but this idea that git is perfect and it's your own fault for not learning it properly is ridiculous.
UX/UI in programs is important. I believe that git has one of the worst, most inconsistent UX's of all time. You can see this by the fractured commands.
Quick examples:
'git reset' vs. 'git revert' and sometime 'git checkout'
'git checkout' vs. 'git clone' vs. 'git pull' vs. 'git fetch' vs. 'git cherrypick'
'git rebase' vs. 'git merge' vs. 'git merge --squash'
Each one of these performs actions on a repo giving you immense power and control to do specific actions, but it's horrible UX. It's very easy to end up in a detached HEAD state, or have accidentally rebased a repo so it's out of alignment with a remote, leaving you with the trouble of dealing with that. It's crap experience, and all I want to do is code. What does it say when resolving these problems the easiest thing is to just reclone the remote repo?
I commend this project for trying to apply some sanity to the entire thing.
Agree. There needs to be a higher level git command interface for those of us who appreciate git's power but would prefer to just get common stuff done without worrying if we just messed up months of work and have to unwind and fix the screwed up code base. git reminds me of C, super powerful and super easy to mess up.
> What does it say when resolving these problems the easiest thing is to just reclone the remote repo?
It says the git works really well because the CLI offers a simple way to "undo" any mistakes you've made. The real reason people struggle with git, and I've seen this in many other programs/places is that they rely on discoverability and just randomly try commands until they work.
Git's simplicity is it's downfall. You don't see people wrapping Angular2 in other frameworks to deal with the warts.
There's a reason people are told to look at man pages all the time, the command line is not the place to play "discoverability". There's already plenty of suggestions and help features built into the tool.
> It's crap experience, and all I want to do is code.
- every engineer when first experiencing version control
> It says the git works really well because the CLI offers a simple way to "undo" any mistakes you've made.
This let's the design off the hook to easily. Yes, on the one hand this is a great feature, but on the other, you are deleting and restarting your workspace. It's not a great UX, it's just a simple workaround for a bad one.
> - every engineer when first experiencing version control
no, wrong. git is unique in the amount of information that you need to know just to get started with it.
Yes, I've worked with RCS, CVS, SVN, SourceSafe, Perforce and some others, though know them less well.
Git is bar none the best of all (of which I've had experience) the VCS' out there. I would pick it over anything else. The issues I'm pointing out are not because I don't use it, don't understand it, or don't appreciate it. I just believe that it's too complex.
If git was literally just the set of commands you listed, that would be great. As a single user experience it's hardly ever an issue. But that doesn't mean that it can't be better! And that's why I like this gitless project (and some of the other similar ones out there), it's trying to create a decent experience that will scale.
Also, your example is about creating a new git repo, I find this to be much more rare than getting involved in an already built and multi-member team, which may have all sorts of rules about proper merges or rebases, and such.
It can be though. That's like saying Linux would be better if they only gave you ls, cat and nano because vi, sed and xargs were too complicated.
There is nothing about gitless that provides a decent experience (compared to git) and certainly nothing about gitless that has anything to do with operating at "scale".
The truth is commands like filter-branch, rebase, cherry-pick, etc. which are notoriously difficult to use... you don't even have to use them.
I'm not saying the git experience can't get better, but the way forward is to modify the existing tools and contribute to the project, not make git wrapper number 84 that does nothing special.
> That's like saying Linux would be better if they only gave you ls, cat and nano because vi, sed and xargs were too complicated.
That's a rather condescending thing to say and not accurate or supportive of the view of git you seem to hold.
> The truth is commands like filter-branch, rebase, cherry-pick, etc. which are notoriously difficult to use... you don't even have to use them.
Until someone on the team _does_ use them and then things can become messed up in ways it takes a git expert to figure out how to fix. I've used git for several years and had never even come across filter-branch, I'd have to chase down the git docs to see what it even does. I never had to filter anything with CVS, Continuus, Perforce, SourceSafe or Subversion.
Here in the real world if you fuck up your local repo by running commands you don't understand there isn't a "git expert" to come by and fix it for you, in the same way if you make a VM and fuck up your local machine there isn't going to be a "linux expert" to come in and explain how to fix what you did wrong.
Part of the benefit of the tool is that you can blow everything away and restart. It's distributed, which means you CAN fuck up your local copy and there are no consequences. It's been years since I've had a repository be in an "unrecoverable" state and part of that is actually taking the time to understand what I'm doing as opposed to just crossing my fingers and hoping shit works.
The fact that other version control systems don't even have some of the power features git has is a big reason git is so popular.
Again, if you don't understand the more complicated commands, don't use them (although you should- they are incredibly powerful and worth learning about). If your team is forcing some bizarre workflow on newer developers that involves using filter-branch and cherry-pick all over the place without good reason, that's an organizational issue, not one with git.
They'd also be more salient if I didn't have to make them 10 times in a thread because everyone feels like their opinion on how "git is too hard" is worth sharing. It gets tiring defending git from the uneducated masses and hearing the same stuff trotted out over and over again that has no value whatsoever.
In my mind you use many of those commands to perform actions in the repo or locally which are related.
For example: 'git reset HEAD~1' is something I use often, it is vaguely like 'git revert <last-hash>'. Therefore I see them as providing similar functions semantically, but not literally.
'git fetch' and 'git cherrypick' are again similar in my mind where one is pulling changes from a remote, while the other pulls a set of changes from one branch into another locally. This is not as good an example though, but I do think they have slightly overlapping concepts.
I'm a programmer because I love to see things I imagine come to life, not because I love to learn arcane CLI interfaces. I can appreciate the beauty of the underlying design and structure of git, but the git CLI is just a horrible turd IMHO. Am I lazy? Sure, my mental ability is not infinite (ASFAIK) and I rather focus it on solving my actual problem rather than trying to find the right git-incantation for making git shut up and leave me the f* alone... I have a decent understanding of the underlying structure of git and I often know what needs to be done in terms of how one commit relates to another but git CLI...
When people suggest that git is great I lose a little faith in them as a programmer cause it indicates to me they don't have much breadth if experience with source control systems & they are too intellectually lazy to investigate alternatives.
I have tried and used Mercurial, SVN, RCS, CVS, Bitkeeper, TFS, Bazaar, Perforce, Darcs and of course Git.
Granted, Git may not be great, but it is still my first choice.
Hg is a very similar model to git but doesn't have the cli problems it does.
Darcs is distributed with a different (and interesting) model that doesn't have the cli problems get does.
But honestly for lots of teams dvcs is not that big an advantage (how many teams are syncing around github right now) which means something like Accurev might be a better choice. It uses a concept of streams which is pretty interesting and is GUI oriented which some people like.
Hg has a lot of problems. It has bookmarks AND branches (for some reason). To edit your commit history you need to pray to the elder gods and sacrifice a newborn. I consider myself pretty smart and yet my mind went completely blank every time I read about anything related to Mercurial Queues. The default install lacks too many features, you need to enable extensions to do even the most basic stuff, like stashing.
Darcs is obviously better than git, but very few people know it exists. And none of free web repositories support it.
My original comment was really hyperbolic as a response to the comment above, I don't actually think being pro-git is a sign of intellectual weakness.
That said, my main issue is that git is a good set of primitives for file change management. But its main design principles are not about SCM. It sacrifices ease of workflow for source control, in favor of making centralized maintainer worflows simpler. This is a perfectly fine trade off for a system largely optimized for a few linux kernel maintainers, dealing with lots of distributed and unorganized contributors (frequently over email).
Those same workflows are not necessarily the best way to organize a small (tens of developers) team with a linear history product.
Some time try to onboard a new-grad developer to a team like the former. You spend way more time explaining git internals and data structures than you do source control management. This just isn't true if you do the same thing with other source control systems. Its easier to explain TFS, SVN, hg, perforce or accurev (the systems I have actual working experience with) in every instance.
My opinion is, if bitbucket and github had switched business models early on (ie hg repos for free if they were public and git repos free for private repos) hg would have become the defacto standard. Its just much easier to work with for most development workflows.
Darcs is not obviously better than git, and I say that as a person that's used Darcs for many, many years (and who has at least patch in the Darcs codebase).
Darcs main feature is the simplicity of its data model. Just a pile of patches that compose to produce some code. Push and pull them at will. It's very neat.
Darcs used to have the advantage a nice interactive UI, but git pretty much stole it wholesale with all the '-p' options (git add -p, git checkout -p, git reset -p) so it doesn't win there any more.
Darcs also has the massive downside of not being able to hold more than one branch at a time in a directory. Do you want to switch contexts? 'darcs get' to a new directory and start over. On my most active darcs project I have about 50 directories all with random unpushed WIP patches in them. In git that would just be a bunch of stashes, which are much easier to search through.
My first experience with a VCS was using Mercurial, about a decade ago. In that time, I've only had at most three or four instances where I so borked the repository that I had to destroy it and start again. This includes the time when I didn't know anything about VCS and was liable to foot-gun myself. I probably first used Git about 5, 6 years ago, and, despite using it at a much reduced frequency (virtually all my git usage is via hg-git nowadays), I've easily had a dozen times where it was easier to blow away a repository than fix it.
Obviously, heavy prior experience with Mercurial does color one's views about UX, but the experience with Git that I have had--and that I have seen many others concur with--is that the UX makes it way too easy to get you in states that you don't know what to do. But that's not the biggest flaw with Git. The biggest flaw is the community: when you don't know what to do, and you start trying to find the answer, instead of being told "this is how you fix it," you instead get a lecture on the full internals of Git, and why the crazy incantation should be really obvious to any user. Is it any surprise that one would find it easier to blow away the directory and recreate the five-line build system fix whose merge conflict caused the mess in the first place?
Your comment is a picture-perfect of this community hostility that I see with Git that I don't see with other VCS. There definitely seems to be a sentiment that there is One True Way™ to do things, and if you're not doing it like that, you are wrong. I care to disagree: a VCS is a tool--it should support my workflow, not dictate it. I find that the community around Mercurial is much more in agreement with the philosophy I hold, and unsurprisingly, I've generally found Mercurial to be superior than Git.
Some reasons I don't like git, straight off the top of my head.
* Some commands require remote branch, others require remote/branch. I can never remember which.
* git lets you create branches with names like 'remote/branch', at which point it starts going crazy because when I then write remote/branch, it doesn't know if I mean branch on remote, or the local branch remote/branch.
* When merging / rebasing goes wrong, it can be hard (or impossible) to recover back to the state I started from.
I like git a lot and wish everyone standardized on it. I use the CLI almost exclusively but from my perspective it's terrible: cryptic and very inconsistent.
Looking back at my RCS history (RCS->VSS->MKSSI->CVS->SVN->git) I have to say that all of them were either hard to use or plain bad (VSS).
The problem RCSs are trying to solve is hard, that's why the tools are simultaneously indispensible and frustrating.
I don't like git because I have zero confidence that it won't do something dumb like fail to diff properly requiring me to merge 980 diffs in a single file while it puts the <<<<<<<< and >>>>>>>> markers in the wrong places, randomly transposing lines from one part of a file to another for no discernible reason.
Git works really well but I've had some exposure to Canonical's Bazaar (bzr) in the past and at a high level; I'd say it's easier to not shoot yourself in the foot with bzr while still accomplishing pretty much what Git does. I'm not knocking Git at all, just bringing some background on an alternative tool I'd say is in the same class.
Whereas when people say they do like Git, I lose a little faith in them as a programmer and/or engineer. Because the only ways you could like Git are either to be so lazy and incurious as to be unfamiliar with the alternatives (Mercurial, and everything else that's come along since), or to have such bad judgment that you prefer Git to them.
More accurate to call it a git client rather than a version control system. It is git.
Then, many clients have tried to hide git complexity under some friendly UI. They might be productive in some cases (e.g: to manage your stage area), but for others at some moment they will end up confused and not knowing what to do.
> Gitless is an experiment to see what happens if you put a simple veneer on an app that changes the underlying concepts.
... changes them how exactly? A big part of what I like about Git is that its underlying concepts are simple and clear and feel like the right building blocks for version control. So I'm curious to know how they believe they can improve on that.
It's not a quick answer but they cover this in the Gitless vs. Git section.[0] One main difference seems to be with branching "The main thing to understand is that in Gitless a branch is a completely independent line of development."
The approach of this experiment is interesting. But, as an experienced git user, I think it does not include easy access to very powerful and easy-to-learn features of git like "git * -p" which bring some interactivity in git commands.
"Gitless is an experiment to see what happens if you put a simple veneer on an app that changes the underlying concepts. Because Gitless is implemented on top of Git (could be considered what Git pros call a "porcelain" of Git), you can always fall back on Git."
As an experienced git user, are you not outside the target audience? From a quick read through, Gitless seems like it's designed for non-git-users who need git access.
The git CLI has gotten a lot better over the past few years. Making simple branch push the default was a good move.
There are some things that could be improved (and any of these can be config options for those who want the old behavior):
* switching branches should auto-stash changes, then auto-apply when switching back (apparently one of the things gitless does)
* a rebase should leave a marker in the tree (with the old hashes) so if you force-push other clients can offer more intelligent options (e.g. Looks like these commits were rebased by a_user; rebase your changes skipping duplicate commits or merge?)
* git still allows you to create branch names differing only by case which is a problem on macOS and Windows
* cherry-pick -x should be the default and tools should do a better job of showing the relationships
* tag sync should include the commit and update on pull so rewriting tags isn't such a PITA. Maybe we need movable vs static tags.
I've seen people recommend npm over submodules. You can give it a git repo as a package and tag/commit as the version so it's not just for JavaScript repositories and also pulls the submodule's own npm dependencies. Although I don't know if you can put it wherever you want or it will always go to the node_modules directory.
I wonder why there is no context-aware vcs; e.g. one that understanding the language and resolve diffs at a functional level. Would make change tracking and merging so much easier. Alternative would be to split each function into a separate file, for C# that would mean partials and the compiler just joins them.
Git is intentionally stupid about file contents to make it simple and robust.
Smalltalk has some systems like you describe. They're integrated with the compiler and Smalltalk makes that easy.
Otherwise I think it's mostly that such systems are lots of work to make and maintain. Treating files as plain text has huge benefits when you consider simplicity and flexibility.
The real "UNIX philosophy" is "worse is better": simpler, quicker, finished solutions are more likely to flourish (except X11).
How is this any different from hub (https://github.com/github/hub). It provide useful command like aliases. Along with ghi(https://github.com/stephencelis/ghi), I can do everything like creating new repo, sending PR, looking/creating/updating/commenting on issues with my command line.
The ability to stage/unstage individual lines using a graphical interface is really nice, and after some years using it I can't think me going without it anymore.
Nowadays I only use the command line when I want to do interactive rebase.
I knew that you can already interactively stage individual lines via the command line using git add -p, which is what I use. But you mentioned unstage as well which I've never done before, so I looked it up. Looks like if you want to do that on the command line it's git reset -p
I don't know if this is not wholly rational, but over time, I became more and more cautious of using any tool for git that wasn't the pure git command line itself. I don't like how the command line was designed, but at least I know what's going on. With other tools (the latest culprit is Visual Studio sync), I often have a reaction of: "You did WHAT?"
Do people really consider git hard to use? It's very easy to learn... In fact, if you can't learn git I would not be confident in your ability to learn any other important technology using the internet as your resource. You don't even need to have internet access as long as you have `man`.
I see gitless has a bunch of 'gl ____ -c foobar' as well. Why is the -c (create?) needed? Isn't it apparent that if that branch doesn't exist we need to create it? If that remote doesn't exist we need to create it?
Exactly. It would be like if `cd pathname` was the equivalent of `mkdir -p pathname && cd pathname`. Even with tab completion, only a tiny minority of users want that behavior. To most, it invites mistakes.
I think tools like github desktop make this unnecessary. I've given some people a quick introduction to git using the desktop app, and they were up and running in about 20 minutes. Sometimes something goes horribly wrong, but it's a rarity. I think the worst case scenario encountered was: "No one knows what's wrong, so we'll use a comparison tool and manually merge in the changes from this branch with a bad repo state as a commit."
gitless looks pretty nice, and I'll be installing and using it on my work PC tomorrow to see how I get along the rest of the week with it. I'm curious to see how the experiment goes.
Not really. Mercurial doesn't use `checkout` in that way (it's an alias for `update` which updates the working copy to a specific changeset — or the tip of the current branch, the hg version of TFA's checkout is `revert`), prints a list of revisions with `log` and uses `add` and `remove` to track and untrack files.
I like Fossil too, and use it for many small projects. To some extent projects can be converted to/from git, but I haven't done much at all with that and I'm sure there are limits. Nonetheless, Fossil is an option with good usability that doesn't lock users in when there are reasons to convert repositories to other tools.
This seems extremely pointless. At worst, this seems like the Gitless team doesn't understand what Git is doing internally, which is a pretty dangerous state to be in when you're trying to "improve" something.
Git as a whole:
* Makes it really hard for you to do something you really shouldn't be doing
* Forces you to stay "clean" and guides you to working well with other repository copies (i.e. the whole point of Git).
* Warns you and makes suggestions when you make a mistake, from silly typos to incorrect command flags.
* Makes it easy to guess how the command should be formatted or how certain structures are formatted based on convention.
They decided to rename certain features that not only give you the wrong idea of what's actually going on, but will no doubt make it extremely hard to research any errors if something goes wrong. A good example of thing is gitless' "fusing" feature. It's just rebasing stuff. Why rename it? Why rename "checkout" with "switch", when this semantic is used throughout git?
And then you have completely brain-damaged concepts such as this:
>(i.e., a file can be untracked on some branch but tracked on another and Gitless will remember this):
Honestly? There was no better way to indicate to me that you're just trying to make git fit some erroneous concepts in your head, and that you don't really understand what you're doing. This combined with the "auto-save" feature seems like a terribly, terribly bad idea and is just begging for a lazy developer who didn't take the time to understand his tools to completely shit on the repository he's working on, locally or remotely.
Take the time to understand your tools. Git is incredibly simple underneath. It's not complicated.
Uh, what? You respond to my post with some of the problems with this system in a hyperbolic, confronting manner without contributing anything. They are not "making the world a better place."
Someone makes a project trying to make something easier to learn (so, trying to make the world a better place), and you call it "extremely pointless", you tell them they "don't understand Git", they're "brain-damaged", "erroneous", they should "take the time to understand their tools", because the tools are "not complicated" and "incredibly simple".
Besides your arrogant "I'm right, you're stupid and wrong, and there's no questioning me" attitude, why would you take such a hostile tone towards anyone's work, ever? How could you think that's okay or constructive?
I'm hugely sympathetic to the opinion that Git is needlessly difficult to learn and needless easy to make mistakes in due to huge flaws in the CLI. I'd present that case, but, hey, it's presented a hundred times here and everywhere else. It's clear there's no point arguing that point to you, though, because I'd be stupid and wrong just for disagreeing with you. So instead I'm trying to convey that your arrogance is unacceptable in the community in the hopes that it will not reappear.
>Someone makes a project trying to make something easier to learn (so, trying to make the world a better place)
Again, spare me the hyperbolic the "trying to make the world a better place." The principle behind my post, as given in my very first statement is that they basically failed. They are gearing people towards failure. It would have been better to just create a thin layer on top of git with slightly renamed or alias commands -- all while having "release valves" that guide you into the true, underlying community crafted toolset underneath that git has been using for years (and for very good reason). Any errors you're likely to come across while using git have been documented either by the team or in various posts around the internet. It's easy to search for these errors. If your target audience are developers who have a hard time with Git, why would you make it needlessly hard to research errors that are likely to happen (given how new this tooling is). For example: labeling rebasing as "fusing" is basically telling them: "haha, good luck googling what just went wrong!". Good luck hopping on an IRC or Slack channel and getting someone to help you. A decade of community problem solving and documentation just went out the window because the Gitless team decided to play musical semantics with commands.
>why would you take such a hostile tone towards anyone's work, ever?
Leave your ego at the door. We're talking about a toolset.
>Besides your arrogant "I'm right, you're stupid and wrong, and there's no questioning me" attitude
Please do not respond to any of my posts in this thread anymore, especially if that is the basis of this comment chain. That is a ridiculous sentiment and I'm not going to devote any effort into addressing it.
>I'm hugely sympathetic to the opinion that Git is needlessly difficult to learn and needless easy to make mistakes
I would strongly disagree about the "needlessly difficult" part, but I would also claim that the "easy to make mistakes" is demonstrably false with Git. Git makes it extremely difficult again to do something you should not be doing in the first place and then the community over the years has placed plenty of warnings when you do those questionable actions anyways; on top of giving you the ability to revert the mistake and bring your repository to a sane place with one simple command. Checking out branches with conflicting changes is just one of the simpler safety checks and roadblock that Git provides where Gitless decided to just go "Nah, you can actually do that." with seemingly no apology as to why you would ever want to allow such a thing -- other than just for the sake of convenience, but I would label it as laziness as it makes it incredibly easy to pollute your repository at that point. It doesn't even provide any kind of warning mechanism or cleanup tool for this handy "feature."
>So instead I'm trying to convey that your arrogance is unacceptable in the community in the hopes that it will not reappear.
The only thing worse than calling me arrogant is your complete, unconstructive obliviousness towards your own attitude. Not only have you still failed to say anything worthwhile or present any kind of counter to my opinion, but you're being a complete dick about it and trying to label me in a negative light for no reason. Which ends up really at the end of the day making you a troll at worst and a hypocrite at best.
I am not talking about a toolset. I'm talking about how I believe you have a "I'm right, you're stupid and wrong" attitude. So I'm not disputing your opinion about Gitless, I'm criticizing how you presented it. I don't think the sentiment is ridiculous, because I think it's correct; clearly if you write it off as ridiculous then we're just talking past each other. Similarly, I don't think I am labeling you in a negative light for "no reason": the reason is that you are acting in a way that I think deserves to be called out negatively, so as to hopefully dissuade you from acting that way.
I do happen to think Gitless is a noble effort that will not change the world or be adopted by much of anyone, as with many interesting projects that are posted here, but I still think you should be non-hostile towards it, and sympathetic instead of dismissive towards the problem it is trying to solve (since clearly there are heaps of people who feel the same way, as evidenced by these and many other comment threads).
> I'm not going to respond to you anymore past this
Feedback from the outside: ajkjk strikes me as someone making reasonable points and who is capable of productive discussion. You are coming across as unnecessarily arrogant and prickly, and thus someone with whom it's best to avoid discussion.
Maybe you are an extremely fluent but non-native speaker of English and your idioms aren't coming across as you want? Or maybe you just prefer a more "aggressive" approach than we are comfortable with?
In any case, independent of the technical merit of your arguments, you might reconsider ajkjk's criticism, as I think there are many others (like me) who agree with it.
You consider his first post to be productive? You must be dreaming.
> ajkjk strikes me as someone making reasonable points
He is not making any point, so it's weird that you would say that. He hypocritically stated I was coming off as arrogant. Fair game, even though I really don't see how it remotely comes off that way, but you can't exempt yourself from your own criticism in a post that does not constructively further the conversation in any way.
> You are coming across as unnecessarily arrogant and prickly, and thus someone with whom it's best to avoid discussion.
Apparently so, but I don't see it. I gave my opinion, and that was it.
>you might reconsider ajkjk's criticism
I most definitely will not, as this is a technical discussion. I'm not going to muddle the waters. Nothing I said was needlessly "arrogant" (at what point was puffing myself up?) -- and if it was prickly then I'd question why it was chosen to focus on that aspect of it instead of directly countering what was stated.
When discussing technical matters: leave your ego at the door. At every turn I gave him a chance to actually discuss something and he refused to do so. The fact that you decided to continue this non-sense is mind-boggling to me. What's the point?
I most definitely will not, as this is a technical discussion.
For better or worse, like most discussions, it also has social aspects. Consideration of these aspects may help you better convey your technical points.
What's the point?
Based on your comment history, you have technical knowledge that others could benefit from, but aren't very successful in getting your point across without being downvoted or flagged. If you continue with your current approach, at some point your account will likely be banned. Whether they are exactly accurate or not, I think contemplating ajkjk's criticisms may help provide you insight that will allow you to have better interactions with HN.
The fact that you decided to continue this non-sense is mind-boggling to me.
I am generally a very technical person, I use git frequently and only by the command line interface, I think I mostly understand the underlying operations, and yet I frequently am baffled by the commands required to get from where I am to where I want to be. While I likely can overcome this through study and repetition, I think git would be a more useful tool for others in the future if the user facing command line interface was improved.
Viewed over the longer term (and I say this as someone who approached git through RCS, CVS, and SVN and likes the improvements Git offers) the current interface is not perfect, is not set in stone, and improvements are a good thing. Assumptions that the 'gitless' authors are only doing this because they do not properly understand the internals of git are likely incorrect. While I don't think 'gitless' quite has the right solution, I think attempts to better align git's command line interface with the underlying operations are commendable, not pointless, and decidedly not nonsense.
>Consideration of these aspects may help you better convey your technical points.
And yet despite him blatantly confronting me in an aggressive personal manner, you've ignored his original post and decided to focus on my post, all in spite of my attempts to keep the conversation on topic. Most likely because you agree with him. It really removes any credence from his post and other posts echoing him about my original post being "prickly" when you're a complete dick to someone directly. Talk about arrogance.
I can't call a technical concept brain damaged, but aggressively labeling people in a confrontational manner is a-okay. Got it.
>and yet I frequently am baffled by the commands required to get from where I am to where I want to be.
Have an example? Most of the examples I've seen come from a fundamental misunderstanding about what git is doing. Git is rarely in the wrong.
There's a lot of internal plumbing commands that are completely backwards (or just have not been updated to align with the rest of the toolset) but an extremely small majority of people will ever even know about them, let alone have to use them. Especially if you're just starting out with git.
>think attempts to better align git's command line interface with the underlying operations are commendable
Except as presented in the examples I've given, it's doing the exact opposite of this. It's going against the very basic foundation of git. Git is an acyclic graph with each node representing a change delta from its "parent." The very fact that branches suddenly keep track of which specific changesets (tracked or not!) belong to them is completely counter to how the very core of git works.
But like with many professinal tools, you don't need to know everything to get to work.
I don't know all Photoshop or Ableton Live features, but I can improve my photos or create songs non the less.
With these commands you can already start your own repo and work on it locally:
If you want to work with a repo from somewhere else like Github etc., you need a few extra commands: I think these 10 commands are all that is needed to get your own project into Git.Yes, the more people are working on a project, the more commands you need, like creating a new branch and getting commits from one branch to another, or amending commits because you forgot something etc.
For a professional tool this isn't too much, I think. The 10 commands I mentioned will be remembered in less than a week. Most of the rest isn't needed often (maybe merge/rebase and branch depending on how you intend to use Git), but they shouldn't take too long either.