Hacker News Reader

Comment by alkonaut | Hacker News Reader

I think it's simple and elegant as a data structure, when what people need and want is something that is (at least also) simple and elegant in its UX and most importantly VERY simple and elegant for the 80/20 use cases.

For example a typical question on Stackoverflow is "How do I answer which branch this branch was created from", always has 10 smug answers saying "You can't because git doesn't really track that, branches are references to commits, and what about a) a detatched head? b) what if you based it off an intermediate branch and that branch is deleted? c) what if...

5 more answers go on to say "just use this alias!" [answer continues with a 200 character zsh alias that anyone on windows, the most common desktop OS, has no idea what to do with].

I don't want to write aliases. I usually don't want to consider the edge cases. If I have 2 long lived branches version-1.0 and master. I want to know whether my feature branch is based on master or version-1.0 and it's an absolute shitshow. Yes it's possible, but is it simple? Is it elegant? No.

The 80/20 (or 99/1) use case is

- centralized workflow.

- "blessed" branches like master and long lived feature branches that should ALWAYS show up as more important in hisory graphs.

- short lived branches like feature branches that should always show up as side tracks in history graphs.

Try to explain to an svn user why the git history for master looks like a zigzag spiderweb just because you merged a few times between master and a few feature branches. Not a single tool I know does a nice straight (svn style swimlane) history graph because it doesn't consider branch importance, when it should be pretty simple to implement simply by configuring what set of branches are "important".

View on HN

As a very basic git user, about once a month my local git repository will get into a state I cannot fix. I cannot revert, cannot reset, cannot make it just fucking be the same as origin/master. Usually I accidentally committed to local master and then did a couple other things and it's just easier to blat and re-clone than work out how to resolve.

Git is hard for idiots imo, and there are a lot of us

The workflow that I have found works best is to just not change anything myself, I let other people do all the work. This way I can be sure that I won't get merge conflicts that I can't fix.

> Usually I accidentally committed to local master and then did a couple other things

Create a new branch and check it out while you are on the last commit (git checkout -b my-branch), delete the master branch (git branch -D master), and pull it again (git pull -u origin master). You'll end up with a local branch with a bunch of commits that you can merge, rebase or cherrypick, depending on what you want.

If you want to learn more about git in a practical way, there's an awesome book called Git Recipes.

That is not easier than "blat and re-clone" so I think you're proving their point.

Recloning means redoing your work on top of a potentially different codebase. The approach I described is how you "blat and reclone" using git instead of the filesystem, and it has the clear advantage of keeping everything in the same repo. You can then mix all the code together in whatever way you prefer.

Git is a very flexible tool that allows for individual local workflows independent of how teams collaborate. Finding a personal workflow that works for you is a little investment that pays huge dividends for a long time. Git is a 15 year old tool that is expected to live for 10-30 years more at the very least. I encourage everyone to learn enough Git to not be afraid of it.

If you’re just going to blat and reclone, then you may as well use a folder system instead of git.

I see no reason git needs to be changed in order to cater to people who refuse to read basic documentation or learn from their mistakes.

I did not read brigandish's comment as advocacy of 'blat and reclone', I took it to be a comment on git's awkwardness.

I have considerable sympathy for the RTFM reply, but I do not think it is the last word that shuts down any question of usability. What seems clear to me is that there are a lot of people using git who probably should not be. In many cases, they do not have a choice, but I also suspect that many of the organizations that have chosen git do not have the issues that it is optimized for.

> I see no reason git needs to be changed in order to cater to people who refuse to read basic documentation or learn from their mistakes.

In my opinion, solving problems and making improvements involves reducing complexity, not defending it. Many people, including myself, have read the Git docs and learnt about the underlying data structures etc etc and still we can make the claim that it could be better, in numerous ways.

Calling everyone feckless won't invalidate that.

> we can make the claim that it could be better

I’m not disputing this. Of course git isn’t perfect.

What I’m against is changing git to cater to people who can’t read the manual and make basic mistakes.

> What I’m against is changing git to cater to people who can’t read the manual and make basic mistakes.

Why? Isn't software that doesn't require reading a manual and doesn't let the user make irreversible mistakes considered good design?

Not if it means reducing capabilities of the program in order to add bumper guards.

I can’t think of any software that handles a complex program that doesn’t have a manual, documentation like a manual, or a learning curve. Git is a tool for developers, not casual users who want typical apps.

Again, you wouldn’t make an argument like this for a tool used by a plumber or a mechanic. If a tool succinctly handles a problem, good! But using tools is part of the profession; they have learning curves.

Most issues with git are PEBKAC issues because people refuse to spend 10 minutes of their life reading about a tool they may use for hundreds or thousands of hours. I wouldn’t want to cater to those kinds of people.

Software can cater to multiple types of uses at the same time. You can have a learn-as-you-go experience while keeping your powerful tools that enable more fine-tuned or complex tasks. Easy-to-use vs. powerful is a false dichotomy.

