"GOT", but the "O" is a cute, smiling pufferfish. Index | Thread | Search

From:
Stefan Sperling <stsp@stsp.name>
Subject:
Re: draft: keeping authorship of diffs in commits
To:
Omar Polo <op@omarpolo.com>
Cc:
gameoftrees@openbsd.org
Date:
Sun, 6 Feb 2022 12:08:32 +0100

Download raw body.

Thread
On Sun, Feb 06, 2022 at 11:20:55AM +0100, Omar Polo wrote:
> Here's a more complete one which adds the manpage bits and a test case
> too.  However, given your concerns I'm not so sure anymore!  I wanted
> something like this to avoid having to switch back to `git am'
> temporally when committing diffs and I thought it would be useful to
> others too (AFAIK freebsd uses this approach at least for ports commits)
> but the UI issues are real.

Then maybe we should have a feature like 'git am'?

Testing patches sent via mailing lists is an integral part of OpenBSD's
workflow. patch(1) lacks any integration with the version control system
and this has always been an issue. Applying and reverting patches becomes
much easier once the version control system provides an interface to do it.

I wrote 'svn patch' many years ago to solve this problem in Subversion.
New files get added, empty files get deleted, and meta-data that can be
carried over is carried over, etc. It doesn't preserve patch authorship
information though, because SVN lacks built-in special-purpose meta-data
to store this.

We could have a similar feature for gameoftrees but it would need to be
written from scratch, perhaps reusing code from patch(1) as found in
the OpenBSD base system. The Subversion code I wrote cannot be used,
it has the wrong licence and relies on many internal SVN abstractions.
However, its behaviour in how it manipulates the working copy could be
used as a guideline, and there are plenty of test case ideas to be found
in SVN's regression tests.

The format is not very difficult to parse, with some edge cases that
mostly involve people messing up trailing newlines and such.
The patching process itself is essentially search/replace on lines of
a file, it is not very complicated.