From: Petr Baudis <pasky@suse.cz>
To: Andy Whitcroft <apw@shadowen.org>
Cc: Andy Parkins <andyparkins@gmail.com>,
junkio@cox.net, git@vger.kernel.org
Subject: Re: [PATCH] Improve git-prune -n output
Date: Fri, 27 Oct 2006 03:45:01 +0200 [thread overview]
Message-ID: <20061027014501.GU20017@pasky.or.cz> (raw)
In-Reply-To: <4540F16F.4060604@shadowen.org>
Junio wrote:
> - We do not enclose a single statement in {}.
I don't think we need to enforce this rule in particular too rigorously
since in comparison with other style slips, it doesn't put you off by
unusual styling when you are reading the code, its only effect at all is
slight vertical space waste (but it isn't a pure loss anyway, for that
matter).
Dear diary, on Thu, Oct 26, 2006 at 07:33:35PM CEST, I got a letter
where Andy Whitcroft <apw@shadowen.org> said that...
> Andy Parkins wrote:
> > prune_object() in show_only mode would previously just show the path to the
> > object that would be deleted. The path the object is stored in shouldn't be
> > shown to users, they only know about sha1 identifiers so show that instead.
> >
> > Further, the sha1 alone isn't that useful for examining what is going to be
> > deleted. This patch also adds the object type to the output, which makes it
> > easy to pick out, say, the commits and use git-show to display them.
> > Signed-off-by: Andy Parkins <andyparkins@gmail.com>
> > ---
> > builtin-prune.c | 7 ++++++-
> > 1 files changed, 6 insertions(+), 1 deletions(-)
> >
> > diff --git a/builtin-prune.c b/builtin-prune.c
> > index 7290e6d..e3bcf5f 100644
> > --- a/builtin-prune.c
> > +++ b/builtin-prune.c
> > @@ -16,8 +16,13 @@ static struct rev_info revs;
> >
> > static int prune_object(char *path, const char *filename, const unsigned char *sha1)
> > {
> > + char type[20];
> > +
> > if (show_only) {
> > - printf("would prune %s/%s\n", path, filename);
> > + if (sha1_object_info(sha1, type, NULL)) {
> > + strcpy( type, "unknown type" );
> > + }
> > + printf("would prune %s %s\n", sha1_to_hex( sha1 ), type );
> > return 0;
> > }
> > unlink(mkpath("%s/%s", path, filename));
>
> If we are changing the format would it not make more sense to be in the
> same order as the tool that lets you use it?
>
> I thought that was git cat-file <type> <commit-ish>
Seconded and please use just 'unknown' for the type string, so that you
can split the lines on spaces in scripts.
Besides, in what situation do we actually get the unknown output?
Thanks,
--
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
#!/bin/perl -sp0777i<X+d*lMLa^*lN%0]dsXx++lMlN/dsM0<j]dsj
$/=unpack('H*',$_);$_=`echo 16dio\U$k"SK$/SM$n\EsN0p[lN*1
next prev parent reply other threads:[~2006-10-27 1:45 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-10-26 10:38 [PATCH] Improve git-prune -n output Andy Parkins
2006-10-26 17:21 ` Junio C Hamano
2006-10-26 17:37 ` Andy Parkins
2006-10-27 8:37 ` Andy Parkins
2006-10-28 14:00 ` Jakub Narebski
2006-10-28 20:37 ` Junio C Hamano
2006-10-26 17:33 ` Andy Whitcroft
2006-10-27 1:45 ` Petr Baudis [this message]
2006-10-27 8:19 ` Andy Parkins
2006-10-27 9:09 ` Junio C Hamano
-- strict thread matches above, loose matches on Subject: below --
2006-11-02 11:12 Andy Parkins
2006-11-03 2:40 ` 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=20061027014501.GU20017@pasky.or.cz \
--to=pasky@suse.cz \
--cc=andyparkins@gmail.com \
--cc=apw@shadowen.org \
--cc=git@vger.kernel.org \
--cc=junkio@cox.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).