About the plumbing/mechanic analogy, I totally would make the same case! Hammers and wrenches don't require a manual and can be used for very complex tasks, and that's exactly what makes them so well designed and popular. Few people want their hammer to have more features, and if they do, they still want to keep the good old hammer ready, because it's so easy and simple to use.

Especially calling out PEBKAC (Problem Exists Between Keyboard And Computer) - while even most of the expert git users, including the author himself say the interface could at least be made much better - makes me really suspicious that you simply like feeling superior to other people because you know something they don't, and you don't want to lose your "edge" if suddenly everyone can use version control without resorting to manuals.

> Easy-to-use vs. powerful is a false dichotomy.

iMovie vs Premiere/Final Cut. Final Cut X vs 7. Garageband vs Pro Tools. Word vs LaTeX. and so on. It's very difficult to design interfaces that are easy enough for average users that don't impede pros/power users.

> hammer

A hammer isn't a good comparison. Something like a multimeter is what I was thinking of, etc. Git solves a significantly more complex problem than either of these, though.

> including the author himself say the interface could at least be made much better

I don't disagree! Git's interface -could- be better. That has nothing to do with my points above with regards to people refusing to read basic literature about the tools they use, expecting them to just magically do everything for them out of the box, "intuitively".

> feeling superior ... you don't want to lose your "edge"

This could not be further from the truth. I simply have no sympathy for people who refuse to read the manual or an intro to using a tool, and then complain about the tool being hard to use. Yeah.. it's hard because you didn't do any reading! Git is actually really easy if you read about the model that it uses. Most people don't need to venture out beyond ~5-6 subcommands, and even then it's easy to learn new subcommands like cherrypick, rebase, etc.

Adobe Photoshop, as another example, has a learning curve, but that tool is indispensable for professionally working on / editing images. (GIMP is also good, but that's not in the scope of this discussion). A lot of beginner issues are basically PEBKAC because they didn't read the manual. Same with Pro Tools, or probably any other software used by industry professionals. They're harder to use but what you can do with them (since they treat you like an adult, instead of holding your hand and limiting you) is incomparable to the output of apps designed for casual users.

What can Git do that Fossil or Mercurial can't?

Deleting master is a thing that would _actually_ never have occurred to me! A neat trick

That being an example that I remember from late last year, there are just sharp edges to git I end up catching myself on :)

The git "master" branch is just an example of 'convention over configuration': some commands use it as the default argument, just like "origin" is the default remote name. Nothing in git is special or sacred! :)

Is there a reason for -D and not -d? Wouldn't -D also delete the remote branch if you accidentally pushed your changes?

"git branch -d" doesn't remove a branch if that means losing track of some local commits. "-D" doesn't check that. The "git branch" commands only operate on your local repo, they don't push any changes to remote repos and they don't pull commits from anywhere.

`-D` doesn't involve the remote at all (unless you are using something like the intentional remote:branch syntax which this example isn't). It is a force delete in that if there were commits locally in that branch and only in that branch it should still delete that branch. It should be unlikely you need that force because the first step was to branch everything as is, so it is safer to just use `-d`, but if the intention is to "blat" it from orbit anyway, `-D` is that.

I wish git had a “metahistory” feature to allow everyone to undo anything. A `git revert` isn’t of any help when you’ve already merged and pushed.

It's called "git reflog": https://www.edureka.co/blog/git-reflog/

Though you do have to have committed. One of the things I hammer on in my tutorials for work is that if you get confused in git, make sure you commit. If you commit, you can take your problem to the other engineers and we can almost certainly get you straightened away. Fail to commit, though, and you really may lose something.

Also, metapoint about git: While I won't deny its UI carries along some dubious decisions carried over from the very first design, in 2020, basically, if you thing "Git really ought to be able to do [this sensible thing]", it can. It has that characteristic that open source software that has been worked on by a ton of contributors has, which is that almost anything you could want to do was probably encountered by somebody else and solved five years ago. It just may take some searching around to figure out what that is. (And on the flip side, when you read the git man pages and are going "Why the hell is that in there?", the answer may well be "a problem that you're going to have in six months".)

> make sure you commit

This is not absolute gospel. If you screw up a rebase and commit, whatever you removed in the rebase is simply gone.

Are you saying that with knowledge of what "git reflog" is? I suspect not. I'd really need to see a sequence of commands that removes committed state from the repo to buy this. If you try to produce it, bear in mind the first thing I'm going to do is run "git reflog" on the result, so if you find your committed state is still there, then I'm going to say it's still saved.

(That's not a git thing. I don't really even want some sort of hypothetical source control system that literally tracks every change I make. It's technically conceivable and should be practical to what would at least be considered a "medium sized" project in the git world, but I'd just be buried in the literally thousands of "commits" I'd be producing an hour. Failing that sort of feature, a source control system can't help but "lose" things not actually put into it.)

