new status output

[James Blackwell]

James Blackwell wrote:
> >Added Renamed Modified             somedirectory/subdir/anotherdir/ 
> >file
> >                       Conflicted  somedirectory/subdir/anotherdir/ 
> >file2
> >
> >(one keeps different types of changes in different fields for easy  
> >parsing
> >by external third party programs)

On Tue, Oct 25, 2005 at 10:04:04AM -0700, Robey Pointer wrote:
> I don't think that's true.  If I were writing a script, I'd find the  
> odd spacing more difficult than just words.  But either way, the idea  
> is more like:
> 
> renamed   somedirectory/subdir/file => somedirectory/subdir/file1
> modified  somedirectory/subdir/file1
> added     somedirectory/subdir/file2

What do you do if something is both renamed and modified? 

The field concept is a rather common one as it works well in C land.
Consider this all-too-sloppy, unflexible and untested c code:

#define READ_FLAG_LENGTH 20
#define READ_FLAG_OFFSET 20
#define BUFFER_LEN 255

char * linein;
char * read_flag;

linein = malloc(BUFFER_LEN + 1);
read_flag = malloc(READ_FLAG_LENGTH+1);
while (fgets linein from stdin)
  {
     strncpy(read_flag, linein+READ_FLAG_OFFSET, READ_FLAG_LENGTH);
     read_flag+READ_FLAG_LENGTH=0
  }

One can see many slightly examples of this in /proc, though they're less
limited in the number of fields. Typically they come with field headers as
well.

> There's no need to pile up all of a file's changes on one line.  In
> some cases (like rename), extra info is helpful anyway.
> 
> And now that I've said all that, I have to deflate by saying that I'm
> actually okay with the current system of changes files out by
> categories. :)

As I mentioned before, this isn't such a hot idea for third party
programs, since it requires at least a minimal state machine.