Hacker News Reader

Comment by 411111111111111 | Hacker News Reader

It's usually not necessary for checkout either

Not typing it with "checkout" gets in the way of good tab completion. At work we have at least tens of thousands of branches and if I hit tab after "git checkout file_path_prefix", my shell is going to freeze for a while, while tab completion is going over remote branches.

How do you end up with that many branches? It sounds like you keep every feature branch around forever. Keeping one around for a few months I get (although personally the sooner they're gone after rebasing or cherry-picking them the better), but this sounds like a full on history of every branch ever.

If someone pushed a branch to remote, then there is a chance that they made a CI build for a customer based on that branch. Later you may need that branch to look at the source code, when you get a coredump, or logs or something.

(Every non-official build is made from a separate branch.)

Deployed versions that need to be referred to later usually get git tagged, but those are not that much different from branches of course (they'll both show up in autocomplete as a committish object). But even then; tens of thousands of tags/branches? At that point it might be worth considering simply baking in the git commit hash into the build artefact for future reference instead of tagging every CI build with a branch/tag.

When I say "non-official", I say that it has some commits that aren't on the main branch. You need to push them somewhere, or else they're going to be lost.

You may not have much choice in the matter, but this level of complexity is where I would strongly recommend a (slightly) more complex architecture.

It's apparently a business requirement to keep every branch around forever, and I'll just take your word for that. At that point, you can have an `origin` remote where work happens, and the CI can include a push to an `archive` remote which is append-only.

Lets you have a development environment where the existence of a branch on origin means that it's in-play, and everything exists on archive if it proves needful.

tags might be a more suitable way of... tagging those releases for future reference ?

https://news.ycombinator.com/item?id=28025573

What does -- do exactly?

-- in git is usually used to mark the end of options. After --. --foo means an argument --foo, not the option --foo.

Git checkout and a few other commands also use it to separate branch and the rest of paths, because you could specify like this

    git checkout branch path1 path2
    git checkout path1 path2
    git checkout branch # what if there's a file named "branch"?

-- help disambiguates that by being between the branch and the paths, so

    git checkout branch -- # always checkout a branch
    git checkout -- path1 path2 # always checkout paths
    git checkout branch -- path1 path2 # same, but disable disambiguation logic

it is used for that purpose in many other tools as well (grep, for example)

Reply on news.ycombinator.com