I'm looking at starting to use Gitflow. I notice that by default the branches end in forward slashes.
I.e.
hotfixes/
releases/
Etc.
Does the forward slash cause any problems as git uses a forward slash as a folder delimiter.
Will it cause any problems with deployment from git with the forward slashes in it?
Could we use another prefix such as hyphen?
What are the pros and cons of either method.
Thanks in advance
I'm going to re-order these questions a bit.
Could we use another prefix such as hyphen?
You can use any name format you want, as long as you respect the limitations of your own OS (operating system—Windows, MacOS, Linux, and so on). Using a hyphen does not fix the limitations.
Does the forward slash cause any problems as git uses a forward slash as a folder delimiter.
Git doesn't use it this way; it's your OS that does. The file path name a/b means "find name b within directory a", even on Windows.
Will it cause any problems with deployment from git with the forward slashes in it?
Not if you avoid one your OS's limitations. Let's take a quick look at those.
Background
Git will, at various times, write branch names (or any other reference names) into a path rooted in the .git/refs/ directory. The "full name" of any branch B is refs/heads/B, e.g., refs/heads/master, refs/heads/develop, refs/heads/feature/tall, refs/heads/bugs/short. These will wind up creating files named .git/refs/heads/master, .git/refs/heads/feature/tall, and so on. In each of these files, Git stores a simple value: the hash ID of the target object (a commit hash, for branch names).
At other times, Git will write all these names into a single "flat file": essentially, a really poor substitute for a key-value store database. Whenever Git uses its own database, rather than the operating system's file system, Git avoids the OS's limitations. But since this is not all the time, you must respect your OS's limitations.
A directory (or "folder") is never a file, and vice versa
Suppose you have a branch named x. This means Git sometimes creates a file named .git/refs/heads/x to hold the tip commit hash ID for x.
If you now try to create a branch named x/y, Git may need to create a file named .git/refs/heads/x/y to hold the tip commit hash ID for x/y. But there is already a file named x, so it becomes impossible to create a directory named x holding a fie named y.
This means you must avoid using one name that becomes a prefix of the other when / is treated as a path name separator.
(This same rule applies to the names of remotes. You may, if you like, name two different remotes hq/a and hq/b, but if you do that, you must not name any remote hq.)
Case folding
Suppose your OS folds case. That is, suppose that you create a file named ReadMe.txt and then ask to open or view or create-or-write a file named readme.txt. Does this make a new file readme.txt that is different from the existing ReadMe.txt, or does it re-use the existing ReadMe.txt? If your OS re-uses the existing ReadMe.txt, your system folds case: it retains the uppercase and lowercase mix you use when you first create a file or directory, but from then on, use of any name that resembles the original name, but has a different mix of upper- and lower-case letters, will wind up re-using the original case.
That means that if you create a branch named master, and then try to create another branch named MASTER, your OS will re-use the lowercase name. This will, in a sense, "confuse" Git: Git thinks that master and MASTER are different branches, but your OS insists that the two different branch values be stored in a single file.
The same applies to directory names within the path. If you name one branch feature/tall and a second branch Feature/wide, Git will think that the second branch should always be named Feature/wide—but when Git goes to create a new file .git/refs/heads/Feature/wide, your OS says to itself: "Aha, I should re-use the existing lowercase-f feature directory and create this as .git/refs/heads/feature/wide." This once again confuses Git.
When this situation occurs, the behavior is somewhat hard to predict. If your OS does case folding on files,1 you should avoid the situation entirely. A good practice here is to pick one case—usually lower-case only—and stick with that.
1Modern OSes, including Linux and MacOS, actually choose whether to do case-folding on a per-file-system basis. This means you can set up a file system that is fully case-sensitive—file readme.txt is entirely different from file ReadMe.txt—and use that, to work around problems with branch names. However, Linux defaults to fully case sensitive for all its native file systems anyway.
Unicode normalization
Case folding, as performed by operating systems, tends to be limited to ASCII: they may not have a concept of an uppercase é, for instance. This is especially true if they use Unicode to represent "non-ASCII" characters (accented characters, Arabic, Chinese, Cyrillic, Hangul, Hebrew lettering, and so on). But if the OS supports Unicode at all for these wider character sets, it often uses UTF-8 encoding,2 which "hides" the Unicode encoding from the OS-level operations, which treat path names as strings-of-bytes. The "higher order" non-ASCII characters, even encoded, never clash with the ordinary ASCII characters such as /, so that when the OS uses / to choose to make or use a directory, this does not affect the non-ASCII characters.
The process of Unicode normalization is a bit mysterious to those who have not experienced it. See the Wikipedia page on Unicode equivalence for details, but in short, consider the idea that ü might be expressed as a single character "u with umlaut", or as the combining sequence "umlaut, u". If the OS wants to fold case, it probably should also treat these two distinct byte-sequences as naming the same file.
MacOS performs Unicode normalization to deal with this (NFD in HFS+; see this StackOverflow posting and its various links). This too affects Git (which, since Git version 2.1, has code to deal with it, though there was a bug fix as late as Git 2.8.4). I have no experience with it, but in general I would just advise avoiding the problem: stick with simple ASCII branch (and other reference) names.
2Windows uses UTF-16-LE, but the effect is similar.
The only problem I encountered is that if you have master branch you cannot create a branch named master/foo/bar because it starts with an already branch name.
I use [fix/feature|path]/{issue-number}/[description/]{destination} pattern
examples:
fix/42/master tells that this branch/pr is a fix of issue number 42 on master branch
feature/23/1.4 tells that this is a feature 23, for next minor release 1.4
and again
feature/123/create-red-button/master add a red button (the card number 123) on master branch
and so on
Currently you can set a different suffix when initialize gitflow with git flow init like this:
❯ git flow init
No branches exist yet. Base branches must be created now.
Branch name for production releases: [master]
Branch name for "next release" development: [develop]
How to name your supporting branch prefixes?
Feature branches? [feature/] feature-
Release branches? [release/] release-
Hotfix branches? [hotfix/] hotfix-
Support branches? [support/] support-
Version tag prefix? [] v
As you can see, in brackets are the default values (forward slash as suffix), but you can overwrite it with yourbranchname- (dash at the end)
I am looking at the vim help files and looking for a variable on the linux version that is like v:completed_item from cygwin. v:completed_item is a:
Dictionary containing the complete-items for the most recently completed word after CompleteDone. The Dictionary is empty if the completion failed.
I am looking for the same thing for Linux but I cannot find it and the closes thing I can find in the ins-completion help file is complete-item but nothing on how to use it anyone know how to use it? And if it will be the same as the completed_item from the cygwin version?
Thanks
The presence of a feature doesn't depend on the platform, it depends on the build type, version number, and patch-level.
If you want feature parity between two environments, you rather obviously must install the same build type and version number (including patches) on both environments.
FYI, that variable was added in patch 7.4.774.
A lot of projects (e.g. Linux) prepend v to their git version tags, e.g. v3.19 which makes parsing of those tags harder for no obvious reason. What's the sense of doing that?
As mentioned in "Is there a standard naming convention for git tags?":
The reason for the preceding 'v' is historical.
Older SCCS (cvs,rcs) could not distinguish between a tag identifier and a revision number.
Tag identifiers were restricted to not begin with a numeric value so that revision numbers could be detected.
That convention is not enforced with Semantic Versionning in its 2.0 revision. It was in its 1.0 revision:
When tagging releases in a version control system, the tag for a version MUST be "vX.Y.Z" e.g. "v3.1.0".
The fact it is no longer enforced shows how optional that 'v' can be.
I'd like to list the modified files at before-build time, in order to increment various build numbers.
For example, if a javascript has been modified, I increment the client-code version number,
if a cSharp file has been modified, I increment the server-code version number.
Do you know if there is a way to do it?
Thanks,
R.
When looking at perforce depot in P4V, an xml file would be read some_file.xml #3/3 <text>. What does this #3/3 mean?
I have files that are #0/1, and do not end up in my workspace when I sync. Scrolling over it gives "not synced in your workspace". Are these related?
The number to the left of the slash is the revision of that file that you have in your workspace, the number to the right of the slash is the number of revisions of that file that exist on the Perforce server. If you see some_file.xml #n/n <text> you have the latest revision of that file (the numbers match).
If you see a zero on the left side of the slash (e.g., some_file.xml #0/n <text>), that means the file exists in version control, but it does not exist in your workspace.
If the number on the left is anything between 0 and n, you have some previous revision of the file. P4V will indicate this with a yellow triangle.
#3/3 means you have version 3 and the maximum version available is 3
#0/1 means you have code that is not committed to your workspace (I don't think the 1 has any significance other than adding this version will produce version 1).
Looking at the documentation, I think more generally the meaning is "yours/theirs". In this case, I would see #0/1 as meaning you don't have a version locally, but there is a version available. Therefore if you sync, you'll get the version locally and hence has #1/1.