11–20 of 38 posts
It looks like this is a list to get to you intermediate level in git, as opposed to tips for already intermediate git users . I would have liked to see some points about git-bisect, hooks, etc.
Earlier quoted context omitted.
>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…
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/f…
The master tip: have a detailed written policy on git usage, on what goes into which branch, on git commit message format, and make really, really sure everyone understands it before they start anything. No tips will help if the history is crap.
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 inc…
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.
The master tip: have a detailed written policy on git usage, on what goes into which branch, on git commit message format, and make really, really sure everyone understands it before they start anything. No tips will help if the history is crap.
Is there some kind of git plug in/linter that will check for commit style before accepting a commit? Basically, linting the commit messages.
Look in any git project's .git/hooks/ directory for some sample scripts.
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 inc…
> 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…
[0] https://www.kernel.org/pub/software/scm/git/docs/git-tag.htm...
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 inc…
Of course, we might have issues if we named a branch `feature` or `hotfix`, but that's never been an issue for us.
Earlier quoted context omitted.
>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…
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/f…
But its a global policy so "wp" and "wp/BTS-number" will always be a folder, and conflicts should never happen.
A tip for intermediate and professional users to avoid headaches: http://subversion.apache.org/