As I am not familiar with the details of reflog (I don't recall ever using it) I took a look at the article. I wasn't long until I reached what looks like a caveat: "This command has to be executed in the repository that had the lost branch. If you consider the remote repository situation, then you have to execute the reflog command on the developer’s machine who had the branch." Joe, who works on another continent, quit last week and his computer was a VM...

OK, so we have backups of his VM and we can recreate a clone of it, but will that be satisfactory? Are there any issues with hardware MAC addresses or CPU ids? How far down the rabbit hole of git minutiae do you have to go before you are confident that you can do all basic source-control operations safely?

No source control system can solve the problem of not having things it was never given.

git log --reflog --all

is the more important imo than

git reflog

The main thing that people fail to understand is that commits are immutable and the overall commit graph is immutable (with the caveat that pathways in the graph that don't end in a branch head are subject to garbage collection).

A rebase does not destroy information. It creates new commits and moves the branch head to a different spot on the graph.

The reason git is seen as painful is because you can't claim expertise until you develop the ability to form a mental map of the graph. But once you do this the lights turn on and everything starts to make sense.

This is why the mantra "commit early and often" still holds. The more experienced git user will tell the newer people this, so when they come with a mess it will always be recoverable.

That GC a pretty big caveat! Combined with the fact that unreferenced objects are never pushed.

reflog is like undelete in filesystems, it's a probabilistic accident recovery mechanism for an individual computer (repo checkout in this case) that you can try to use if you don't have backups.

In any case, git garbage collection isn't a common phenomenon. It usually triggers every few weeks, even in repos with high activity. The chance of hitting a GC that deletes an untracked commit you need is extremely small.

How would it be gone? You can't rebase onto a dirty working directory so you can't blow away uncommitted changes accidentally and any state prior to and during the rebase is always recoverable via the reflog.

It takes trying to do anything that's not easily recoverable as long as you commit before you start messing around and don't rm -rf .git.

It's definitely not gone. Just `git checkout ORIG_HEAD` and you'll be back to whatever the tree was before you rebased.

NO. Nothing is gone after commit. You just don't see it.

Make a git log --reflog --all and you will see all the commits you made (or rebase made) in the last 3 months.

You can than rescucitate an old branch by simply putting a branch name on it with git branch newname <old sha1>

It won't be gone until you actively prune dangling commits. The commit may not be reachable from the HEADs of existing branches, but go through the reflog and your commits will be there. You can then create a branch to make the commit reachable.

Does this not show up in the reflog?

You have a branch named <branchname> you do your operation that fouls up your branch. If you check with

git log --reflog --all

you will see with this magical command that git DOESN'T REMOVE any commit. Your old tree is still there, only normally hidden. The commit that was there before you fouled up your branch is still there.

You now only need to set your branch to the old commit. A branch is nothing else than a pointer in the tree.

You have 2 possiblities to change the commit a branch points to

1. git branch --force <branchname> SHA1 (works only if <branchname> is not the current checked-out branch. Simply checking out with the SHA1 works also as it deteches the HEAD).

2. replace the SHA1 in the text file in .git/refs/heads/<branchname> by the SHA1 where you want the branch to point to.

With that, your repo is in the same state it was before your error.

Harkening back to my early days of git, I have a rough guess as to what you can do to fix that. If all you want is remote master,

  git stash
  git checkout master
  git stash
  git fetch origin
  git reset --hard origin/master

and maybe a 'git rm -r --cached .' in case you have staged files you didn't intend to which stash failed to drop.

With the amount of information available, there is no excuse:

* https://rogerdudler.github.io/git-guide/

* https://git-scm.com/book/en/v2

Also see stackoverflow.

Git is a complex tool because it’s tackling a complex problem. I don’t see a way of making it “easier” without massively reducing what it can do. It’s like saying we should reduce a formula one car so people can use it without reading up on it, etc.

If something happens once, it happens. If something happens multiple times then it means you’re not evaluating why it occurred in the first place and learning from it. No tool in the world can solve this problem because it’s not a problem with the tool, rather the user.

Git is really not so hard, but it requires a little reading.

Git isn’t something which you can generally be successful using in a shallow way. Most developers will need to devote significant time and energy to mastering it. There really needs to be a better layer on top of it in order to make it easier for developers to figure out how to do what they want to do. Some of the commands and switches don’t seem to be orthogonal and/or intuitive.

Git already has layers on top of it like git porcelain or the various GUI tools that attempt to handle things smoothly.

> significant time and energy

All someone needs is to read through https://rogerdudler.github.io/git-guide/, and learn a few commands.

Are we seriously going to refer to “reading the manual” as “significant time and energy”? In this case you don’t even have to read the manual, just a primer on how git works. You know, on how the tool that you’re using works. Why are people so allergic to spending even a modicum of time on learning a tool that massively simplifies their life and makes their work possible?

Do plumbers complain about having to read manuals for the equipment that they use? Electricians?

As programmers our tools are easier to learn and use, yet we complain about having to any work at all.

Why even be a programmer? If reading about git is so hard, what about the rest of the field that doesn’t even have documentation?

How about we don’t make tools that cater to the lowest common denominator, in this case people who basically can’t be assed to do anything? RTFM.

Because a lot of us have used tools besides git that enable the workflow we need without that complexity, and without the fragility that often necessitates going to stackoverflow or asking on a slack channel.

I have a way of picking the losing side so I've been using mercurial for everything until now, and until now Bitbucket offered hg. They're decommissioning it so I'm moving over to git and I feel like my workflow has been hampered, not just in the immediate complexity of learning the new tool, but in the ongoing complexity of using a less good tool for my needs.

I'm dealing with it, but the situation you're describing isn't really the one that I and a lot of other whiners are dealing with.

> Because a lot of us have used tools besides git that enable the workflow we need without that complexity

I spend ages unfucking local svn working copies and long running branches on both windows and linux. git needs some serious flaws to keep up with that experience.

> Because a lot of us have used tools besides git that enable the workflow we need

Thankfully the standard DVCS is flexible enough to enable the workflows others need too.

A lot of people get by just staging and pushing/pulling commits, myself included. That’s 3 commands, 4 if you count git status. You do not need to dig deep to get a lot of use out of git as a basic remote sync.

> Git is a complex tool because it’s tackling a complex problem.

Fossil tackles much the same sort of problem, yet it's far simpler to use.

Most of Git's problems are due to purposeful choices, but they're design choices, not inherent aspects of how a DVCS must behave.

We've laid out our case for the differences here: https://fossil-scm.org/fossil/doc/trunk/www/fossil-v-git.wik...

> their thing: Sprawling, incoherent, and inefficient

> our thing: Self-contained and efficient

This is not biased in any way and makes me want to continue reading. /s

Also, you can’t claim something to be “efficient” when it’s doing many different things like scm, issues/tickets, a web forum/ui ....

Then you have non-issues like git being installed via a package manager instead of dragging and dropping a binary. Yeah, this is such a huge problem that concerns people, better switch to Better Project (tm).

And then you take Gitlab and conflate Gitlab’s issues with problems with Git. I guess gogs/gitea don’t exist?

This page needs to be rewritten to simply list the differences in neutral language. There are good points but they’re lost in unnecessary epithets like “caused untold grief for git users”. I get it: git bad, our product good. Switch!

—

Personally, I don’t want something that tries to do many different things all at once.

> This is not biased in any way

Of course we're biased, but every row in that table corresponds to a section below where we lay out our argument for the few words up in the table at the top.

Here's the direct link for that particular point:

https://fossil-scm.org/fossil/doc/trunk/www/fossil-v-git.wik...

Now, if you want to debate section 2.2 on its merits, we can get into that.

> you can’t claim something to be “efficient” when it’s doing many different things

We can when all of that is in a single binary that's 4.4 MiB, as mine here is.

A Git installation is much larger, particularly if you count its external dependencies, yet it does less. That's what we mean when we say Git is "inefficient."

But I don't really want to re-hash the argument here. We laid it out for you already, past the point where you stopped reading.

> git being installed via a package manager instead of dragging and dropping a binary. Yeah, this is such a huge problem that concerns people, better switch to Better Project (tm).

It is on Windows, where they had to package 44-ish megs of stuff in order to get Git to run there.

On POSIX platforms, the package manager isn't much help when you want to run your DVCS server in a chroot or jail. The more dependencies there are, the more you have to manually package up yourself.

If your answer to that is "just" install a Docker container or whatever, you're kind of missing the original point. `/home/repo/bin/fossil` chroots itself and is self-contained within that container. (Modulo a few minor platform details like /dev/null and /dev/urandom.)

> This page needs to be rewritten to simply list the differences in neutral language.

We accept patches, and we have an active discussion forum. Propose alternate language, and we'll consider it.

> unnecessary epithets like “caused untold grief for git users”

You don't have to go searching very hard to find those stories of woe. They're so common XKCD has satirized them. We think the characterizations are justified, but again, if you think they're an over-reach, propose alternate language.

> I don’t want something that tries to do many different things all at once.

Not a GitHub user, then?

Hey, are you a fossil dev?

I haven't used nor looked at fossil in maybe 5 years, but had a couple of questions.

Does fossil now have any kind of email support built in to the ticket manager? I remember when I tried to use fossil for actual production use, there was no way to trigger emails sent when, e.g. tickets were submitted, and one of the devs said to just write a script to monitor the fossil rss feed and send the appropriate email, which seemed like a baroque and fragile (and time-consuming) solution.

And is any more of the command-line behavior configurable (like the mv/rm behavior -- affecting the file on disk as well as the repository, or just marking the file as (re)moved in the repository)?

> Hey, are you a fossil dev?

I have commit access, yes, but mainly I work on the docs.

> Does fossil now have any kind of email support built in to the ticket manager?

Yes. It was added in support of the forum feature last year, but it also applies to several other event types: https://fossil-scm.org/fossil/doc/trunk/www/alerts.md

> one of the devs said to just write a script to monitor the fossil rss feed

Probably me. :)

> seemed like a baroque and fragile (and time-consuming) solution.

A dozen lines of Perl; easy-peasy. That and a pile of CPAN modules, but that's easily fetched with `cpanm`.

> the mv/rm behavior -- affecting the file on disk as well as the repository

The default you're referring to was changed a few years ago: the old `--hard` option is now the default.

By the way, the "one checkout per repository" is not strictly true. You can use "git worktree"; this is a lightweight way to reuse an existing git repository and have each worktree use a different branch. It's a nice feature, and I use it daily.

Also, a comment about the argumentation in "test before commit". It feels a bit artificial wrt. what can be done locally, what git commit and git push do and what their relation is in a sane workflow. Certainly, one can push untested stuff to the remote server by mistake; but, even so, this should be OK, because if one can push directly to important branches like master or similar without going through any reviews and other sanity checks, one has a problem... and the problem isn't really Git :)

> By the way, the "one checkout per repository" is not strictly true.

You must be referring to just the table at the top, not to the detailed argument below, which mentions git-worktree and then points you to a web search that gives a bunch of blog articles, Q&A posts, project issue reports and such talking about the problems that come from using that feature of Git.

I suspect this is because git-worktree is a relatively recent feature of Git (2.5?) so most tutorials aren't written to assume use of it, so most tools don't focus on making it work well, so bugs and weaknesses with it don't get addressed.

Fossil is made to work that way from the start, so you can't run into these problems with Fossil. You'd have to go out of your way to use Fossil in the default Git style, such as by cloning into ~/ckout/.fossil and opening that repo in place.

> test before commit". It feels a bit artificial wrt. what can be done locally, what git commit and git push do and what their relation is in a sane workflow.

That just brings you back to the problems you buy when separating commit from push, which we cover elsewhere in that doc, primarily here: https://www.fossil-scm.org/xfer/doc/trunk/www/fossil-v-git.w...

> Fossil is made to work that way from the start, so you can't run into these problems with Fossil. You'd have to go out of your way to use Fossil in the default Git style, such as by cloning into ~/ckout/.fossil and opening that repo in place.

That's unfortunate. Reading the comments here, switch-branch-in-place is seen as some kind of flaw, but I don't think I would voluntarily use a VCS that doesn't let me easily do that (it's most sensible way for me to work, from way before Git was a thing).

