git/list[1] front-page[2] threads[3] people[4] search[5] about
 

Re: git-describe recognize modified files

From
TPtzachi perelstein <tzachi_perelstein@yahoo.com>
Date
Jan 19, 2010, 12:59 UTC
Message-ID
<780857.77695.qm@web45209.mail.sp1.yahoo.com>
In-Reply-To
<alpine.DEB.1.00.1001191134130.3164@intel-tinevez-2-302>
Show 25 quoted lines
> From: Johannes Schindelin <Johannes.Schindelin@gmx.de>
> To: tzachi perelstein <tzachi_perelstein@yahoo.com>
> Cc: git@vger.kernel.org
> Sent: Tue, January 19, 2010 12:35:41 PM
> Subject: Re: git-describe recognize modified files
> 
> Hi,
> 
> On Tue, 19 Jan 2010, tzachi perelstein wrote:
> 
> > I use git-describe to form a build version automatically. This allows me
> > to deliver temporary builds for testing without having to make manual
> > tags for them. The only thing that bothers me about this is that from
> > the output of git-describe I cannot tell if there are some modified
> > files in tree or not. In both cases I will get the same version. 
> > 
> > To solve this issue, in addition to git-describe, my do_version script
> > also run git-status, and if there are "modified:" files then it
> > concatenates the string "+dirty" to output of git-describe.
> 
> The problem is that this does not describe the exact version you used very 
> well.  If you are really serious about describing the exact state you 
> described, make a tag (committing the changes to a detached HEAD first, if 
> you do not want the changes in a real branch).
> 
Well yes, this is valid, but you will end up with a tag for every build... this goes way too far.
Consider the case where you have no modified files in your tree. The output of git-describe at some given point is 'v1.0.0-2-g123457' and during the build it becomes the build version. Now you make some changes, but before committing them you build, install, and run a test. During the second build, the output of git-describe remains the same 'v1.0.0-2-g123457' although it represent two different trees. This behavior looks like somewhat incomplete to me. It sounds reasonable to me to let git-describe have the option of indicating about modified files in tree, say 'v1.0.0-2-g123457-modified' or something similar. While 'v1.0.0-2-g123457' is something you and git can refer to (i.e. checkout), 'v1.0.0-2-g123457-modified' is not. By adding the "-modified" string, git tells you explicitly that it cannot fully describe the exact tree you're using.
      
Previous: tzachi perelstein
Message 6 of 6 in “git-describe recognize modified files”
  1. tzachi perelsteinJan 19, 2010
  2. Johannes SchindelinJan 19, 2010
  3. Andreas KreyJan 19, 2010
  4. Jakub NarebskiJan 19, 2010
  5. tzachi perelsteinJan 19, 2010
  6. tzachi perelsteinJan 19, 2010

Read the whole thread, see it on lore, or plain text.

$ cat FOOTERMessages come from the public archive at lore.kernel.org/git, fetched every hour. The front page is chosen and written each morning by an AI editor and can be wrong; the threads themselves are the record. About and API. For agents: an MCP server at https://gitlist.dev/mcp, and any thread, story or person page as Markdown by adding .md to its URL (or sending Accept: text/markdown). Details in /llms.txt.