[RFC/PATCH] git-rev-parse vs IFS
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 [EMAIL PROTECTED]
Date: Sat Jul 16 23:13:03 2005 -0700
add foo
:00 100644 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 [EMAIL PROTECTED]
---
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;
-
To unsubscribe from this list: send the line unsubscribe git in
the body of
Re: [PATCH] git-revover-tags-script
Junio C Hamano [EMAIL PROTECTED] writes: [EMAIL PROTECTED] (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_sha1s 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
git cvsimport with branches?
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: [EMAIL PROTECTED] Little known fact about Middle Earth: The Hobbits had a very sophi- sticated computer network! It was a Tolkien Ring... - To unsubscribe from this list: send the line unsubscribe git in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] Audit rev-parse users.
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 [EMAIL PROTECTED]
---
*** 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() {
-
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: git cvsimport with branches?
В сообщении от Воскресенье 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: = [EMAIL PROTECTED]:/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 [EMAIL PROTECTED]:/tmp$ = Is it a planned behaivoir or cvsimport script were just recently broken? -- Respectfully Alexey Nezhdanov #!/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
Re: git cvsimport with branches?
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 | [EMAIL PROTECTED]
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]
-
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: git cvsimport with branches?
In message [EMAIL PROTECTED] 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: [EMAIL PROTECTED] Either one of us, by himself, is expendable. Both of us are not. -- Kirk, The Devil in the Dark, stardate 3196.1 - To unsubscribe from this list: send the line unsubscribe git in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [darcs-devel] Darcs-Git: upgrading to Git 0.99
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 - To unsubscribe from this list: send the line unsubscribe git in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] git-revover-tags-script
[EMAIL PROTECTED] (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 9e734775f7c22d2f89943ad6c745571f1930105fv2.6.12-rc2 26791a8bcf0e6d33f43aef7682bdb555236d56dev2.6.12 ... a339981ec18d304f9efeb9ccf01b1f04302edf32v2.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. - To unsubscribe from this list: send the line unsubscribe git in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Cannot get git any more?
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 . 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: [EMAIL PROTECTED] It's all Klatchian to me. - Terry Pratchett Stephen Briggs, _The Discworld Companion_ - To unsubscribe from this list: send the line unsubscribe git in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] git-revover-tags-script
Junio C Hamano [EMAIL PROTECTED] writes: [EMAIL PROTECTED] (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 - To unsubscribe from this list: send the line unsubscribe git in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] git-revover-tags-script
Junio C Hamano [EMAIL PROTECTED] writes: [EMAIL PROTECTED] (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 - To unsubscribe from this list: send the line unsubscribe git in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 0/6] cogito: compatibility with OS X
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 - To unsubscribe from this list: send the line unsubscribe git in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/6] cogito: remove use of xargs -r, a non-portable GNU extension
Remove usage of xargs -r, a non-portable gnu extension.
Signed-off-by: Bryan Larsen [EMAIL PROTECTED]
---
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.XX) || exit 1
find [EMAIL PROTECTED] -type f -print0 $TMPFILE || {
die not all files exist, nothing added
@@ -43,6 +43,6 @@ find [EMAIL PROTECTED] -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 -mInitial commit -E ${infoonly}
fi
-
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 3/6] cogito: try harder to find gnu stat
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 [EMAIL PROTECTED]
---
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)
-
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 4/6] cogito: try harder to find gnu date
Look harder for gnu date, use if available.
Signed-off-by: Bryan Larsen [EMAIL PROTECTED]
---
cg-Xlib | 12 ++--
1 files changed, 10 insertions(+), 2 deletions(-)
diff --git a/cg-Xlib b/cg-Xlib
--- a/cg-Xlib
+++ b/cg-Xlib
@@ -70,7 +70,7 @@ showdate () {
secs=$(($secs + $tzhours * 3600 + $tzmins * 60))
[ $format ] || format=+%a, %d %b %Y %H:%M:%S $2
if [ $has_gnudate ]; then
- LANG=C date -ud 1970-01-01 UTC + $secs sec $format
+ LANG=C ${has_gnudate} -ud 1970-01-01 UTC + $secs sec $format
else
LANG=C date -u -r $secs $format
fi
@@ -241,4 +241,12 @@ for stat in $(which gnustat) $(which
fi
done
-has_gnudate=$(date -Rud 1970-01-01 UTC 2/dev/null)
+has_gnudate=
+for date in $(which gnudate) $(which gdate) $(which date) ; do
+if ( [ $date ] $date -Rud 1970-01-01 UTC 2 /dev/null 2 ) ; then
+ has_gnudate=$date
+ break
+fi
+done
+
+
-
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 5/6] cogito: remove findutils dependency from Portfile
Gnu findutils (xargs) is no longer required; remove the dependency.
Gnu coreutils is still required, but only if awk is not installed.
Signed-off-by: Bryan Larsen [EMAIL PROTECTED]
---
Portfile.in |4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/Portfile.in b/Portfile.in
--- a/Portfile.in
+++ b/Portfile.in
@@ -14,8 +14,8 @@ long_description The git core, develope
homepage http://kernel.org/pub/software/scm/cogito/
master_sites http://kernel.org/pub/software/scm/cogito/
configure{}
-depends_lib bin:gcp:coreutils
-depends_lib bin:gnuxargs:findutils
+depends_lib bin:gstat:coreutils
+depends_lib lib:libz.dylib:zlib
build.typegnu
destroot.type gnu
destroot.destdir prefix=${prefix} DESTDIR=${destroot}
-
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 6/6] cogito: update documentation
Update the documentation to add a README.osx and update requirements. Signed-off-by: Bryan Larsen [EMAIL PROTECTED] --- README |2 ++ README.osx | 31 +++ 2 files changed, 33 insertions(+), 0 deletions(-) diff --git a/README b/README --- a/README +++ b/README @@ -45,6 +45,8 @@ The following tools are optional but str libcrypto (OpenSSL) rsync + gnu coreutils (the gnu versions of stat, date and cp are + preferred over the BSD variants) Starting a Fresh GIT Repository diff --git a/README.osx b/README.osx new file mode 100644 --- /dev/null +++ b/README.osx @@ -0,0 +1,31 @@ +This version of Cogito should work on OS X and other BSD variants. + +To install on OS X: + +1) Install darwinports (http://darwinports.opendarwin.org/) 2) type +make Portfile 3) type sudo port install + +You may have to deal with md5 mismatches. Either adjust the md5sum in +your new Portfile or place the new tarball in +/opt/local/var/db/dports/distfiles/cogito. + +Caveats: + +cg-pull on a local repository requires cp -u, a non-portable gnu +extension. This means that cg-pull, cg-clone and cg-update from a +local repository are broken. + +Workaround #1: Use rsync for local clones. I.e. cg-clone +rsync://localhost/dir instead of cg-clone dir. This loses the disk +space savings of normally gained by cg-clone. + +Workaround #2: Use gnu cp. cd /opt/local/bin; sudo ln -s gcp cp. + +Recommendations: + +The gnu versions of stat and date are preferred over their BSD +variants. + +patch, diff, merge, curl and rysnc are required. OS X.4 +includes recent versions of these tools. If you are not running X.4, +you may wish to check this. - To unsubscribe from this list: send the line unsubscribe git in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/6 RESEND] cogito: remove use of xargs -r, a non-portable GNU extension
Remove usage of xargs -r, a non-portable gnu extension.
Resent with nasty bug fixed.
Signed-off-by: Bryan Larsen [EMAIL PROTECTED]
---
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.XX) || exit 1
find [EMAIL PROTECTED] -type f -print0 $TMPFILE || {
die not all files exist, nothing added
@@ -43,6 +43,6 @@ find [EMAIL PROTECTED] -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 -mInitial commit -E ${infoonly}
fi
-
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] cg-commit chokes when given a very large list of files
cg-commit currently chokes when passed a very large list of files.
Fix it.
This patch depends on your filenames not containing line feeds. No
big deal, other parts of cogito break on filenames containing line
feeds.
Resent because previous send appears to have been dropped. This patch
is cleaner.
Signed-off-by: Bryan Larsen [EMAIL PROTECTED]
---
cg-commit |6 +++---
1 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/cg-commit b/cg-commit
--- a/cg-commit
+++ b/cg-commit
@@ -289,9 +289,9 @@ precommit_update () {
eval [EMAIL PROTECTED]\$fname\
done
# XXX: Do we even need to do the --add and --remove update-caches?
- [ $queueN ] { git-update-cache --add ${infoonly} -- [EMAIL
PROTECTED] || return 1; }
- [ $queueD ] { git-update-cache --force-remove -- [EMAIL
PROTECTED] || return 1; }
- [ $queueM ] { git-update-cache ${infoonly} -- [EMAIL PROTECTED]
|| return 1; }
+ [ $queueN ] { ( echo ${queueN[*]} | tr \\n \\0 | IFS=$'\n' xargs
-0 git-update-cache --add ${infoonly} -- ) || return 1; }
+ [ $queueD ] { ( echo ${queueD[*]} | tr \\n \\0 | IFS=$'\n' xargs
-0 git-update-cache --force-remove -- ) || return 1; }
+ [ $queueM ] { ( echo ${queueM[*]} | tr \\n \\0 | IFS=$'\n' xargs
-0 git-update-cache ${infoonly} -- ) || return 1; }
return 0
}
-
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] cg-commit chokes when given a very large list of files
This patch is broken. The original patch still works.
Bryan
Bryan Larsen wrote:
cg-commit currently chokes when passed a very large list of files.
Fix it.
This patch depends on your filenames not containing line feeds. No
big deal, other parts of cogito break on filenames containing line
feeds.
Resent because previous send appears to have been dropped. This patch
is cleaner.
Signed-off-by: Bryan Larsen [EMAIL PROTECTED]
---
cg-commit |6 +++---
1 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/cg-commit b/cg-commit
--- a/cg-commit
+++ b/cg-commit
@@ -289,9 +289,9 @@ precommit_update () {
eval [EMAIL PROTECTED]\$fname\
done
# XXX: Do we even need to do the --add and --remove update-caches?
- [ $queueN ] { git-update-cache --add ${infoonly} -- [EMAIL
PROTECTED] || return 1; }
- [ $queueD ] { git-update-cache --force-remove -- [EMAIL
PROTECTED] || return 1; }
- [ $queueM ] { git-update-cache ${infoonly} -- [EMAIL PROTECTED]
|| return 1; }
+ [ $queueN ] { ( echo ${queueN[*]} | tr \\n \\0 | IFS=$'\n' xargs
-0 git-update-cache --add ${infoonly} -- ) || return 1; }
+ [ $queueD ] { ( echo ${queueD[*]} | tr \\n \\0 | IFS=$'\n' xargs
-0 git-update-cache --force-remove -- ) || return 1; }
+ [ $queueM ] { ( echo ${queueM[*]} | tr \\n \\0 | IFS=$'\n' xargs
-0 git-update-cache ${infoonly} -- ) || return 1; }
return 0
}
-
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Barebone Porcelain. Where to stop?
Junio C Hamano wrote: I have been somewhat disturbed and confused by the fact that the line between what Porcelain like Cogito does and what we ship as part of core GIT is getting more and more blurred. This was especially so while I was working on the $GIT_DIR/branches/ patch. I have also been disturbed. But I am gratified that such a core git personage shares my concern. This is enough from a technical point of view, at least for me. Any lack of porcelain momentum is probably due to git having better documentation than the current porcelains, such as cogito and stacked git. The documentation, like tutorial.txt and Jeff Garzik's git kernel howto give the impression that most kernel folks use git instead of cogito. I personally think that the cogito interface and stacked git interfaces are much nicer than git's, and would like to see these two tools achieve some momentum. Another way of encouraging porcelain is by helping Pasky and Catalin out. Myself, I have been sending corresponding patches for Cogito and Stacked when making changes to git. This is purely selfish: I use both of these porcelains, but if it became general practice, we'd probably see less breakage. Bryan - To unsubscribe from this list: send the line unsubscribe git in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
git, porcelain, darcs, and version 1.0
Juliusz Chroboczek wrote: 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; I was under the impression that the stablest interface to git was the command line; we use spawnvp in stacked git. I've been using it with repositories that make the Linux kernel look small. I certainly don't think the lib interface is anywhere near stable: Linus accepted my change to index_fd far too easily. (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. Ugh. That's what they do in the commercial world. We have it so much better here in Linux BSD land: you just add a depends libgit1 line to your package, and the right thing happens: minor updates happen automatically and changes that break the interface don't. Of course, keeping it that easy for the user requires active effort from us, the developers, and sometimes the pain spills over, but the benefits are nice. I see too major long-term alternatives: 1) talk the darcs guys into using spawnvp 2) talk the git people into exporting a stable lib interface It's my opinion that #1 is a non-starter. We want others to interact with us. I'm going to use spawnvp for my porcelain, but we should be inclusive. The current 'libgit' probably contains more than Linus and Junio are comfortable locking down as a stable interface, but I'm sure that there's a subset that they'd be comfortable with once a relative amount of stability is achieved, or it may be achievable via some other method. I propose that Darcs includes all of git for now. (I prefer this over partial inclusion; anybody should be able to take the darcs sources and easily drop in a later git). However, the long term goal is for a library. Darcs and git work together to determine the minimal amount that needs to go into libgit1.so. It gets blessed by being documented, and doesn't change until libgit2.so. I'd like to see this added to Junio's list of 1.0 goals. A similar 1.0 goal would be to document porcelain's use of the .git directory. For instance, stacked git uses .git/patches, .git/patchdescr.tmpl and .git/patchexport.tmpl. If Linus does not accept a patch documenting this usage, stacked git should use .stgit instead. Bryan - To unsubscribe from this list: send the line unsubscribe git in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Last mile to 1.0?
Satturday, 16 July 2005 21:46 Junio C Hamano wrote: I do not know what release plan Linus has in mind, and also expect things to be quieter next week during OLS and kernel summit, but I think we are getting really really close. Here are the things I think we would want to see before we hit 1.0: - Remaining feature enhancements and fixes. - Anonymous pull from packed archives on remote sites via non-rsync, non-ssh transport. Many people are behind corporate firewalls that do not pass anything but outgoing http(s) and some do not even pass outgoing ssh. The recent addition of git-daemon by Linus would greatly alleviate the situation, but we may also end up wanting something HTTP reachable. I'd add the UTF-8 native support. Currently neither commit nor gitk doesn't support that. Probably this should be done at as low as possible level. -- Respectfully Alexey Nezhdanov - To unsubscribe from this list: send the line unsubscribe git in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Last mile to 1.0?
Alexey Nezhdanov [EMAIL PROTECTED] writes: I'd add the UTF-8 native support. Currently neither commit nor gitk doesn't support that. Probably this should be done at as low as possible level. I do not understand your proposal. Care to clarify? You can write your commit messages in UTF-8 today and git-cat-file commit $commit_ID, which is as low level as you can go, gives you that commit message in UTF-8. - To unsubscribe from this list: send the line unsubscribe git in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] git-revover-tags-script
Junio C Hamano [EMAIL PROTECTED] writes: [EMAIL PROTECTED] (Eric W. Biederman) writes: 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 ;-). Yep. I confused the want and have cases when I was reading the code. A generalization of git-fetch-pack that can handle multiple heads looks like it would handle the transfer part of the problem with tags. git-clone-pack already does. Then all that is needed is a sane way to list the heads that are read back and some post processing to install everything. The big question is in what format should we return the heads? Just a space separated list of sha1's or a directory hierarchy like git-clone-pack uses. Eric - To unsubscribe from this list: send the line unsubscribe git in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
