Hacker News Reader

Comment by philsnow | Hacker News Reader

> I believe the core issue is devs like above never take the time to “grok” Git. I believe part of this is due to the lack of a tool like above to teach easily, but also because devs want to ignore the “how” of their tool working to find out the exact commands they need to run in their current situation.

Github is largely to "blame" for this. It mostly only exposes the happy path and using git kind of like any other VCS, but above all it ossifies the idea of git repositories being centralized (both because the canonical repo is always on github.com but also because of the forking/ownership model). A lot of the power (and sharp edges, and messiness) of git are in scenarios where everybody has a local repo and nobody's is really "canonical".

Git is really well-suited to development of the linux kernel. It's not.. amazingly well-suited for the job that 95% of people these days press it into?

View on HN

I think that the bigger problem is the misuse of Tags as the sole method of marking a commit for release for example.

Tags could be utilised for naming commits which would make it much easier to reason about where in the process of your development you are instead of referencing commits by hash. Hashes are hard to remember after all.

Except, if you rebase, your tags get "lost" (not really, but they still point to the same old commit unless explicitly changed). Log is your friend, and making sure that the commits make sense (they do a single well-defined thing) helps a lot, because you always know which commit does what. But yes, that means using `git commit --fixup <commit id> && git -i --autosquash <commit id>^1` frequently to fix existing (older) commits instead of making new trivial ones.

why are you rebasing a branch that has tags?

in my opinion (the one where i don't care what anyone else thinks kind) you shouldn't be using tags on your working branches and your mainline/release branches should only be the ones where tags exists.

This then means that the only place you should be rebasing is your working/feature/pr branches and that when you merge your working/feature/pr branch, it should get squashed into the target branch... No one cares about your fifty gazillion 'wip' commits.

I guess that's the parent's annoyance. It'd be nice to be able to use something like tags or labels for other things than releases, but since they're commit referents, they're pretty much only useful for releases and nothing else.

I was responding to GPs idea to "name" commits with tags, so you've taken my comment out of context.

Why not use branches for that? That's often for people to it.

This is called a branch in Git.

Mutable names should be branches, in my opinion, but not because I think tags are only for releases. I will absolutely use local-only "light weight" tags to name immutable points in time that look nothing like releases (and try not to push them accidentally; this is something that I think git's UI could be better about, it's an expected pattern which is why `git push --tags` or `git push --follow-tags` is a separate action by default from normal push, but `git push --tags` which is mostly all-or-none is much more convenient than patterns that push individual, specific tags). I just feel strongly if it is a mutable reference point it needs to be a branch.

Branches are so cheap in git that there's little to no reason to not use a million branches to name every step in a process if you need to, and yeah if you need a long-term name for a specific commit local-only lightweight tags are handy for that. (I find lightweight versus annotated an often easy enough distinction between tags intended for local development and tags intended for release markers. This also seems to be intentional in git UX because of the way `git describe` by default skips lightweight tags.)

I agree with your position. Our use case at the company I mentioned above was ten developers, all physically co-located, actually all operating on the same 3 or 4 servers. A centralized VCS was a better fit to our development needs. In situations where the problem space is centralized, applying a distributed tool is using the wrong tool for the job.

Reply on news.ycombinator.com