git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Yasushi SHOJI <yashi@atmark-techno.com>
To: "Shawn O. Pearce" <spearce@spearce.org>
Cc: Junio C Hamano <gitster@pobox.com>, git@vger.kernel.org
Subject: Re: [RFC] describe: add option --dirty
Date: Mon, 23 Jul 2007 16:54:10 +0900	[thread overview]
Message-ID: <87lkd7mu71.wl@mail2.atmark-techno.com> (raw)
In-Reply-To: <20070723070818.GI32566@spearce.org>

At Mon, 23 Jul 2007 03:08:18 -0400,
Shawn O. Pearce wrote:
> 
> Junio C Hamano <gitster@pobox.com> wrote:
> > Yasushi SHOJI <yashi@atmark-techno.com> writes:
> > 
> > > when --dirty is given, git describe will check the working tree and
> > > append "-dirty" to describe string if the tree is dirty.
> > > ---
> > > I'm not sure this is good idea or the current way (using diff-index in
> > > shell script) is more prefered.
> > 
> > Hmph, this makes sense _ONLY_ for HEAD, doesn't it?
> > 
> > IOW, what should this output?
> > 
> > 	$ git checkout v1.5.0 ;# detached HEAD
> >         $ git reset --hard  ;# clean slate
> >         $ echo >>Makefile ;# not anymore
> >         $ git describe --dirty v1.4.0^1
> > 
> > Should it say "v1.4.0-rc2-156-g0a8f4f0-dirty"?  The dirtiness
> > does not have anything to do with commit v1.4.0^1, so...
> 
> Good catch.  I had that in my mind when I was reading the patch,
> but failed to mention it.  I blame metze on #git, he interrupted
> my train of thought.  ;-)

I knew the issue be failed to note about it.  Thanks.

> I think the answer is the user passes either --dirty OR one or
> more commit-ish.  But not --dirty and a commit-ish.  In other words
> you can either describe the working directory state, or a commit,
> but not both at once.  Which also neatly solves my issue with
> diff-index running more than once.

So the point is would it be worth implementing in usable form?

>From the comments I'd add an option "--workinig-tree" instead of
--dirty to describe the working tree.  because that, the special case,
is what we want after all,

synopsis would be:

	SYNOPSIS
	--------
	'git-describe' [--all] [--tags] [--contains] [--abbrev=<n>]
	               [--candidates=<n>] [--debug]
	               --working-tree | <committish>...
	    :
	    :
	--working-tree::
		Describe the working tree instead of committishes.  if the
		working tree is dirty, the describe string will have "-dirty"
		appended.
	
		As you can assume from the name, this option requires working
		tree; running it on a bare repository will fail.

what do you think?
-- 
         yashi

  reply	other threads:[~2007-07-23  7:54 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-07-23  6:35 [RFC] describe: add option --dirty Yasushi SHOJI
2007-07-23  6:56 ` Junio C Hamano
2007-07-23  7:08   ` Shawn O. Pearce
2007-07-23  7:54     ` Yasushi SHOJI [this message]
2007-07-23  7:58       ` Shawn O. Pearce
2007-07-23  8:52         ` Yasushi SHOJI
2007-07-23  6:59 ` Shawn O. Pearce

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=87lkd7mu71.wl@mail2.atmark-techno.com \
    --to=yashi@atmark-techno.com \
    --cc=git@vger.kernel.org \
    --cc=gitster@pobox.com \
    --cc=spearce@spearce.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).