From: "Dirk Süsserott" <newsletter@dirk.my1.cc>
To: Daniel Quinlan <danq@brtt.com>
Cc: Jakub Narebski <jnareb@gmail.com>,
Daniel Barkalow <barkalow@iabervon.org>,
git@vger.kernel.org
Subject: Re: help with git usage
Date: Thu, 08 May 2008 22:01:06 +0200 [thread overview]
Message-ID: <48235C02.9010808@dirk.my1.cc> (raw)
In-Reply-To: <200805072242.m47Mg1o0015578@rs40.luxsci.com>
Hi,
what about using git-describe? At work we use sth. similar to the
following script. Let's call it 'git-stamp':
-------------
#!/usr/bin/bash
if [ "$(git rev-parse --is-inside-work-tree 2>/dev/null)" = "true" ]; then
here=$(pwd)
topdir=$(git rev-parse --show-cdup)
cd ${topdir:-'./'}
desc=$(git describe)
if [ $(git diff-index --name-only HEAD | wc -l) -ne 0 ]; then
desc="$desc-dirty"
fi
cd $here
echo $desc
exit 0;
else
echo "Not inside a git working tree."
exit 1;
fi
-------------
Basically it outputs the output of 'git-describe'. When something
whithin your working dir is currently *not* checked in, it outputs
"$(git-describe)-dirty".
Some sort of "-D$(git-stamp)" compiler switch would do the thing.
Depending on your makefile or scons-script this would yield to a
complete recompile of everything when only one file has changed.
In our environment we patch $(git-stamp) into some "version.c"
so the whole application only gets recompiled when version.c
has changed.
HTH,
Dirk
Daniel Quinlan schrieb:
> Thanks for your earlier responses, they were very helpful.
>
> On Apr 30, 2008, at 1:39 AM, Jakub Narebski wrote:
>
>> Daniel Barkalow <barkalow@iabervon.org> writes:
>>
>>> On Tue, 29 Apr 2008, Daniel Quinlan wrote:
>>>
>>>> I've been trying to use git for awhile now, (and I've read a lot
>>>> of documentation, though maybe my comprehension has not been high
>>>> enough) but there are several operations which I can't figure out:
>>
>> Many of answers to your questions can be found on GitFaq,
>> http://git.or.cz/gitwiki/GitFaq
>
> I should have read this earlier. I don't really understand the
> details, but I get the idea: make the central repository bare.
>
>>
>
>>>> 3) Similarly, I can't use the little context diffs I can see in
>>>> git-gui -- I need to see side by side comparisons; I've become
>>>> accustomed to tkdiff. It seems like git mergetool knows how to do
>>>> that in some restricted circumstances, but I want to do it outside
>>>> the context of a merge.
>>>
>>> This I don't know, but you can get particular files from particular
>>> commits output with "git show <commit>:<path>", and you can likely wire
>>> something up.
>>
>> From the various graphical comparison tools, Meld has supposedly Git
>> support (http://meld.sourceforge.net/). Supposedly only because I
>> have not tested this; see
>> http://git.or.cz/gitwiki/InterfacesFrontendsAndTools#head-00fbd1ac45fe93dac4653cad3639b3df73d8657e
>>
>>
>
> I found no mention of git on the meld man page or in the meld mailing
> list.
>
> Here's a (perhaps naive) perl script which uses "git show" and wraps
> around
> the original tkdiff. Other cvs users might find it useful, though it
> can surely
> be improved.
>
>
>
>
>
> I'm looking for a way to embed some identifying information about version
> into compiled programs. I hasten to add that I am not looking to
> expand RCS-like
> tags. Unlike CVS/RCS, git provides a single value that characterizes
> the whole
> distribution, at least if everything is committed. So, something like
> "git log | head -1 | awk '{print $2}'"
> probably provides a value which I can embed into executables and
> libraries, tying
> them to a particular source configuration. I'm just curious if
> there's a better approach
> to getting the commit hash.
>
> -- danq
>
>
next prev parent reply other threads:[~2008-05-08 20:02 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-04-29 17:37 help with git usage Daniel Quinlan
2008-04-29 18:07 ` Daniel Barkalow
2008-04-30 7:39 ` Jakub Narebski
2008-05-07 22:41 ` Daniel Quinlan
2008-05-08 0:16 ` Julian Phillips
2008-05-08 20:01 ` Dirk Süsserott [this message]
2008-05-08 23:07 ` Jakub Narebski
2008-04-30 12:02 ` Matt Graham
2008-04-30 13:09 ` Andreas Ericsson
2008-04-30 8:22 ` Richard Quirk
2008-04-30 10:39 ` Jakub Narebski
2008-04-30 11:50 ` Richard Quirk
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=48235C02.9010808@dirk.my1.cc \
--to=newsletter@dirk.my1.cc \
--cc=barkalow@iabervon.org \
--cc=danq@brtt.com \
--cc=git@vger.kernel.org \
--cc=jnareb@gmail.com \
/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.