> switch-branch-in-place is seen as some kind of flaw

You're conflating two separate concepts:

1. Git's default of commingled repo and and working/checkout directory

2. Switch-in-place workflow encouraged by #1

Fossil doesn't do #1, but that doesn't prevent switch-in-place or even discourage it. The hard separation of repo and checkout in Fossil merely encourages multiple separate long-lived checkouts.

A common example is having one checkout directory for the active development branch (e.g. "trunk" or "master") and one for the latest stable release version of the software. A customer calls while you're working on new features, and their problem doesn't replicate with the development version, so you switch to the release checkout to reproduce the problem they're having against the latest stable code. When the call ends, you "cd -" to get back to work on the development branch, having confirmed that the fix is already done and will appear in the next release.

Another example is having one checkout for a feature development branch you're working on solo and one for the team's main development branch. You start work from the team's working branch, realize you need a feature branch to avoid disturbing the rest of the team, so you check your initial work in on that branch, open a checkout of that new branch in a separate directory and continue work there so you can switch back to the team's working branch with a quick cd if something comes up. Another team member might send you a message about a change needed on the main working branch that you're best suited to handle: you don't want to disturb your personal feature branch with the work by switching that checkout in place to the other branch, so you cd over to the team branch checkout, do the work there, cd back, and probably merge the fix up into your feature branch so you can work with the fix in place there, too.

