Knowledge Base

Details

Parent Category: Knowledge base

Category: GIT

After adding files before a commit you may get the following message on a Windows OS

$ git add .
# It is perfectly safe to see a lot of messages here that read
# "warning: LF will be replaced by CRLF in file."

One way to deal with this is to ignore the warning and then make sure that the default setting for Windows OS is globally configured like so:

git config --global core.autocrlf true

And configured like the following on Linux and Mac OS:

git config --global core.autocrlf input

That may not be enough if you want to make sure everyones system work as you want without needlessly requiring developers to change their system settings.

Instead we can set rules for line endings via the .gitattributes file:

# Set the default behavior for all files.
* text=auto

# Normalized and converts to 
# native line endings on checkout.
*.c text
*.h text

# Convert to CRLF line endings on checkout (Windows OS).
*.aspx text eol=crlf

# Convert to LF line endings on checkout (Linux & MAC OS).
*.sh text eol=lf
*.php text eol=lf

# Binary files.
*.png binary
*.jpg binary

After you have configured the core.autocrlf and committed a .gitattributes file, you will likely discover that Git wants to commit files that you have not modified. Git is able to change the line endings of every file for us.

So we should allow GIT to automatically configure our repository's line endings by first backing-up the files with Git, delete every file in the repository INDEX file, and then restore the index all at once.

1^st - Save the current files in Git, so that none of the work you did is lost.

$ git add . -u
$ git commit -m "Saving files before refreshing line endings"

2^nd - Remove the index and force Git to rescan the working directory.

 Linux / MAC OS:

$ rm .git/index

 Windows OS:

> del .git\index

3^rd - Rewrite the Git index to pick up all the new line endings.

$ git reset

4^th - Show the rewritten, normalized files.

$ git status

 5^th - Add all your changed files back, and prepare them for a commit. This is your chance to inspect which files, if any, were unchanged.

$ git add -u

6^th - Rewrite the .gitattributes file.

$ git add .gitattributes

7^th - Commit the changes to your repository.

$ git commit -m "Normalize all the line endings"

 

Details

Parent Category: Knowledge base

Category: GIT

Tagging can be used for anything, but is usually used to tag a specfic commit as a particular version or level of development and to specify something like an "alpha" or "beta" release.

Tip: Tag immediately after making the Commit you want the specific Tag to reference

My recommended simplified aproach. Use a .gitignore and then add, commit and push often, and tag only if needed before a push leaving annotations to commits - like so:

$ git add .
$ git commit -m "removed collate feature and invoked strict validation for version 2.0. Testing completed with no errors and ready for release"
$ git tag "v2.0"
$ git push origin master
$ git push origin --tags

 

List tags that has been used on your current system:

$ git tag

 

List tags matching a specific string:

$ git tag -l "v1.8.5*"

 

Annotating Tags using -a and -m operators

$ git tag -a v1.4 -m "my version 1.4 stable and ready for release"

 

Show tag data and the commit data

$ git show v1.4

 

Tagging a Commit, Multiple Commits Later

 First lookup a list of recent commits made in your current workspace or machine, where you plan to create a tag.

$ git log --pretty=oneline

This should produce a list somewhat similar to the following

15027957951b64cf874c3557a0f3547bd83b3ff6 Merge branch 'experiment'
a6b4c97498bd301d84096da251c98a07c7723e65 beginning write support
0d52aaab4479697da7686c15f77a3d64d9165190 one more thing
6d52a271eda8725415634dd79daabbc4d9b6008e Merge branch 'experiment' before go-live
0b7434d86859cc7b8c3d5e1dddfed66ff742fcbc added a commit function
4682c3261057305bdd616e23b64b0857d832627b added a todo file
166ae0c4d3f420721acbb115cc33848dfcc2121a started write support
9fceb02d0ae598e95dc970b74767f19372d61af8 updated readme.md
964f16d36dfccde844893cac5b347e7b3d44abbc commit the todo
8a5cbc430f1a9c3d00faaeffd07798508422908a updated readme

 

Now you should be able to identify the commit that is missing a tag. Suppose you forgot to tag go-live commit with a release v1.2, you can then do this by using just part of the checksum of the commit you want to tag

$ git tag v1.2 6d52a271

 

Pushing tags to a remote repository

By default, the "git push" command doesn’t transfer tags to remote servers. So to push a specific tag you can specify the tag like so

$ git push origin v1.5

If you want to just push all tags to the remote server

$ git push origin --tags

 

Deleting a Tag

$ git tag -d v1.4

This only deleted the tag on the machine you are working on. To delete the tag on the remote repository, do the following

$ git push origin --delete v1.4