* Quick command reference
From: Junio C Hamano @ 2005-05-06 6:30 UTC (permalink / raw)
To: Linus Torvalds; +Cc: David Greaves, git
In-Reply-To: <42750D06.70004@dgreaves.com>
Linus, please pull from git-jc.git archive at:
http://members.cox.net/junkio/git-jc.git/
(this time I have refs/heads/master there as well as HEAD; sorry
but no rsync).
I've added the Documentation directory as you suggested and
placed the copy of Quick reference David Greaves has been
working on. I've minimally copy edited it to match the current
command names after the big git-* renaming, and also added
descriptions of commands and scripts that was missing back
then. These three steps are recorded as separate commits (in
sequence, not Octopus).
The format is still plain text. AsciiDoc can come in the next
round, but let's get the ball rolling by putting something in
there.
Please note that I do not intend to take the document over from
David. I am just trying to help him get the result of his
effort into the mainline so that the document helps wider
audience, and to encourage (and remind) patch writers to keep it
up to date when modifying the Plumbing.
^ permalink raw reply
* Re: tool to diff cache <-> working directory
From: Thomas Glanzmann @ 2005-05-06 3:13 UTC (permalink / raw)
To: git
In-Reply-To: <7vy8atdq7i.fsf@assigned-by-dhcp.cox.net>
Hello,
> Are you using pure GIT, without any Porcelain layer like Cogito?
no, I actually write a porcelain layer myself in perl. For several reasons:
- I want something that runs on Solaris without gnu-utils
- I want to understand the git internals.
- I don't need branches and refs in .git
> Cogito has "cg-status" that shows something like "cvs -n update"
> output.
I just finished implementing my 'git status' command which does the
following:
(faui01) [~/work/git/git] git status
+ 1
? 2
- COPYING
D* Makefile
* commit.c
D export.c
+/-/* -> add, rm, mod
? -> orphan (not under revision control)
D -> dirty -> was explicit modified in cache but cache doesn't match working copy
I also have a ignore list for known orphans:
(faui01) [~/work/git/git] cat .git/ignore
\.o$
git-cat-file
...
git-write-tree
libgit.a
Sincerely,
Thomas
^ permalink raw reply
* Re: commit-id fails after cg-init
From: David A. Wheeler @ 2005-05-06 3:06 UTC (permalink / raw)
To: Alexey Nezhdanov; +Cc: git
In-Reply-To: <200505051122.03111.snake@penza-gsm.ru>
I said:
>>There's an interesting side-effect of this; I _think_ it's
>>fine but it might be worth thinking through. If all
>>new projects start with an empty tree, that creates a
>>"common root" that all projects can appeal to.
>>That means that in theory a merge between any two project root
>>trees can eventually find a common ancestor: the empty tree.
>>I _think_ that's okay... is it?
Alexey Nezhdanov wrote:
> I think this problem can be easily solved with:
> 1) Restricting to auto-select empty commit as the merge base
> 2) Make an exception from rule (1) for first real commit
Okay, but that's only true if this is really a problem.
I'm not sure it _is_, in fact I think the semantics make perfect sense.
I just wanted to note that as the kind of change
that MIGHT have a surprising side-effect, so if anyone knew of one,
please speak up!
> By (1) we will restrict accidental bad merges that can happen due to crasy
> operator - he will need to explicitly select empty commit as merge base.
Is that really a problem, though? It seems to me that since a
bad merge can be undone, it's not really a problem.
--- David A. Wheeler
^ permalink raw reply
* Re: read-only git repositories (ancient history)
From: David A. Wheeler @ 2005-05-06 3:01 UTC (permalink / raw)
To: David Lang; +Cc: git
In-Reply-To: <Pine.LNX.4.62.0505050231300.15451@qynat.qvtvafvgr.pbz>
David Lang wrote:
> given that git already treats everything in the object storage as being
> fixed it occured to me that there may be value in makeing it so that git
> can make use of more then one pool of storage
...
> there are probably other uses and it seems like a fairly small
> modification to add a hook to use if the object isn't found initially
> that I thought I'd mention it to the group.
Reasonable. Another use would be to have a repository with
"ancient history" (e.g., Linux pre-2.6) that isn't normally
loaded or looked at, but COULD be looked at if you added
that repository. For that use, though, you'd need a way to
record "the parent of X is Y" since the information creating
connections BETWEEN the repositories might not be stored in
the later repository itself (see the discussions about Linux kernel
history recreation).
--- David A. Wheeler
^ permalink raw reply
* Re: tool to diff cache <-> working directory
From: Junio C Hamano @ 2005-05-06 2:48 UTC (permalink / raw)
To: Thomas Glanzmann; +Cc: git
In-Reply-To: <20050506020759.GA11506@cip.informatik.uni-erlangen.de>
>>>>> "TG" == Thomas Glanzmann <sithglan@stud.uni-erlangen.de> writes:
TG> I thought there would be no cache<->working directory delta generation.
TG> And I need a way to see if there are unchecked-in deltas in the working
TG> tree. So I thought about looking at the 'git-diff-cache --cached tree1'
TG> and comparing it with the self generated SHAs of the working tree. But
TG> now, that there is such a tool, I am perfectly fine.
Are you using pure GIT, without any Porcelain layer like Cogito?
Cogito has "cg-status" that shows something like "cvs -n update"
output.
My (shameless plug ;-) JIT [*1*] also has "jit-status".
[References]
*1* http://members.cox.net/junkio/
^ permalink raw reply
* Re: tool to diff cache <-> working directory
From: Thomas Glanzmann @ 2005-05-06 2:07 UTC (permalink / raw)
To: git
In-Reply-To: <7vhdhhf88u.fsf@assigned-by-dhcp.cox.net>
Hello,
> git-diff-tree tree1 tree2 two trees
> git-diff-cache --cached tree1 cache and tree
> git-diff-cache tree1 tree and working directory
> git-diff-files cache and working directory
that makes it clear. Thanks.
> So git-diff-files is not just similar to but exactly is what you
> want if I read your question correctly.
Yes, it is. :-)
> Yes there is a way, git-write-blob, but why would you want to do
> that?
I thought there would be no cache<->working directory delta generation.
And I need a way to see if there are unchecked-in deltas in the working
tree. So I thought about looking at the 'git-diff-cache --cached tree1'
and comparing it with the self generated SHAs of the working tree. But
now, that there is such a tool, I am perfectly fine.
Thanks,
Thomas
^ permalink raw reply
* Re: list all dirty files in working directory
From: Linus Torvalds @ 2005-05-06 2:06 UTC (permalink / raw)
To: Thomas Glanzmann; +Cc: GIT
In-Reply-To: <20050505212152.GP20994@cip.informatik.uni-erlangen.de>
On Thu, 5 May 2005, Thomas Glanzmann wrote:
>
> is there another way than call 'checkout-cache -a' and parse the output?
> Maybe a command which lists one dirty file per line?
A simple
git-diff-files
does what I think you want.
Of course, it does a lot more too, but part of the deal is that you get to
know which files are dirty.
Linus
^ permalink raw reply
* Re: tool to diff cache <-> working directory
From: Junio C Hamano @ 2005-05-06 1:33 UTC (permalink / raw)
To: Thomas Glanzmann; +Cc: git
In-Reply-To: <20050506002347.GU20994@cip.informatik.uni-erlangen.de>
>>>>> "TG" == Thomas Glanzmann <sithglan@stud.uni-erlangen.de> writes:
TG> Is there a tool to compare cache with working directory
TG> similiar to diff-tree, diff-cache and diff-files?
git-diff-tree tree1 tree2 two trees
git-diff-cache --cached tree1 cache and tree
git-diff-cache tree1 tree and working directory
git-diff-files cache and working directory
So git-diff-files is not just similar to but exactly is what you
want if I read your question correctly.
TG> Or is there a way to find out the SHA checksum of a file in
TG> a working directory without adding it to a temporary cache?
Yes there is a way, git-write-blob, but why would you want to do
that?
^ permalink raw reply
* Re: Kernel nightly snapshots..
From: H. Peter Anvin @ 2005-05-06 0:28 UTC (permalink / raw)
To: David Woodhouse; +Cc: Linus Torvalds, Git Mailing List
In-Reply-To: <1115307033.16187.146.camel@hades.cambridge.redhat.com>
David Woodhouse wrote:
> On Thu, 2005-05-05 at 16:10 +0100, David Woodhouse wrote:
>
>>2.6.12-rc3-git1 is in the process of being built; if the attached
>>script works and continues working when invoked from cron, we might
>>even see nightly snapshots again as requested...
>
> Eep. That'll be a whole lot more useful if I do
> cg-diff -r $RELTREE:$CURTREE
> instead of
> cg-diff -r $CURTREE:$RELTREE
> ... but it should be OK now. This is the md5sum of the correct one:
>
> 21a0ee13c539e8b016682c1542bb9167 patch-2.6.12-rc3-git1.gz
>
Hi David,
Could you add that to 2.4 as well, too?
-hpa
^ permalink raw reply
* tool to diff cache <-> working directory
From: Thomas Glanzmann @ 2005-05-06 0:23 UTC (permalink / raw)
To: GIT
Hello,
is there a tool to compare cache with working directory similiar to
diff-tree, diff-cache and diff-files? Or is there a way to find out the
SHA checksum of a file in a working directory without adding it to a
temporary cache?
Thomas
^ permalink raw reply
* [PATCH] create subdirs for symlinks
From: Kay Sievers @ 2005-05-05 23:34 UTC (permalink / raw)
To: Linus Torvalds; +Cc: git
We may need to create subdirectories, before we can create a
symlink.
Signed-off-by: Kay Sievers <kay.sievers@vrfy.org>
---
--- a/checkout-cache.c
+++ b/checkout-cache.c
@@ -96,6 +96,7 @@ static int write_entry(struct cache_entr
case S_IFLNK:
memcpy(target, new, size);
target[size] = '\0';
+ create_directories(path);
if (symlink(target, path)) {
free(new);
return error("checkout-cache: unable to create symlink %s (%s)",
^ permalink raw reply
* Re: git-diff-cache uses checked-out-working-directory-files if files are newer than the cache entry
From: Thomas Glanzmann @ 2005-05-05 22:58 UTC (permalink / raw)
To: GIT
In-Reply-To: <20050505223727.GR20994@cip.informatik.uni-erlangen.de>
Hello,
* Thomas Glanzmann <sithglan@stud.uni-erlangen.de> [050506 00:38]:
> I have trouble with git-diff-cache, because it uses the file from the
> working directory instead of the cache file if the working directory is
> newer than the entry in the cache:
'git-diff-cache -r --cached HEAD' does what I want.
~~~~~~~~
Thomas
^ permalink raw reply
* git-diff-cache uses checked-out-working-directory-files if files are newer than the cache entry
From: Thomas Glanzmann @ 2005-05-05 22:37 UTC (permalink / raw)
To: GIT
Hello,
I have trouble with git-diff-cache, because it uses the file from the
working directory instead of the cache file if the working directory is
newer than the entry in the cache:
(faui01) [~/work/git/git] echo 1 > 1
(faui01) [~/work/git/git] ./git-update-cache --add 1
(faui01) [~/work/git/git] ./git-diff-cache -r HEAD
+100644 blob d00491fd7e5bb6fa28c517a0bb32b8b506539d4d 1
(faui01) [~/work/git/git] echo 2 > 1
(faui01) [~/work/git/git] ./git-diff-cache -r HEAD
+100644 blob 0000000000000000000000000000000000000000 1
(faui01) [~/work/git/git] ./git-diff-cache -p -r HEAD
Created: 1 (mode:100644)
--- /dev/null
+++ b/1
@@ -0,0 +1 @@
+2
Note this Output is wrong because the '1' get committed, if I call write-tree
(faui01) [~/work/git/git] write-tree
5a38ca90309671c5029f32f67e1aba970a4f1e08
(faui01) [~/work/git/git] ./git-ls-tree 5a38ca90309671c5029f32f67e1aba970a4f1e08 | grep 1\$
100644 blob d00491fd7e5bb6fa28c517a0bb32b8b506539d4d 1
040000 tree 9823f134bfb89097ce796f931d3efc92aadfcfbf mozilla-sha1
Same for modification:
(faui01) [~/work/git/git] echo 1 >> COPYING
(faui01) [~/work/git/git] update-cache COPYING
(faui01) [~/work/git/git] ./git-diff-cache -r HEAD
*100644->100644 blob 6ff87c4664981e4397625791c8ea3bbb5f2279a3->c17665dc78a012a55b11d083bfa065d8cd2b0df1 COPYING
(faui01) [~/work/git/git] echo 2 >> COPYING
(faui01) [~/work/git/git] ./git-diff-cache -r HEAD
*100644->100644 blob 6ff87c4664981e4397625791c8ea3bbb5f2279a3->0000000000000000000000000000000000000000 COPYING
(faui01) [~/work/git/git] write
write write-tree writevt
(faui01) [~/work/git/git] write-tree
a3f88e4c7c6818ee880d97bf3293ea56fe12c478
(faui01) [~/work/git/git] ./git-ls-tree a3f88e4c7c6818ee880d97bf3293ea56fe12c478 | grep COPYING\$
100644 blob c17665dc78a012a55b11d083bfa065d8cd2b0df1 COPYING
Is this behaviour intended? I would like to see that git-diff-cache
doesn't even look at the working directory but only operates on the
cache.
Greetings,
Thomas
^ permalink raw reply
* Re: Please rename cg-X* to something else
From: H. Peter Anvin @ 2005-05-05 22:31 UTC (permalink / raw)
To: Pavel Roskin; +Cc: git
In-Reply-To: <1115329026.3838.8.camel@dv.roinet.com>
Pavel Roskin wrote:
> Hello!
>
> Since cg-X* scripts are not supposed to be used by the end users, I
> suggest that we rename them so something not starting with "cg-" or even
> "cg" so that tab completion in bash doesn't show them. I suggest "_cgX"
> instead of "cg-X"
>
> In the long term, the internal scripts should go to
> $prefix/share/cogito, but it would require generating other scripts from
> templates to substitute $prefix, which could be inconvenient at this
> stage.
>
$prefix/libexec/cogito rather...
Pattern-substituting in bulk isn't really very hard.
-hpa
^ permalink raw reply
* Please rename cg-X* to something else
From: Pavel Roskin @ 2005-05-05 21:37 UTC (permalink / raw)
To: git
Hello!
Since cg-X* scripts are not supposed to be used by the end users, I
suggest that we rename them so something not starting with "cg-" or even
"cg" so that tab completion in bash doesn't show them. I suggest "_cgX"
instead of "cg-X"
In the long term, the internal scripts should go to
$prefix/share/cogito, but it would require generating other scripts from
templates to substitute $prefix, which could be inconvenient at this
stage.
--
Regards,
Pavel Roskin
^ permalink raw reply
* Re: list all dirty files in working directory
From: Andreas Gal @ 2005-05-05 21:35 UTC (permalink / raw)
To: Thomas Glanzmann; +Cc: GIT
In-Reply-To: <20050505212152.GP20994@cip.informatik.uni-erlangen.de>
git-update-cache --refresh | while read line; do
echo $line | cut -d ':' -f 1
done
That should give you one file per line, for every dirty file.
Andreas
On Thu, 5 May 2005, Thomas Glanzmann wrote:
> Hello,
> is there another way than call 'checkout-cache -a' and parse the output?
> Maybe a command which lists one dirty file per line?
>
> Thomas
> -
> To unsubscribe from this list: send the line "unsubscribe git" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
^ permalink raw reply
* Re: list all dirty files in working directory
From: Thomas Glanzmann @ 2005-05-05 21:32 UTC (permalink / raw)
To: GIT
In-Reply-To: <20050505212152.GP20994@cip.informatik.uni-erlangen.de>
Hello,
* Thomas Glanzmann <sithglan@stud.uni-erlangen.de> [050505 23:24]:
> is there another way than call 'checkout-cache -a' and parse the output?
> Maybe a command which lists one dirty file per line?
of course I meant parsing the output of 'update-cache --refresh'.
Thomas
^ permalink raw reply
* Re: git and symlinks as tracked content
From: Daniel Barkalow @ 2005-05-05 21:23 UTC (permalink / raw)
To: Alan Chandler; +Cc: git
In-Reply-To: <200505050709.43307.alan@chandlerfamily.org.uk>
On Thu, 5 May 2005, Alan Chandler wrote:
> On Thursday 05 May 2005 00:03, Daniel Barkalow wrote:
>
> > (on the other hand, it might make sense for git to handle files starting
> > with '.', and only skip .git).
>
> definitely only as an option. I envisage checking out (maybe anonymously)
> from svn or other repositories and then using git locally to manage my own
> development. It would be preferable for the .git repository not to be
> "polluted" with the svn prisine trees etc
It wouldn't touch them at all unless you specifically added them. The
present situation is that git ignores files starting with "." even if you
specifically add them.
-Daniel
*This .sig left intentionally blank*
^ permalink raw reply
* list all dirty files in working directory
From: Thomas Glanzmann @ 2005-05-05 21:21 UTC (permalink / raw)
To: GIT
Hello,
is there another way than call 'checkout-cache -a' and parse the output?
Maybe a command which lists one dirty file per line?
Thomas
^ permalink raw reply
* Re: [PATCH] have commit-id dereference git tags
From: Matt Porter @ 2005-05-05 21:14 UTC (permalink / raw)
To: Alexander Beyn; +Cc: git
In-Reply-To: <20050505074823.GA9075@fatelectrons.org>
On Thu, May 05, 2005 at 12:48:23AM -0700, Alexander Beyn wrote:
> With this patch, if commit-id is passed a git tag, it will check to see
> if the tag points to a commit. If it does, commit-id will return that
> commit's id.
>
> I'm not sure if this is the proper place to handle git tags, but it does
> make things like "cg-diff -r v2.6.12-rc2:v2.6.12-rc3" work in the Linus
> kernel tree. I've not noticed any problems this introduces, but I didn't
> do a thorough check.
I like this feature and it works on the Linus tree for me as well.
However, it fails on the cogito tree as follows:
mporter@beef:~/src/cogito$ cg-diff -r git-pasky-0.7:cogito-0.8
.git/objects/c8/3b95297c2a6336c2007548f909769e0862b509: No such file or directory
fatal: git-cat-file c83b95297c2a6336c2007548f909769e0862b509: bad file
Invalid id: c83b95297c2a6336c2007548f909769e0862b509
usage: git-cat-file [-t | tagname] <sha1>
usage: git-cat-file [-t | tagname] <sha1>
Invalid id:
I haven't looked any further at it yet though.
-Matt
^ permalink raw reply
* Re: Mercurial v0.4d
From: Matt Mackall @ 2005-05-05 20:36 UTC (permalink / raw)
To: Jeff Garzik; +Cc: linux-kernel, git, Linus Torvalds
In-Reply-To: <427A6E3F.5090904@pobox.com>
On Thu, May 05, 2005 at 03:04:31PM -0400, Jeff Garzik wrote:
> Matt Mackall wrote:
> >The web protocol is painfully slow, mostly because it makes an http
> >round trip per file revision to pull. I'm about to start working on a
> >replacement that minimizes round trips.
>
> Can you make it do HTTP 1.1 pipelining?
Yes, a zsync-like protocol ought to be doable. But you'll still
potentially be doing 16k requests to pull something the size of the
kernel, which isn't very friendly to a web server. So I'm working on a
stand-alone or possibly CGI-based replacement.
My goal is to do something like this:
client server
I last saw change N from you
W, X, Y, and Z are newer here
Send me X, Y, and Z relative to N
Here you go, deltas from N to X to
Y to Z, sorted by file
So not only can we be efficient in number of round trips and data
transferred, we can reduce seeks by applying all per-file changes together.
We can also usually avoid decompress/recompress and patch/diff because
both ends will end up storing the same delta.
--
Mathematics is the supreme nostalgia of our time.
^ permalink raw reply
* [PATCH] git: Mention the '-p' option in the usage help string if git-diff-tree.
From: Thomas Glanzmann @ 2005-05-05 19:51 UTC (permalink / raw)
To: Linus Torvalds, GIT
Mention the '-p' option in the usage help string of git-diff-tree.
Signed-Off-by: Thomas Glanzmann <sithglan@stud.uni-erlangen.de>
--- a/diff-tree.c
+++ b/diff-tree.c
@@ -250,7 +250,7 @@ static int diff_tree_sha1(const unsigned
return retval;
}
-static char *diff_tree_usage = "diff-tree [-r] [-z] <tree sha1> <tree sha1>";
+static char *diff_tree_usage = "diff-tree [-p] [-r] [-z] <tree sha1> <tree sha1>";
int main(int argc, char **argv)
{
^ permalink raw reply
* Re: Mercurial v0.4d
From: Jeff Garzik @ 2005-05-05 19:04 UTC (permalink / raw)
To: Matt Mackall; +Cc: linux-kernel, git, Linus Torvalds
In-Reply-To: <20050504181802.GS22038@waste.org>
Matt Mackall wrote:
> The web protocol is painfully slow, mostly because it makes an http
> round trip per file revision to pull. I'm about to start working on a
> replacement that minimizes round trips.
Can you make it do HTTP 1.1 pipelining?
Jeff
^ permalink raw reply
* Re: Kernel nightly snapshots..
From: Linus Torvalds @ 2005-05-05 16:40 UTC (permalink / raw)
To: David Woodhouse; +Cc: H. Peter Anvin, Git Mailing List
In-Reply-To: <1115307033.16187.146.camel@hades.cambridge.redhat.com>
On Thu, 5 May 2005, David Woodhouse wrote:
>
> Eep. That'll be a whole lot more useful if I do
> cg-diff -r $RELTREE:$CURTREE
> instead of
> cg-diff -r $CURTREE:$RELTREE
> ... but it should be OK now. This is the md5sum of the correct one:
>
> 21a0ee13c539e8b016682c1542bb9167 patch-2.6.12-rc3-git1.gz
Btw, if you want to, you could simplify and optimize things heavily by
doign some very specific git internal mucking around, and using the new
"-m" flag I added to "git-diff-cache".
The "-m" flag says that a file that isn't checked out will always match
the cache, which means that you can create your magic diffs that modify
the Makefile with something like this:
export SNAP_TAG_DIRECTORY=/pub/linux/kernel/v2.6/snapshots/tags
export BASE_DIRECTORY=/pub/scm/linux/kernel/git/torvalds/linux-2.6
export SHA1_FILE_DIRECTORY=$BASE_DIRECTORY/objects
RELNAME=`ls $BASE_DIRECTORY/refs/tags | tail -1`
RELCOMM=`cat $BASE_DIRECTORY/refs/tags/$RELNAME`
CURCOMM=`cat $BASE_DIRECTORY/HEAD`
SNAPNAME=`ls $SNAP_TAG_DIRECTORY | grep -- "$RELNAME-git" | tail -1`
if [ "$SNAPNAME" ]; then
SNAPCOMM=`cat $SNAP_TAG_DIRECTORY/$SNAPNAME`
[ "$SNAPCOMM" == "$CURCOMM" ] && exit 0
OLDGITNUM=`echo $SNAPNAME | sed s/^.*-git//`
NEWGITNUM=`expr $OLDGITNUM + 1`
CURNAME="$RELNAME-git$NEWGITNUM"
else
CURNAME="$RELNAME-git1"
fi
EXTRAVERSION=-`echo $CURNAME | cut -f2- -d-`
rm -rf tmp-empty-tree
mkdir -p tmp-empty-tree/.git
( cd tmp-empty-tree
git-read-tree $CURCOMM
git-checkout-cache Makefile
perl -pi -e "s/EXTRAVERSION =.*/EXTRAVERSION = $EXTRAVERSION/" Makefile
git-diff-cache -m -p $RELCOMM ) | gzip -9 > patch-$CURNAME.gz
echo CURCOMM > $SNAP_TAG_DIRECTORY/$CURNAME
but it's entirely untested, and only written in my mail editor, so..
Anyway, here's explaining what it does:
- it creates a new "tmp-empty-tree" thing, and points the object database
to _my_ tree (which is unwritable for you, but you don't care, you just
want to read it)
- it picks up my last tag as the release, and your last git tag from your
private snapshot tag directory as the last git thing. Then it takes my
current HEAD as the new thing to diff.
- we read that current tree into this empty tree, but we don't check any
of it out except for the Makefile. So the "tmp-empty-tree" should
literally just have the files "Makefile" and ".git/index" in it.
- we edit the Makefile, and then we do "git-diff-cache -m -p" between the
result and the old base.
This _should_ work. Modulo bugs. And it should be reasonably efficient. It
just needs my current git tree as of five minutes ago..
Linus
^ permalink raw reply
* Re: Kernel nightly snapshots..
From: Linus Torvalds @ 2005-05-05 15:46 UTC (permalink / raw)
To: David Woodhouse; +Cc: H. Peter Anvin, Git Mailing List
In-Reply-To: <1115305813.16187.143.camel@hades.cambridge.redhat.com>
On Thu, 5 May 2005, David Woodhouse wrote:
>
> OK, I've changed my 'origin' to an rsync URL referring to the same
> place, to make sure I get tags correctly in future. 2.6.12-rc3-git1 is
> in the process of being built; if the attached script works and
> continues working when invoked from cron, we might even see nightly
> snapshots again as requested...
RELNAME=`cg-tag-ls | grep -v 'git' | tail -n1 | cut -f1 | sed s/^v//`
this seems to assume that cg-tag-ls outputs things in the right order,
which I'm not at all sure it does.
It looks like cg-tag-ls just does
cd .git/refs/tags
for tag in *; do
...
which means that the ordering will depend on the shell ordering or
globbing.
Bash does globbing alphabetically sorted (and documents that), and it's
quite possible that all other shells do too. Even so, that doesn't
actually mean that it would be sorted by release, since v2.6.2 will sort
_after_ v2.6.12.
So this _should_ work for a while, but will eventually (before a -rc10
happens or we get to v2.6.100 ;^) need something better. That something
better probably being to ignore any tags that don't point to commits, and
then sorting by the date of the commit object.
Linus
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox