On Thursday, January 03, 2013 21:05:20 Marc Hoersken wrote:
> I think it's too late to fix the history without actually rewriting
> it. Even reverting or manually undoing the rename, which would
> basically result in the same changeset with regards to git, would
> still result in a "hole" or "jump" in the history of each file. And
> since the git repository is public and mirrored all over the world,
> rewriting history is not an option.

Yes, rewriting the upstream history sounds like unnecessary overkill. That
would be an option in case somebody pushed a non-distributable contents by
mistake or something like that.

> I haven't tested this myself, but from my experience with previous
> renames, GitHub and all the other tools in the git ecosystem will show
> you the history till the last rename, but won't automatically follow
> the history before that point.

I am not sure about the web interface of github, but you can still use
'git log --follow' to list the history of a file beyond renames.
 
> And this basically renders my vote obsolete. Either way, the git
> history is now written and this means that it can't be the reason for
> a decision.

I disagree with the above statement. If we revert the mass rename now, all
bug fixes committed from now on will be easier to cherry-pick for the old
versions of curl.

Kamil
-------------------------------------------------------------------
List admin: http://cool.haxx.se/list/listinfo/curl-library
Etiquette: http://curl.haxx.se/mail/etiquette.html
Received on 2013-01-03