1

I've physically deleted a file and created a new one somewhere else with a new name. I do not want the history from the old file to carry over to the new file. I want the old file to be seen as deleted and the other file to be seen as new.

If git picks these up as a move when I stage the two files, how can I tell it to not automatically detect moves for just those files?

I'm using git 1.9.2 on Windows.

void.pointer
  • 24,859
  • 31
  • 132
  • 243

1 Answers1

1

On a move operation git won't follow the history unless you use the --follow flag. As far as Git is concerned, since its mostly the same contents, it is a "move".

There is a good summary of what a "move" is here

Community
  • 1
  • 1
jeremy
  • 4,294
  • 3
  • 22
  • 36
  • My understanding is that a rename is really just there for conflict resolution and history persistence. If I don't want either of these, why should GIT still mark the two files as related? At the very least it is confusing based on common expectations of what a VCS "move" is. – void.pointer Apr 24 '14 at 15:56
  • 2
    `git` doesn't store a "move" or "rename" at all - it simply stores the current state of the working tree. It detects move/rename/copy operations when you do various things like `git log`. `git log` in particular has many options you can use to tune or even disable the detection if you want (e.g. `--no-renames`, `-B`, `-M`, `-C`...) – twalberg Apr 24 '14 at 16:44
  • @twalberg I see that as a defect then, because imagine if this new file was meant to have a clean history, then a month later I did actually intend for it to be moved. If I did `--follow`, I'd see 2 moves: The oldest one being the one that it shouldn't have recorded, where the file was meant to be completely new... and the newest move which would be a legitimate move. There's ambiguity here. How will I know a year later that this file wasn't moved twice? The semantics may not matter to GIT, but it matters to people. – void.pointer May 02 '14 at 13:03
  • If you want to better understand the reasoning behind this, see [this](http://permalink.gmane.org/gmane.comp.version-control.git/217) – jeremy May 02 '14 at 16:27