All of lore.kernel.org
 help / color / mirror / Atom feed
From: Ramkumar Ramachandra <artagnon@gmail.com>
To: Jonathan Nieder <jrnieder@gmail.com>
Cc: Junio C Hamano <gitster@pobox.com>,
	Git List <git@vger.kernel.org>,
	Christian Couder <chriscool@tuxfamily.org>,
	Daniel Barkalow <barkalow@iabervon.org>,
	Jeff King <peff@peff.net>
Subject: Re: [PATCH 3/7] revert: Make commit descriptions in insn sheet optional
Date: Sun, 14 Aug 2011 21:51:21 +0530	[thread overview]
Message-ID: <CALkWK0kdd=+w4-jiBX8hh1_-mi9US+A4nng4qeoRRNmR5yDpDw@mail.gmail.com> (raw)
In-Reply-To: <20110814160923.GL18466@elie.gateway.2wire.net>

Hi Jonathan,

Jonathan Nieder writes:
> If I understand correctly, the current code makes it perfectly possible
> to use commands like
>
>        pick origin/master^^2~5

I was thinking exactly the same thing a few hours ago!  I was
wondering what to do about such a tree'ish specification, and I came
to the conclusion that we should discourage this atleast for normal
users.  Why?  Because the tree'ish has to be invariant over the entire
sequencer operation*: something like "pick HEAD~3" is clearly flawed
since the picking operation updates HEAD.

* Some of us might find some really clever uses for a tree'ish that
refers to different commits during the course of the sequencer
operation, and I'm alright with that.  It might just be something
that's too complicated for many users to grok, and we can protect them
by not advertising this tree'ish operand feature.

> when that is more convenient to type.  So I wonder whether 40 is actually
> a good limit.  Another possibility would be to do something like
>
>        static struct strbuf cmit = STRBUF_INIT;

I don't like this; the sequencer will just end up drinking a lot of
memory for no reason if the insn sheet is horribly corrupted.  I think
40 is a very reasonable limit, even for the most complex tree'ish I
can dream of.

Thanks.

-- Ram

  reply	other threads:[~2011-08-14 16:21 UTC|newest]

Thread overview: 43+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-08-14  8:33 [PATCH v2 0/7] Generalized sequencer foundations Ramkumar Ramachandra
2011-08-14  8:33 ` [PATCH 1/7] revert: Free memory after get_message call Ramkumar Ramachandra
2011-08-14 16:15   ` Jonathan Nieder
2011-08-14  8:33 ` [PATCH 2/7] revert: Fix buffer overflow in insn sheet parser Ramkumar Ramachandra
2011-08-14 11:58   ` Jonathan Nieder
2011-08-14 14:07     ` Ramkumar Ramachandra
2011-08-14  8:33 ` [PATCH 3/7] revert: Make commit descriptions in insn sheet optional Ramkumar Ramachandra
2011-08-14 16:09   ` Jonathan Nieder
2011-08-14 16:21     ` Ramkumar Ramachandra [this message]
2011-08-14  8:33 ` [PATCH 4/7] revert: Allow mixed pick and revert instructions Ramkumar Ramachandra
2011-08-14 12:12   ` Jonathan Nieder
2011-08-14 14:06     ` Ramkumar Ramachandra
2011-08-14 14:28       ` Jonathan Nieder
2011-08-14  8:33 ` [PATCH 5/7] revert: Make the argument parser responsible for setup_revisions Ramkumar Ramachandra
2011-08-14 12:52   ` Jonathan Nieder
2011-08-14 13:43     ` Ramkumar Ramachandra
2011-08-14  8:33 ` [PATCH 6/7] sequencer: Expose API to cherry-picking machinery Ramkumar Ramachandra
2011-08-14 13:13   ` Jonathan Nieder
2011-08-14 13:57     ` Ramkumar Ramachandra
2011-08-14 15:22       ` Jonathan Nieder
2011-08-16 17:51         ` Junio C Hamano
2011-08-16 18:16           ` [PATCH v2] revert: plug memory leak in "cherry-pick root commit" codepath Jonathan Nieder
2011-08-16 18:27             ` Jonathan Nieder
2011-08-16 18:31             ` Jeff King
2011-08-16 18:56               ` Jonathan Nieder
2011-08-14  8:33 ` [PATCH 7/7] sequencer: Remove sequencer state after final commit Ramkumar Ramachandra
2011-08-14 16:04   ` Jonathan Nieder
2011-08-14 16:37     ` Ramkumar Ramachandra
2011-08-14 16:48       ` Jonathan Nieder
2011-08-14 21:13     ` Junio C Hamano
2011-08-14 21:32       ` Jonathan Nieder
2011-08-14 22:30         ` Junio C Hamano
2011-08-15 18:55           ` Junio C Hamano
2011-08-17 20:23             ` Ramkumar Ramachandra
2011-08-18 18:51             ` Ramkumar Ramachandra
2011-08-18 19:18               ` Jonathan Nieder
2011-08-18 19:50                 ` Ramkumar Ramachandra
2011-08-18 20:05                   ` Jonathan Nieder
2011-08-18 20:06                   ` Ramkumar Ramachandra
2011-08-18 20:12                     ` Jonathan Nieder
2011-08-18 20:22                   ` Junio C Hamano
2011-08-18 20:42                 ` Junio C Hamano
2011-08-19  9:08                   ` Ramkumar Ramachandra

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='CALkWK0kdd=+w4-jiBX8hh1_-mi9US+A4nng4qeoRRNmR5yDpDw@mail.gmail.com' \
    --to=artagnon@gmail.com \
    --cc=barkalow@iabervon.org \
    --cc=chriscool@tuxfamily.org \
    --cc=git@vger.kernel.org \
    --cc=gitster@pobox.com \
    --cc=jrnieder@gmail.com \
    --cc=peff@peff.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 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.