28 Oct, 2011, Runter wrote in the 1st comment:
Votes: 0
I've found this to be a great resource for git.

http://book.git-scm.com/index.html
28 Oct, 2011, quixadhal wrote in the 2nd comment:
Votes: 0
For the most part, I've found git to be pretty straightforward, but there have been a few "gotcha" surprises along the way.

One I'll mention here, is the file renaming issue. Git doesn't directly track file renames, instead it automatically follows checksums to see when a rename happens. There are flags you can give it when viewing the history (or getting a diff) to try harder, but by default this means if you BOTH rename/move a file AND change it in the same commit, it will look like you deleted the old file and added a brand new one, thus losing your history.

In practice, this isn't usually a big deal, and there are flags that usually work to get around it, but if you need solid change histories, splitting your checkin into two stages, one where you rename the file ONLY, and another where you commit the actual changes, may be helpful.
28 Oct, 2011, Runter wrote in the 3rd comment:
Votes: 0
If you use git mv and git rm it shouldn't ever be an issue. I.e. avoid heuristics. Alternatively, you could simply commit immediately after any rename.

edit: Also after a rename you'd need to actually add the file before it detected it if you didn't use git mv. Using git add


I think I'm not understanding the actual problem. What's the problematic distinction between showing in the commit history that a file was renamed vs a file was deleted and another was created?
28 Oct, 2011, Runter wrote in the 4th comment:
Votes: 0
battlegalaxy:test jeffreybasurto$ touch file
battlegalaxy:test jeffreybasurto$ git add file
battlegalaxy:test jeffreybasurto$ git commit -am "added file"
[master 9f1b3ee] added file
0 files changed, 0 insertions(+), 0 deletions(-)
create mode 100644 file
battlegalaxy:test jeffreybasurto$ mv file moved_file
battlegalaxy:test jeffreybasurto$ echo "some content" > moved_file
battlegalaxy:test jeffreybasurto$ git add moved_file
battlegalaxy:test jeffreybasurto$ git commit -am "moved and added content"
[master db3ac03] moved and added content
1 files changed, 1 insertions(+), 0 deletions(-)
delete mode 100644 file
create mode 100644 moved_file



In this example, are you saying you want it to display in the commit log as:

1 files changed, 0 insertions(+), 0 deletions(-)
rename file => new_name (100%)


?
29 Oct, 2011, quixadhal wrote in the 5th comment:
Votes: 0
The problem is when you are trying to trace a set of changes through history… if git can't detect a file rename, you'll lose track of it at the point of the rename, since it will simply think the "new" file didn't exist before that.

git diff -M90, for example, says consider a delete/add pair to be a rename if the contents were 90% similar. If the changes were greater than 10%, it won't see it as a rename and you won't be able to follow the change history.

git log –follow will also have this issue.

In a large project, that can make for some annoying headaches if there have been many changes and reorganizations since the point you're trying to view.
31 Oct, 2011, oenone wrote in the 6th comment:
Votes: 0
Not really ruby related, is it?
31 Oct, 2011, quixadhal wrote in the 7th comment:
Votes: 0
oenone said:
Not really ruby related, is it?


Please die in a fire.

It's hard enough to get semi-useful discussions on the internet, without the categorization police adding their two cents, just to be spiteful. You should spend a paragraph nitpicking my spelling and grammatical errors too, while you're at it.
31 Oct, 2011, Runter wrote in the 8th comment:
Votes: 0
Well, it's a tool almost universally used in the ruby community. So much so that ruby services rely on git deploy hooks. Whether or not it's ruby, it's definitely worthy of being considered a tool of Ruby interest.
31 Oct, 2011, Tyche wrote in the 9th comment:
Votes: 0
oenone said:
Not really ruby related, is it?

Nope. Thread should be moved.
31 Oct, 2011, Runter wrote in the 10th comment:
Votes: 0
Tyche said:
oenone said:
Not really ruby related, is it?

Nope. Thread should be moved.


To the git forum? I insist all makefile threads be moved as well.
31 Oct, 2011, Tyche wrote in the 11th comment:
Votes: 0
There are several forums that are much more appropriate.

In regard to the side topic, it's tech zealotry that kills discussion.
(e.g.) See ruby core developer discussion on git.
31 Oct, 2011, David Haley wrote in the 12th comment:
Votes: 0
I was seeing a useful discussion of renaming subtleties in git before the "tech zealotry" killed the discussion. Oh well. Thanks for trying, Runter and Quix. :smile:

FWIW I've also been bit by git's handling of renames, although I've never used it heavily enough to really care about looking into it. This was a useful overview. (I've used bzr far, far more than git.)
0.0/12