GIT

So git is pretty cool, however I feel it has been modeled in Linus' image, so it's his way or the highway.

One thing that is bothering me a lot is that you can't specify copy sources. Now, if you're copying or moving a file normally, passing enough -Cs might do the trick, as long as the code is also present (or being removed) somewhere in the same commit.

However consider this scenario. Let's assume a linear history for simplicity. On some rev you delete a file, you don't think you'll need it anymore. 10000 revs later, you suddenly want it back.

Now, on svn, you just copy the file from the old revision inside the repo, using svn copy. In git, all you can do is add the file back. However at this point the history is effectively lost (for commands like log or blame). Of course it's still in the repo and if you can remember the original file you might manually look for it, but it's pretty useless compared with svn.

So how would you handle this specific case? Does mercurial support this better? I heard somewhere it supports copies. However I also heard if you delete a file and later add one with the same name, you'll get the log entries of the old file too, which is also wrong (maybe less so).

>>1
how dare you question linus!

There's probably another way of doing this.
The best workflow for git is quite different then that in svn.
First thing comes to mind would be doing something to the effect of:
git checkout YE_OLDE_TAG
git branch OLD_SHIT
git checkout master
git merge OLD_SHIT
git checkout HEAD # Resolves all conflicts with OLD_SHIT
git rm ... # old stuff you don't want
git commit
It's not as straightforward as
git checkout OLD_SHIT file.c
but gets the job done if you really need it.

>>3
different then that
Get the fuck out.

If git were so Linus-like then why is everybody on Github using macs?

>>3
I tested this. It didn't work. The merge doesn't merge anything, seeing as there are no new changes for that file.