[iamthebest]

This looks like a set of notes that are mostly correct but encourage bad practices. I think it's because they author doesn't understand git and doesn't know what they are doing.

>A lightweight tag is simply a named pointer to a commit. You can always change it to point to another commit.

Umm, you can do this, but in general you should never rename tags. Occasionally a developer will tell me the tag they pushed is incorrect and I'll agree to remove it only if they promise not to re-create it. If you read the man page on git-tag it's clear why you should avoid doing this.

>A lovely little tip – don’t forget that branch names aren’t limited to a-z and 0-9. It can be quite nice to use / and . in names for fake namespacing

If you use '/' is branch names you can create path conflicts. I've seen it happen and it took me a day to debug and figure out. There is some code checking for path conflicts in the git source but it's not invoked via all code paths that create branches. I recommend against using slashes in branch names unless you know what you are doing.

[andyjeffries]

"I think it's because they author doesn't understand git and doesn't know what they are doing."

Thanks for your kind comment...

I would like to point out that this article is over 4 years old (hence my knowledge will have increased since then) and it was also basically my notes on our training with Scott Chacon of GitHub. I'm sure you wouldn't consider him to not "know what [he is] doing". Maybe it reflected best practices at the time the training was delivered and the article was written.

Anyway, I appreciate it's resurgence in popularity...

[hueving]

>If you use '/' is branch names you can create path conflicts. I've seen it happen and it took me a day to debug and figure out. There is some code checking for path conflicts in the git source but it's not invoked via all code paths that create branches. I recommend against using slashes in branch names unless you know what you are doing.

Can you elaborate on this? What you said doesn't make much sense. If having a slash in the branch name creates path conflicts, that means slashes are treated specially, right? How exactly does someone 'know what they are doing' to be able to use them?

[iamthebest]

Yeah. For example:

  $ git branch fireos
  $ git branch fireos/feature-branch
  error: unable to create directory for .git/refs/heads/fireos/feature-branch
  fatal: Failed to lock ref for update: No such file or directory

This happens because creating 'fireos' branch stores the sha1 in file .git/refs/heads/fireos. But if you later want to create branch 'fireos/feature-branch', git needs to store the sha1 in .git/refs/heads/fireos/feature-branch. This is impossible because 'fireos' is a file and cannot be a directory. Path conflict.

[JoshTriplett]

It gets even uglier when you don't discover those conflicts until a pull or push.

[maddening]

It can be solved with a right branch naming policy. E.g. where I work we usually name branches like "wp/BTS-number/1" for first attempt to do the BTS-number task, "wp/BTS-number/2" when we somehow need to try another approach or rebase or squash history, "wp/BTS-number/3" for next attempt and so on.

But its a global policy so "wp" and "wp/BTS-number" will always be a folder, and conflicts should never happen.

[je42]

I really like to use '/' to create folders. Git (X) has a nice GUI for this naming convention.

[Fede_V]

> Umm, you can do this, but in general you should never rename tags. Occasionally a developer will tell me the tag they pushed is incorrect and I'll agree to remove it only if they promise not to re-create it. If you read the man page on git-tag it's clear why you should avoid doing this.

I'll take your word for it, but the git man pages are notoriously unreadable. They might be useful for a git guru, but for someone that is learning the commands they are downright harmful.

[qznc]

On the git-tag help page, there is a section "On Re-tagging" [0]. It looks quite readable to me.

[0] https://www.kernel.org/pub/software/scm/git/docs/git-tag.htm...

[eyko]

> I'll take your word for it, but the git man pages are notoriously unreadable. They might be useful for a git guru, but for someone that is learning the commands they are downright harmful.

Can you elaborate? I'm definitely not a git guru and I always read the man pages, and I find them quite readable. It's also the first place I learn best practices from.

[Fede_V]

Sure. I think this is largely a matter of preferences in pedagogy, but when I'm looking to learn something, I like to have heavily annotated examples that get progressively more complex.

Listing every option with a description, to me, is not as useful as seeing it in practice.

[BrandonM]

We use slashes at our company as a manner of course, and we've had no issues. We name all our features as `feature/i18n` and our bug fixes as `hotfix/ie-promises`.

Of course, we might have issues if we named a branch `feature` or `hotfix`, but that's never been an issue for us.

[philjackson]

> If you use '/' is branch names you can create path conflicts.

You could say the same thing about filesystems though. Not sure this is an issue.

[ghswa]

It's a gotcha for anybody, like me, that expects a branch name to be 'just' a string.

[philjackson]

Yea, perhaps it's worth being explicit about it in the documentation, if it's not already mentioned.