git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Junio C Hamano <gitster@pobox.com>
To: Paul Mackerras <paulus@samba.org>
Cc: Linus Torvalds <torvalds@linux-foundation.org>, git@vger.kernel.org
Subject: Re: Suggestion: make --left-right work with --merge
Date: Fri, 29 Feb 2008 11:26:29 -0800	[thread overview]
Message-ID: <7vfxvbd0nu.fsf@gitster.siamese.dyndns.org> (raw)
In-Reply-To: 18375.58359.687664.855599@cargo.ozlabs.ibm.com

Paul Mackerras <paulus@samba.org> writes:

> Junio C Hamano writes:
>
>> Doesn't
>> 
>> 	git rev-parse --revs-only --no-flags "$@" | grep '^[0-9a-f]'
>> 
>> give you what you want?
>
> Well, it does, except for --merge, which is perhaps a special case.
>
> (Actually, what would git rev-parse --revs-only --no-flags output that
> isn't a SHA1 ID?  Why do you have the grep command there?)

Try it on user inputs like "master..next", "next...master".  You
wanted to grab only the positive ones, no?

> That's essentially what I do.  I think I'll just have to do special
> cases for --merge and --left-right.

Are you sure?  I can imagine that --merge may be problematic,
because it implicitly is about MERGE_HEAD...HEAD, but rev-parse
may not know about it.  I think --left-right and symmetric
should be fine.

	$ set x --left-right master...next; shift
	$ git rev-parse --revs-only --no-flags "$@" |
          git name-rev --stdin
        88113cfea67557067f1363b210b803637d186632 (next)
        97b97c58e609a1cd23b3c2514f41cdb0405870ee (master)
        ^97b97c58e609a1cd23b3c2514f41cdb0405870ee (master)

In the above case, master is a strict ancestor of next, but the
third line that is negative (and my grep would exclude) is
generally the merge-base between the left and right positives.
The two positives are what you wanted to exclude from the second
round, aren't they?

And in order to handle them sanely without worrying about
revision machinery and rev-parse going out-of-sync, I would
almost suggest doing something like the attached patch and say:

	$ git rev-list --no-walk "$@"

The user options can contain --left-right and --boundary, so the
output from this could begin with ">", "<" and "-".  If you
discard the ones that are prefixed with "-" (i.e. the user had
the --boundary option in "$@"), grab the ones that are not
prefixed (i.e. the user did not have the --left-right option in
"$@"), and the ones prefixed with ">" and "<" (i.e. the user did
have --left-right, and you would strip the prefix from such a
line), you would find all positive ones the user specified, I
think.

-- >8 --
revision --no-walk: do not refuse to show the list with negatives

Scripts may want to find out what revs the user gave from the
command line.

	git rev-list --no-walk --boundary "$@"

would be a natural way to find out what revs (with flags) they
are, but --no-walk refused to work if there are negative ones.
Lift that restriction.
 
Signed-off-by: Junio C Hamano <gitster@pobox.com>
---

 revision.c |    2 --
 1 files changed, 0 insertions(+), 2 deletions(-)

diff --git a/revision.c b/revision.c
index 0eb6faa..c0931eb 100644
--- a/revision.c
+++ b/revision.c
@@ -129,8 +129,6 @@ void mark_parents_uninteresting(struct commit *commit)
 
 static void add_pending_object_with_mode(struct rev_info *revs, struct object *obj, const char *name, unsigned mode)
 {
-	if (revs->no_walk && (obj->flags & UNINTERESTING))
-		die("object ranges do not make sense when not walking revisions");
 	if (revs->reflog_info && obj->type == OBJ_COMMIT &&
 			add_reflog_for_walk(revs->reflog_info,
 				(struct commit *)obj, name))


  reply	other threads:[~2008-02-29 19:27 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-02-27  2:49 Suggestion: make --left-right work with --merge Paul Mackerras
2008-02-27  7:18 ` Junio C Hamano
2008-02-27 22:36   ` Paul Mackerras
2008-02-27 22:50     ` Junio C Hamano
2008-02-28 11:21       ` Paul Mackerras
2008-02-29  7:32         ` Junio C Hamano
2008-02-29 10:52           ` Paul Mackerras
2008-02-29 19:26             ` Junio C Hamano [this message]
2008-03-01  7:39               ` Paul Mackerras
2008-03-01  7:52                 ` Junio C Hamano
2008-03-01 10:59                   ` Paul Mackerras
2008-02-29 21:05             ` Linus Torvalds
2008-02-29  7:49     ` 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=7vfxvbd0nu.fsf@gitster.siamese.dyndns.org \
    --to=gitster@pobox.com \
    --cc=git@vger.kernel.org \
    --cc=paulus@samba.org \
    --cc=torvalds@linux-foundation.org \
    /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).