Proper tracking of file-level operations: rename, directories, merges

Talden talden at gmail.com
Fri Oct 21 19:04:05 UTC 2011


On Sat, Oct 22, 2011 at 5:50 AM, Colin D Bennett <colin at gibibit.com> wrote:
> On Fri, 21 Oct 2011 09:22:08 +0200
> Martin Geisler <mg at aragost.com> wrote:
>
>> Colin D Bennett <colin at gibibit.com> writes:
>>
>> > On Fri, 21 Oct 2011 08:57:00 +1100
>> > Ben Finney <ben+bazaar at benfinney.id.au> wrote:
>> >
>> >>...
>> >> $ hg status
>> >> A bar/beans
>> >> A bar/eggs
>> >> A bar/spam
>> >> R foo/beans
>> >> R foo/eggs
>> >> R foo/spam
>> >> =====
>> >
>> > It took me a moment to see the significance of this behavior of
>> > hg:
>> >
>> > You can't distinguish the single file with modified content
>> > from the other files which have no content change.
>>
>> That is false. After renaming and modifying the file, you get:
>>
>>   $ hg status -C
>>   A bar/beans
>>     foo/beans
>>   A bar/eggs
>>     foo/eggs
>>   A bar/spam
>>     foo/spam
>>   R foo/beans
>>   R foo/eggs
>>   R foo/spam
>>
>> Not pretty, but it shows where each file was renamed from. To see
>> the modifications you use 'hg diff':
>>...
>
> My point still stands: you can't look at the 'status' summary
> output and see which file was changed an which was merely renamed.

Absolutely. We're a java-shop and package rename is a frequent enough
operation to get good value from that clear feedback - especially at
merge-time when resolving conflicts.

That feedback might just be some human interpretable output but it
makes a difference to the (necessary) human resolving complex merges.

> Diff is not a substitute for this, because I don't want to wade
> through a many-page diff just to see which files changed.
> Sure, it's just output, I understand Mercurial has the information,
> but that's little help to the user who wants it to “just work.”

It's definitely no substitute. It can't tell me that a whole package
was renamed, only that a large number of files were moved. To know
that the folder was renamed I'd need to look at the tree-state prior
to that change and after the change to see that no other files exist
in the tree (and that the folder has disappeared).

I'd be surprised if there aren't some tree-shape conflicts in merge
that could be better resolved or reported with folder tracking too,
but without that the feedback can still be critical information.
Failing to deliver that capability had better deliver me a pretty big
up-side in return to excuse it...

--
Talden



More information about the bazaar mailing list