These are just two common reasons why it can be useful to have multiple long-lived checkouts which you switch among with "cd" rather than invalidate build artifacts multiple times in a workday when switching versions.

Git can give you multiple long-lived working checkouts via git-worktree, but according to the Internets it has several well-known problems. Not being a daily Git user, I'm not able to tell you whether this is still true, just that it apparently has been true up to some point in the past.

Since no one is telling me those issues with git-worktree are all now fixed, it remains a valid point of comparison in the fossil-v-git article.

If what you're trying to tell me is that I can use switch-in-place workflow in Fossil as easily as in Git then that's cool. Thumbs up!

Edit: It could be worth it to emphasize this in the Fossil vs. Git comparison that you linked, as it wasn't very clear to me after reading it.

It's updated now, here: https://www.fossil-scm.org/fossil/doc/trunk/www/fossil-v-git...

Thanks for the feedback!

> You must be referring to just the table at the top, not to the detailed argument below

Well, not entirely, because in my opinion the detailed argument kind of hand-waves away the entire git worktree. Continuously switching branches inside a single large Git repo is certainly a suboptimal way to work with Git, but most of the time one should be able to avoid that with the worktree (though the worktree stuff is, of course, not a miracle cure for everything).

You’re not addressing the list of problems resulting from the use of this tacked-on feature.

