Re: [patch 1/2] libunwind/ia64: Rename libunwind-frame.[ch]

[Pedro Alves <palves@redhat.com>]

On 03/08/2012 09:15 AM, Jan Kratochvil wrote:

> On Tue, 06 Mar 2012 08:54:35 +0100, Pedro Alves wrote:
>> On 03/04/2012 09:57 PM, Jan Kratochvil wrote:
>>> this is just a rename, it breaks the build, but it makes the changes
>>> reviewable in [patch 2/2].  It would be checked-in as a single commit.
>>
>> BTW, there's a different way to split this so that you don't mix
>> the rename with other changes to the same files, and so that
>> git log sees through pure file renames without trouble.



> 'git log' never see a rename while 'git log -M' sees the rename even if those
> changes are in single commit as those changes are really very small:


Thanks, but well, I said "git log", but I meant "git in general".

> diff --git a/gdb/libunwind-frame.h b/gdb/ia64-libunwind-tdep.h

> similarity index 93%
> rename from gdb/libunwind-frame.h
> rename to gdb/ia64-libunwind-tdep.h
> index a6b3c34..221bbd2 100644
> --- a/gdb/libunwind-frame.h
> +++ b/gdb/ia64-libunwind-tdep.h
> @@ -1,4 +1,4 @@
> -/* Frame unwinder for frames with libunwind frame information.
> +/* Frame unwinder for ia64 frames with libunwind frame information.
> [...]
> 
> So I do not find a need to use multiple commits into the (CVS) repository.


Hmm, okay, that's smart.  I do think rename-only in one commit/patch, and then
changes as separate commits in the repository is anyway a good principle to aim
for (making sure the build doesn't break in the process).  But given that, I don't
care so much.

> I was posting it this way so that one can easily apply the series by 'patch'

> while still being able to see the changes (in [patch 2/2]).


There's nothing in my suggestion that'd prevent that, given the changes are
always separate from the rename.

> If one can assume every mailing list user has GIT anyway the repository
> absolutely no longer makes sense in CVS.

There's more to the cvs/git conversion than what mailing list
users are using, so let's keep that out of the discussion.
(That'd actually make my argument stronger.  Making pure renames in separate
commits increases the chances of tools other than git also understanding
a rename.)

Anyway, please go ahead as you prefer.

-- 
Pedro Alves