4

I'm looking at using Git for local developer VCS support (this is for multi-diciplinary development).

Previous practice was that the top level directory would be renamed (and a zip copy kept) for each trial version. It was reasonably effective for 1-2 person teams. Beyond Compare was used between versions.

However a quick try applying Git to the method shows that it 'thinks' that files are deleted and new one created, rather than simply being on a new path.

Thus we have

\GIT-Dir  
  \.git
  \Master-with-updating-version-name1  
    \ProjectName  
      \Source  
        files.etc

becomes

\GIT-Dir  
  \.git
  \Master-with-updating-version-name2  
    \ProjectName  
      \Source  
        files.etc

and then 

\GIT-Dir  
  \.git
  \Master-with-updating-version-name3  
    \ProjectName  
      \Source  
        files.etc

Given that I will need to keep alive the old method during the transition, what are the options?
a/ How to get Git to realise that it is simply a path update?
b/ how to make sure that the lower level files become properly tracked & diff'ed?

I'm on Windows, using GitGui 0.13, and git 1.7.4.msysgit.0, and have GitExtensions 2.21 installed

Kara
  • 5,650
  • 15
  • 48
  • 55
Philip Oakley
  • 11,745
  • 8
  • 42
  • 63

2 Answers2

3

Git doesn't track renames, it retrospectively determines them as part of the log and show commands. You don't ever have to explicitly rename/move a file or directory using the git commands.

Renames are determined by a difference threshold, if there's been an addition and a deletion of a file and the content is sufficiently similar, then git will consider it a rename/move.

If you rename your directory outside of git, then do a git status, you'll see it's picked them up as a deletion. Now add them both to your index (git add -A will do it), you should now see it sees them as a rename.

James Gregory
  • 13,857
  • 2
  • 39
  • 58
  • It didn't for my toy test. I'll have to try with larger files - what's a good minimum size? – Philip Oakley May 05 '11 at 17:39
  • I'm getting different results (that is the two displays imply different things). The `git add -A`, followed by `git status` says that we have a rename, yet the Git Gui still displays the situation as being a deletion and creation of a new file (this is just before doing a commit) – Philip Oakley May 05 '11 at 19:47
  • just tried `git whatchanged -r` (within git bash) and it shows additions and deletions of files, but at the same time shows the content blob sha1's as unchanged (except where I did deliberate changes to see if the diff would catch it) – Philip Oakley May 05 '11 at 21:25
  • 1
    Git Gui isn't perfect and doesn't do a lot of what the command-line can, trust the command-line. Have a read of the [Git community book](http://book.git-scm.com/) or [Git Pro](http://progit.org/) about how Git treats content. It's counter-productive to think in terms of files and directories most of the time. If the hashes are the same, then git will treat them as a move/rename. – James Gregory May 06 '11 at 08:19
  • 1
    @James Gregory: Thanks for the update. It looks like I'll have look at (supporting) the GitGui itself, as it's current response isn't likely to be acceptable to the community I'll be trying to promote Git to. It is awkward when our current simple/dumb/effective approach doesn't match the GitGui viewpoint. I need the presentational issues to present well (obviously;-) – Philip Oakley May 06 '11 at 09:45
  • If it's a GUI you're after, there are better ones out there than git gui. It'll depend on your platform, obviously, but there's a list of [GUIs here](https://git.wiki.kernel.org/index.php/Interfaces,_frontends,_and_tools#Graphical_Interfaces). I've always thought of git gui as a useful tool for command-line users who occasionally want to see something in a GUI, but I wouldn't use it full time. – James Gregory May 06 '11 at 10:16
2

On the command-line, you'd rename a file or directory with git mv. Your GUI should have an option for this.

Fred Foo
  • 328,932
  • 68
  • 689
  • 800
  • The gui's don't appear to have a command (or menu item) for it. I've tried it via a git bash window, and I still get that Git says (after a rescan from Git Gui) that, for this branch, the files in the old directory are deleted and new ones created in the new directory, rather than showing that they (a) have been renamed (re-pathed), and then (b) showing the diffs for the changed files. – Philip Oakley May 05 '11 at 15:36
  • @Philip: then your GUI is lacking. It doesn't matter though, because Git will never store to two identical files in the repo due to its hashing. – Fred Foo May 05 '11 at 20:54
  • It happens in the git bash as well (see my comment in reply to James Gregory). You are right that it is only storing the common content the once, but then goes on to report that everything changed :-( – Philip Oakley May 05 '11 at 21:41