All the mail mirrored from lore.kernel.org
 help / color / mirror / Atom feed
From: Michael J Gruber <git@drmicha.warpmail.net>
To: Junio C Hamano <gitster@pobox.com>, Duy Nguyen <pclouds@gmail.com>
Cc: "Michael S. Tsirkin" <mst@redhat.com>,
	Martin Fick <mfick@codeaurora.org>,
	Jacob Keller <jacob.keller@gmail.com>,
	Git List <git@vger.kernel.org>,
	repo-discuss@googlegroups.com,
	Git Mailing List <git@vger.kernel.org>
Subject: Re: storing cover letter of a patch series?
Date: Tue, 9 Aug 2016 09:12:54 +0200	[thread overview]
Message-ID: <70b74f2e-3870-4bef-1664-1c2dd05eda96@drmicha.warpmail.net> (raw)
In-Reply-To: <xmqqmvknf986.fsf@gitster.mtv.corp.google.com>

Junio C Hamano venit, vidit, dixit 08.08.2016 19:42:
> Duy Nguyen <pclouds@gmail.com> writes:
> 
>> git-notes was mentioned in this thread back in 2015, but I think it's
>> discarded because of the argument that's part of the cover letter was
>> not meant to be kept permanently.
> 
> I do not think the reason why we didn't think the notes mechanism
> was a good match was mainly because the cover letter material was
> about a branch as a whole, which does not have a good counter-part
> in Git at the conceptual level.  "A branch is just a moving pointer
> that points at one commit that happens to be at the tip" is not a
> perfect match to "I am holding these N patches to achieve X and I am
> constantly adding, rewinding and rebuilding".  The notes mechanism
> gives an easy way to describe the former (i.e. annotate one commit,
> and let various commands to move that notes as you rewind and
> rebuild) but not the latter (i.e. "branch.description" configuration
> is the best match, but that is just a check-box feature and does not
> make any serious attempt to be part of a version-control system).
> 
>> But I think we can still use it as a
>> local/temporary place for cover letter instead of the empty commit at
>> the topic's tip. It is a mark of the beginning of commit, it does not
>> require rewriting history when you update the cover letter, and
>> git-merge can be taught to pick it up when you're ready to set it in
>> stone.
> 
> That depends on what you exactly mean by "the beginning of".  Do you
> mean the first commit that is on the topic?  Then that still requires
> you to move it around when the topic is rebuilt.  If you mean the
> commit on the mainline the topic forks from, then of course that
> would not work, as you can fork multiple topics at the same commit.

Well, my idea back then was: attach notes to refs rather than commits,
in this case to the branch ref. That would solve both the "branch moves"
as well as the "cover letter refers to the whole branch/topic" issues.

In fact, I had an implementation that I had been rebasing and using for
quite some time, but it never became popular, and branch.description
landed in-tree. [short version: notes attached to (virtual) refname
objects (virtual blobs - not stored, but "existing" for (fsck, notes
prune and the like)]

The notes based approach suffered from the old notes deficiency: we
don't have good simple tooling for sharing notes; really, we don't have
good tooling for dealing with any remote refs besides branches (read:
ref namespace reorg project is stalled), unless you set up specific
refspecs.


OTOH, branch.description is inherently local, too, and can't even be
transported after setting up refspecs or such.

Also, notes trees have a history, so you would gain a log on your cover
letter edits; again, our tooling around that notes feature is
sub-optimal, that is: the feature is there, the ui could improve.

Michael


  reply	other threads:[~2016-08-09  7:23 UTC|newest]

Thread overview: 57+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-09-10 16:28 storing cover letter of a patch series? Jacob Keller
2015-09-10 17:41 ` Junio C Hamano
2015-09-10 18:02   ` Martin Fick
2015-09-10 18:38     ` Jacob Keller
2015-09-10 18:39     ` Junio C Hamano
2015-09-11 22:24       ` Junio C Hamano
2016-08-04 23:49       ` Michael S. Tsirkin
2016-08-05 15:39         ` Junio C Hamano
2016-08-05 21:20           ` Martin Fick
2016-08-05 21:23             ` Junio C Hamano
2016-08-06 16:51               ` Junio C Hamano
2016-08-07  5:12           ` Michael S. Tsirkin
2016-08-07  9:52             ` John Keeping
2016-08-07 10:42             ` Duy Nguyen
2016-08-08 17:42               ` Junio C Hamano
2016-08-09  7:12                 ` Michael J Gruber [this message]
2015-09-10 18:32   ` Jacob Keller
2015-09-10 18:44     ` Junio C Hamano
2015-09-10 18:46       ` Jacob Keller
2015-09-10 20:09         ` Philip Oakley
2015-09-10 21:03           ` Jacob Keller
2016-08-04 23:43             ` Michael S. Tsirkin
2015-09-10 18:58 ` Johannes Schindelin
2015-09-10 21:00   ` Jacob Keller
2015-09-10 21:21     ` Johannes Schindelin
2015-09-10 22:20       ` Philip Oakley
2015-09-12 22:51   ` [PATCH] doc: show usage of branch description Philip Oakley
2015-09-12 23:44     ` Jacob Keller
2015-09-14 12:01       ` Philip Oakley
2015-09-14 13:24         ` Philip Oakley
2015-09-14 17:00         ` Junio C Hamano
2015-09-15 16:06           ` Philip Oakley
2015-09-15 19:10           ` Philip Oakley
2015-09-14 14:10     ` [PATCH v2] " Philip Oakley
2015-09-11  8:30 ` storing cover letter of a patch series? Chris Packham
2015-09-18  4:03   ` Simon Glass
2016-08-08 17:27 ` Stefan Beller
2016-08-08 20:09   ` Junio C Hamano
2016-08-13  8:49   ` Duy Nguyen
2016-08-14  7:15     ` Jacob Keller
2016-08-15  6:28       ` Stefan Beller
2016-08-15  6:38         ` Jacob Keller
2016-08-15  6:49           ` Stefan Beller
2016-08-15  6:52             ` Jacob Keller
2016-08-15  9:40         ` Duy Nguyen
2016-08-15 12:37           ` Philip Oakley
2016-08-15 13:30             ` Duy Nguyen
2016-08-15 13:47               ` John Keeping
2016-08-15 20:09             ` Jacob Keller
2016-08-15 20:38               ` Junio C Hamano
2016-08-15 23:01                 ` Jacob Keller
2016-08-15 20:46               ` Philip Oakley
2016-08-16  3:45                 ` Duy Nguyen
2016-08-16  5:26                   ` Jacob Keller
2016-08-16  6:45                     ` Duy Nguyen
2016-08-16 15:52                       ` Jacob Keller
2016-08-16 21:29                       ` Philip Oakley

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=70b74f2e-3870-4bef-1664-1c2dd05eda96@drmicha.warpmail.net \
    --to=git@drmicha.warpmail.net \
    --cc=git@vger.kernel.org \
    --cc=gitster@pobox.com \
    --cc=jacob.keller@gmail.com \
    --cc=mfick@codeaurora.org \
    --cc=mst@redhat.com \
    --cc=pclouds@gmail.com \
    --cc=repo-discuss@googlegroups.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.