From: Michael J Gruber <git@drmicha•warpmail.net>
To: Junio C Hamano <gitster@pobox•com>
Cc: git@vger•kernel.org
Subject: Re: [PATCH 0/6] A handful of "branch description" patches
Date: Fri, 23 Sep 2011 10:56:47 +0200 [thread overview]
Message-ID: <4E7C49CF.60508@drmicha.warpmail.net> (raw)
In-Reply-To: <1316729362-7714-1-git-send-email-gitster@pobox.com>
Junio C Hamano venit, vidit, dixit 23.09.2011 00:09:
> Here are a few patches that I have queued in 'pu', redoing some of the
> patches I already sent out to the list, around "branch description".
>
> The original motivation was to make the push/pull workflow appear more
> robust by allowing human-to-human communication to leave audit trail that
> can be verified when it becomes necessary. Namely:
>
> * request-pull message carries the SHA-1 of what is expected to be
> merged; and
>
> * "signed push" leaves the SHA-1 of what was pushed to the remote,
> cryptographically signed.
>
> Linus's reaction, as I understood him, was "if we are spending efforts to
> add more information, the end result should be more informative to humans
> not just to machines", and I agree. An example of piece of information we
> often talk about is branch description---what a particular branch is meant
> to achieve. Both request-pull messages and declarations of what was pushed
> are good places to record that piece of information.
>
> So here is a partially re-rolled series to get us closer.
>
> * The logic to read from an existing branch description was in
> builtin/branch.c in the original series, but the first patch separates
> it out into branch.c as a helper function;
>
> * The second one is a digression; the branch description describes what
> the topic aims to achieve, so it was natural to use it to prime the
> cover letter while preparing a patch series with format-patch;
>
> * The third one that adds "branch --edit-description" is basically
> unchanged modulo small leakfix from the original round;
>
> * And the remainder of the series for request-pull is the same as the
> last round.
I'm afraid I've missed the first installment of the series, or rather the fact that it was about more than just signed pushes. I've been working at (and with) branch and tag annotations for quite a while now and should have probably pushed the WIP rather than just dropping the occasional note. So I'll describe briefly what I have (the branches are in any of my repos[1]), which is notes based:
mjg/vob/branch-notes [mjg/vob/virtual-objects: ahead 4]
Annotations for branches and tags
Show notes for branches and tags when "branch" resp. "tag" is called with "--notes".
The "--notes" argument can take on all usual forms.
mjg/vob/format-patch-branch-note [mjg/vob/refrev-hash: ahead 1]
Cover letter from notes
Fill in the cover letter from a note to ref:HEAD if --notes is given.
TODO: The current branch may not be the one the format-patch arguments refer to.
mjg/vob/refrev-hash [mjg/vob/virtual-objects: ahead 2]
Pseudo revs for refnames
Introduce "ref:foo" to denote the (virtual) refname object for the ref named
"foo". This is handy for now (editing branch and tag notes) but should
become obsoleted by a better ui, such as "git branch --edit foo" or
"git notes --refname edit foo".
Introduce "ref:" as a shortcut to "ref:HEAD" which is the refname object
for the current branch.
mjg/vob/refrev-pretend [mjg/vob/virtual-objects: ahead 1]
Pseudo revs for refnames
An alternative implementation using pretend_sha1...
Currently unused.
mjg/vob/virtual-objects [origin/next: ahead 2, behind 10]
Virtual refname objects
For each existing refname, introduce virtual objects corresponding to a blob
with the refname as the content. "virtual" refers to the fact that these
objects are not written out but exist for all other purposes, such as
attaching notes and keeping them from being pruned.
mjg/vob/virtual-refs-for-rnos
Virtual refs for refname objects
For each ref, pretend that the corresponding refname object is referenced
to keep it from being pruned. This still requires branch note code to
write out these objects.
(Unused earlier approach.)
mjg/vob/virtual-refs-pretend-all
Virtual refs for refname objects
For each ref, pretend that the corresponding refname object is referenced
to keep it from being pruned. This still requires branch note code to
write out these objects.
(Unused earlier approach using pretend_sha1....)
Yes, the above is (with added newlines and removed top commit info) the output of 'git branch -vv --notes --list mjg/vob\*' :)
Open questions:
* Should the refname object for ref "foo" really be identical to a blob with content "foo"? Or content "ref: foo? Or...?
* Should ref (branch and tag) annotations use the same default notes tree as commit notes?
* How best to view annotations on remote branches? This is connected with open questions about notes sharing and the ref namespace structure.
I do think that config based descriptions are a quick solution, but a very non-distributed, non-versioned approach when compared to the notes approach.
Michael
[1]
git://github.com/gitigit/git.git
git://gitorious.org/~mjg/git/mjg.git
git://repo.or.cz/git/mjg.git
next prev parent reply other threads:[~2011-09-23 9:55 UTC|newest]
Thread overview: 62+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-09-13 16:45 [Survey] Signed push Junio C Hamano
2011-09-13 22:28 ` [PATCH v2 0/2] State commit name explicitly in request-pull messages Junio C Hamano
2011-09-13 22:28 ` [PATCH v2 1/2] fetch: allow asking for an explicit commit object by name Junio C Hamano
2011-09-13 22:28 ` [PATCH v2 2/2] request-pull: state exact commit object name Junio C Hamano
2011-09-13 23:26 ` [Survey] Signed push Guenter Roeck
2011-09-13 23:50 ` Junio C Hamano
2011-09-14 0:02 ` Junio C Hamano
2011-09-14 0:31 ` Sam Vilain
2011-09-14 0:39 ` Shawn Pearce
2011-09-14 1:03 ` Sam Vilain
[not found] ` <CA+55aFxAQTR3sT7gekAD4qih8J+z-qwri7ZmNCPUd811xgci6w@mail.gmail.com>
2011-09-14 7:06 ` Fwd: " Linus Torvalds
2011-09-14 10:45 ` Michael Haggerty
2011-09-14 11:03 ` Matthieu Moy
2011-09-14 11:46 ` Nguyen Thai Ngoc Duy
2011-09-14 12:28 ` Johan Herland
2011-09-14 12:56 ` Ted Ts'o
2011-09-14 15:27 ` Linus Torvalds
2011-09-14 15:42 ` Matthieu Moy
2011-09-14 16:14 ` Johan Herland
2011-09-14 22:51 ` Philip Oakley
2011-09-14 23:30 ` Linus Torvalds
2011-09-14 23:44 ` Junio C Hamano
2011-09-14 15:25 ` Linus Torvalds
2011-09-14 17:52 ` Junio C Hamano
2011-09-14 18:36 ` Linus Torvalds
2011-09-14 17:49 ` Junio C Hamano
2011-09-14 20:52 ` Sam Vilain
2011-09-16 19:04 ` [PATCH v3] request-pull: state what commit to expect Junio C Hamano
2011-09-20 23:01 ` Junio C Hamano
2011-09-20 23:02 ` [PATCH 2/3] branch: teach --edit-description option Junio C Hamano
2011-09-21 0:15 ` Andrew Ardill
2011-09-21 2:44 ` Junio C Hamano
2011-09-20 23:03 ` [PATCH] request-pull: use the branch description Junio C Hamano
2011-09-22 22:09 ` [PATCH 0/6] A handful of "branch description" patches Junio C Hamano
2011-09-22 22:09 ` [PATCH 1/6] branch: add read_branch_desc() helper function Junio C Hamano
2011-09-22 22:09 ` [PATCH 2/6] format-patch: use branch description in cover letter Junio C Hamano
2011-09-22 22:09 ` [PATCH 3/6] branch: teach --edit-description option Junio C Hamano
2011-09-23 9:00 ` Michael J Gruber
2011-09-23 9:47 ` Nguyen Thai Ngoc Duy
2011-09-23 19:04 ` Junio C Hamano
2011-09-25 5:21 ` Nguyen Thai Ngoc Duy
2011-09-22 22:09 ` [PATCH 4/6] request-pull: modernize style Junio C Hamano
2011-09-22 22:09 ` [PATCH 5/6] request-pull: state what commit to expect Junio C Hamano
2011-09-22 22:09 ` [PATCH 6/6] request-pull: use the branch description Junio C Hamano
2011-09-23 8:56 ` Michael J Gruber [this message]
2011-09-23 20:18 ` [PATCH 0/6] A handful of "branch description" patches Jeff King
2011-09-23 20:52 ` Junio C Hamano
2011-09-23 20:53 ` Jeff King
2011-09-24 14:42 ` Michael J Gruber
2011-09-27 21:58 ` Jeff King
2011-09-28 4:23 ` Annotated branch ≈ annotated tag? Michael Haggerty
2011-09-28 7:12 ` Andrew Ardill
2011-09-28 8:04 ` Michael Haggerty
2011-09-28 8:58 ` Branch annotations [Re: Annotated branch ≈ annotated tag?] Michael J Gruber
2011-09-29 6:44 ` Annotated branch ≈ annotated tag? Jeff King
2011-09-14 11:58 ` [Survey] Signed push Nguyen Thai Ngoc Duy
2011-09-14 21:05 ` Jonathan Nieder
2011-09-14 22:42 ` Nguyen Thai Ngoc Duy
2011-09-15 17:50 ` Jeff King
2011-09-14 19:35 ` Andy Lutomirski
2011-09-14 20:40 ` Junio C Hamano
2011-09-14 20:49 ` Andrew Lutomirski
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4E7C49CF.60508@drmicha.warpmail.net \
--to=git@drmicha$(echo .)warpmail.net \
--cc=git@vger$(echo .)kernel.org \
--cc=gitster@pobox$(echo .)com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox