Re: Using VC for change descriptions

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

  > That's generically the case for any aspect of a change description.  What 
  > we can judge is what's most useful for understanding the change *now*, and 
  > write that.

That would be the wrong goal.  We should aim, rather, for what we
expect WILL be useful when it is time to debug code that was affected
by this change.

How do we estimate what that will be?  Based on experience.

                 We can also judge what's hard to reconstruct from the diff, 

Right.

  > which is generally the higher-level information, versus what could be 
  > reconstructed from the diff in future if needed, which includes the list 
  > of entities.

The git facilities I've been shown can sort-of reconstruct that,
but with errors and gaps.

If someone will write a script to reconstruct it reliably,
then I would agree we don't need to write it in advance.

  > If the average number of times a list of entities is needed is much 
  > smaller than 1 per commit (and I suspect it's much smaller, for the 
  > projects I work on), it makes more sense for the reader to construct it if 
  > needed rather than for the writer to construct such lists that will 
  > probably never be needed.

The "reader", someone who wants to use that data, would have to
reconstruct it for all the changes in the history of the given source
file.  Each time someone wants to investigate that source file, person
would have to do that again.  This means generating by hand the entities
changed for each change in that file.

Better to do it just once for each change.

  > > Entities are concrete,
  > > unambiguous---you can phrase them only one way.

  > For the example I gave of Makefile entity names involving complicated GNU 
  > make constructs, that needed to be wrapped over multiple lines, that's not 
  > the case.

I have a feeling that your response is not talking about the same
thing, here, as the previous statement.  I remember that case, and it
was cumbersome, but not in that way.


-- 
Dr Richard Stallman
President, Free Software Foundation (https://gnu.org, https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)
Skype: No way! See https://stallman.org/skype.html.