On Sun, Jan 6, 2013 at 6:23 PM, Yang Tse yangs...@gmail.com wrote:
I'm pushing revertion commit in... 3, 2, 1.
Thanks to all,
Thanks Yang. I'm happy to see that 'git log -- filename' now shows
the full history exactly as if there had never been any renaming, so
we don't need to add any
Hi friends,
List of those who have expressed their opinion on reverting the
lib/*.[ch] renaming, after I said that the revertion commit is ready
for pushing and requested reassurance on pushing it or not:
Marc Hoersken - Don't revert renaming.
Dave Reisner - Push revertion commit.
Oscar Koeroo -
Hi friends,
List of those who have expressed their opinion on reverting the
lib/*.[ch] renaming, after I said that the reversion commit is ready
for pushing and requested reassurance on pushing it or not:
Marc Hoersken - Don't revert renaming.
Dave Reisner - Push reversion commit.
Oscar Koeroo -
Hi Yang,
I would appreciate this list gets populated, at least, with every
one's name which have posted in this thread. In case I've
misinterpreted the decision of anyone listed above, please
speak up and I'll fix as desired.
I'm still more in favour of going back to the old names and
I'm also in favour of reverting the name change, but it'll be what it'll be.
But I hope that at least it'll be obvious to everyone that it's a good
idea to publish suggested patches to the list before committing,
unless it's really trivial or clearly right (as in fixing typos
preventing builds),
Hi friends,
Updated list of those who have expressed their opinion on reverting
the lib/*.[ch] renaming, after I said that the reversion commit is
ready for pushing and requested reassurance on pushing it or not:
Marc Hoersken - Don't revert renaming.
Dave Reisner - Push reversion commit.
Oscar
Steve Holme steve_ho...@hotmail.com wrote:
I'm still more in favour of going back to the old names and reverting the
change.
Me too.
--gv
---
List admin: http://cool.haxx.se/list/listinfo/curl-library
Etiquette:
On Sat, Jan 05, 2013 at 02:29:19PM +0100, Gisle Vanem wrote:
Steve Holme steve_ho...@hotmail.com wrote:
I'm still more in favour of going back to the old names and reverting the
change.
Me too.
I am as well.
Dan
---
List
Hi friends,
Updated list of those who have expressed their opinion on reverting
the lib/*.[ch] renaming, after I said that the reversion commit is
ready for pushing and requested reassurance on pushing it or not:
Marc Hoersken - Don't revert renaming.
Dave Reisner - Push reversion commit.
Oscar
As a user of libcurl, I've expressed a preference for the renaming. However,
it's only my two cents' worth; I don't know enough about the version control
situation, or other implications, to make a formal vote or recommendation,
sorry!
Tom
On Jan 5, 2013, at 1:05 PM, Yang Tse
On Fri, 4 Jan 2013, Yang Tse wrote:
First: thanks a lot for your calm and sensible approach to this Yang.
If the above mentioned two workarounds are not enough to overcome so called
'breakage of history across renames' it is not libcurl's fault, It is simply
git's and github's idiosyncrasy,
Hi,
I've re-read all messages in this thread a couple of times, if you
wish to reply to this message, please, don't do it until you've read
it fully ...
In first place. I apologize for not bringing to the list the renaming
change before pushing it to the public repo.
Thanks to all for the
Hi everyone,
2013/1/4 Yang Tse yangs...@gmail.com:
Hi,
I've re-read all messages in this thread a couple of times, if you
wish to reply to this message, please, don't do it until you've read
it fully ...
thanks for this summary, Yang.
Before pushing this reversion, I'm here asking you all
On Fri, Jan 04, 2013 at 06:01:45PM +0100, Marc Hoersken wrote:
Hi everyone,
2013/1/4 Yang Tse yangs...@gmail.com:
Hi,
I've re-read all messages in this thread a couple of times, if you
wish to reply to this message, please, don't do it until you've read
it fully ...
thanks for
On 04-01-13 16:51, Yang Tse wrote:
So please, either way express yourselves again. I don't want to goof
it twice in a row.
I'm (still) in favor of filename change. The old names also surface easily
on a shell if you have tab-completion.
My motivation is simply my own experience in addressing
GitHub nore...@github.com i.e. Yang Tse wrote:
93 *.c source files renamed to use our standard naming scheme.
..
A lib/curl_amigaos.c
A lib/curl_asyn_ares.c
A lib/curl_asyn_thread.c
A lib/curl_axtls.c
A lib/curl_base64.c
A lib/curl_bundles.c
Okay, but now we can say
Hi Daniel, Gisle, and all,
The renaming of lib/*.h which already were not named curl_*.h to
curl_*.h, and renaming lib/*.c which already were not named curl_*.c
has at least the following intended benefits over the non-renamed
sources:
Relative to the header files...
1) We are able to guarantee
On Thu, 3 Jan 2013, Yang Tse wrote:
1) We are able to guarantee to a higher degree that the headers being
included are actually libcurl ones.
I'm not a fan of fixing *potential* problems. We've managed fine for 14 years
with this naming, I don't see anything new on the horizon that suddenly
On Thu, Jan 3, 2013 at 12:35 PM, Daniel Stenberg dan...@haxx.se wrote:
Further downsides with the renames:
* Patches for older curl versions now suddenly don't apply anymore and will
give us (and others) much more work to apply. This will not only affect a
couple of patches that I have
On Thursday, January 03, 2013 12:35:54 Daniel Stenberg wrote:
Further downsides with the renames:
* Patches for older curl versions now suddenly don't apply anymore and will
give us (and others) much more work to apply. This will not only affect a
couple of patches that I have pending in
Yang Tse yangs...@gmail.com wrote:
2) When debugging libcurl or apps that use it with debuggers that are
capable of showing the name of the source file it is much easier to
know if one is stepping in libcurl's code or elsewhere.
I think that's a good argument for renaming.
From your
Replying to all in last msg in thread I've read in order to keep a
linear thread, even at the expense of making this msg longer...
@Daniel...
On Thu, Jan 3, 2013, Daniel Stenberg wrote:
On Thu, 3 Jan 2013, Yang
On Thursday 03 January 2013 18:04:53 Yang Tse wrote:
3) On core dumps, and fatal happenings which trace the source file
name of where the problem has been triggered, it becomes much easier
for not expert souls to figure out if it is a libcurl problem or not.
I would be surprised if this
On Thu, 3 Jan 2013, Yang Tse wrote:
The splitting of a single header or two surely can't motivate the renaming
of 190 *other* files?
True, the splitting doesn't actually motivate the renaming. It would only
justify the modification of the 190 *other* files.
Yes indeed, but that change
2013/1/3 Marc Hoersken i...@marc-hoersken.de:
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 have to
2013/1/3 Marc Hoersken i...@marc-hoersken.de:
2013/1/3 Marc Hoersken i...@marc-hoersken.de:
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
On Thu, Jan 03, 2013 at 10:10:31PM +0100, Marc Hoersken wrote:
2013/1/3 Marc Hoersken i...@marc-hoersken.de:
2013/1/3 Marc Hoersken i...@marc-hoersken.de:
I haven't tested this myself, but from my experience with previous
renames, GitHub and all the other tools in the git ecosystem will
Hi all
I count it as such. Let us give ourselves 24, 48 hours to let other
express themselves, if they desire so.
I must admit I'm not all for it but saying that I'm not dead set against it
either - given the choice I personally wouldn't do it.
However, I am all for consistency. So if we do
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
2013/1/3 Kamil Dudka kdu...@redhat.com:
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
30 matches
Mail list logo
