RFC: iter_changes with specific_files, status and commit

[Martin Pool]

2009/6/26 Robert Collins <robertc at robertcollins.net>:
> So, one kindof-principle about status is that it tells you what commit
> will do. This isn't _strict_ and it falls down with specific files.

Do you mean it's intentionally not strict, or accidentally?  I wonder
if it's useful to call out somewhere what the differences are meant to
be.

>
> I've been looking at adding automatic inclusion of parents to
> iter_changes to ensure that commit generates valid inventory deltas.
> Currently given a change like:
>
> A b
> R a->b/c
>
> doing 'commit b/c' will commit both the new file b and the rename of a
> to c, because b is above an added-or-reparented entry.
>
> However, doing 'st b/c' lists *only* the rename.
>
> Adding automatic inclusion of parents would make 'st b/c' show both
> changes.
>
> Below the UI level, this is very simple: expose the yield_parents
> parameter of inventory.iter_entries_by_dir, and add some small set
> tracking logic to dirstate's iter_changes. PreviewTree may need
> something different but I imagine it will be fairly straight forward.
>
> I'm seeking specific feedback:
>  - does this sound reasonable at the UI layer.
>  - can anyone see some unexpected issues?

I can't think of any problems at the moment.

-- 
Martin <http://launchpad.net/~mbp/>