cURL / Mailing Lists / curl-library / Single Mail


Re: [bagder/curl] 13606b: build: make use of 93 lib/*.c renamed files

From: Marc Hoersken <>
Date: Thu, 3 Jan 2013 21:05:20 +0100

Hi everyone,

2013/1/3 Yang Tse <>
> I count it as such. Let us give ourselves 24, 48 hours to let other
> express themselves, if they desire so.

generally speaking I like the idea of having a clear naming convention
in place, but I think that such fundamental changes should only be
made in major releases, meaning curl 8.y.z.

This means that I am not voting for this change to make it into curl just yet.

> If we were to revert the renaming commits, which would be the best
> approach in order to keep github's master repo history unchanged?
> In other words, is it possible, and how, to make all commits following
> commit ec691ca34b disappear from github repo, even if we have to
> manually re-commit other 23 unrelated commits that have been
> intermixed sinche the renaming of the header files?
> Or is history breakage already done no matter what we do? :-((

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.

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.

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. In my opinion the decision for or against the renaming
should now be based on other technical and organisational aspects,
like distributions and such.

Lessons learned: Please talk to the mailinglist before making
fundamental and/or disruptive changes in a public and central
repository like this. No offense intended.

Best regards,
List admin:
Received on 2013-01-03