Re: [Gnu-arch-users] "tla commit" generates a patch-set even if there are no changes

[Aaron Bentley]

James Blackwell wrote:

> > I'll be okay.  I just wish you hadn't taken away -n.  I liked being able 
> > to use "delta" like "changes".
>
>
> I'll probably regret asking this (grin) but why did you like using delta
> instead of changes?

Well, delta's like a more powerful, less refined version of changes. 
"tla delta --diffs $(tla logs -f | tail -n 1) ." has the same output as 
"tla changes --diffs".  But since delta can be applied to any two 
directories, you can use it to see which files changed in a non-arch 
tree, compared to an arch tree.  I was doing that recently.  Or you can 
also use it to see what files differ between any two revisions.

So technically, "changes" is redundant.  Good thing I'm not one of those 
people pushing to reduce tla's list of commands, or it'd be on the 
chopping block.  We'd just need certain defaults.

I like the idea of "logs", "tree-root", "delta" and "apply-delta" being 
all you need to  construct "changes", "undo", "changeset" and "update". 
 In fact, I recently adjusted my change-version script to use 
apply-delta instead of  "sync-tree" and "undo", with the bonus that it 
now preserves uncommitted changes.

> The way I interpreted delta at the time was either you wanted a
> changeset, or you wanted a diff. It seemed logical to me that if you
> wanted a diff, then you weren't looking for a changeset, and I folded -n
> into the default operation for --diff (which was a rename from --report)

If you were doing that much, maybe you should have copied the entire 
"changes" interface.  If people want delta to output a changeset, they 
probably don't want the changeset to be called ",,changes*" anyway.

Aaron