On 12/28/12 8:18 PM, Daniel Murphy wrote:
> "Andrei Alexandrescu"<SeeWebsiteForEmail@erdani.org>  wrote in message
> news:kbl3eh$2qe8$1@digitalmars.com...
>> On 12/28/12 4:39 PM, Brad Roberts wrote:
>>> What impact does this have on the open pull requests?  If it's going to
>>> suddenly break every one of them, then I think it's a particularly bad
>>> idea.
>>
>> There are dozens of open pull requests and if worse comes to worst people
>> will agree to fix their requests because the request for changing
>> extensions has enjoyed considerable popularity.
>>
>>> The benefit is debatable and the cost is pretty annoying.
>>
>> The benefit is we'll avoid resurrecting a debate that comes back and
>> again. Technically there's no reason to move with the change, but right
>> now we're wasting time and burning through karma. Making the change shows
>> respect for the community and for working together in an environment that
>> has few gratuitous idiosyncrasies.
>>
>> Let's do it.
>>
>>
>> Thanks,
>>
>> Andrei
>
> You want to screw up over a hundred open pull requests and destroy the
> commit history...

I used git mv, which to my understanding preserves commit history and makes pull requests easy to fix via a rebase: http://stackoverflow.com/questions/2641146/handling-file-renames-in-git


Andrei

On Saturday, 29 December 2012 at 03:27:38 UTC, Andrei Alexandrescu wrote:
> On 12/28/12 8:18 PM, Daniel Murphy wrote:
>> "Andrei Alexandrescu"<SeeWebsiteForEmail@erdani.org>  wrote in message
>> news:kbl3eh$2qe8$1@digitalmars.com...
>>> On 12/28/12 4:39 PM, Brad Roberts wrote:
>>>> What impact does this have on the open pull requests?  If it's going to
>>>> suddenly break every one of them, then I think it's a particularly bad
>>>> idea.
>>>
>>> There are dozens of open pull requests and if worse comes to worst people
>>> will agree to fix their requests because the request for changing
>>> extensions has enjoyed considerable popularity.
>>>
>>>> The benefit is debatable and the cost is pretty annoying.
>>>
>>> The benefit is we'll avoid resurrecting a debate that comes back and
>>> again. Technically there's no reason to move with the change, but right
>>> now we're wasting time and burning through karma. Making the change shows
>>> respect for the community and for working together in an environment that
>>> has few gratuitous idiosyncrasies.
>>>
>>> Let's do it.
>>>
>>>
>>> Thanks,
>>>
>>> Andrei
>>
>> You want to screw up over a hundred open pull requests and destroy the
>> commit history...
>
> I used git mv, which to my understanding preserves commit history and makes pull requests easy to fix via a rebase: http://stackoverflow.com/questions/2641146/handling-file-renames-in-git
>
>
> Andrei

On Saturday, 29 December 2012 at 03:27:38 UTC, Andrei Alexandrescu wrote:
> On 12/28/12 8:18 PM, Daniel Murphy wrote:
>> "Andrei Alexandrescu"<SeeWebsiteForEmail@erdani.org>  wrote in message
>> news:kbl3eh$2qe8$1@digitalmars.com...
>>> On 12/28/12 4:39 PM, Brad Roberts wrote:
>>>> What impact does this have on the open pull requests?  If it's going to
>>>> suddenly break every one of them, then I think it's a particularly bad
>>>> idea.
>>>
>>> There are dozens of open pull requests and if worse comes to worst people
>>> will agree to fix their requests because the request for changing
>>> extensions has enjoyed considerable popularity.
>>>
>>>> The benefit is debatable and the cost is pretty annoying.
>>>
>>> The benefit is we'll avoid resurrecting a debate that comes back and
>>> again. Technically there's no reason to move with the change, but right
>>> now we're wasting time and burning through karma. Making the change shows
>>> respect for the community and for working together in an environment that
>>> has few gratuitous idiosyncrasies.
>>>
>>> Let's do it.
>>>
>>>
>>> Thanks,
>>>
>>> Andrei
>>
>> You want to screw up over a hundred open pull requests and destroy the
>> commit history...
>
> I used git mv, which to my understanding preserves commit history and makes pull requests easy to fix via a rebase: http://stackoverflow.com/questions/2641146/handling-file-renames-in-git
>
>
> Andrei


[bleep][bleep][bleep][bleep] it should *all* be .d at this point (last nail in C++ coffin please).

Merry holidays everyone!

--rt

On 2012-12-29 03:39, Bernard Helyer wrote:

> IIRC, Git can figure out if a raw renamed file (a new file from git's
> perspective) is a rename of an old file if the contents are the
> same as a recently removed file above a certain threshold (70 percentish).
>
> Considering the contents of the files shouldn't change at all, I
> _think_ git should be able to figure out what's happened.

Git can figure out it's a rename even if some of the content has changed.

-- 
/Jacob Carlborg

On 12/28/2012 10:39 PM, Brad Roberts wrote:
> What impact does this have on the open pull requests?  If it's going to
> suddenly break every one of them, then I think it's a particularly bad
> idea.  The benefit is debatable and the cost is pretty annoying.

You could always pull some of the requests into your local copy to check if it's causing a lot of conflicts or not.

-- 
Mike Wey

> I would expect rebasing to fix it trivially so long as git mv was used rather
> than renaming the file with the OS' commands, but I don't know for sure.
>
> - Jonathan M Davis
>

Git doesn't record renamings but uses a heuristic check for similarity instead. Rebasing will be trivial as long as the rename detection succeeds. Once the '.cc' files differ too much from the '.c' base in an open pull request it'll cause a delete/modify conflict.
http://stackoverflow.com/questions/2314437/resolve-conflict-delete-modify-in-git