* Re: Last mile to 1.0?
From: Junio C Hamano @ 2005-07-17 0:49 UTC (permalink / raw)
To: Eric W. Biederman; +Cc: git
In-Reply-To: <m18y06pphg.fsf@ebiederm.dsl.xmission.com>
ebiederm@xmission.com (Eric W. Biederman) writes:
> Junio C Hamano <junkio@cox.net> writes:
>>
>> - Anonymous pull from packed archives on remote sites via
>> non-rsync, non-ssh transport. ...
>> ... but we may also end up wanting something HTTP
>> reachable.
>
> For this we need a cgi script that will generate an appropriate
> pack.
I agree that nothing would beat a pack customized for each
puller from the bandwidth point of view. I like the general
idea of git-daemon Linus did and the cgi script you suggest, but
I wonder what the CPU/disk load implications for the server.
^ permalink raw reply
* Re: [PATCH] git-revover-tags-script
From: Junio C Hamano @ 2005-07-17 0:51 UTC (permalink / raw)
To: Eric W. Biederman; +Cc: git
In-Reply-To: <m1u0iuo63i.fsf@ebiederm.dsl.xmission.com>
ebiederm@xmission.com (Eric W. Biederman) writes:
> First pass at a script to dig through .git/objects and find dangling
> tags. It likely has a lot of weird limitations, I don't know if it
> will work with packs, and the policy it implments is pretty stupid,
> but it is a sane start and should keep people from needing to
> rsync anything except the .git/objects part of the tree.
Also in an earlier message:
> Do we want to put some porcelain around, git-fsck-cache --tags?
> So we can discover the tag objects in the archive and place
> them someplace usable. Jeff Garzik in his howto is still recommending:
>
>> git-pull-script only downloads sha1-indexed object data, and the requested remote head.
>> This misses updates to the .git/refs/tags/ and .git/refs/heads/ directories. It is
>> advisable to update your kernel .git directories periodically with a full rsync command, to
>> make sure you got everything:
>>$ cd linux-2.6
>>$ rsync -a --verbose --stats --progress \
>> rsync://rsync.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git/ \
>> .git/
>
> Which feels like something is missing. Given that tags are
> sha1-indexed objects we should be pulling them. And I believe you can
> have a tag as a parent of a commit, so even with the pack optimized
> clients we should be pulling them now.
You cannot have a tag as a parent of a commit. commit-tree.c
explicitly checks for "commit" objects, and I think it is the
right thing to do [*1*]. You will also notice that at the end
of git-fetch-script, a tag is written in the .git/tag/<name>
file as fetched, but the .git/FETCH_HEAD file records the commit
SHA1 if a tag is fetched. So, no, unless you are using rsync
transport to pull everything in sight, I do not think you will
pull tags you do not explicitly request to be pulled as part of
the commit chain (be it done by the old fashioned commit walker,
or the on-the-fly pack transfer). I do not think "finding a
dangling tag using git-fsck-cache" is something we particularly
want to have a special wrapper around for [*2*], because the
user should not be needing to do it.
I do think we need a way to discover remote tags, an equivalent
to "wget $remote_repo/refs/tags/" (non recursive kind, just the
names). When to fetch them from remote, and where to store them
locally, however, are different matter, I think.
Given that tags, especially the signed kind, are almost always
only made by the project lead and percolate down the patch
foodchain in practice, copying _all_ tags from the remote
repository like Jeff suggests makes sense in many situations,
but in general I think the namespace under the .git/refs
directory should be controlled by the local user [*3*]. As
Linus said before, you can choose to pull a tag from him only
because he told you about it. After learning about that tag,
deciding to pull the tag "v2.6.13-rc3" from his repository, and
storing it in the same ".git/refs/tags/v2.6.13-rc3" path locally
is your choice, not his [*4*].
I think the same can be said about the remote branch heads; an
obvious case is ".git/refs/heads/master".
"git-fetch-script" is very conservative. Only when you tell it
to fetch the tag <name>, it stores it in .git/refs/tags/<name>
locally. When you tell it to fetch the head via the short-hand
merchanism by having .git/branch/linus file that records the URL
of his repository, the head is stored in .git/ref/heads/linus.
Otherwise it does not touch .git/refs at all, and I think that
is the right thing to do.
Maybe we want to have "git-list-remote URL --tags --heads" for
discovery, and perhaps "--all-tags" flag to "git-fetch-script",
to cause it to fetch all remote tags.
[Footnote]
*1* I think I once sent a patch to break this, but luckily Linus
had a much better sense than me and dropped it. It is very nice
to have adult supervision ;-).
*2* I noticed you have already sent a patch about it.
*3* I am not saying what Jeff suggests is wrong. In his
suggestion, the user is making a conscious decision to accept
and use all tags Linus has in his repository as they are; and
that is one valid usage pattern.
*4* The tag discovery mechanism is one way for the remote
repository owner to tell you about the tags.
^ permalink raw reply
* Re: Last mile to 1.0?
From: David Lang @ 2005-07-17 1:18 UTC (permalink / raw)
To: Junio C Hamano; +Cc: ebiederm, git
In-Reply-To: <7vy8869ryi.fsf@assigned-by-dhcp.cox.net>
On Sat, 16 Jul 2005, Junio C Hamano wrote:
> ebiederm@xmission.com (Eric W. Biederman) writes:
>
>> Junio C Hamano <junkio@cox.net> writes:
>>>
>>> - Anonymous pull from packed archives on remote sites via
>>> non-rsync, non-ssh transport. ...
>>> ... but we may also end up wanting something HTTP
>>> reachable.
>>
>> For this we need a cgi script that will generate an appropriate
>> pack.
>
> I agree that nothing would beat a pack customized for each
> puller from the bandwidth point of view. I like the general
> idea of git-daemon Linus did and the cgi script you suggest, but
> I wonder what the CPU/disk load implications for the server.
>
I think you need to nail down the various scenerios that people will be
useing here.
a very common one will be prople who want to setup a cron job to update
their local tree nightly, in this case having a pre-generated pack file
with each day's updates will save a significant amount of processing
power.
would it make sense to have it do something along the lines of sending the
day;s pack file plus a small number of individual object (even if the pack
file will partially duplicate object the puller already has)
David Lang
--
There are two ways of constructing a software design. One way is to make it so simple that there are obviously no deficiencies. And the other way is to make it so complicated that there are no obvious deficiencies.
-- C.A.R. Hoare
^ permalink raw reply
* [RFC/PATCH] git-rev-parse vs IFS
From: Junio C Hamano @ 2005-07-17 6:59 UTC (permalink / raw)
To: Linus Torvalds; +Cc: git
"git whatchanged" does not work with parameters that have an IFS
character; this includes a filename with SP in it. A silly
example:
$ git-whatchanged --max-count=1
diff-tree 98800286dffc76736549d7279622157ca2be9a3b (from 9171e0...
Author: Junio C Hamano <junkio@cox.net>
Date: Sat Jul 16 23:13:03 2005 -0700
add foo
:000000 100644 0000000000000000000000000000000000000000 8b13789...
$ git-whatchanged --max-count=1 'foo bar'
$ ;# no output!
This is because the tail parameter to git-diff-tree used in
git-whatchanged is $(git-rev-parse --no-revs "$@"), and the
output from git-rev-parse is split at $IFS, so it ends up
getting "foo" and "bar" separately).
If it were just embedded SP and TAB in the filnames, I would say
we can set IFS to LF in the script that use git-rev-parse,
declare that we do not support filenames with embedded LF, and
be done with it. The thing is, for pickaxe, it is very natural
to give a multi-line parameter, so setting IFS to LF is not a
general workaround.
Doing this portably is possible but a bit of pain. I can add
git-rev-parse ability to sq_quote its outputs, and change the
callers to build a command line to "eval" using it. Here is an
RFC patch that does it. My barf-o-tolerance for shell quoting
and evaling is usually much higher than others, so while I feel
this is not too ugly, it may offend your aesthetics.
------------
Help scripts that use git-rev-parse to grok args with SP/TAB/LF
The git-rev-parse command uses LF to separate each arguments it
parses, so its users at least need to set IFS to LF to be able
to handle filenames with embedded SPs and TABs. Some commands,
however, can take and do expect arguments with embedded LF
(notably, -Spickaxe of diff family), so even this workaround
does not work for them.
When --sq flag to git-rev-parse is given, instead of showing one
argument per line, it outputs arguments quoted for consumption
with "eval" by the caller, to remedy this situation.
As an example, this patch converts git-whatchanged to use this
new feature.
Signed-off-by: Junio C Hamano <junkio@cox.net>
---
git-whatchanged | 9 ++++++---
rev-parse.c | 36 ++++++++++++++++++++++++++++++++++--
2 files changed, 40 insertions(+), 5 deletions(-)
79cdb9505b0ee9a47969c3cbc8c8bf2a35b23ca8
diff --git a/git-whatchanged b/git-whatchanged
--- a/git-whatchanged
+++ b/git-whatchanged
@@ -1,4 +1,7 @@
#!/bin/sh
-git-rev-list $(git-rev-parse --default HEAD --revs-only "$@") |
- git-diff-tree --stdin --pretty -r $(git-rev-parse --no-revs "$@") |
- LESS="$LESS -S" ${PAGER:-less}
+rev_list_args=$(git-rev-parse --sq --default HEAD --revs-only "$@") &&
+diff_tree_args=$(git-rev-parse --sq --no-revs "$@") &&
+
+eval "git-rev-list $rev_list_args" |
+eval "git-diff-tree --stdin --pretty -r $diff_tree_args" |
+LESS="$LESS -S" ${PAGER:-less}
diff --git a/rev-parse.c b/rev-parse.c
--- a/rev-parse.c
+++ b/rev-parse.c
@@ -15,6 +15,7 @@ static int do_rev_argument = 1;
static int output_revs = 0;
static int flags_only = 0;
static int no_flags = 0;
+static int output_sq = 0;
#define NORMAL 0
#define REVERSED 1
@@ -54,14 +55,41 @@ static void show_rev(int type, const uns
if (no_revs)
return;
output_revs++;
+
+ /* Hexadecimal string plus possibly a carret;
+ * this does not have to be quoted even under output_sq.
+ */
printf("%s%s\n", type == show_type ? "" : "^", sha1_to_hex(sha1));
}
+static void show(const char *arg)
+{
+ if (output_sq) {
+ int sq = '\'';
+ const char *next;
+
+ putchar(sq);
+ while (*arg) {
+ next = strchr(arg, sq);
+ if (!next) {
+ fputs(arg, stdout);
+ break;
+ }
+ fputs("'\\''", stdout);
+ arg = next + 1;
+ }
+ putchar(sq);
+ putchar('\n');
+ }
+ else
+ puts(arg);
+}
+
static void show_rev_arg(char *rev)
{
if (no_revs)
return;
- puts(rev);
+ show(rev);
}
static void show_norev(char *norev)
@@ -70,7 +98,7 @@ static void show_norev(char *norev)
return;
if (revs_only)
return;
- puts(norev);
+ show(norev);
}
static void show_arg(char *arg)
@@ -328,6 +356,10 @@ int main(int argc, char **argv)
single_rev = 1;
continue;
}
+ if (!strcmp(arg, "--sq")) {
+ output_sq = 1;
+ continue;
+ }
if (!strcmp(arg, "--not")) {
show_type ^= REVERSED;
continue;
^ permalink raw reply
* [PATCH] rev-parse --sq bugfixes.
From: Junio C Hamano @ 2005-07-17 8:06 UTC (permalink / raw)
To: Linus Torvalds; +Cc: git
In-Reply-To: <7vmzol29zm.fsf@assigned-by-dhcp.cox.net>
We expect --sq output to be used to construct a string to be
"eval"ed in shell scripts, so we should not be separating the
parameter with LF, which would cause the current command to be
ended.
Also there was a silly thinko for doing the shell quoting.
Signed-off-by: Junio C Hamano <junkio@cox.net>
---
*** This is a fix on top of the "git-rev-parse vs IFS" RFC
*** patch.
rev-parse.c | 29 ++++++++++++++++-------------
1 files changed, 16 insertions(+), 13 deletions(-)
bf5a2b2f3cd5693560ab72974f9956c76a8fd667
diff --git a/rev-parse.c b/rev-parse.c
--- a/rev-parse.c
+++ b/rev-parse.c
@@ -50,18 +50,6 @@ static int is_rev_argument(const char *a
}
}
-static void show_rev(int type, const unsigned char *sha1)
-{
- if (no_revs)
- return;
- output_revs++;
-
- /* Hexadecimal string plus possibly a carret;
- * this does not have to be quoted even under output_sq.
- */
- printf("%s%s\n", type == show_type ? "" : "^", sha1_to_hex(sha1));
-}
-
static void show(const char *arg)
{
if (output_sq) {
@@ -75,16 +63,31 @@ static void show(const char *arg)
fputs(arg, stdout);
break;
}
+ while (arg < next)
+ putchar(*arg++);
fputs("'\\''", stdout);
arg = next + 1;
}
putchar(sq);
- putchar('\n');
+ putchar(' ');
}
else
puts(arg);
}
+static void show_rev(int type, const unsigned char *sha1)
+{
+ if (no_revs)
+ return;
+ output_revs++;
+
+ /* Hexadecimal string plus possibly a carret;
+ * this does not have to be quoted even under output_sq.
+ */
+ printf("%s%s%c", type == show_type ? "" : "^", sha1_to_hex(sha1),
+ output_sq ? ' ' : '\n');
+}
+
static void show_rev_arg(char *rev)
{
if (no_revs)
^ permalink raw reply
* [PATCH] diffcore-pickaxe: switch to "counting" behaviour.
From: Junio C Hamano @ 2005-07-17 8:21 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Paul Mackerras, git
In-Reply-To: <7vy886e1ry.fsf@assigned-by-dhcp.cox.net>
Instead of finding old/new pair that one side has and the
other side does not have the specified string, find old/new pair
that contains the specified string as a substring different
number of times. This would still not catch a case where you
introduce two static variable declarations and remove two static
function definitions from a file with -S"static", but would make
it behave a bit more intuitively.
Signed-off-by: Junio C Hamano <junkio@cox.net>
---
*** Linus, the "counting" behaviour that came up in our private
*** exchange was brought up independently by Paul. I think it
*** is a good compromise.
diffcore-pickaxe.c | 23 +++++++++++++++++------
1 files changed, 17 insertions(+), 6 deletions(-)
7532cfc15932595d679c16ae007f9a910a5b1d1e
diff --git a/diffcore-pickaxe.c b/diffcore-pickaxe.c
--- a/diffcore-pickaxe.c
+++ b/diffcore-pickaxe.c
@@ -5,19 +5,30 @@
#include "diff.h"
#include "diffcore.h"
-static int contains(struct diff_filespec *one,
- const char *needle, unsigned long len)
+static unsigned int contains(struct diff_filespec *one,
+ const char *needle, unsigned long len)
{
+ unsigned int cnt;
unsigned long offset, sz;
const char *data;
if (diff_populate_filespec(one, 0))
return 0;
+
sz = one->size;
data = one->data;
- for (offset = 0; offset + len <= sz; offset++)
- if (!strncmp(needle, data + offset, len))
- return 1;
- return 0;
+ cnt = 0;
+
+ /* Yes, I've heard of strstr(), but the thing is *data may
+ * not be NUL terminated. Sue me.
+ */
+ for (offset = 0; offset + len <= sz; offset++) {
+ /* we count non-overlapping occurrences of needle */
+ if (!memcmp(needle, data + offset, len)) {
+ offset += len - 1;
+ cnt++;
+ }
+ }
+ return cnt;
}
void diffcore_pickaxe(const char *needle, int opts)
^ permalink raw reply
* Re: [PATCH] git-revover-tags-script
From: Eric W. Biederman @ 2005-07-17 8:40 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vr7dy9rw4.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano <junkio@cox.net> writes:
> ebiederm@xmission.com (Eric W. Biederman) writes:
>
>> First pass at a script to dig through .git/objects and find dangling
>> tags. It likely has a lot of weird limitations, I don't know if it
>> will work with packs, and the policy it implments is pretty stupid,
>> but it is a sane start and should keep people from needing to
>> rsync anything except the .git/objects part of the tree.
>
> Also in an earlier message:
>
>> Do we want to put some porcelain around, git-fsck-cache --tags?
>> So we can discover the tag objects in the archive and place
>> them someplace usable. Jeff Garzik in his howto is still recommending:
>>
>>> git-pull-script only downloads sha1-indexed object data, and the requested
> remote head.
>>> This misses updates to the .git/refs/tags/ and .git/refs/heads/
> directories. It is
>>> advisable to update your kernel .git directories periodically with a full
> rsync command, to
>>> make sure you got everything:
>>>$ cd linux-2.6
>>>$ rsync -a --verbose --stats --progress \
>>> rsync://rsync.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git/ \
>>> .git/
>>
>> Which feels like something is missing. Given that tags are
>> sha1-indexed objects we should be pulling them. And I believe you can
>> have a tag as a parent of a commit, so even with the pack optimized
>> clients we should be pulling them now.
>
> You cannot have a tag as a parent of a commit. commit-tree.c
> explicitly checks for "commit" objects, and I think it is the
> right thing to do [*1*]. You will also notice that at the end
> of git-fetch-script, a tag is written in the .git/tag/<name>
> file as fetched, but the .git/FETCH_HEAD file records the commit
> SHA1 if a tag is fetched. So, no, unless you are using rsync
> transport to pull everything in sight, I do not think you will
> pull tags you do not explicitly request to be pulled as part of
> the commit chain (be it done by the old fashioned commit walker,
> or the on-the-fly pack transfer). I do not think "finding a
> dangling tag using git-fsck-cache" is something we particularly
> want to have a special wrapper around for [*2*], because the
> user should not be needing to do it.
Sounds fine. I totally agree that a better method for finding
the tags is preferable. So far that is all I have and currently
it works. However since commit's cannot have tags as their parents
all tags that are no non-local tags will show up as dangling tags
in git-fsck-cache. So it is a good general technique. I would
certainly prefer for us to process tags when they come in so we
don't need to play with git-fsck-cache.
> I do think we need a way to discover remote tags, an equivalent
> to "wget $remote_repo/refs/tags/" (non recursive kind, just the
> names). When to fetch them from remote, and where to store them
> locally, however, are different matter, I think.
What we care about are the tag objects, those are the only kind
that are verifiable and usable remotely.
Now that I know we do not pull tags currently with any of the
optimized transports, I would suggest taking the list of commit
objects we are transporting and for each commit look in the
remote repo/refs/tags and transferring every tag object we can find
that refers to that commit.
The implementation would likely be different from the description,
above. Probably simply finding the list of all remote tags (on the
remote end for packs). Indexing that list by commit sha1 and then
merging that list with the list of commits we are fetching.
Maybe we should create a reverse index like
repo/refs/tag_objects/<object_sha1>/<tag_sha1>s to make finding and
processing tag objects easier?
> Given that tags, especially the signed kind, are almost always
> only made by the project lead and percolate down the patch
> foodchain in practice, copying _all_ tags from the remote
> repository like Jeff suggests makes sense in many situations,
> but in general I think the namespace under the .git/refs
> directory should be controlled by the local user [*3*]. As
> Linus said before, you can choose to pull a tag from him only
> because he told you about it. After learning about that tag,
> deciding to pull the tag "v2.6.13-rc3" from his repository, and
> storing it in the same ".git/refs/tags/v2.6.13-rc3" path locally
> is your choice, not his [*4*].
>
> I think the same can be said about the remote branch heads; an
> obvious case is ".git/refs/heads/master".
Agreed. As my script was a first pass I was not handling tag name
conflicts or renaming, I was simply detecting the conflicts. As to tags
everyone who maintains a public tree for consumption makes tags.
On kernel.org we recognize several trees and their associated tags.
2.6.x (linus's tags)
2.6.12.x (the sucker tree)
2.4.x (Marcelo's tags)
2.2.x
2.0.x
2.6.?-acx ( Allen's tree)
2.6.?-mmx ( Andrew's tree)
There are several additional trees by prominent kernel developers.
And then we have the distro vendors trees.
So ultimately there are a lot of tags from a lot of different people
I would care about. Having to grab the different branches separately
is sane but having to grab each individual tag along the way starts
becoming a major pain.
Linus's comment about knowing a tag exists when he announces it
is a silly even for Linus because he doesn't always announce his
tags.
The way I envision using tags is that I have a local repository
that is maintained with automated scripts. Basically pulling
the branches that I think I will care about. This mirroring needs
the option of happening preemptively because publicly accessible
content from time to time disappears. So if you don't get it
when it is published you may never get it.
Eventually I will get a report about something in reference to a
particular tag, that I will care about. I will find that tag
and perform a checkout and look at the code.
> "git-fetch-script" is very conservative. Only when you tell it
> to fetch the tag <name>, it stores it in .git/refs/tags/<name>
> locally. When you tell it to fetch the head via the short-hand
> merchanism by having .git/branch/linus file that records the URL
> of his repository, the head is stored in .git/ref/heads/linus.
> Otherwise it does not touch .git/refs at all, and I think that
> is the right thing to do.
I agree that not updating the local .git/refs/heads or .git/refs/tags
automatically is a good thing. However none of that precludes
automatically fetching or storing of tag objects.
What happens in the rsync case of simply fetching the tag objects
is perfectly serviceable, and a simple script is all that it
takes to pull out the tags and make them useful. The only problem
in usability is that git-fsck-cache is slow, so having an index
is desirable.
> Maybe we want to have "git-list-remote URL --tags --heads" for
> discovery, and perhaps "--all-tags" flag to "git-fetch-script",
> to cause it to fetch all remote tags.
Something like that. After we get the tag objects with
the generic git mechanisms it becomes a question for porcelain what
to do with them. But porcelain can't do anything with tags if
we can't fetch tags or find tags.
> [Footnote]
>
> *1* I think I once sent a patch to break this, but luckily Linus
> had a much better sense than me and dropped it. It is very nice
> to have adult supervision ;-).
:) Until you replied I wasn't certain where we stood, and it
seemed faster to ask and start the needed conversation then to read
through the code.
> *2* I noticed you have already sent a patch about it.
What better way to start a conversation.
> *3* I am not saying what Jeff suggests is wrong. In his
> suggestion, the user is making a conscious decision to accept
> and use all tags Linus has in his repository as they are; and
> that is one valid usage pattern.
Agreed. A matter for the user or for the porcelain to decide.
> *4* The tag discovery mechanism is one way for the remote
> repository owner to tell you about the tags.
And tag discovery is what we don't have, and that is what
I am picking on.
Eric
^ permalink raw reply
* "git cvsimport" with branches?
From: Wolfgang Denk @ 2005-07-17 8:40 UTC (permalink / raw)
To: git
Is there a way to make "git cvsimport" create branches in git for any
branches it encounters in the CVS repository?
All my imports so far show just a linear line of development, and CVS
branch information seems lost.
Best regards,
Wolfgang Denk
--
Software Engineering: Embedded and Realtime Systems, Embedded Linux
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd@denx.de
Little known fact about Middle Earth: The Hobbits had a very sophi-
sticated computer network! It was a Tolkien Ring...
^ permalink raw reply
* [PATCH] Audit rev-parse users.
From: Junio C Hamano @ 2005-07-17 8:45 UTC (permalink / raw)
To: Linus Torvalds; +Cc: git
In-Reply-To: <7vmzol29zm.fsf@assigned-by-dhcp.cox.net>
This patch changes rev-parse users that pass a single argument
that is supposed to be a rev parameter to use "--verify".
Signed-off-by: Junio C Hamano <junkio@cox.net>
---
*** This does not have anything to do with the --sq flag.
git-checkout-script | 2 +-
git-cherry | 8 ++++----
git-commit-script | 2 +-
git-rebase-script | 8 ++++----
git-resolve-script | 4 ++--
5 files changed, 12 insertions(+), 12 deletions(-)
eee0f165b4762203c0d827bae7480daf41514f17
diff --git a/git-checkout-script b/git-checkout-script
--- a/git-checkout-script
+++ b/git-checkout-script
@@ -22,7 +22,7 @@ while [ "$#" != "0" ]; do
force=1
;;
*)
- rev=$(git-rev-parse --verify --revs-only "$arg^0") || exit
+ rev=$(git-rev-parse --verify "$arg^0") || exit
if [ -z "$rev" ]; then
echo "unknown flag $arg"
exit 1
diff --git a/git-cherry b/git-cherry
--- a/git-cherry
+++ b/git-cherry
@@ -28,11 +28,11 @@ The output is intended to be used as:
'
case "$#" in
-1) linus=`git-rev-parse "$1"` &&
- junio=`git-rev-parse HEAD` || exit
+1) linus=`git-rev-parse --verify "$1"` &&
+ junio=`git-rev-parse --verify HEAD` || exit
;;
-2) linus=`git-rev-parse "$1"` &&
- junio=`git-rev-parse "$2"` || exit
+2) linus=`git-rev-parse --verify "$1"` &&
+ junio=`git-rev-parse --verify "$2"` || exit
;;
*) echo >&2 "$usage"; exit 1 ;;
esac
diff --git a/git-commit-script b/git-commit-script
--- a/git-commit-script
+++ b/git-commit-script
@@ -15,7 +15,7 @@ do
-m) shift
case "$#" in
0) usage ;;
- *) use_commit=`git-rev-parse "$1"` ||
+ *) use_commit=`git-rev-parse --verify "$1"` ||
exit ;;
esac
;;
diff --git a/git-rebase-script b/git-rebase-script
--- a/git-rebase-script
+++ b/git-rebase-script
@@ -11,11 +11,11 @@ upstream tree.'
: ${GIT_DIR=.git}
case "$#" in
-1) linus=`git-rev-parse "$1"` &&
- junio=`git-rev-parse HEAD` || exit
+1) linus=`git-rev-parse --verify "$1"` &&
+ junio=`git-rev-parse --verify HEAD` || exit
;;
-2) linus=`git-rev-parse "$1"` &&
- junio=`git-rev-parse "$2"` || exit
+2) linus=`git-rev-parse --verify "$1"` &&
+ junio=`git-rev-parse --verify "$2"` || exit
;;
*) echo >&2 "$usage"; exit 1 ;;
esac
diff --git a/git-resolve-script b/git-resolve-script
--- a/git-resolve-script
+++ b/git-resolve-script
@@ -6,8 +6,8 @@
#
. git-sh-setup-script || die "Not a git archive"
-head=$(git-rev-parse --revs-only "$1")
-merge=$(git-rev-parse --revs-only "$2")
+head=$(git-rev-parse --verify "$1")
+merge=$(git-rev-parse --verify "$2")
merge_msg="$3"
dropheads() {
^ permalink raw reply
* Re: "git cvsimport" with branches?
From: Alexey Nezhdanov @ 2005-07-17 8:57 UTC (permalink / raw)
To: git
In-Reply-To: <20050717084053.94D603525D1@atlas.denx.de>
[-- Attachment #1: Type: text/plain, Size: 1638 bytes --]
В сообщении от Воскресенье 17 Июль 2005 12:40 Wolfgang Denk написал(a):
> Is there a way to make "git cvsimport" create branches in git for any
> branches it encounters in the CVS repository?
Heh. I was just preparing mail about the same problem.
It seems that git-cvsimport-script really don't likes branches in CVS.
I have attached simple script that demonstrates this.
On my machine it gives:
=============================
snake@home2:/tmp$ ./testscript
cvs checkout: Updating project
cvs add: scheduling file `a' for addition
cvs add: use `cvs commit' to add this file permanently
/tmp/20050717125452/cvsroot/project/a,v <-- a
initial revision: 1.1
cvs tag: Tagging .
T a
/tmp/20050717125452/cvsroot/project/a,v <-- a
new revision: 1.2; previous revision: 1.1
cvs update: Updating .
U a
/tmp/20050717125452/cvsroot/project/a,v <-- a
new revision: 1.1.2.1; previous revision: 1.1
cvs rlog: Logging project
New a: 2 bytes.
Tree ID 2ce1eef76631e82282e0f7f0cf9e6f3e9a4a0b1e
Committed patch 1 (origin)
Committing initial tree 2ce1eef76631e82282e0f7f0cf9e6f3e9a4a0b1e
Commit ID f7030e1c361f94b8847ef6ad88248a675c7ce5a9
Update a: 4 bytes.
Tree ID 9d3d025fff2e43c6a7b837056632b436c8e31dfe
Parent ID f7030e1c361f94b8847ef6ad88248a675c7ce5a9
Committed patch 2 (origin)
Commit ID 67889434ca9623ad91f8e81e6143fed9c4115a86
Switching from origin to branch1
usage: git-read-tree (<sha> | -m [-u] <sha1> [<sha2> [<sha3>]])
read-tree failed: 256
snake@home2:/tmp$
=============================
Is it a planned behaivoir or cvsimport script were just recently broken?
--
Respectfully
Alexey Nezhdanov
[-- Attachment #2: testscript --]
[-- Type: text/plain, Size: 339 bytes --]
#!/bin/sh
dirname=`date +"%Y%m%d%H%M%S"`
mkdir /tmp/$dirname
cd /tmp/$dirname
mkdir cvsroot
declare -x CVSROOT=/tmp/$dirname/cvsroot
cvs init
mkdir cvsroot/project
cvs co project
cd project
echo 1 >a
cvs add a
cvs ci -m 1 a
cvs tag -b branch1
echo 2 >>a
cvs ci -m 2 a
cvs update -r branch1
echo 3 >>a
cvs ci -m 3 a
git-cvsimport-script -v
^ permalink raw reply
* Re: "git cvsimport" with branches?
From: Matthias Urlichs @ 2005-07-17 9:37 UTC (permalink / raw)
To: git
In-Reply-To: <20050717084053.94D603525D1@atlas.denx.de>
Hi, Wolfgang Denk wrote:
> Is there a way to make "git cvsimport" create branches in git for any
> branches it encounters in the CVS repository?
>
That's what it does.
> All my imports so far show just a linear line of development, and CVS
> branch information seems lost.
Umm, exactly what did you do to visualize that? "gitk origin" obvioously
shows only one branch, because CVS doesn't have merge infe. Use
"gitk $(cat .git/revs/heads/*)" to show everything.
--
Matthias Urlichs | {M:U} IT Design @ m-u-it.de | smurf@smurf.noris.de
Disclaimer: The quote was selected randomly. Really. | http://smurf.noris.de
- -
"Any body of men who believe in hell will
persecute whenever they have the power."
[Joseph McCabe, "What Gods Cost Men"]
^ permalink raw reply
* Re: "git cvsimport" with branches?
From: Wolfgang Denk @ 2005-07-17 10:15 UTC (permalink / raw)
To: Matthias Urlichs; +Cc: git
In-Reply-To: <pan.2005.07.17.09.37.58.463540@smurf.noris.de>
In message <pan.2005.07.17.09.37.58.463540@smurf.noris.de> you wrote:
>
> > All my imports so far show just a linear line of development, and CVS
> > branch information seems lost.
>
> Umm, exactly what did you do to visualize that? "gitk origin" obvioously
> shows only one branch, because CVS doesn't have merge infe. Use
> "gitk $(cat .git/revs/heads/*)" to show everything.
s/v/f/
I see. Thanks for pointing out. Umm... is there a way to manually
adjust this later? I can identify the specific PatchSet(s) which
merge my CVS branches back into the trunk.
Best regards,
Wolfgang Denk
--
Software Engineering: Embedded and Realtime Systems, Embedded Linux
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd@denx.de
Either one of us, by himself, is expendable. Both of us are not.
-- Kirk, "The Devil in the Dark", stardate 3196.1
^ permalink raw reply
* Re: [darcs-devel] Darcs-Git: upgrading to Git 0.99
From: David Roundy @ 2005-07-17 10:40 UTC (permalink / raw)
To: Juliusz Chroboczek; +Cc: darcs-devel, git, Linus Torvalds
In-Reply-To: <7islyev5s4.fsf@lanthane.pps.jussieu.fr>
On Sat, Jul 16, 2005 at 10:45:47PM +0200, Juliusz Chroboczek wrote:
>
> I'd like to upgrade the Git code used in Darcs to 0.99 (we're
> currently using 0.6). [...]
Great!
> Now I'm wondering how to do that. Currently, I'm using a nasty hack
> using the C preprocessor to include just the sources we need in
> Darcs. As 0.99 builds a ``libgit.a'', I'd like to use that instead.
>
> There are three ways to do that:
>
> (1) require that the users put a suitable libgit.a in /usr/local/lib
> before building Darcs, and distribute a tarball of Git from
> darcs.net;
>
> (2) include just the sources needed for libgit.a in Darcs, and have
> the Darcs build build a local libgit
>
> (3) as (2), but include all of Git, including their
> ``user-friendly'' scripts.
>
> Solution (2) will include 33 files totalling 167KB, while (3) is about
> a megabyte of source.
I'd really prefer option (1), *if* the git folks can confirm that the API
is at least intended to be stable. As an subtly different option, we could
include a script that would download and untar the git sources and then
build them. But it'd be great to allow users to upgrade their libgit
without our intervention if a protocol or repository format change occurs
that doesn't affect the API.
I guess the real question is whether the API is more or less stable than
the protocols and disk formats. If the API is more stable, we'd rather
link with an external libgit and be robust with respect to on-disk format
changes (such as pack files). If the on-disk format is more stable, we'd
rather include a copy of the source code and be robust with respect to API
changes of libgit.
A fourth option would be to include git sources, but also include a
configure flag that could be used to link with an external libgit. This is
probably the most robust solution, but also the most complex solution (and
thus probably not the best).
--
David Roundy
http://www.darcs.net
^ permalink raw reply
* Re: "git cvsimport" with branches?
From: Alexey Nezhdanov @ 2005-07-17 10:48 UTC (permalink / raw)
To: git; +Cc: Matthias Urlichs
In-Reply-To: <pan.2005.07.17.09.37.58.463540@smurf.noris.de>
Sunday, 17 July 2005 13:37 Matthias Urlichs wrote:
> Hi, Wolfgang Denk wrote:
> > Is there a way to make "git cvsimport" create branches in git for any
> > branches it encounters in the CVS repository?
>
> That's what it does.
But it does not, at least in some cases.
See my previous mail:
http://marc.theaimsgroup.com/?l=git&m=112159075029007&w=2
It have simple script attached that reproduces the problem.
--
Respectfully
Alexey Nezhdanov
^ permalink raw reply
* Re: "git cvsimport" with branches?
From: Alexey Nezhdanov @ 2005-07-17 12:33 UTC (permalink / raw)
To: git
In-Reply-To: <200507171448.09049.snake@penza-gsm.ru>
Sunday, 17 July 2005 14:48 Alexey Nezhdanov wrote:
> Sunday, 17 July 2005 13:37 Matthias Urlichs wrote:
> > Hi, Wolfgang Denk wrote:
> > > Is there a way to make "git cvsimport" create branches in git for any
> > > branches it encounters in the CVS repository?
> >
> > That's what it does.
>
> But it does not, at least in some cases.
> See my previous mail:
> http://marc.theaimsgroup.com/?l=git&m=112159075029007&w=2
> It have simple script attached that reproduces the problem.
Ouch. It was all me. I have lost -A flag.
Sorry for noise.
--
Respectfully
Alexey Nezhdanov
^ permalink raw reply
* [offtopic]Re: "git cvsimport" with branches?
From: Alexey Nezhdanov @ 2005-07-17 18:02 UTC (permalink / raw)
To: git
In-Reply-To: <200507171633.17667.snake@penza-gsm.ru>
Sorry for noise again.
I have found two bugs in cvsps that results in the wrong import to git.
I tried to contact developer but it seems that his mail have no mailserver
ATM. Since he has made some changes for git already - probably someone on
this list have his new contact. Please tell me it or forward my mail to him.
Thanks.
For the curious, here are the bugs:
1) some branches fork off too late - cvsps shifts brahches starts forward to
the future
Example:
http://www.penza-gsm.ru/snake/testscript
2) some branches are not detected at all, not recorded as patchsets and
consequently not imported into git.
Example (branch "old"):
http://www.penza-gsm.ru/snake/simplexml.py,v
--
Respectfully
Alexey Nezhdanov
^ permalink raw reply
* Re: [PATCH] git-revover-tags-script
From: Junio C Hamano @ 2005-07-17 18:53 UTC (permalink / raw)
To: Eric W. Biederman; +Cc: git
In-Reply-To: <m1psthomf0.fsf@ebiederm.dsl.xmission.com>
ebiederm@xmission.com (Eric W. Biederman) writes:
> What we care about are the tag objects, those are the only kind
> that are verifiable and usable remotely.
>
> Now that I know we do not pull tags currently with any of the
> optimized transports, I would suggest taking the list of commit
> objects we are transporting and for each commit look in the
> remote repo/refs/tags and transferring every tag object we can find
> that refers to that commit.
I do not think it is particularly a good idea to fetch a tag
that refers to a commit when the user asks only for that commit
(e.g. the user said "the head of this remote branch I am
tracking", and the head happened to have been tagged). Yes, it
may be convenient, but retrieving the commit chain and
retrieving tags are conceptually separate issues. A tag does
not necessarily refer to a commit, so your reverse index does
not make sense for a tag pointing at a blob, for example.
I think if we have discovery mechanism of remote tags/heads, we
do not need anything else. You _could_ say something like:
$ git-list-remote --tags linux-2.6
9e734775f7c22d2f89943ad6c745571f1930105f v2.6.12-rc2
26791a8bcf0e6d33f43aef7682bdb555236d56de v2.6.12
...
a339981ec18d304f9efeb9ccf01b1f04302edf32 v2.6.13-rc3
$ git-list-remote --tags linux-2.6 |
while read sha1 tag;
do
git fetch linux-2.6 tag $tag
done
and you are done. We did not use the reverse index, nor we used
the --all-tags flag to git-fetch-script. You do not even need
git-list-remote if you are willing to wget a=summary output from
gitweb and parse the bottom of the page ;-).
The above may not exactly work for linux-2.6 repository because
I think the "tag" form of git-fetch-script may expect to find a
tag that resolves to a commit object and there is the oddball
v2.6.11-tree tag, but you got the general idea.
^ permalink raw reply
* Cannot get git any more?
From: Wolfgang Denk @ 2005-07-17 22:49 UTC (permalink / raw)
To: git
Hi,
I cannot access the git repositorey any more:
-> rpm -q cogito
cogito-0.12.1-1
-> cd git
-> cat .git/branches/origin
rsync://rsync.kernel.org/pub/scm/git/git.git
-> cg-update
@ERROR: Unknown module 'pub'
rsync: connection unexpectedly closed (41 bytes read so far)
rsync error: error in rsync protocol data stream (code 12) at io.c(342)
cg-pull: unable to get the head pointer of branch master
-> cd ..
-> mv git git.OLD
-> cg-clone rsync://rsync.kernel.org/pub/scm/git/git.git
/usr/local/src/git
defaulting to local storage area
@ERROR: Unknown module 'pub'
rsync: connection unexpectedly closed (41 bytes read so far)
rsync error: error in rsync protocol data stream (code 12) at io.c(342)
cg-pull: unable to get the head pointer of branch master
cg-init: pull failed
-> rm -fr git
-> cg-clone http://www.kernel.org/pub/scm/git/git.git
/usr/local/src/git
defaulting to local storage area
00:44:43 URL:http://www.kernel.org/pub/scm/git/git.git/refs/heads/master [41/41] -> "refs/heads/origin" [1]
progress: 2 objects, 4252 bytes
error: File 6ff87c4664981e4397625791c8ea3bbb5f2279a3 (http://www.kernel.org/pub/scm/git/git.git/objects/6f/f87c4664981e4397625791c8ea3bbb5f2279a3) corrupt
Cannot obtain needed blob 6ff87c4664981e4397625791c8ea3bbb5f2279a3
while processing commit 0000000000000000000000000000000000000000.
cg-pull: objects pull failed
cg-init: pull failed
Am I missing something?
Best regards,
Wolfgang Denk
--
Software Engineering: Embedded and Realtime Systems, Embedded Linux
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd@denx.de
It's all Klatchian to me.
- Terry Pratchett & Stephen Briggs, _The Discworld Companion_
^ permalink raw reply
* Re: [PATCH] git-revover-tags-script
From: Eric W. Biederman @ 2005-07-18 0:06 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7voe91jmc6.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano <junkio@cox.net> writes:
> ebiederm@xmission.com (Eric W. Biederman) writes:
>
>> What we care about are the tag objects, those are the only kind
>> that are verifiable and usable remotely.
>>
>> Now that I know we do not pull tags currently with any of the
>> optimized transports, I would suggest taking the list of commit
>> objects we are transporting and for each commit look in the
>> remote repo/refs/tags and transferring every tag object we can find
>> that refers to that commit.
>
> I do not think it is particularly a good idea to fetch a tag
> that refers to a commit when the user asks only for that commit
> (e.g. the user said "the head of this remote branch I am
> tracking", and the head happened to have been tagged). Yes, it
> may be convenient, but retrieving the commit chain and
> retrieving tags are conceptually separate issues. A tag does
> not necessarily refer to a commit, so your reverse index does
> not make sense for a tag pointing at a blob, for example.
After thinking it through I have to agree but not for your reasons.
The killer argument for me is that tags can be made at any time.
Which means that any incremental scheme that links pulling of tags
to the pulling of the objects they refer to will fail when
the tag is made after you have pulled the object.
So at the very least the computation of which tags to pull needs
to be separate from the computation of which object to pull.
> I think if we have discovery mechanism of remote tags/heads, we
> do not need anything else. You _could_ say something like:
>
> $ git-list-remote --tags linux-2.6
> 9e734775f7c22d2f89943ad6c745571f1930105f v2.6.12-rc2
> 26791a8bcf0e6d33f43aef7682bdb555236d56de v2.6.12
> ...
> a339981ec18d304f9efeb9ccf01b1f04302edf32 v2.6.13-rc3
> $ git-list-remote --tags linux-2.6 |
> while read sha1 tag;
> do
> git fetch linux-2.6 tag $tag
> done
>
> and you are done. We did not use the reverse index, nor we used
> the --all-tags flag to git-fetch-script. You do not even need
> git-list-remote if you are willing to wget a=summary output from
> gitweb and parse the bottom of the page ;-).
I agree that anything we do will need to look roughly like the
above. Beyond a simple index of what tags are present
in the objects directory I can't think of anything that would
be a cost savings, except possibly ordering the tags by creation
date.
There are a couple pieces of your example that disturb me.
- The tag names are forced to be the same between trees.
- You don't verify the tags before installing them.
- I view tags as history and by having tag fetching totally
separate it becomes easy to loose that history.
I do like the fact that when you fetch a tag you are certain
to fetch all of the objects and it refers to.
I don't know what the solution is but we seem to be getting closer.
Eric
^ permalink raw reply
* Re: [PATCH] git-revover-tags-script
From: Eric W. Biederman @ 2005-07-18 0:19 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7voe91jmc6.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano <junkio@cox.net> writes:
> ebiederm@xmission.com (Eric W. Biederman) writes:
>
>> What we care about are the tag objects, those are the only kind
>> that are verifiable and usable remotely.
>>
>> Now that I know we do not pull tags currently with any of the
>> optimized transports, I would suggest taking the list of commit
>> objects we are transporting and for each commit look in the
>> remote repo/refs/tags and transferring every tag object we can find
>> that refers to that commit.
>
> I think if we have discovery mechanism of remote tags/heads, we
> do not need anything else. You _could_ say something like:
>
> $ git-list-remote --tags linux-2.6
> 9e734775f7c22d2f89943ad6c745571f1930105f v2.6.12-rc2
> 26791a8bcf0e6d33f43aef7682bdb555236d56de v2.6.12
> ...
> a339981ec18d304f9efeb9ccf01b1f04302edf32 v2.6.13-rc3
> $ git-list-remote --tags linux-2.6 |
> while read sha1 tag;
> do
> git fetch linux-2.6 tag $tag
> done
Actually looking a little deeper unless I have misread
the code git-fetch-pack at least will only ask for commit
objects so git fetch will never return a tag object.
I have yet to find where it git-fetch-pack actually prints
objects out so I still may be something.
Eric
^ permalink raw reply
* Re: [PATCH] git-revover-tags-script
From: Junio C Hamano @ 2005-07-18 1:13 UTC (permalink / raw)
To: Eric W. Biederman; +Cc: git
In-Reply-To: <m1hdetnfjq.fsf@ebiederm.dsl.xmission.com>
ebiederm@xmission.com (Eric W. Biederman) writes:
> There are a couple pieces of your example that disturb me.
Did you actually think I suggested you to make that into a
script that cannot be configured? No, it was Junio acquiring a
habit from Linus to give a rough outline in a code form in his
e-mail client.
In another message, you said:
> Actually looking a little deeper unless I have misread
> the code git-fetch-pack at least will only ask for commit
> objects so git fetch will never return a tag object.
I thought so but then I tried it and actually it does seem to
work as expected (well, it is Linus code so it has to be perfect
;-). I created an empty directory and ran the following script.
It creates two commits, tags the later commit to
".git/refs/tags/one", and shows the list of objects the
upload-pack (the peer git-fetch-pack talks to) decides to pack
and send to the puller that has the first commit only. The
first git-rev-list shows one extra object compared to the second
one; the difference is the named tag that is being asked.
------------
#!/bin/sh
rm -fr .git
git-init-db
zero_tree=$(git-write-tree)
echo "base tree $zero_tree"
zero_commit=$(
echo Empty tree as the base |
git-commit-tree $zero_tree
)
echo "base commit $zero_commit"
echo >a
git-update-cache --add a
one_tree=$(git-write-tree)
echo "one tree $one_tree"
one_commit=$(
echo Add one file |
git-commit-tree $one_tree -p $zero_commit
)
echo "one commit $one_commit"
tagger=$(git-var GIT_COMMITTER_IDENT)
echo "object $one_commit
type commit
tag tag-one
tagger $tagger
just a tag." | git-mktag >.git/refs/tags/one
echo "one tag `cat .git/refs/tags/one`"
echo "*** reachable from one tag but not from zero"
git-rev-list --objects tags/one ^$zero_commit
echo "*** reachable from one commit but not from zero"
git-rev-list --objects $one_commit ^$zero_commit
^ permalink raw reply
* [PATCH 0/6] cogito: compatibility with OS X
From: Bryan Larsen @ 2005-07-18 2:50 UTC (permalink / raw)
To: bryan.larsen; +Cc: Bryan Larsen, pasky, git
This is a resend of my previous set of patches.
I have updated these patches with Junio's suggestion.
I have also added some documentation, a simple README.osx.
Once you have applied these patches, could you choose one of these 4
options, Junio?
1) send me the result of "make Portfile" on next release
2) attach the result of "make Portfile" to
http://bugzilla.opendarwin.org/show_bug.cgi?id=3949 on next release
3) upload Portfile's along with the .tar.gz's.
4) tell me you're doing none of the above's, and I'll do the process
manually.
2 of these 5 patches are unchanged from the previous post. I have
attached them anyways to maintain the series. Please let me know if
this is poor etiquette.
thanks,
Bryan
^ permalink raw reply
* [PATCH 1/6] cogito: remove use of xargs -r, a non-portable GNU extension
From: Bryan Larsen @ 2005-07-18 2:50 UTC (permalink / raw)
To: bryan.larsen; +Cc: Bryan Larsen, pasky, git
In-Reply-To: <20050718025024.11198.10556.sendpatchset@bryan-larsens-ibook-g4.local>
Remove usage of xargs -r, a non-portable gnu extension.
Signed-off-by: Bryan Larsen <bryan.larsen@gmail.com>
---
cg-add | 6 +++---
cg-init | 2 +-
2 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/cg-add b/cg-add
--- a/cg-add
+++ b/cg-add
@@ -25,8 +25,6 @@ USAGE="cg-add [-N] FILE..."
. ${COGITO_LIB}cg-Xlib
-[ "$1" ] || usage
-
infoonly=
while optparse; do
if optparse -N; then
@@ -36,6 +34,8 @@ while optparse; do
fi
done
+[ "$ARGS" ] || usage
+
TMPFILE=$(mktemp -t gitadd.XXXXXX) || exit 1
find "${ARGS[@]}" -type f -print0 > $TMPFILE || {
die "not all files exist, nothing added"
@@ -43,6 +43,6 @@ find "${ARGS[@]}" -type f -print0 > $TMP
}
cat $TMPFILE | tr '\0' '\n' | sed 's/^/Adding file /'
-cat $TMPFILE | xargs -0r git-update-cache --add ${infoonly} --
+cat $TMPFILE | xargs -0 git-update-cache --add ${infoonly} --
rm $TMPFILE
diff --git a/cg-init b/cg-init
--- a/cg-init
+++ b/cg-init
@@ -55,7 +55,7 @@ if [ "$uri" ]; then
echo "Cloned (origin $uri available as branch \"origin\")"
else
git-read-tree # Seed the dircache
- find * \( -type f -o -type l \) -print0 | xargs -0r cg-add ${infoonly}
+ [ `ls` ] && find * \( -type f -o -type l \) -print0 | xargs -0 cg-add ${infoonly}
cg-commit -C -m"Initial commit" -E ${infoonly}
fi
^ permalink raw reply
* [PATCH 2/6] cogito: remove use of cp -a, a non-portable GNU extension
From: Bryan Larsen @ 2005-07-18 2:50 UTC (permalink / raw)
To: bryan.larsen; +Cc: Bryan Larsen, pasky, git
In-Reply-To: <20050718025024.11198.10556.sendpatchset@bryan-larsens-ibook-g4.local>
Remove usage of cp -a, a non-portable gnu extension.
Signed-off-by: Bryan Larsen <bryan.larsen@gmail.com>
---
cg-pull | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/cg-pull b/cg-pull
--- a/cg-pull
+++ b/cg-pull
@@ -217,7 +217,7 @@ fetch_local () {
[ "$1" = "-i" ] && shift
[ "$1" = "-s" ] && shift
- cp_flags_l="-va"
+ cp_flags_l="-vdpR"
if [ "$1" = "-u" ]; then
cp_flags_l="$cp_flags_l -u$can_hardlink"
suggest_hardlink=
^ permalink raw reply
* [PATCH 3/6] cogito: try harder to find gnu stat
From: Bryan Larsen @ 2005-07-18 2:51 UTC (permalink / raw)
To: bryan.larsen; +Cc: Bryan Larsen, pasky, git
In-Reply-To: <20050718025024.11198.10556.sendpatchset@bryan-larsens-ibook-g4.local>
Look harder for gnu stat.
Cogito has code to use awk if gnu stat is missing. Look harder
for gnu stat under alternate names such as gstat and gnustat, avoiding
the use of awk if possible.
Signed-off-by: Bryan Larsen <bryan.larsen@gmail.com>
---
cg-Xlib | 13 +++++++++----
1 files changed, 9 insertions(+), 4 deletions(-)
diff --git a/cg-Xlib b/cg-Xlib
--- a/cg-Xlib
+++ b/cg-Xlib
@@ -229,11 +229,16 @@ fi
# Compatibility hacks:
-# Fortunately none as of now.
-
export BROKEN_MKTEMP=1
del=$($(which mktemp) -t 2>/dev/null) && { rm $del; export BROKEN_MKTEMP=; }
-has_stat=$(which stat 2>/dev/null)
-[ "$has_stat" ] && $has_stat -c %s / 2>/dev/null >&2 || has_stat=
+
+has_stat=
+for stat in "$(which gnustat)" "$(which gstat)" "$(which stat)" ; do
+ if ( [ $stat ] && $stat -c %s / 2> /dev/null >&2 ) ; then
+ has_stat=$stat
+ break
+ fi
+done
+
has_gnudate=$(date -Rud "1970-01-01 UTC" 2>/dev/null)
^ 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