On Thu, Aug 4, 2016 at 8:58 AM, Johannes Schindelin
<Johannes.Schindelin@xxxxxx> wrote:
>
>> If we were to change our workflows drastically, I'd propose to
>> go a way[1] similar to notedb in Gerrit, or git-series,
>
> Gerrit is a huge, non-distributed system. Complex, too. If we change the
> patch submission process, we should make things *easier*, not *harder*. So
> I think Gerrit is pretty much out of the question.
I did not propose to use Gerrit or git-series or git appraise.
However whenever I see these projects talking to each other, the talk focuses on
a "unified review storage format" pretty often, which would make them compatible
with each other. So then I could choose git-series, while you could go with
git appraise (although that is written in go, so maybe too fancy already ;)
Or there could be another new program written in C that follows the "review
format".
>
> Even requiring every contributor to register with GitHub would be too much
> of a limitation, I would wager.
>
> And when I said I have zero interest in tools that use the "latest and
> greatest language", I was hinting at git-series. Rust may be a fine and
> wonderful language. Implementing git-series in Rust, however, immediately
> limited the potential engagement with developers dramatically.
>
> Additionally, I would like to point out that defining a way to store
> reviews in Git is not necessarily improving the way our code contribution
> process works. If you want to record the discussions revolving around the
> code, I think public-inbox already does a pretty good job at that.
Yeah recording is great, but we want to talk about replying and modifying
a series? So if I see a patch flying by on the mailing list, ideally I could
attach a "!fixup, signed off by Stefan" thing to that patch. (I said "thing"
as I do not necessarily mean email here.
>
> I guess I have no really good idea yet, either, how to retain the ease of
> access of sending mails to the list, yet somehow keep a strong tie with
> the original data stored in Git.
Does it have to be email? Transmitting text could be solved differently as well.
With git push/fetch we can interact with a git remote and pertain the state
(commits, ancestor graph) at a full level even including notes that comment
on commits.
git send-email/format-patch recently learned to include a base commit
(xy/format-patch-base), maybe we need a counter part to git send-email
that downloads a series from your mailbox, such that a local branch
can be transmitted to via
"git send-email --base=origin/master --include-notes --name=sb/new-series"
and completely reconstructed (i.e. the commit sha1s even match) including
notes via:
git fetch-email --name=sb/new-series
That way would ensure we have a "simple" way to transmit patches back and forth
and adding potential fixups.
You wrote:
> In short, I agree that our patch submission process is a saber tooth tiger
> that still reflects pre-Git times. While we use Git's tools, the workflow
> really tries to cut out Git as much as possible, in favor of pure mails
> with non-corrupted, non-HTML patches in them, a charmingly anachronistic
> requirement until you try to use state-of-the-art mail clients to send
> them.
And there are two ways out:
* either we teach git how to deal with emails (completely, i.e.
sending+receiving)
* or we change the development model (e.g. no emails any more)
There is no golden third way IMHO.
Thanks,
Stefan
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html