* Re: git-ls-files -o no recurse?
From: Linus Torvalds @ 2006-01-05 17:31 UTC (permalink / raw)
To: Darrin Thompson; +Cc: Git Mailing List
In-Reply-To: <1136481352.5597.2.camel@localhost.localdomain>
On Thu, 5 Jan 2006, Darrin Thompson wrote:
>
> Worked great!
Ok. You can bug Junio about it when he returns, maybe he thinks it's a
great feature.
> > +static int show_ignored_directories = 0;
>
> Did you perhaps mean s/ignored/other/g ? I thought maybe you were being
> clever but I couldn't get it to do anything useful with -i, only -o.
Yeah.
Linus
^ permalink raw reply
* Re: use result of open(2) to check for presence
From: Alex Riesen @ 2006-01-05 18:07 UTC (permalink / raw)
To: Morten Welinder; +Cc: Junio C Hamano, git
In-Reply-To: <118833cc0601050845i40f93bbajdd70e77953d07014@mail.gmail.com>
Morten Welinder, Thu, Jan 05, 2006 17:45:27 +0100:
> Config files always tend to grow, but I do agree that 4GB config files stretches
> credibility a bit.
>
> However, empty ones are not unlikely and then mmap will fail.
>
Shouldn't be a problem: the code in question does not seem to do
anything for empty files and wont even touch the result of mmap.
^ permalink raw reply
* Re: use GIT_DIR instead of /var/tmp
From: Alex Riesen @ 2006-01-06 9:32 UTC (permalink / raw)
To: Jon Nelson; +Cc: Linus Torvalds, junio, git
In-Reply-To: <Pine.LNX.4.63.0601051048490.667@gheavc.wnzcbav.cig>
Jon Nelson, Thu, Jan 05, 2006 17:49:36 +0100:
> Do you still need write access to $GIT_DIR if $GIT_INDEX_FILE is set to
> some place outside of $GIT_DIR?
yes, $GIT_DIR/refs/heads/ref-pointed-by-HEAD is updated by git-reset.
^ permalink raw reply
* Re: use GIT_DIR instead of /var/tmp
From: Johannes Schindelin @ 2006-01-06 10:00 UTC (permalink / raw)
To: Alex Riesen; +Cc: git
In-Reply-To: <20060106093213.GA4268@steel.home>
Hi,
On Fri, 6 Jan 2006, Alex Riesen wrote:
> Jon Nelson, Thu, Jan 05, 2006 17:49:36 +0100:
> > Do you still need write access to $GIT_DIR if $GIT_INDEX_FILE is set to
> > some place outside of $GIT_DIR?
>
> yes, $GIT_DIR/refs/heads/ref-pointed-by-HEAD is updated by git-reset.
In a strict sense, this means write access to $GIT_DIR/refs/heads/. In a
shared setup, I have repositories where all developers are allowed to
write to that folder, but only the repo maintainer (yours truly) is
allowed to write to $GIT_DIR (which effectively means: nobody can write
an index).
Maybe the safe method would be to introduce $GIT_TMP_DIR, with "/tmp/"
being the default?
Ciao,
Dscho
^ permalink raw reply
* [PATCH] Teach cvsexportcommit to add new files
From: Yann Dirson @ 2006-01-06 20:54 UTC (permalink / raw)
To: GIT list
Teach cvsexportcommit to add new files
"cvs add" support was already there, but the "unknown" status
returned when querying a file not yet known to cvs caused the
script to abort prematurely.
---
commit 7e1b8a9af653c9a4f8d2a6a4b34ccf56a2f48526
tree f94f057ec672b715ffda28e359bd5d672fdfb6b3
parent 58e3fb40f7ca1c28f9105c15166884f80bb22e55
author Yann Dirson <ydirson@altern.org> Fri, 06 Jan 2006 21:31:21 +0100
committer Yann Dirson <dwitch@gandelf.nowhere.earth> Fri, 06 Jan 2006 21:31:21 +0100
git-cvsexportcommit.perl | 12 ++++++++++--
1 files changed, 10 insertions(+), 2 deletions(-)
diff --git a/git-cvsexportcommit.perl b/git-cvsexportcommit.perl
index 5a8c011..d5fbee7 100755
--- a/git-cvsexportcommit.perl
+++ b/git-cvsexportcommit.perl
@@ -103,8 +103,16 @@ undef @files; # don't need it anymore
# check that the files are clean and up to date according to cvs
my $dirty;
-foreach my $f (@afiles, @mfiles, @dfiles) {
- # TODO:we need to handle removed in cvs and/or new (from git)
+foreach my $f (@afiles) {
+ my $status = `cvs -q status "$f" | grep '^File: '`;
+
+ unless ($status =~ m/Status: Unknown$/) {
+ $dirty = 1;
+ warn "File $f is already known in your CVS checkout!\n";
+ }
+}
+foreach my $f (@mfiles, @dfiles) {
+ # TODO:we need to handle removed in cvs
my $status = `cvs -q status "$f" | grep '^File: '`;
unless ($status =~ m/Status: Up-to-date$/) {
--
Yann Dirson <ydirson@altern.org> |
Debian-related: <dirson@debian.org> | Support Debian GNU/Linux:
| Freedom, Power, Stability, Gratis
http://ydirson.free.fr/ | Check <http://www.debian.org/>
^ permalink raw reply related
* Re: [PATCH] diff-tree: stop on broken output pipe
From: Junio C Hamano @ 2006-01-06 22:36 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git
In-Reply-To: <Pine.LNX.4.63.0601020116020.11331@wbgn013.biozentrum.uni-wuerzburg.de>
Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> Without this, on my iBook git-whatchanged keeps running when I
> quit "less". I have to interrupt the process a second time. No
> idea why it works on Linux.
>
> - if (!no_commit_id)
> - printf("%s%c", header, diff_options.line_termination);
> + if (!no_commit_id && printf("%s%c", header,
> + diff_options.line_termination) < 0)
> + die("broken output pipe");
> header = NULL;
There are tons of output other than this printf() and catching
an output error only on this one and assuming that is a broken
pipe somehow feels doubly wrong to me.
^ permalink raw reply
* Re: local git push bug wrt GIT_OBJECT_DIRECTORY
From: Junio C Hamano @ 2006-01-06 22:36 UTC (permalink / raw)
To: Matt Draisey; +Cc: git
In-Reply-To: <1135922900.2103.37.camel@della.draisey.ca>
Matt Draisey <matt@draisey.ca> writes:
> Using git-send-pack to push to a local repository will propagate the
> environment variable GIT_OBJECT_DIRECTORY to git-receive-pack.
> git-receive-pack correctly ignores GIT_DIR (as opposed to what the
> documentation says) but, unfortunately, honours GIT_OBJECT_DIRECTORY.
Thanks for noticing.
True; receive-pack does not "ignore", but is explicitly told to
use the other repository by invoking send-pack.
> It's not clear to me whether the correct behaviour is for git-send-pack
> to clean up its environment before it execs or for git-receive-pack to
> ignore most GIT variables.
Probably GIT_OBJECT_DIRECTORY should not be propagated;
GIT_ALTERNATE_OBJECT_DIRECTORIES neither.
^ permalink raw reply
* Re: [PATCH] Teach cvsexportcommit to add new files
From: Junio C Hamano @ 2006-01-06 22:37 UTC (permalink / raw)
To: Yann Dirson; +Cc: git, Martin Langhoff
In-Reply-To: <20060106205441.GA32585@nowhere.earth>
Yann Dirson <ydirson@altern.org> writes:
> Teach cvsexportcommit to add new files
> "cvs add" support was already there, but the "unknown" status
> returned when querying a file not yet known to cvs caused the
> script to abort prematurely.
Thanks. I'll take the patch as is, but I noticed that the
cvsexportcommit still has some room for polishing.
* The command is to be run from CVS working copy (as desribed
in the documentation) and seems to assume that the parent
commit is checked out at least for the paths involved between
the commit and the parent (not clearly documented).
* I wonder if it is safe with filenames with embedded SP?
* This undef @files seem premature; later you will say
cleanupcvs(@files) won't you?
> $opt_v && print "The commit affects:\n ";
> $opt_v && print join ("\n ", @afiles,@mfiles,@dfiles) . "\n\n";
> undef @files; # don't need it anymore
> ...
> ### NOTE: if you are planning to die() past this point
> ### you MUST call cleanupcvs(@files) before die()
* I think this grep '^Binary' is unsafe; different versions of
gnu diff say just "Files differ".
> print "'Patching' binary files\n";
>
> my @bfiles = `git-diff-tree -p $parent $commit | grep '^Binary'`;
* ls-tree can take $parent (a commit which is by definition a
treeish) happily here, so rev-parse is not needed.
> my $tree = `git-rev-parse $parent^{tree} `;
> chomp $tree;
> my $blob = `git-ls-tree $tree "$f" | cut -f 1 | cut -d ' ' -f 3`;
> chomp $blob;
* another way would be git-hash-object (without -w) the working
tree file (which you already know matches the $parent
version) and compare the hash with $blob without extracting
it with cat-file.
> `git-cat-file blob $blob > $tmpdir/blob`;
> `cmp -q $f $tmpdir/blob`;
I am getting an impression that _if_ we care about applying
fuzzy patch like this, giving fuzz feature to git-apply would
help this program somewhat, but at the same time I do not think
of a good reason to even accept nonexact patch when synching two
SCM histories.
^ permalink raw reply
* Re: [PATCH] rpmbuild doesn't like '-' in version strings
From: Junio C Hamano @ 2006-01-06 22:37 UTC (permalink / raw)
To: John Ellson; +Cc: git, Linus Torvalds
In-Reply-To: <dp3qpb$7uk$1@sea.gmane.org>
John Ellson <ellson@research.att.com> writes:
> Suggested fix: Use '_' instead of '-'
I wonder if the right fix is to change the git-describe output
before the current output becomes too widespread. After all,
somebody might be tempted to use 1.0.6-g58e3 as a tagname ;-).
For example, if we say "1.0.6:58e3" there is no ambiguity, but
probably binary packagers would not like colon either X-<.
More seriously, I do not think git-describe based versioning
scheme meshes well with binary packagers. There is no guaranee
1.0.6-g58e3 comes before 1.0.6-g4e7a2 (it does not). To really
fix this problem, I think the rpm target of the main Makefile
needs to be modified to include something monotonicly increasing
(e.g. number of seconds since the base commit encoded in base26,
or something silly like that) between the base version and the
abbreviated object name, but the development being distributed,
my today's version on top of 1.0.6 may be way behind your
yesterday's version, so some centralized coordination (read:
manual version assignment by the maintainer, or automated
assignment but only reserved for the maintainer and unavailable
to mere mortals) might be needed to truly solve this. In that
sense, maybe leaving the interim version unbuildable for binary
packaging might be considered a feature.
What Linus did with git-describe is good for people who do not
install prebuilt binaries, or know how to override (false)
downgrade refusal by package managers.
I vaguely recall that Debian does not like underscores at random
places, but we know both RPM and Debian can handle multiple
dots, so if you insist using the git-describe based version to
build binary packages, I suspect dot instead of underscore would
be a better choice. Since I do not understand what that "g"
stands for anyway, how about doing something like this instead?
Note that the part about "describe --stamp" is not really a
serious counterproposal. If I cut a binary package out of my
master and then one of my topic branches, it is very likely they
will get confused time ordering when they happen to find the
same base revision. This patch is for discussion only and I
will not even keep it in the proposed updates branch. I would
however welcome if somebody polishes it up and makes it suitable
for binary packaging purposes ;-).
-- >8 --
[PATCH] sanitize describe output used in GIT_VERSION
It is reported that RPM does not like '-' in version name, which
unfortunately is what the new "git-describe" based interim
versioning scheme gives.
This does three things:
- GIT-VERSION-GEN avoids '-' characters and replaces them with '.'.
- git-describe --stamp flag adds number of seconds since the
base revision until the named revision, between the base
revision name and the abbreviated object name.
- GIT-VERSION-GEN uses describe --stamp to make commits
monotonically increasing to keep binary package managers
happier, unless you have multiple branches or skewed clocks.
---
diff --git a/Documentation/git-describe.txt b/Documentation/git-describe.txt
index 0efe82a..ca0e781 100644
--- a/Documentation/git-describe.txt
+++ b/Documentation/git-describe.txt
@@ -8,7 +8,7 @@ git-describe - Show the most recent tag
SYNOPSIS
--------
-'git-describe' [--all] [--tags] [--abbrev=<n>] <committish>...
+'git-describe' [--all] [--tags] [--abbrev=<n>] [--stamp] <committish>...
DESCRIPTION
-----------
@@ -35,6 +35,12 @@ OPTIONS
Instead of using the default 8 hexadecimal digits as the
abbreviated object name, use <n> digits.
+--stamp::
+ Add a timestamp string, expressed as number of seconds
+ between the commit times of the base commit and the
+ named commit, encoded in base26 (a-z), between the base
+ version name and abbreviated object name.
+
EXAMPLES
--------
diff --git a/GIT-VERSION-GEN b/GIT-VERSION-GEN
index 845b9dc..f6ed589 100755
--- a/GIT-VERSION-GEN
+++ b/GIT-VERSION-GEN
@@ -2,8 +2,8 @@
GVF=GIT-VERSION-FILE
-VN=$(git-describe --abbrev=4 HEAD 2>/dev/null) || VN=v1.0.GIT
-VN=$(expr "$VN" : v'\(.*\)')
+VN=$(git-describe --abbrev=4 --stamp HEAD 2>/dev/null) || VN=v1.0.GIT
+VN=$(echo "$VN" | sed -e 's/^v//' -e 's/-g\([^-]*\)$/-\1/' -e 's/-/./g')
if test -r $GVF
then
VC=$(sed -e 's/^GIT_VERSION = //' <$GVF)
diff --git a/describe.c b/describe.c
index 84d96b5..0414100 100644
--- a/describe.c
+++ b/describe.c
@@ -13,6 +13,7 @@ static int tags = 0; /* But allow any ta
#define DEFAULT_ABBREV 8 /* maybe too many */
static int abbrev = DEFAULT_ABBREV;
+static int stamp = 0; /* show timestamps between base and abbrev */
static int names = 0, allocs = 0;
static struct commit_name {
@@ -98,6 +99,39 @@ static int compare_names(const void *_a,
return (a_date > b_date) ? -1 : (a_date == b_date) ? 0 : 1;
}
+static void describe_it(struct commit *cmit, struct commit_name *name)
+{
+ const char *ab = find_unique_abbrev(cmit->object.sha1, abbrev);
+ if (stamp) {
+ unsigned long t1 = name->commit->date;
+ unsigned long t2 = cmit->date;
+ char tstamp[11]; /* 26^13 < 2^64 < 26^14 */
+ int i;
+
+ /* It had better be the former unless there is something
+ * really really screwy with your clock.
+ */
+ if (t1 < t2) {
+ unsigned long t = t2 - t1;
+ for (i = 0; i < sizeof(tstamp) && t; i++) {
+ unsigned long d = t % 26;
+ t /= 26;
+ tstamp[i] = d + 'a';
+ }
+ }
+ else {
+ tstamp[0] = '0';
+ i = 1;
+ }
+ printf("%s-", name->path);
+ while (0 < i)
+ putchar(tstamp[--i]);
+ printf("-g%s\n", ab);
+ }
+ else
+ printf("%s-g%s\n", name->path, ab);
+}
+
static void describe(struct commit *cmit)
{
struct commit_list *list;
@@ -122,8 +156,7 @@ static void describe(struct commit *cmit
struct commit *c = pop_most_recent_commit(&list, SEEN);
n = match(c);
if (n) {
- printf("%s-g%s\n", n->path,
- find_unique_abbrev(cmit->object.sha1, abbrev));
+ describe_it(cmit, n);
return;
}
}
@@ -146,6 +179,10 @@ int main(int argc, char **argv)
tags = 1;
continue;
}
+ if (!strcmp(arg, "--stamp")) {
+ stamp = 1;
+ continue;
+ }
if (!strncmp(arg, "--abbrev=", 9)) {
abbrev = strtoul(arg + 9, NULL, 10);
if (abbrev < 4 || 40 <= abbrev)
^ permalink raw reply related
* Re: trivial: remove the dots at the end of file names
From: Junio C Hamano @ 2006-01-06 22:37 UTC (permalink / raw)
To: Alex Riesen; +Cc: git
In-Reply-To: <81b0412b0601050346v43dc1e58k7e0b51c6d6817d1e@mail.gmail.com>
Alex Riesen <raa.lkml@gmail.com> writes:
> Subject: [PATCH] Remove the dots at the end of file names
> to make the output more mouse copy-paste friendly.
> - echo "ERROR: Merge conflict in $4."
> + echo "ERROR: Merge conflict in $4"
Hmph. I think there are places we state pathname within 'single
quotes' as a part of sentence, which may have the same issue. I
understand and am sympathetic to the motivation, but at the same
time messages that do not end with full-stop somehow make me
feel quite uneasy. I'll swallow the patch; maybe it is just me.
^ permalink raw reply
* Re: [PATCH] update-hook: Major overhaul (handling tags, mainly).
From: Junio C Hamano @ 2006-01-06 22:37 UTC (permalink / raw)
To: Andreas Ericsson; +Cc: git
In-Reply-To: <20060104161729.7FD9C5BE85@nox.op5.se>
Andreas Ericsson <ae@op5.se> writes:
> This is the update hook we use in all our git-repos.
>
> It has some improvements over the original version, namely:
> * Don't send every commit since dawn of time when adding a new tag.
> * When updating an annotated tag, just send the diffs since the last tag.
> * Add diffstat output for 'normal' commits (top) and annotated tags (bottom).
> * Block un-annotated tags in shared repos.
>
> I'm a bit uncertain about that last one, but it demonstrates how to
> disallow updates of a ref which we use, so I kept it.
>
> Note that git-describe is needed for the "changes since last annotated tag"
> thing to work.
>
> Signed-off-by: Andreas Ericsson <ae@op5.se>
templates/hooks--* is a good place to showcase these "best
current practices", but unfortunately we can have only one BCP
per script there. If nobody objects I'd take this patch.
I have been wondering if we would want to have an "examples/"
directory in the source tree.
^ permalink raw reply
* Re: [PATCH] debian/ directory
From: Junio C Hamano @ 2006-01-06 22:37 UTC (permalink / raw)
To: Gerrit Pape; +Cc: git
In-Reply-To: <20060102103138.3414.qmail@e631ec7a6a8b9a.315fe32.mid.smarden.org>
Gerrit Pape <pape@smarden.org> writes:
> Thanks to Norbert Tretkowski, the git* and cogito packages are now
> available for Debian sarge through http://backports.org/.
Good to hear. Does that mean nobody would suffer if I drop
debian/ subdirectory along with deb target in the main Makefile
anymore? If so I would.
^ permalink raw reply
* Re: git-ls-files -o no recurse?
From: Junio C Hamano @ 2006-01-06 22:38 UTC (permalink / raw)
To: Git Mailing List; +Cc: Linus Torvalds, Darrin Thompson
In-Reply-To: <Pine.LNX.4.64.0601041330550.3668@g5.osdl.org>
Linus Torvalds <torvalds@osdl.org> writes:
> On Wed, 4 Jan 2006, Darrin Thompson wrote:
>>
>> Would it be hard to make git-ls-files optionally do this?
>
> Something like the appended may or may not be what you're looking for..
>
> Linus
Not to mention test scripts, I suspect that making this the
default would break existing callers including the famous
"git-init-db && git-add ." pattern. The other commonplace use
is git-status, which might benefit from this option. If we are
going to use it in git-status, we may want to give them trailing
slashes to make them stand out, though.
^ permalink raw reply
* Re: Use testlib to skip t3300-funny-names
From: Junio C Hamano @ 2006-01-06 22:38 UTC (permalink / raw)
To: Alex Riesen; +Cc: git
In-Reply-To: <81b0412b0601050353o6b96ed4fp2a6d24dd514cc9c2@mail.gmail.com>
Alex Riesen <raa.lkml@gmail.com> writes:
> The test cannot be run on cygwin anyway.
> Corrected the error message to reflect the problem source.
I'd rather see the test actually try to create a funny-named
testfile and see if it managed to create it, so that it can be
skipped on non DOS systems that mounted DOS filesystem.
So instead I would do something like this:
---
diff --git a/t/t3300-funny-names.sh b/t/t3300-funny-names.sh
index 6a85d67..b1a86db 100755
--- a/t/t3300-funny-names.sh
+++ b/t/t3300-funny-names.sh
@@ -9,9 +9,6 @@ This test tries pathnames with funny cha
tree, index, and tree objects.
'
-# since FAT/NTFS does not allow tabs in filenames, skip this test
-test "$(uname -o 2>/dev/null)" = Cygwin && exit 0
-
. ./test-lib.sh
p0='no-funny'
@@ -27,6 +24,12 @@ EOF
cat >"$p1" "$p0"
echo 'Foo Bar Baz' >"$p2"
+test -f "$p1" && cmp "$p0" "$p1" || {
+ # since FAT/NTFS does not allow tabs in filenames, skip this test
+ say 'Your filesystem does not allow tabs in filenames, test skipped.'
+ test_done
+}
+
echo 'just space
no-funny' >expected
test_expect_success 'git-ls-files no-funny' \
^ permalink raw reply related
* Re: [PATCH] git-mv.perl: use stderr for error output and cleanup
From: Junio C Hamano @ 2006-01-06 22:38 UTC (permalink / raw)
To: Alex Riesen; +Cc: git
In-Reply-To: <81b0412b0601050349s6bec1a36jc410fd315fbbc4c@mail.gmail.com>
Alex Riesen <raa.lkml@gmail.com> writes:
> It is cleaned up in the "Perl' meaning" of process: trivial loops
> replaced with map{}
I agree with dies and warns, but I am slightly negative about
this one.
> - foreach my $fileName (@deletedfiles) {
> - print H "$fileName\0";
> - }
> + print H map {"$_\0"} @deletedfiles;
Although there is always one more way to do the same thing in
Perl, and there are good idioms that make well written Perl
programs very compact and clear, I tend to value readability for
(competent) programmers whose native language happens to be
something other than Perl.
I think using map{} to build a list to be printed without
inter-element spaces is far less intuitive than how the code was
originally written for non Perl readers. Using join("\0", @df)
might be easier to read but you would then need terminating NUL,
and either one of the following are worse:
do { local ($") = "\0"; print "@deletedfiles\0" } # this one is buggy
do { local ($\) = "\0"; print for (@deletedfiles); } # impossible to read
So I'd prefer not touching for (@df) { print H "$_\n" } loops.
^ permalink raw reply
* Re: fix potential deadlock in create_one_file
From: Junio C Hamano @ 2006-01-06 22:38 UTC (permalink / raw)
To: Alex Riesen; +Cc: git
In-Reply-To: <81b0412b0601050100v519e76c8u11f4d484f9d28e0a@mail.gmail.com>
Alex Riesen <raa.lkml@gmail.com> writes:
> It can happen if the temporary file already exists (i.e. after a panic
> and reboot).
We use pid here and using somebody else's pid feels wrong but
that is only for collision avoidance, mktemp(3) is no better,
and neither tmpfile(3) nor mkstemp(3) are usable for directories
anyway, so your patch as is would be the best solution.
Thanks.
^ permalink raw reply
* Re: [PATCH] Ignore tags that contain colons in their names
From: Junio C Hamano @ 2006-01-06 22:37 UTC (permalink / raw)
To: Simon Richter; +Cc: git
In-Reply-To: <43BBCA0A.6020906@kleinhenz.de>
Simon Richter <Simon.Richter@kleinhenz.de> writes:
> a repo I was trying to clone contained a tag that somehow had a colon
> in its name, which is illegal. The attached patch makes git-fetch
> ignore these tags rather than barf.
Good intentions, but colon is not the only character.
I suspect we need to do something like this instead.
---
diff --git a/git-fetch.sh b/git-fetch.sh
index 125bcea..b46b3e5 100755
--- a/git-fetch.sh
+++ b/git-fetch.sh
@@ -188,11 +188,20 @@ esac
reflist=$(get_remote_refs_for_fetch "$@")
if test "$tags"
then
- taglist=$(git-ls-remote --tags "$remote" |
- sed -e '
- /\^/d
- s/^[^ ]* //
- s/.*/.&:&/')
+ taglist=$(IFS=" " &&
+ git-ls-remote --tags "$remote" |
+ while read sha1 name
+ do
+ case "$name" in
+ (*^*) continue ;;
+ esac
+ if git-check-ref-format "$name"
+ then
+ echo ".${name}:${name}"
+ else
+ echo >&2 "warning: tag ${name} ignored"
+ fi
+ done)
if test "$#" -gt 1
then
# remote URL plus explicit refspecs; we need to merge them.
^ permalink raw reply related
* cg-commit problems with path_xargs
From: Becky Bruce @ 2006-01-06 22:51 UTC (permalink / raw)
To: git
So,
I'm having an issue with cg-commit, where it only commits the first
[modified,added,deleted] file listed by cg-status (example below). I
tracked this down to these lines in cg-commit:
[ "$queueA" ] && { ( echo "${queueA[*]}" | path_xargs git-
update-index --add ${infoonly} -- ) ||
return 1; }
[ "$queueD" ] && { ( echo "${queueD[*]}" | path_xargs git-
update-index --force-remove -- ) || re
turn 1; }
[ "$queueM" ] && { ( echo "${queueM[*]}" | path_xargs git-
update-index ${infoonly} -- ) || retur
n 1; }
If I revert these lines to their form in cogito 0.13, the problem
resolves itself:
[ "$queueA" ] && { ( echo "${queueA[*]}" | tr \\n \\0 |
xargs -0 git-update-index --add ${infoon
ly} -- ) || return 1; }
[ "$queueD" ] && { ( echo "${queueD[*]}" | tr \\n \\0 |
xargs -0 git-update-index --force-remove
-- ) || return 1; }
[ "$queueM" ] && { ( echo "${queueM[*]}" | tr \\n \\0 |
xargs -0 git-update-index ${infoonly} --
) || return 1; }
I've seen the threads about problems with newer bash versions, but
this is happening to me with bash 2.05b (/usr/bin/env bash --version
reports GNU bash, version 2.05b.0(1)-release (i386-redhat-linux-
gnu)). This is occuring with the latest git repository for cogito
(cogito-0.17pre.GIT)
Should I be running a different bash?
Thanks,
Becky
Here's the cg-commands that show the problem.....
> cg-status
Heads:
>master 4c1697d8a481086ea58307f88e7bb251a92e1d9b
R origin 88202a0c84e1951d6630d1d557d4801a8cc5b5ef
M arch/powerpc/Kconfig
M arch/powerpc/kernel/pci_64.c
M arch/powerpc/kernel/prom.c
M arch/powerpc/kernel/udbg.c
M arch/powerpc/platforms/maple/setup.c
M arch/powerpc/platforms/powermac/feature.c
M arch/powerpc/platforms/powermac/pci.c
M arch/powerpc/platforms/powermac/pic.c
M arch/powerpc/platforms/powermac/setup.c
M arch/powerpc/platforms/powermac/smp.c
M arch/powerpc/sysdev/Makefile
M arch/powerpc/sysdev/dart.h
M arch/powerpc/sysdev/mpic.c
M drivers/ide/ppc/pmac.c
M drivers/macintosh/smu.c
M include/asm-powerpc/hardirq.h
M include/asm-powerpc/iommu.h
M include/asm-powerpc/mpic.h
M include/asm-powerpc/pmac_feature.h
M include/linux/pci_regs.h
> cg --version
cogito-0.17pre.GIT (6d0b0790e812618e694798f741f76ccb202c9cab)
> cg-commit -m "test"
M arch/powerpc/Kconfig
M arch/powerpc/kernel/pci_64.c
M arch/powerpc/kernel/prom.c
M arch/powerpc/kernel/udbg.c
M arch/powerpc/platforms/maple/setup.c
M arch/powerpc/platforms/powermac/feature.c
M arch/powerpc/platforms/powermac/pci.c
M arch/powerpc/platforms/powermac/pic.c
M arch/powerpc/platforms/powermac/setup.c
M arch/powerpc/platforms/powermac/smp.c
M arch/powerpc/sysdev/Makefile
M arch/powerpc/sysdev/dart.h
M arch/powerpc/sysdev/mpic.c
M drivers/ide/ppc/pmac.c
M drivers/macintosh/smu.c
M include/asm-powerpc/hardirq.h
M include/asm-powerpc/iommu.h
M include/asm-powerpc/mpic.h
M include/asm-powerpc/pmac_feature.h
M include/linux/pci_regs.h
Committed as 33f25d02e785e549be195a2c34dcee659ece185f.
cde-tx32-ldt329:~/merge/becky/test.linus.newgit > cg-status
Heads:
>master 33f25d02e785e549be195a2c34dcee659ece185f
R origin 88202a0c84e1951d6630d1d557d4801a8cc5b5ef
M arch/powerpc/kernel/pci_64.c
M arch/powerpc/kernel/prom.c
M arch/powerpc/kernel/udbg.c
M arch/powerpc/platforms/maple/setup.c
M arch/powerpc/platforms/powermac/feature.c
M arch/powerpc/platforms/powermac/pci.c
M arch/powerpc/platforms/powermac/pic.c
M arch/powerpc/platforms/powermac/setup.c
M arch/powerpc/platforms/powermac/smp.c
M arch/powerpc/sysdev/Makefile
M arch/powerpc/sysdev/dart.h
M arch/powerpc/sysdev/mpic.c
M drivers/ide/ppc/pmac.c
M drivers/macintosh/smu.c
M include/asm-powerpc/hardirq.h
M include/asm-powerpc/iommu.h
M include/asm-powerpc/mpic.h
M include/asm-powerpc/pmac_feature.h
M include/linux/pci_regs.h
^ permalink raw reply
* Re: [PATCH] git-mv.perl: use stderr for error output and cleanup
From: Randal L. Schwartz @ 2006-01-06 22:55 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Alex Riesen, git
In-Reply-To: <7vek3lq8wu.fsf@assigned-by-dhcp.cox.net>
>>>>> "Junio" == Junio C Hamano <junkio@cox.net> writes:
Junio> So I'd prefer not touching for (@df) { print H "$_\n" } loops.
Being as I'm a *bit* familiar with Perl, I'd write that as:
print H "$_\0" for @deletedfiles;
if you want to write "for" as "foreach", I wouldn't complain either.
After all, that's spelled "f o r", but pronounced "foreach". :)
--
Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095
<merlyn@stonehenge.com> <URL:http://www.stonehenge.com/merlyn/>
Perl/Unix/security consulting, Technical writing, Comedy, etc. etc.
See PerlTraining.Stonehenge.com for onsite and open-enrollment Perl training!
^ permalink raw reply
* Re: [PATCH] git-mv.perl: use stderr for error output and cleanup
From: Linus Torvalds @ 2006-01-06 23:28 UTC (permalink / raw)
To: Randal L. Schwartz; +Cc: Junio C Hamano, Alex Riesen, git
In-Reply-To: <86wthd7ypx.fsf@blue.stonehenge.com>
On Fri, 6 Jan 2006, Randal L. Schwartz wrote:
> >>>>> "Junio" == Junio C Hamano <junkio@cox.net> writes:
>
> Junio> So I'd prefer not touching for (@df) { print H "$_\n" } loops.
>
> Being as I'm a *bit* familiar with Perl, I'd write that as:
>
> print H "$_\0" for @deletedfiles;
>
> if you want to write "for" as "foreach", I wouldn't complain either.
> After all, that's spelled "f o r", but pronounced "foreach". :)
It is official: perl people are crazy.
I'm sorry, Randal, but you're clearly a totally different species.
I just hope you don't cross-breed. Shudder.
Linus
^ permalink raw reply
* Re: [PATCH] git-mv.perl: use stderr for error output and cleanup
From: Randal L. Schwartz @ 2006-01-06 23:53 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Junio C Hamano, Alex Riesen, git
In-Reply-To: <Pine.LNX.4.64.0601061525100.3169@g5.osdl.org>
>>>>> "Linus" == Linus Torvalds <torvalds@osdl.org> writes:
Linus> I just hope you don't cross-breed. Shudder.
Don't worry. So far, I haven't had any offers.
:-)
--
Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095
<merlyn@stonehenge.com> <URL:http://www.stonehenge.com/merlyn/>
Perl/Unix/security consulting, Technical writing, Comedy, etc. etc.
See PerlTraining.Stonehenge.com for onsite and open-enrollment Perl training!
^ permalink raw reply
* Re: [PATCH] rpmbuild doesn't like '-' in version strings
From: Andreas Ericsson @ 2006-01-07 0:04 UTC (permalink / raw)
To: git
In-Reply-To: <7voe2prniw.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano wrote:
> John Ellson <ellson@research.att.com> writes:
>
>
>>Suggested fix: Use '_' instead of '-'
>
>
> I wonder if the right fix is to change the git-describe output
> before the current output becomes too widespread.
I don't think there's any major risk of the current output being very
widespread. It's not very useful for scripting.
> To really
> fix this problem, I think the rpm target of the main Makefile
> needs to be modified to include something monotonicly increasing
> (e.g. number of seconds since the base commit encoded in base26,
> or something silly like that)
Why not keep it super-simple and just print the number of commits since
whatever tag is found? It only counts commits on the current branch, so
a merge shows up as a single commit. That should more or less be ok
though and goes well with the topic branch model.
> If I cut a binary package out of my
> master and then one of my topic branches, it is very likely they
> will get confused time ordering when they happen to find the
> same base revision.
I suppose this could happen when counting commits as well. People who
build packages from different branches should be shot on sight though,
so I wouldn't worry about it.
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
^ permalink raw reply
* Re: [PATCH] git-mv.perl: use stderr for error output and cleanup
From: Linus Torvalds @ 2006-01-07 0:10 UTC (permalink / raw)
To: Randal L. Schwartz; +Cc: Junio C Hamano, Alex Riesen, git
In-Reply-To: <86psn49alm.fsf@blue.stonehenge.com>
On Fri, 6 Jan 2006, Randal L. Schwartz wrote:
>
> Linus> I just hope you don't cross-breed. Shudder.
>
> Don't worry. So far, I haven't had any offers.
I was more worried about the "collective" of perl people, not any
particular individual developer.
If it was just you, I could just poison you over lunch some time..
Which reminds me - you owe me lunch. A non-poisoned one.
Linus
^ permalink raw reply
* Re: [PATCH] diff-tree: stop on broken output pipe
From: Johannes Schindelin @ 2006-01-07 0:41 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vhd8ht24d.fsf@assigned-by-dhcp.cox.net>
Hi,
On Fri, 6 Jan 2006, Junio C Hamano wrote:
> Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
>
> > Without this, on my iBook git-whatchanged keeps running when I
> > quit "less". I have to interrupt the process a second time. No
> > idea why it works on Linux.
> >
> > - if (!no_commit_id)
> > - printf("%s%c", header, diff_options.line_termination);
> > + if (!no_commit_id && printf("%s%c", header,
> > + diff_options.line_termination) < 0)
> > + die("broken output pipe");
> > header = NULL;
>
> There are tons of output other than this printf() and catching
> an output error only on this one and assuming that is a broken
> pipe somehow feels doubly wrong to me.
Welcome back! Hope you had a good time, and the fish tasted fine.
There really are tons of printf(), but
- I did not want to be invasive,
- if one printf() fails, the next will, too (probably), and
- the problem occurs only on macosx here.
Maybe it is not correct to assume that the output pipe is broken, but it
is an error to keep going when printf() fails. So I picked one printf()
which is called regularly.
Andreas said that a SIGPIPE should be thrown, and bash should kill the
script. I have not found out why my bash doesn't. Until I do, I will have
this patch in my local git (and a similar patch in git-rev-list). It just
is plain annoying when git-whatchanged (the git script I use most often)
hangs there, burning cycles.
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH] git-mv.perl: use stderr for error output and cleanup
From: Junio C Hamano @ 2006-01-07 0:46 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Randal L. Schwartz, Alex Riesen, git
In-Reply-To: <Pine.LNX.4.64.0601061525100.3169@g5.osdl.org>
Linus Torvalds <torvalds@osdl.org> writes:
>> After all, that's spelled "f o r", but pronounced "foreach". :)
>
> It is official: perl people are crazy.
I sometimes pronounce "foreach" when I see "ef oh ar" in Perl
programs, but I do not do that aloud around other people.
My point was that things like this:
>> print H "$_\0" for @deletedfiles;
is perfectly fine among Perl people (and I would probably even
encourage rewriting git-*.perl scripts in more Perlish style if
the project were about an SCM primarily targetted for Perl
people --- it is not), but look obfuscated without merit to
people who do not talk Perl.
^ 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