Also, Git continues to be taught with the switch-in-place method by default.

I’m not saying it is impossible to get a Fossil-like workflow with Git, just that there are consequences from that not being the default.

Getting a "Fossil-like workflow with Git" is not really the point, is it? One could argue that Fossil does not support "Git like workflow". It is not really a good argument either way.

It is not like Fossil's workflow is a global optimum, it's just something Fossil does well.

> It’s like saying we should reduce a formula one car so people can use it without reading up on it, etc

A far better analogy is:

It's like saying we should reduce a programming language so people can use it without reading up on it, etc.

Sorry, but this is a terrible analogy.

The core problem with it is that very few people can get paid more by being better at using their [D]VCS, whereas those more skilled with their programming language(s) of choice often do get paid more to wield that knowledge.

Consequently, most people do not fully master their version control system to the same level that they do with their programming language, their text editor, etc.

To be specific, there are many more C++ wizards and Vim wizards than there are Git wizards.

In situations like this, I prefer a tool that lets me pick it up quickly, use it easily, and then put it back down again without having to think too much about it.

You see this pattern over and over in software. It is why all OSes now have some sort of Control Panel / Settings app, even if all it does is call down to some low-level tool that modifies a registry setting, XML file, or whatever, which you could edit by hand if you wanted to. These tools exist even for geeky OSes like Linux because driving the OS is usually not the end user's goal, it is to do something productive atop that OS.

[D]VCSes are at this same level of infrastructure: something to use and then get past ASAP, so you can go be productive.

You could always do:

  git reflog

to see when you last checked out master, then:

  git reset <commit hash> --soft

to reset to the commits at that point (but keep your files the same)

  git add . && git stash save

to stash your changes (not 100% sure you actually need the "git add ." part)

  git pull

in master

and then finally:

  git stash pop

and commit again as needed.

> Git is hard for idiots imo, and there are a lot of us

Yes, thus https://xkcd.com/1597/

I find myself saying "git reset --hard origin/" and such with disturbing frequency.

Both are examples of "I give up; it's faster to start over." This is not what I want in a DVCS.

Git push/pull -f

Then write a little merge message and you are good to go.

> Git is hard for idiots imo, and there are a lot of us

Then let the idiots end up screwing their own local repo, instead of doing some magic and making it easy to screw up upstream or someone else repo.

> I think it's simple and elegant as a data structure, when what people need and want is something that is (at least also) simple and elegant in its UX and most importantly VERY simple and elegant for the 80/20 use cases.

That's what UIs (whether CLIs or otherwise) for standardized workflows like git-flow are, IMO.

It doesn't nearly go all the way there though. Why do people need to use a command line and a gui tool (usually) for git? Because it's fundamentally not written to be used with a GUI. That I think is one of its biggest flaws. Using a GUI with git always feels like you are missing vital information and just trying to poke a cli underneath to do what you want.

Some design decisions also shine through like "no branch is more important than any other branch" which is completely mental considering how people actually use git.

Most of the guis are crap because everybody who builds them thinks that a GUI should just be a more or less a visual representation of the command line.

"Why do people need to use a command line and a gui tool (usually) for git?"

You don't. The reason is that you're using a tool that didn't budget the time to directly work on git data files and it uses the command line under the hood, because that's a hard business case to make for most small tools. This is not fundamental to git; the very top-end git-based tools like Github or Bitbucket all do their own internal, direct implementation of git functionality for this reason. It's not a characteristic of git, it's a characteristic of the GUI tools you're using.

A perfectly sensible one based on perfectly sensible engineering tradeoffs, let me add; no criticism of such tools intended. Git's internals from what I've seen are not particularly difficult to manipulate directly as such things go, but you are simply by the nature of such a thing taking on a lot more responsibility than if you use the command line-based UI.

Another simple tracking thing that git doesn't do that would easily make git much much better is if it tracked when you did a cherrypick of another commit in the commit graph (not just as some kind of metadata comment in the commit message, but as a kind of soft parent); then if you did a rebase, you could actually "reverse engineer" the rebase (if and only if you absolutely needed to, such as to track what happened during a squash, or to automate re-applying the rebase correctly to someone who was tracking one of the prior commits) and it would largely solve the question of "merge or rebase" with "por que no los dos".

Another thing that Git does not track -

I saw a web designer check in a huge hierarchy of empty directories which would be the structure of the new project that their team should work on. They were quite surprised when it didn't show up on any of the other designer's computers after a "pull". They had to go to the "Git guru" for help.

