[darcs-devel] adding feature: patch origins

[Stefan Wehr]

Hi everyone,

[sorry for not properly replying to the original message; I wasn't a
member of darcs-devel until now, so I didn't receive the original
mail.]

On 10 February 2013 22:42, Sebastian Fischer <mail <at> sebfisch.de> wrote:
> I would like to add a feature to `darcs changes` to show information
> about who added a patch to the current repository (and when it was
> added.) This information would typically differ from the currently
> shown info if a patch has been recorded in a different repository and
> applied to the current repository using a sent patch bundle or by
> pushing/pulling from a different repository.

The idea for this feature comes from the daily work in our company
with darcs. It's often beneficial to see the "history" of a
repository. With history I mean information about additions and
removals of patches. For every such edit operation, I would like to be
able to see who added or removed certain patches and when did the
change occur.

This means that extending `darcs changes` is not quite enough because
`darcs changes` doesn't show removals of patches. But it's a good
starting point because information about patch additions is more
important than about removals. And I would like to see the new
information with `darcs changes` anyway. But for the full feature set
we would need a new command, maybe `darcs history`?

I don't think that the terminology "origin" is correct. For me,
information about the origin of a patch is exactly what darcs already
provides: who recorded the patch and when was it done. It's more about
maintainership: who applied a patch and when was it done. Btw, git
makes exactly the same distinction: the former information is called
Author and AuthorDate, the latter Commit and CommitDate in git. For
darcs, I would suggest the terminology Maintainer and MaintainerDate
instead.

Note that history information is *not* a property of a certain patch
but of a repository.

> I would like to implement origin tracking in a way that does not
> influence commands that don't use it. So it seems that other commands
> need an option to record the additional information, like
>
>     darcs pull --track-origin
>
> and similar, for push and apply.

As Owen Stephens already pointed out: I don't see why such a flag is
necessary. `darcs pull` should simply update the history information.
Imho, the following darcs commands would need to write history
information.

* initialize, get
* record  (author and maintainer are identical)
* amend-record (author and maintainer are identical but we should keep
an extra piece of information about patch amendment)
* pull, push, apply
* tag
* rollback
* unrecord, obliterate

Did I forget a command?

On 2013-02-10 23:30:47 GMT, Owen Stephens writes:
> Where should the applier details come from, in the case of push? (Darcs
> implements push by creating a patch bundle of the patches to push and invoking
> a remote darcs process to apply the bundle.) I imagine you would want the
> person who pushed the patches to show up as the applier, not the remote user
> that executes darcs? What happens if the remote darcs is older, and doesn't
> know anything about this feature (i.e. you can't just stick something extra in
> the remote invocation arguments)

In this case, `darcs apply` should get the maintainer information via
a commandline argument. `darcs pull` would then pass the local
maintainer information to the remote darcs. If the remote darcs is too
old, maintainer information is not passed.

I think maintainer information should be handled similar to author
information, that is darcs stores this information in its _prefs dir
and provides a suitable commandline flag. I believe it would be
possible to "misuse" the author preferences for this purpose because
the commands writing history information either don't take an --author
flag yet or author and maintainer are identical (for record and
amend-record). However, I would prefer to have a separate maintainer
option. How expensive is it to add such a new option?

Cheers,
Stefan