4 ms·

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 wha

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.

hueving 12y ago
>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?
- je42 12y ago
  I really like to use '/' to create folders. Git (X) has a nice GUI for this naming convention.
- iamthebest 12y ago
  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 12y ago
    It gets even uglier when you don't discover those conflicts until a pull or push.
  - maddening 12y ago
    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.
Fede_V 12y ago
> 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 12y ago
  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.html#_on_re_tagging https://www.kernel.org/pub/software/scm/git/docs/git-tag.htm...
- eyko 12y ago
  > 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 12y ago
    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 12y ago
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 12y ago
> 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 12y ago
  It's a gotcha for anybody, like me, that expects a branch name to be 'just' a string.
  - tenken 12y ago
    So you don't organize anything in a hierarchy ... how 1980s of you.
  - philjackson 12y ago
    Yea, perhaps it's worth being explicit about it in the documentation, if it's not already mentioned.
andyjeffries 12y ago
"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 12y ago

>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?

je42 12y ago
I really like to use '/' to create folders. Git (X) has a nice GUI for this naming convention.
iamthebest 12y ago
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 12y ago
  It gets even uglier when you don't discover those conflicts until a pull or push.
- maddening 12y ago
  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.

Fede_V 12y ago

> 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 12y ago
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.html#_on_re_tagging https://www.kernel.org/pub/software/scm/git/docs/git-tag.htm...
eyko 12y ago
> 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 12y ago
  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 12y ago

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 12y ago

> 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 12y ago
It's a gotcha for anybody, like me, that expects a branch name to be 'just' a string.
- tenken 12y ago
  So you don't organize anything in a hierarchy ... how 1980s of you.
- philjackson 12y ago
  Yea, perhaps it's worth being explicit about it in the documentation, if it's not already mentioned.

andyjeffries 12y ago

"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...