Windows and Mac both have directories as a major fundamental concept. Everyone knows them and is familiar with them. Subversion tracks directories. Git does not.

I also can't figure out why it doesn't: An empty tree object should be sufficient to do the job. I actually had to write extra code in git9[1] to avoid accidentally allowing empty directories.

[1] https://github.com/oridb/git9

According to this[1], which I think might be an official FAQ:

> Currently the design of the Git index (staging area) only permits files to be listed, and nobody competent enough to make the change to allow empty directories has cared enough about this situation to remedy it.

[1] https://git.wiki.kernel.org/index.php/GitFaq#Can_I_add_empty...

Hm. I should see how git behaves when it gets a repository with empty directories. If it doesn't blow up, I may just add support -- it'd be useful for me.

It kind of does, iff you have a file there. In which case it tracks the path to the file, and then creates the relevant directory structure to get to it.

Of course git is also incredibly painful and brittle if you want "exclude/except" behavior on the gitignore involving subdirectories.

Another thing Git does not and cannot even attempt to do - file locking.

The assumption behind Git is, everyone develops on their machines and/or branches, and then things are merged. This only works for files which can be merged.

There are plenty of things pretty much any project wants to track which cannot be merged, for example Word documents (documentation), Photoshop files (source of graphics), PNGs (icons in webapps), and so on.

With a centralized system, that's easy, just go over to using file locks ("svn lock") for those files. With a distributed system, that's impossible.

> Another thing Git does not and cannot even attempt to do - file locking.

That's a seriously hard problem for a DVCS if you're serious about the "D".

