git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Michael J Gruber <drmicha@warpmail.net>
To: Junio C Hamano <gitster@pobox.com>
Cc: git@vger.kernel.org, Johan Herland <johan@herland.net>
Subject: Re: [PATCH] git-notes.txt: clarify -C vs. copy and -F
Date: Tue, 29 Mar 2011 20:36:36 +0200	[thread overview]
Message-ID: <4D9226B4.20806@warpmail.net> (raw)
In-Reply-To: <7v7hbhss0g.fsf@alter.siamese.dyndns.org>

Junio C Hamano venit, vidit, dixit 29.03.2011 20:25:
> Junio C Hamano <gitster@pobox.com> writes:
> 
>> Michael J Gruber <git@drmicha.warpmail.net> writes:
>>
>>> The current description of '-C' together with the analogy to 'git commit
>>> -C' can lead to the wrong conclusion that '-C' copies notes between
>>> objects. Make this clearer by rewording and pointing to 'copy'.
>>>
>>> The example for attaching binary notes with 'git hash-object' followed
>>> by 'git notes add -C' immediately raises the question: "Why not use 'git
>>> notes add -F'?". Answer it (the latter is not binary-safe).
>>>
>>> Signed-off-by: Michael J Gruber <git@drmicha.warpmail.net>
>>> ---
>>> In fact, the long name '--reuse-message' is really misleading, but I've been
>>> around long enough to refrain from trying to change it ;)
>>
>> Yeah, it utterly is broken.  Why not fix it before people start making
>> serious use of notes?

You seriously ask why? Because I've banged my head way to often by
suggesting behavior changes!

> 
> Actually I take it back and throw it again after doubling it.  Not just
> the long name, but using -C/-c is already utterly broken.  These are meant
> to reuse (meta)data associated with an existing object, not using some
> data that happens to be stored in a random loose blob.  I don't think of
> any similar option anywhere in git.
> 
> Instead of mucking with the documentation, why not fix the behaviour to
> match what -C/-c/--reuse usually means, which is what the documentation
> describes?

Because it's not what the doc describes. The current version is easy to
misunderstand, but in connection with the example it is clear how it is
meant, and that's how it is implemented. If I were to reimplement it I
would:

- make "notes add -C/-c" really analogous to "commit -c/-C", i.e. do
"notes copy"

- make -F binary safe

and while at it rename "add" to "edit", because I've been bitten too
often by trying to add to a note using the "add" command. But all these
are behavior changes/incompatibilities, i.e. a no-go.

I don't mean to criticize the initial implementation of "notes", it just
shows that we detect rough ui edges only after using a feature. I'm all
for changes, I just rarely can get myself to making a hopeless feature
change patch any more.

Michael

  reply	other threads:[~2011-03-29 18:46 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-03-29  8:45 [PATCH] git-notes.txt: clarify -C vs. copy and -F Michael J Gruber
2011-03-29  9:36 ` Johan Herland
2011-03-29 18:22 ` Junio C Hamano
2011-03-29 18:25   ` Junio C Hamano
2011-03-29 18:36     ` Michael J Gruber [this message]
2011-03-29 19:04       ` Junio C Hamano
2011-03-29 19:57         ` Junio C Hamano
2011-08-25 10:26           ` Michael J Gruber
2011-08-25 18:50             ` Johan Herland
2011-03-30  0:02         ` [RFC/PATCH] Make "git notes add" more user-friendly when there are existing notes Johan Herland
2011-03-30  6:54           ` Michael J Gruber
2011-03-30  9:59             ` Johan Herland
2011-04-04 11:35               ` Lasse Makholm
2011-04-04 12:54                 ` Michael J Gruber
2011-03-30 19:32           ` Junio C Hamano

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=4D9226B4.20806@warpmail.net \
    --to=drmicha@warpmail.net \
    --cc=git@vger.kernel.org \
    --cc=gitster@pobox.com \
    --cc=johan@herland.net \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).