* Re: submodule init problem
From: Junio C Hamano @ 2007-07-25 22:20 UTC (permalink / raw)
To: skimo; +Cc: Johannes Schindelin, Lars Hjemli, git, Ricky Nite, Chris Larson
In-Reply-To: <20070725081508.GN1591MdfPADPa@greensroom.kotnet.org>
Sven Verdoolaege <skimo@kotnet.org> writes:
> On Tue, Jul 24, 2007 at 06:49:26PM -0700, Junio C Hamano wrote:
>> Ok, this appears it most likely to be related to the fact that
>> one is a prefix of the other in problematic case.
>
> Yes, this has been noted before and Chris Larson sent in a patch,
> but he didn't follow up on it.
Ok, I re-read the thread and came up with a different solution.
How does this look?
-- >8 --
git-submodule module_name: avoid using unwieldy "value_regexp" feature.
"module_name $path" function wants to look up a configuration
variable "submodule.<modulename>.path" whose value is $path, and
return the <modulename> found. "git-config --get-regexp" is the
natural thing to use for this, but (1) its value matching has an
unfortunate "feature" that takes leading '!' specially, and (2)
its output needs to be parsed with sed to extract <modulename>
part anyway.
This changes the call to "git-config --get-regexp" not to use
the value-regexp part, and moves the "pick the one whose value
is $path" part to the downstream sed.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
---
git-submodule.sh | 7 +++++--
1 files changed, 5 insertions(+), 2 deletions(-)
diff --git a/git-submodule.sh b/git-submodule.sh
index 1f0cb99..afbaec7 100755
--- a/git-submodule.sh
+++ b/git-submodule.sh
@@ -46,8 +46,11 @@ get_repo_base() {
#
module_name()
{
- name=$(GIT_CONFIG=.gitmodules git config --get-regexp '^submodule\..*\.path$' "$1" |
- sed -nre 's/^submodule\.(.+)\.path .+$/\1/p')
+ # Do we have "submodule.<something>.path = $1" defined in .gitmodules file?
+ re=$(printf '%s' "$1" | sed -e 's/\([^a-zA-Z0-9_]\)/\\\1/g')
+ name=$( GIT_CONFIG=.gitmodules \
+ git config --get-regexp '^submodule\..*\.path$' |
+ sed -n -e 's|^submodule\.\(.*\)\.path '"$re"'$|\1|p' )
test -z "$name" &&
die "No submodule mapping found in .gitmodules for path '$path'"
echo "$name"
^ permalink raw reply related
* Re: StGIT (or guilt) + git-svn?
From: Steven Walter @ 2007-07-25 22:25 UTC (permalink / raw)
To: Steven Grimm; +Cc: Steven Walter, 'git'
In-Reply-To: <46A6EF24.4040606@midwinter.com>
On Wed, Jul 25, 2007 at 02:35:16PM +0800, Steven Grimm wrote:
> Do you mix your public and private commits on the private branch, then
> cherry-pick some of them over to the public branch before running
> dcommit? Or do you have some other workflow?
Yes, what you describe is what I usually do.
> That was actually my first suggestion to him, but he pointed out (and I
> had to agree) that that would mean he's always just one mistake away
> from publishing his local changes. All it takes is getting interrupted
> for a moment and mistakenly thinking he already switched to the public
> branch. He wants some less human-error-prone way to tell the system that
> a particular change and/or a particular file is not intended for
> publication, and for the system to just honor that without further human
> intervention.
If I wanted to be argumentative, you're still only one step from
disaster with stgit. In order to build, you'd have to keep your local
changes applied. If you forgot to pop them before a dcommit, they would
be published.
> Actually, one could argue that the above isn't a git-svn issue at all.
> You could reasonably want the same thing from git-push too (and even
> from pull, though that'd be trickier.) I guess it'd take the form of
> marking a commit as local-only, and having the system automatically
> rebase all the local-only commits on top of the public ones.
>
> Maybe a wrapper than maintains a pair of underlying git branches for
> each user-visible branch would work. If you have a branch "foo" with
> some public and some private changes (private ones in lower case here):
>
> A---B---C---D---e---f---g foo
> ^ foo-public
>
> Now if you commit a new private revision, it's like normal:
>
> A---B---C---D---e---f---g---h foo
> ^ foo-public
>
> But if you commit a new public revision, we do something like
>
> git commit
> git checkout foo-public
> git cherry-pick foo
> git checkout foo
> git rebase foo-public
>
> to get
>
> A---B---C---D---H---e---f---g foo
> ^ foo-public
>
> Then, when it comes time to do the push / dcommit, we always switch to
> the foo-public branch first. We push / dcommit, then checkout foo and
> rebase it on foo-public again (since svn dcommit will leave foo-public
> pointing at a different revision.)
>
> This seems like it should work in the context of git-svn with its
> mostly-linear history. Not sure if it'd fall flat on its face in the
> presence of lots of branching and merging.
>
> I also suspect I've more or less just described StGIT and this would be
> a big waste of time to reinvent from scratch.
This actually sounds fairly useful, as it's mostly the automation of my
existing workflow. Let me know if you follow up on this.
--
-Steven Walter <stevenrwalter@gmail.com>
"A human being should be able to change a diaper, plan an invasion,
butcher a hog, conn a ship, design a building, write a sonnet, balance
accounts, build a wall, set a bone, comfort the dying, take orders,
give orders, cooperate, act alone, solve equations, analyze a new
problem, pitch manure, program a computer, cook a tasty meal, fight
efficiently, die gallantly. Specialization is for insects."
-Robert Heinlein
^ permalink raw reply
* Re: git stash apply segfaulting when called in subdir
From: Junio C Hamano @ 2007-07-25 22:28 UTC (permalink / raw)
To: Uwe Kleine-König; +Cc: Git Mailing List
In-Reply-To: <20070725212311.GA13325@cassiopeia>
Uwe Kleine-König <ukleinek@informatik.uni-freiburg.de> writes:
> zeisberg@cassiopeia:/tmp$ mkdir repo; cd repo; git init
> Initialized empty Git repository in .git/
>
> zeisberg@cassiopeia:/tmp/repo$ mkdir dir; echo one > file; echo two > dir/file
>
> zeisberg@cassiopeia:/tmp/repo$ git add file dir/file
>
> zeisberg@cassiopeia:/tmp/repo$ git commit -m tralala
> Created initial commit 265b7d7: tralala
> 2 files changed, 2 insertions(+), 0 deletions(-)
> create mode 100644 dir/file
> create mode 100644 file
>
> zeisberg@cassiopeia:/tmp/repo$ echo three >> file
>
> zeisberg@cassiopeia:/tmp/repo$ git stash
> Saved "WIP on master: 265b7d7... tralala"
> HEAD is now at 265b7d7... tralala
>
> zeisberg@cassiopeia:/tmp/repo$ cd dir; git stash apply
> error: missing object referenced by '696146c2a44d7fc4d5ae4a71589c4c0d84f59789'
> /home/zeisberg/usr/bin/git-stash: line 111: 13618 Segmentation fault git-merge-recursive $b_tree -- $c_tree $w_tree
This probably is a merge-recursive bug, but in the meantime,
I think this should fix it.
---
git-stash.sh | 1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/git-stash.sh b/git-stash.sh
index de13dd1..d9cd42d 100755
--- a/git-stash.sh
+++ b/git-stash.sh
@@ -6,6 +6,7 @@ USAGE='[ | list | show | apply | clear]'
SUBDIRECTORY_OK=Yes
. git-sh-setup
require_work_tree
+cd_to_toplevel
TMP="$GIT_DIR/.git-stash.$$"
trap 'rm -f "$TMP-*"' 0
^ permalink raw reply related
* Re: git stash apply segfaulting when called in subdir
From: Steven Walter @ 2007-07-25 22:32 UTC (permalink / raw)
To: Uwe Kleine-König, Git Mailing List
In-Reply-To: <20070725212311.GA13325@cassiopeia>
On Wed, Jul 25, 2007 at 11:23:11PM +0200, Uwe Kleine-König wrote:
> zeisberg@cassiopeia:/tmp/repo$ cd dir; git stash apply
> error: missing object referenced by '696146c2a44d7fc4d5ae4a71589c4c0d84f59789'
> /home/zeisberg/usr/bin/git-stash: line 111: 13618 Segmentation fault git-merge-recursive $b_tree -- $c_tree $w_tree
I've been seeing this, as well.
--
-Steven Walter <stevenrwalter@gmail.com>
"A human being should be able to change a diaper, plan an invasion,
butcher a hog, conn a ship, design a building, write a sonnet, balance
accounts, build a wall, set a bone, comfort the dying, take orders,
give orders, cooperate, act alone, solve equations, analyze a new
problem, pitch manure, program a computer, cook a tasty meal, fight
efficiently, die gallantly. Specialization is for insects."
-Robert Heinlein
^ permalink raw reply
* Re: [RFC PATCH] Re: Empty directories...
From: Nix @ 2007-07-25 22:43 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git
In-Reply-To: <f83bfv$95g$1@sea.gmane.org>
On 23 Jul 2007, Jakub Narebski spake thusly:
> Nix wrote:
>
>> And the problem is that while git has a lot of strategies for merging
>> *trees*, its file merge system is totally unpluggable: it just falls
>> back to xdiff's merging system. I guess I'll have to add that feature :)
>
> Not true. You can add custom diff driver for files using gitattributes
> system.
Oo. Excellent, I didn't notice that. Thank you.
^ permalink raw reply
* Re: [PATCH] gitweb: Fix error in generating snapshot
From: Junio C Hamano @ 2007-07-25 22:47 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git
In-Reply-To: <11854018464134-git-send-email-jnareb@gmail.com>
Heh, I was working on that and had the identical fix committed
;-).
Thanks.
^ permalink raw reply
* Re: rc3 gitweb is broken, won't deliver snapshots
From: Junio C Hamano @ 2007-07-25 22:48 UTC (permalink / raw)
To: Mark Levedahl; +Cc: Git Mailing List
In-Reply-To: <30e4a070707250627l29ce4794x97d03b8232352cae@mail.gmail.com>
"Mark Levedahl" <mlevedahl@gmail.com> writes:
> gitweb in 1.5.3-rc3 fails to deliver snapshots in any useable format
> (bzip2, gz, or zip). Clicking on a link seems to work, but the
> delivered file as stored on my system is empty. No error messages
> appear anywhere I can find. I am hosting gitweb on FC7 using lighttpd,
> if that matters.
>
> The snapshot service at git.kernel.org also seems broken, I don't know
> what gitweb is running there so don't know if the issue is related.
>
> I have fixed this for my use by reverting the following commits
>
> 3473e7df5f8c7f8dc3e2c3f2fdc99a1d1a719c16 gitweb: More detailed error
> messages for snapshot format
> a781785d8f1eb7adf05a24b121104716a086a67a gitweb: Fix support for
> legacy gitweb config for snapshots
> a3c8ab30a54c30a6a434760bedf04548425416ef gitweb: snapshot cleanups &
> support for offering multiple formats
>
> The snapshot problem first appears when a3c8ab30a54 is applied.
True. I wonder if people who submitted patches even tested
these things... Sigh.
---
gitweb/gitweb.perl | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/gitweb/gitweb.perl b/gitweb/gitweb.perl
index 0acd0ca..b381692 100755
--- a/gitweb/gitweb.perl
+++ b/gitweb/gitweb.perl
@@ -4343,7 +4343,7 @@ sub git_snapshot {
my $cmd;
$filename .= "-$hash$known_snapshot_formats{$format}{'suffix'}";
$cmd = "$git_command archive " .
- "--format=$known_snapshot_formats{$format}{'format'}" .
+ "--format=$known_snapshot_formats{$format}{'format'} " .
"--prefix=\'$name\'/ $hash";
if (exists $known_snapshot_formats{$format}{'compressor'}) {
$cmd .= ' | ' . join ' ', @{$known_snapshot_formats{$format}{'compressor'}};
^ permalink raw reply related
* Re: Windows support
From: Wincent Colaiuta @ 2007-07-25 22:52 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Stephen Cuppett, Steffen Prohaska, git
In-Reply-To: <alpine.LFD.0.999.0707251131540.3607@woody.linux-foundation.org>
El 25/7/2007, a las 20:43, Linus Torvalds escribió:
> I think cygwin may add some overhead, but people should really realize
> that Linux is quite often an order of magnitude faster (or more) than
> other systems on some very basic operations.
>
> That's especially true for filesystem operations. We really are
> just that
> good.
>
> Really simple things like stat/open/read/write/close are just damn
> fast on
> Linux. To the point where you really do notice it when you compare to
> other systems. If something takes hours on Linux, and it's very
> filesystem-intensive, I'm not at all surprised that it might take
> days on
> Windows.
>
> (OS X is probably better than Windows when it comes to filesystem
> ops, but
> their memory management absolutely sucks, and I can pretty much
> guarantee
> that their filesystem operation latency doesn't hold a candle to
> Linux,
> so while I'd expect git to perform "pretty well" on OS X, it's still
> going to be slower than on Linux)
Would be very interesting to see some "scientific" benchmarks of Git
performance on the different platforms.
Anyone got an Intel Mac with Windows and Linux installed on it as well?
Cheers,
Wincent
^ permalink raw reply
* Re: git stash apply segfaulting when called in subdir
From: Johannes Schindelin @ 2007-07-25 23:01 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Uwe Kleine-König, Git Mailing List
In-Reply-To: <7v1wewdsoz.fsf@assigned-by-dhcp.cox.net>
[-- Attachment #1: Type: TEXT/PLAIN, Size: 2348 bytes --]
Hi,
On Wed, 25 Jul 2007, Junio C Hamano wrote:
> Uwe Kleine-König <ukleinek@informatik.uni-freiburg.de> writes:
>
> > zeisberg@cassiopeia:/tmp$ mkdir repo; cd repo; git init
> > Initialized empty Git repository in .git/
> >
> > zeisberg@cassiopeia:/tmp/repo$ mkdir dir; echo one > file; echo two > dir/file
> >
> > zeisberg@cassiopeia:/tmp/repo$ git add file dir/file
> >
> > zeisberg@cassiopeia:/tmp/repo$ git commit -m tralala
> > Created initial commit 265b7d7: tralala
> > 2 files changed, 2 insertions(+), 0 deletions(-)
> > create mode 100644 dir/file
> > create mode 100644 file
> >
> > zeisberg@cassiopeia:/tmp/repo$ echo three >> file
> >
> > zeisberg@cassiopeia:/tmp/repo$ git stash
> > Saved "WIP on master: 265b7d7... tralala"
> > HEAD is now at 265b7d7... tralala
> >
> > zeisberg@cassiopeia:/tmp/repo$ cd dir; git stash apply
> > error: missing object referenced by '696146c2a44d7fc4d5ae4a71589c4c0d84f59789'
> > /home/zeisberg/usr/bin/git-stash: line 111: 13618 Segmentation fault git-merge-recursive $b_tree -- $c_tree $w_tree
>
> This probably is a merge-recursive bug, but in the meantime,
> I think this should fix it.
>
> ---
>
> git-stash.sh | 1 +
> 1 files changed, 1 insertions(+), 0 deletions(-)
>
> diff --git a/git-stash.sh b/git-stash.sh
> index de13dd1..d9cd42d 100755
> --- a/git-stash.sh
> +++ b/git-stash.sh
> @@ -6,6 +6,7 @@ USAGE='[ | list | show | apply | clear]'
> SUBDIRECTORY_OK=Yes
> . git-sh-setup
> require_work_tree
> +cd_to_toplevel
>
> TMP="$GIT_DIR/.git-stash.$$"
> trap 'rm -f "$TMP-*"' 0
It does... And here is a test case:
-- snipsnap --
[PATCH] Test "stash apply" in a subdirectory
Signed-off-by: Johannes Schindelin <Johannes.Schindelin@gmx.de>
---
t/t3903-stash.sh | 14 ++++++++++++++
1 files changed, 14 insertions(+), 0 deletions(-)
diff --git a/t/t3903-stash.sh b/t/t3903-stash.sh
index 392ac1c..9e363fd 100755
--- a/t/t3903-stash.sh
+++ b/t/t3903-stash.sh
@@ -66,4 +66,18 @@ test_expect_success 'apply stashed changes (including index)' '
test 1 = $(git show HEAD:file)
'
+test_expect_success 'apply in subdir' '
+ git --git-dir=new init &&
+ cd new &&
+ mkdir dir &&
+ echo one > file &&
+ echo two > dir/file &&
+ git add file dir/file &&
+ git commit -m first &&
+ echo three >> file &&
+ git stash &&
+ cd dir &&
+ git stash apply
+'
+
test_done
^ permalink raw reply related
* Re: [PATCH] git-p4: Fix p4 user cache population on Windows.
From: Junio C Hamano @ 2007-07-25 23:07 UTC (permalink / raw)
To: Simon Hausmann; +Cc: Git Mailing List
In-Reply-To: <200707250931.41414.simon@lst.de>
Thanks.
^ permalink raw reply
* Re: [PATCH] Document --unified/-U option
From: Junio C Hamano @ 2007-07-25 23:07 UTC (permalink / raw)
To: Robin Rosenberg; +Cc: git
In-Reply-To: <20070725100817.21185.91337.stgit@lathund.dewire.com>
Thanks
^ permalink raw reply
* Re: [PATCH] git-submodule: Error messages from 'git describe' shouldn't end up on the terminal
From: Junio C Hamano @ 2007-07-25 23:09 UTC (permalink / raw)
To: Emil Medve; +Cc: git
In-Reply-To: <11853733111502-git-send-email-Emilian.Medve@Freescale.com>
Emil Medve <Emilian.Medve@Freescale.com> writes:
> As of now a failure to locate the closest tag to a commit (e.g because there is
> no tag in the repository) is handled explicitly by displaying an 'undefined' tag
> error message. However when git describe fails it will still display an
> undesirable "fatal: cannot describe SHA1" message. This patch hides that
> message as git-submodule has an alternative and explicit error handling method
> in place for this situation
>
> Signed-off-by: Emil Medve <Emilian.Medve@Freescale.com>
> ---
> git-submodule.sh | 2 +-
> 1 files changed, 1 insertions(+), 1 deletions(-)
>
> diff --git a/git-submodule.sh b/git-submodule.sh
> index 1f0cb99..3804f18 100755
> --- a/git-submodule.sh
> +++ b/git-submodule.sh
> @@ -233,7 +233,7 @@ modules_list()
> say "-$sha1 $path"
> continue;
> fi
> - revname=$(unset GIT_DIR && cd "$path" && git describe --tags $sha1)
> + revname=$(unset GIT_DIR && cd "$path" && git describe --tags $sha1 2>/dev/null)
> set_name_rev "$path" "$sha1"
> if git diff-files --quiet -- "$path"
> then
It appears that set_name_rev does the moral equivalent of that
line you touched but more elaborately, to set the same
variable. Shouldn't we be simply removing that line instead?
^ permalink raw reply
* Re: index-pack died on pread
From: Robin Rosenberg @ 2007-07-25 23:15 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Michal Rokos, GIT
In-Reply-To: <alpine.LFD.0.999.0707230956390.3607@woody.linux-foundation.org>
måndag 23 juli 2007 skrev Linus Torvalds:
>
> On Mon, 23 Jul 2007, Michal Rokos wrote:
> >
> > fatal: cannot pread pack file: No such file or directory (n=0,
> > errno=2, fd=3, ptr=40452958, len=428, rdy=0, off=123601)
>
> Ok, that's bogus. When "n" is zero, the errno (and thus the error string)
> is not changed by pread, so that's a very misleading error report.
>
> So what seems to have happened is that the pack-file is too short, so we
> got a return value of 0, and then reported it as if it had an errno.
>
> The reason for returning zero from pread would be:
>
> - broken pread. I don't think HPUX should be a problem, so that's
> probably not it.
>
> - the pack-file got truncated
>
> - the offset is corrupt, and points to beyond the size of the packfile.
>
> In this case, since the offset is just 123601, I suspect it's a truncation
> issue, and your pack-file is simply corrupt. Either because of some
> problem with receiving it, or because of problems on the remote side.
>
> > fetch-pack from 'git://git.kernel.org/pub/scm/git/git' failed.
>
> One thing to look out for is that the "git.kernel.org" machines aren't the
> "primary" ones, and the data gets mirrored from other machines. If the
> mirroring is incomplete, I could imagine that the remote side simply ended
> up terminating the connection, and you ended up with a partial pack-file.
>
> Some of the kernel.org machines ran out of disk space the other day, so
> maybe you happened to hit it in an unlucky window. Does it still happen?
Does cygwin have the same pread problem then.. ? after make NO_PREAD=1 with 1.5.2.4
clone works.
Here is my output with pread. Note that I'm cloning from or.cz, not kernel.org .
$ git clone git://repo.or.cz/git.git GIT
Initialized empty Git repository in /roro/GIT/.git/
remote: Generating pack...
remote: Done counting 56038 objects.
remote: Deltifying 56038 objects...
remote: 100% (56038/56038) done
Indexing 56038 objects...
remote: Total 56038 (delta 39190), reused 52555 (delta 36164)
100% (56038/56038) done
Resolving 39190 deltas...
fatal: cannot pread pack file: No such file or directory
fatal: index-pack died with error code 128
fetch-pack from 'git://repo.or.cz/git.git' failed.
-- robin
^ permalink raw reply
* Re: [PATCH 1/2] resolve symlinks when creating lockfiles
From: Junio C Hamano @ 2007-07-25 23:35 UTC (permalink / raw)
To: Bradford C. Smith; +Cc: git
In-Reply-To: <11853821951367-git-send-email-bradford.carl.smith@gmail.com>
This probably is going in the right direction, but the code is
too densely formatted and unreviewable. Please imitate the
layout convention of the other parts of the code.
> +/**
> + * p = absolute or relative path name
> + *
> + * Return a pointer into p showing the beginning of the last path name
> + * element. If p is empty or the root directory ("/"), just return p.
> + */
/*
* multi-line comments look like this without the extra
* asterisk at the beginning of the first line.
*/
> +static char * last_path_elm(char * p)
char *last_path_elem(char *p)
> +{
> + int p_len = strlen(p);
> + char * r;
> +
> + if (p_len < 1) return p;
char *r;
int p_len = strlen(p);
if (p_len < 1)
return p;
Aren't p and r of type "const char *", I wonder...
> + /* r points to last non-null character in p */
> + r = p + p_len - 1;
> + /* first skip any trailing slashes */
> + while (*r == '/' && r > p) r--;
That is
r = strrchr(p, '/');
isn't it?
> +/**
> + * p = char array containing path to existing file or symlink
> + * s = size of p
> + *
> + * If p indicates a valid symlink to an existing file, overwrite p with
> + * the path to the real file. Otherwise, leave p unmodified.
I suspect some callers use lockfile interface to create a new
file. There will be a symlink to not-yet-created real file,
that is.
^ permalink raw reply
* [Bradford C. Smith] [PATCH 2/2] use lockfile.c routines in git_commit_set_multivar()
From: Junio C Hamano @ 2007-07-25 23:39 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git
From: "Bradford C. Smith" <bradford.carl.smith@gmail.com>
Subject: [PATCH 2/2] use lockfile.c routines in git_commit_set_multivar()
Date: Wed, 25 Jul 2007 12:49:53 -0400
Message-Id: <11853821962210-git-send-email-bradford.carl.smith@gmail.com>
Changed git_commit_set_multivar() to use the routines provided by
lockfile.c to reduce code duplication and ensure consistent behavior.
Signed-off-by: "Bradford C. Smith" <bradford.carl.smith@gmail.com>
Dscho, I think this is worth doing regardless of that "symlinked
config" issue. I haven't followed the code closely enough,
though.
What do you think?
^ permalink raw reply
* Re: submodule init problem
From: Ricky Nite @ 2007-07-25 23:43 UTC (permalink / raw)
To: Junio C Hamano; +Cc: skimo, Johannes Schindelin, Lars Hjemli, git, Chris Larson
In-Reply-To: <7v8x94dt2b.fsf@assigned-by-dhcp.cox.net>
works for me :)
backgrounder:
I'm currently importing a large cvs repo (multiple projects, shared
modules, shared environment) into cvs-tracking git "superprojects".
Incremental import of the cvs modules using periodic invocations of
"git cvsimport" seems to be working, although there were some messages
(I suspect cvsps - will post later). I was adding modules into the
superprojects when I hit this submodule init issue.
It will also be nice to have some kind of "superproject browser" in gitk..
On 7/26/07, Junio C Hamano <gitster@pobox.com> wrote:
> Sven Verdoolaege <skimo@kotnet.org> writes:
>
> > On Tue, Jul 24, 2007 at 06:49:26PM -0700, Junio C Hamano wrote:
> >> Ok, this appears it most likely to be related to the fact that
> >> one is a prefix of the other in problematic case.
> >
> > Yes, this has been noted before and Chris Larson sent in a patch,
> > but he didn't follow up on it.
>
> Ok, I re-read the thread and came up with a different solution.
> How does this look?
>
^ permalink raw reply
* Re: index-pack died on pread
From: Linus Torvalds @ 2007-07-25 23:44 UTC (permalink / raw)
To: Robin Rosenberg; +Cc: Michal Rokos, GIT
In-Reply-To: <200707260115.13234.robin.rosenberg.lists@dewire.com>
On Thu, 26 Jul 2007, Robin Rosenberg wrote:
>
> Does cygwin have the same pread problem then.. ? after make NO_PREAD=1 with 1.5.2.4
> clone works.
Interesting.
It's true that pread() is used much less than normal reads, and maybe the
cygwin pread() is indeed broken. But it's intriguing how apparently both
HP-UX and Cygwin are showing the same breakage.
But if git was doing something odd with pread(), then NO_PREAD shouldn't
work either, because that just enables the exact same code, except we now
supply a pread emulation library function (which does it using "lseek()":
not a *good* emulation, but good enough for the very limited use that git
puts it to).
So yeah, it looks like pread() is broken under cygwin and hpux-11.11.
Googling for "pread" "cygwin" does seem to show that it's been buggy at
times. Eg:
Fixes since 1.5.21-1:
...
- Fix pread in case current file offset is non-zero. (Hideki Iwamoto)
but I'm a bit surprised that hp-ux has the bug. pread isn't *that*
complex.
Linus
^ permalink raw reply
* [ANNOUNCE] Stacked GIT 0.13
From: Catalin Marinas @ 2007-07-25 23:46 UTC (permalink / raw)
To: GIT list, Linux Kernel Mailing List
Stacked GIT 0.13 release is available from http://www.procode.org/stgit/.
StGIT is a Python application providing similar functionality to Quilt
(i.e. pushing/popping patches to/from a stack) on top of GIT. These
operations are performed using GIT commands and the patches are stored
as GIT commit objects, allowing easy merging of the StGIT patches into
other repositories using standard GIT functionality.
The main features in this release:
* Documentation directory with man pages
* Safety checks for the 'rebase' command
* Various contrib scripts
* 'cp' command to copy files
* 'sink' command to complement 'float'
* '--diff-opts' option to some commands for passing additional
arguments to 'git-diff-*'
* 'stgit.mail.prefix' configuration option for the default 'mail
--prefix' value
* Interractive 2-way merging via xxdiff or emacs (previously, only
3-way merging had this feature)
* Slightly changed behaviour to the 'patches' command when no
argument is given to show the patches touching the locally modified
files
* Correct importing of multipart e-mails
* '--unrelated' option to 'mail' to send patches unthreaded and
without sequence numbering
* '--update' option to 'refresh' to only check in the files
already modified by the current patch (similar to 'pick --update')
* '--keep' option to 'goto' (though it only works for patch popping)
* '--expose' option to 'pick' to append the picked commit id to
the log (similar to the 'git cherry-pick -x' command)
* The 'new' command can automatically generate the patch name from
the given log
* 'uncommit' can generate patches up to a given commit id
* Bug fixes
Acknowledgements (special thanks to Yann Dirson who was the main
contributor to this release; many thanks to all the contributors
below):
Yann Dirson (88):
Refuse to pull/rebase when rendered unsafe by (un)commits.
Rework of the 'stg pull' policy.
Correctly raise exception on unknown pull-policy.
Add a testcase for the safety of pull-policy='pull'.
Factorize editor handling.
Add a Documentation directory inspired by the git one.
Merge doc/ and Documentation/ directories.
Add missing files to stgit manifest.
Add contrib/stg-whatchanged: look at what would be changed by refreshing.
Add contrib/stg-show-old: show old version of a patch.
Add contrib/stg-fold-files-from: pick selected changes from a
patch above current one
Add contrib/stg-swallow: completely merge an unapplied patch
into current one
Add contrib/stg-cvs: helper script to manage a mixed cvs/stgit
working copy
Add contrib/stg-gitk: helper script to run gitk
Add contrib/stg-mdiff: display diffs of diffs.
Add contrib/stg-sink: sink a patch to given location (mirrors float).
Fix bash completion to not garble the screen with an error message.
Add 'stg cp' command.
Do not link to docs that will never be written.
Some clarifications to the main doc.
Make 'stg cp' 2nd form safe.
Fixed t2102-pull-policy-rebase to really test 'rebase' policy.
Fix stack deletion when orig-base is present.
Fix diagnostic messages on patch deletion and simplify others.
Make use exception raised by removedirs.
Drop utils.remove_dirs() in favor of os.removedirs().
Copy parentbranch setting on 'stg branch --clone'.
Remove debugging output from contrib/stg-sink
Add a script to quickly run an interactive test session.
Add support for unsetting config vars.
Cleanup parent information on stgit branch deletion.
Fix typo in help string.
Don't use section 7 for main manpage.
Add doc for 'clone' and 'init'.
Add doc for 'branch'.
Fix doc cross-refs.
Make the documentation of options more consistent.
Stop advertising 'pull' as the only operation blocked on protected stacks.
Add "stg bury" command, with the functionality of contrib/stg-sink.
Document the new 'stg branch --description' features.
Avoid contrib/stg-swallow deleting unrelated empty patches.
Cleanup variable names in pick.
Copy patchlogs when cloning a stack or picking a patch.
Teach bash to complete branch names in some places.
Document patch syntax.
Stop recording branch.*.remote to '.' for local parents.
Rename "bury" back to "sink".
Add 2 new contrib scripts.
Call external commands without a shell where possible.
Make diff flags handling more modular.
Add new --diff-opts/-O flag to diff- and status-related commands.
Fix deletion and move of a hidden patch (gna bug #9244).
Fix removal of series with non-existant trash dir.
Fix removal of series to nuke the formatversion config item.
Robustify rebase test: check patches are reapplied.
Catch early trying rebasing to unknown ref, and add testcase.
Fixed typo in contrib/stg-whatchanged.
Changed rebasing safety check to look for reachability of stack
base (gna bug #9181).
Test "stg rebase" after "stg commit"
Have series show empty hidden patches as hidden rather than empty.
Have mail take the default for --prefix from stgit.mail.prefix.
Use get/set_name for a stack's name.
Abstract a PatchSet object out of Series.
Move stack format-version checks into Stack class.
Rename branch.*.stgitformatversion to branch.*.stgit.stackformatversion.
Revert 'Test "stg rebase" after "stg commit"'
Revert 'Changed rebasing safety check to look for reachability of
Update test-lib.sh from current git.
Fix contrib/stg-whatchanged way of identifying a conflict.
stg-cvs: update doc, and use correct setting for parent branch.
Revert part of the reverted commit that we want to keep.
Fixed thinko in error message.
Changed sync not to use -b which has other semantics.
Fix t1200 to catch intermediate errors.
If available, use gitk --argscmd in contrib/stg-gitk.
Allow "git show --branch".
Disallow non-patch args to "stg show" (gna #8453).
Make hidden patches visible to various commands (notably log, show, pick).
Forbid the "series --all --short" combination.
Recognize refs under remotes/ as parent branch on stack creation.
Document shortcoming of stg-k and stg-unnew.
Add a constructor to PatchSet.
Revert 'Disallow non-patch args to "stg show" (gna #8453).'
Display a message when the server refused some recipients.
Fix stg-whatchanged to deal with conflicts already solved.
Add range comparison support to stg-mdiff.
Add to stg-mdiff the ability to pass options to underlying diff opts.
Port stg-whatchanged improvements to stg-mdiff and have the
former use the latter.
Catalin Marinas (34):
Add --branch option to 'patches'
Add an interractive 2-way merge option
Add EditorException to stgit/utils.py
Use and..or as a ternary operator rather than a dictionary
[Revert] Make 'push --undo' safer
Only check for upstream merges if not fast-forwarding
Add --description option to branch
Move man page stg(1) to stg(7)
Fix the 'bury' command completion to include all patches
Revert commit "Move man page stg(1) to stg(7)"
Failed recursive merging can silently lose date in StGIT
Fix typo in the patchlogs copying code
Use list comprehension in uncommit.py for Python 2.3
Add a "make tags" target
Fix the automatic patch name generation for the pick command
Fix bug #9284 - error messages include abbreviated command
Fix the hidden patches functionality (bug #9077)
Factor out common functionality into the utils.py file
Add my release scripts to the contrib directory
Show a joined string rather than list when reporting GIT failures
Pass a string rather than an exception object in gitmergeonefile
Modify the 'patches' command to use the locally modified files
Fix the importing of multipart emails
'sync' code comments clean-up after commit 6b79a09c
Add the --unrelated option to mail
Add '--update' option to 'refresh'
Add --keep option to goto
Allow 'refresh' to annotate the patch log entries
Do not call 'refresh' when creating a patch (bug #8872)
Add the '--expose' option to 'pick'
Allow refresh --annotate to replace the top log entry
Modify the assertion in Series.new_patch
Add .mailmap file
Release 0.13
Karl Hasselström (23):
String comparison is done with "=", not "=="
dash doesn't do curly brace expansion, so avoid that
Don't use refs/bases/<branchname>
Don't use patches/<branch>/current
Fix popping on non-active branches
Make the "name" argument to "stg new" optional
Make patch deletion test more specific
Test patch order, not just number of patches
Use "stg applied" instead of reading the applied file directly
Store branch description in the config file
Make the "name" argument to "stg new" optional
Generate patch names of more uniform length
Remove an unnecessary parameter to make_patch_name
If any uncommit would fail, don't uncommit anything
Uncommit to a named commit
Store branch description in the config file
Remove obsolete files when deleting a branch
Fix config caching so that get, set, get works
Have only a single command in each test_expect_failure
Upgrade old StGIT branches to new-format metadata
Test the format version upgrade code
Add --binary flag to commands that generate diffs
Refactor message printing
Robin Rosenberg (3):
Add an empty line before signed-off-by
Update the bash prompt from 'applied' instead of the obsolete 'current'
Don't use / as separatar since it is common i branch names
Petr Baudis (1):
StGIT: Support Cc: fields in stg mail --auto
Roland Dreier (1):
Fix deleting series trash directory
Sam Vilain (1):
Some minor debian packaging fixes
--
Catalin
^ permalink raw reply
* Re: submodule init problem
From: Junio C Hamano @ 2007-07-25 23:49 UTC (permalink / raw)
To: Ricky Nite
Cc: Junio C Hamano, skimo, Johannes Schindelin, Lars Hjemli, git,
Chris Larson
In-Reply-To: <d4b731510707251643m4c1b416qabf8a01205581c9d@mail.gmail.com>
"Ricky Nite" <ricky.nite@gmail.com> writes:
> works for me :)
Thanks, will commit.
^ permalink raw reply
* Re: Bug in gitk search box
From: Paul Mackerras @ 2007-07-26 0:27 UTC (permalink / raw)
To: Brian Downing; +Cc: git, Junio C Hamano
In-Reply-To: <20070725135621.GC21692@lavos.net>
Brian Downing writes:
> * Open gitk in any repository, the Git one seems to work fine.
> * Type a string that it won't find into the search box, like 'asdfasdf'.
> * Click find.
>
> You'll get:
>
> can't read "commitdata(e83c5163316f89bfbde7d9ab23ca2e25604af290)": no such element in array
It turns out that this problem crept in when I changed from using git
rev-list --header to git log -z --pretty=raw, and the thing that
causes it is that git rev-list puts a null character after every
commit, while git log only puts a null between commits, i.e., there
isn't a null after the last commit.
Junio, is this behaviour deliberate?
Paul.
^ permalink raw reply
* [PATCH] Fix git_mkstemp to return an error when path is too long.
From: Carlos Rica @ 2007-07-26 1:32 UTC (permalink / raw)
To: git, Junio C Hamano, Johannes Schindelin
Now the function returns -2 to the caller if the given buffer
is too short to save the entire path for the temporary file.
Signed-off-by: Carlos Rica <jasampler@gmail.com>
---
diff.c | 2 ++
path.c | 9 ++++++---
2 files changed, 8 insertions(+), 3 deletions(-)
diff --git a/diff.c b/diff.c
index cd6b0c4..8735467 100644
--- a/diff.c
+++ b/diff.c
@@ -1694,6 +1694,8 @@ static void prep_temp_blob(struct diff_tempfile *temp,
int fd;
fd = git_mkstemp(temp->tmp_path, PATH_MAX, ".diff_XXXXXX");
+ if (fd == -2)
+ die("path too long for temp-file");
if (fd < 0)
die("unable to create temp-file");
if (write_in_full(fd, blob, size) != size)
diff --git a/path.c b/path.c
index c4ce962..f33d15d 100644
--- a/path.c
+++ b/path.c
@@ -68,7 +68,8 @@ char *git_path(const char *fmt, ...)
}
-/* git_mkstemp() - create tmp file honoring TMPDIR variable */
+/* git_mkstemp() - create tmp file honoring TMPDIR variable.
+ * return -2 if path is too long to have it concatenated. */
int git_mkstemp(char *path, size_t len, const char *template)
{
char *env, *pch = path;
@@ -79,12 +80,14 @@ int git_mkstemp(char *path, size_t len, const char *template)
pch += 5;
} else {
size_t n = snprintf(pch, len, "%s/", env);
-
+ if (n >= len)
+ return -2;
len -= n;
pch += n;
}
- strlcpy(pch, template, len);
+ if (strlcpy(pch, template, len) >= len)
+ return -2;
return mkstemp(path);
}
--
1.5.0
^ permalink raw reply related
* problem after cvsimport
From: Bert Douglas @ 2007-07-26 1:49 UTC (permalink / raw)
To: git
I am new to git, so probably doing something wrong.
Hope somebody can enlighten me.
Here is what happened so far.
Followed instructions here:
http://www.kernel.org/pub/software/scm/git/docs/cvs-migration.html
Did command like this:
$ git cvsimport -C <destination> <module>
This was done from top level of existing cvs working directory.
Destination was new empty directory, outside the cvs tree.
It worked for several hours and seemed to complete ok.
I can look at history in destination git directory with gitk and git log.
All the stuff in ".git" looks normal, as far as I can tell.
But I have no files in the working directory.
When I do command:
$git checkout master
I get a bunch of lines to console with "D" in front.
Btw, what does that mean? Nothing about it in "man git-checkout" or elsewhere that I can find.
Then it says -- Already on branch "master"
But working directory is still empty.
Thanks much,
Bert Douglas
^ permalink raw reply
* Re: Windows support
From: Dmitry Kakurin @ 2007-07-26 2:26 UTC (permalink / raw)
To: Nguyen Thai Ngoc Duy; +Cc: git
In-Reply-To: <fcaeb9bf0707250513v587d7a92lb688b52da3c28bb7@mail.gmail.com>
On 7/25/07, Nguyen Thai Ngoc Duy <pclouds@gmail.com> wrote:
> What features is mingw port missing?
Well, 'git commit' from a regular cmd prompt does not work.
IMHO, That's a pretty serious omission :-).
^ permalink raw reply
* Re: Bug in gitk search box
From: Junio C Hamano @ 2007-07-26 2:54 UTC (permalink / raw)
To: Paul Mackerras; +Cc: Brian Downing, git
In-Reply-To: <18087.60033.676105.538784@cargo.ozlabs.ibm.com>
Paul Mackerras <paulus@samba.org> writes:
> It turns out that this problem crept in when I changed from using git
> rev-list --header to git log -z --pretty=raw, and the thing that
> causes it is that git rev-list puts a null character after every
> commit, while git log only puts a null between commits, i.e., there
> isn't a null after the last commit.
>
> Junio, is this behaviour deliberate?
There was a recent message from Linus on the list, stating that
NUL in -z format is inter-record separator, not after-record
terminator.
^ permalink raw reply
* Re: Windows support
From: Dmitry Kakurin @ 2007-07-26 2:56 UTC (permalink / raw)
To: Steven Grimm; +Cc: git
In-Reply-To: <46A73015.7020306@midwinter.com>
On 7/25/07, Steven Grimm <koreth@midwinter.com> wrote:
> > How serious are you guys about Windows support?
> Much (nearly all?) of the core git team never touches Windows, so they
> both have no selfish motivation to get it working well and no way to
> test their changes even if they decide to take it up for the greater good.
This actually answers my question (if it's true).
If core team is not interested in supporting Windows then I cannot
trust this system with my source code :-(.
My concerns are (mostly):
* lack of (or insufficient) testing for Windows platform
* possibly lower code quality of Windows port, since core devs don't
touch it and don't care
* possible troubles with support if issues arise
* Windows port could become abandoned if those few brave people, who
work on it right now will leave
In short, all kinds of issues associated with software not being a
first class citizen :-).
- Dmitry
^ 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