This topic turned into [the single longest thread in the history of the Fossil forum](https://www.fossil-scm.org/forum/forumpost/2afc32b1ab) because it drags in the CAP theorem and all of the problems people run into when they try to have all three of C, A, and P at the same time.

To the extent that Fossil based projects are usually more centralized than Git ones, Fossil has a better chance of solving this, but I'm still not holding my breath that Fossil will get what a person would naively understand as file locking any time soon.

> Word documents (documentation), Photoshop files (source of graphics), PNGs (icons in webapps), and so on.

You want to avoid putting such things into a VCS anyway, because it [bloats the repo size](https://fossil-scm.org/fossil/doc/trunk/www/image-format-vs-...). I wrote that article in the context of Fossil, but its key result would replicate just as well under Git or anything else that doesn't do some serious magic to avoid the key problem here.

Instead of Word files, check in Markdown or [FODT](https://en.wikipedia.org/wiki/OpenDocument_technical_specifi...). (Flat XML OpenDocument Text.) Or with Fossil, put the doc in the wiki.

Instead of PNG, check in BMP, uncompressed TIFF, etc., then "build" the PNG as part of your app's regular build process.

This has the side benefit that when you later change your mind on the parameters for the final delivered PNGs, you can just adjust the build script, not check in a whole new set of PNGs. My current web app has several such versions: 8-bit paletted versions from back before IE could handle 24-bit PNG, then matted 24-bit PNGs from the days when IE couldn't handle transparency in PNG, and finally the current alpha-blended 24-bit PNGs. It'd have been better if I'd checked in TIFF originals and built deliverable PNGs at each step.

> Instead of Word files, check in Markdown or [FODT]

Another fun option is to unzip the DOCX and check that in, since it is mostly a collection of XML files in a zip container. I built a tool to automate zipping/unzipping files like DOCX years ago as pre-commit/post-checkout/post-merge hooks. [1] It's an interesting way to source control some types of files if you can find a way to deconstruct them into smaller pieces that merge better. Admittedly, merging Office Open XML by hand is not a great experience (and dealing with subtly broken or corrupt internal contents is not fun, because programs like Word can fussy when things are even slightly wrong), but you get better diffs sometimes than you would expect.

[1] https://github.com/WorldMaker/musdex

Yes, I cover that option for Fossil at the end of the pointed-to document. I did it in terms of Makefiles rather than commit hooks, but whichever...

> You want to avoid putting such things into a VCS anyway, because it [bloats the repo size]

How do you suggest projects like games handle this, where data files are naturally linked to source files? Imagine trying to sort out an animation bug when you only have source level tracking and no idea which version of the animation data corresponds to the animation source files of the bug report. These data files are not 'built' from the 'build' step as they are the product of artists.

I’d guess not one user in 100.000 uses git decentralized (as in, doesn’t have a blessed “central” repo). It’s the disabling of locking that should be the special case! The big problem with git is that you can’t mark a repo as a master repo/blessed repo (which would be the one where lockfiles are stored). A lot of functionality would be helped if the commands could know which end is the important/central one.

> I’d guess not one user in 100.000 uses git decentralized

I understand your sentiment, but the denominator in that fraction is probably much lower than your guess.

Consider even simple cases like the disconnected laptop case. You may work at a small office with only local employees, and so you have one central "blessed" repo, but if one person locks a file and then goes off to lunch, working on the file while at the restaurant, you still have a CAP problem:

CA: Because the one guy with a laptop went off-network, you have no full quorum, so no one can use the repo at all until he gets back and rejoins the network. (No practical DVCS does this, but it's one of the options, so I list it.)

CP: When the one guy went off to lunch, we lost the ability to interact with his lock, and that will continue to be the case until he gets back from lunch. Also vice versa: if someone still at the office takes out a lock, the guy off at lunch doesn't realize there is lock, so he could do something bad with the "locked" file. (This is the mode DVCSes generally run in by default.)

AP: No locking at all, thus no consistency, thus your original problem that inspired the wish to have file locking.

Not sure I understand the problem. If I lock fileX and go to lunch, then I own the lock on that file while I’m out to lunch. It’s basically analogous me pushing the file fileX.lock to the repo next to fileX, with my user id as content. I can only do it if it isn’t there.

Everyone else will only see that lock if they fetch and if they don’t, they might edit their local copy of fileX too, but would be prevented from pushing their version to the blessed repository by the lock. They can push a copy under another name, or wait until I have removed the lock (but probably can’t resolve the conflict anyway because it’s likely a binary document). So they user will remember to never start editing without taking the lock in the future.

It’s not perfect by any stretch of the imagination but it’s all anyone asks for in terms of file locking. It’s what Subversion always did.

> Not sure I understand the problem. If I lock fileX and go to lunch, then I own the lock on that file while I’m out to lunch.

And if you go on vacation for two weeks instead?

Same thing obviously. But this is just a method of communication. It’s instead of emailing/shouting “don’t edit the background image today please” across the office.

An admin can remove the lock. Or you can allow force-pushing by anyone to replace it or whatever.

Not sure why this is seen as so complicated, version control systems have done it since forever. It’s not trying to solve some distributed lock system in a clever way. It’s dumb centralized mutex per file. And yet again this is all that’s needed (and it’s also added to git in git-LFS!).

You can set up custom merge drivers for different file types.

More importantly, if you've got stuff in your decentralised repo that shouldn't be decentralised, that's not the fault of the DVCS you're using, it's your fault. That everything looks like a nail does not speak against the value of a hammer.

> You can set up custom merge drivers for different file types

True, but there are inevitably some files which still cannot be merged, so the problem remains.

> More importantly, if you've got stuff in your decentralised repo that shouldn't be decentralised, that's not the fault of the DVCS you're using, it's your fault.

Indeed, if you want to store the history of your files - the whole software including the icons it uses, so that you can go back to any previous version and build it - and you chose a DVCS like Git, I would agree the fault was yours.

That's basically what I was arguing, that Git is the wrong choice if you have any binary assets like icons (even if those assets have small filesize) due to the lack of locking, sorry if I was unclear.

You should not be checking in binary files into git. That defeats the entire purpose and bloats the repo size enormously.

Git LFS should be used instead. Or storing a Sha256sum and putting the file elsewhere.

That is a solution but then it's no longer distributed.

Being distributive isn’t a feature for the binary files contents. I don’t want 100 historical versions of a huge game texture, just the latest one. The history is distributed however, so I can see who changed the texture even when disconnected. Centralized binaries like git LFS works like any package/asset manager.

There is no one that would want distributed binaries in git. But people also don’t want to switch from git to something else just because they have a 100GB or 10TB repo. Tooling (build tools, issue management) everywhere has decided that git is all that’s needed.

Not putting binaries in git isn’t a solution at all. Binaries are part of the source in many applications (e.g game assets, web site images...). Distributing every version of every binary to everyone is also not a solution.

Maybe for your particular problem it's worthwhile to setup a CM policy for the (topic) branch naming. For example in your case something like: topic/alkonaut/version-1.0/foo or topic/alkonaut/master/bar.

Or use something like: git log --all --graph --oneline

One tip for "zigzag spiderweb" is to always rebase your topic branch to the target branch prior to a fast-forward merge to the target branch (e.g. master). To clarify: while in your branch topic/foobar: "git rebase master", "git checkout master", "git merge --ff-only topic/foobar".

(There's surely a clever shorthand for the above procedure but when it comes to the command line, I like to combine small things instead of complicated memorized things, it's some kind of Lego syndrome)

Rebase + FF solves the spiderweb problem by removing the branches. But some insist on keeping the branches and I don’t get why a “git log” doesn’t have (and default) to showing important branches as straight lines.

Also with dozens of tiny commands but only a handful of actual desired outcomes, the high operations should be explicit commands. E.g “rebase this branch on master and then squash it and commit on master”.

A lot of the local/remote could also be hidden. The number of times I want to rebase on my local master which is behind origin by 2 commits is... zero.

Said 80/20 was the idea behind Fossil, along the "easy to learn because similar to svn". Seemed a good idea. But lost to having a famous user, which the Linux kernel obviously is.

Reply on news.ycombinator.com