[Gnu-arch-users] fixing and extending "selected commit"

[Denys Duchier]

At Tom's request on IRC, I am continuing this conversation on the
list.

1. THE PRESENT

There are currently two ways to specify selected commits:

        tla commit -- FILE1 FILE2 ... FILEn
        tla commit --file-list MANIFEST

where MANIFEST is a file containing filenames:

---MANIFEST---
FILE1
FILE2
...
FILEn
--------------

These are both implemented by the same mechanism which currently
doesn't work for binary files (Tom just pushed a mini-fix, so that
arch now signals an error and stops instead of just doing the wrong
thing).

Fixing the problem is not entirely trivial and (currently) requires to
duplicate the logic dealing with the return status from diff and the
updating of changeset reports (I think).

Of course, we would still like to properly fix the problem with binary
files.  We could either just bite the bullet, or...

2. THE FUTURE

Tom's code contains some preliminary and unfinished support for a more
general notion that subsumes what is currently possible with selected
commits.

The idea is to introduce the notion of "limits".  When computing what
is involved in a commit, arch considers both an ORIG tree and a MOD
tree.  Limits are intended to restrict its attention to only subparts
of these trees.

If I read the code correctly, the current notion of limits is just
FILE and DIR names.  They induce a matching relation for the PATH
elements of a tree, where the intent is more or less:

        PATH matches DIR  if DIR is a prefix of PATH      (1)
        PATH matches FILE if PATH==FILE                   (2)

(2) is really just a special case of (1), but I thought the intent
would be clearer if it was stated explicitly.  The general idea is
that arch's attention should be restricted to only the subset of PATHs
that match some spec in the limits.

My personal preference would be to finish this new (cleaner)
implementation and discard the old (incorrect) one instead of
attempting to fix it.

3. THE CHALLENGE

The challenge is to finish specifying the limits mechanism.

3.a There are potentially interesting questions that arise when a
    matching PATH exists in one tree but not in the other.

For example, Tom made the following note:

      * Little lemma:  for each (canonicalized) limit $PREFIX/$TAIL,
      * the item in MOD with loc $PREFIX must exist in ORIG.   Because,
      * otherwise, the limit wants to add files to dirs that have not been
      * added to ORIG (a user error).

I disagree (or perhaps I misunderstand his intent).  It seems to me
that this restriction should be relaxed if the tagging-method permits,
i.e. if $PREFIX/$TAIL is source in MOD.

3.b More generally, we need to nail down the mechanism that computes
    "selected" views of the ORIG and MOD trees, and what counts as an
    error.

I'd really appreciate your feedback on these issues (while you take a
breather from arguing about the linux kernel :-)

Cheers,

-- 
Dr. Denys Duchier
Équipe Calligramme
LORIA, Nancy, FRANCE