* Re: [PATCH] Add --no-reuse-delta option to git-gc
From: Johannes Schindelin @ 2007-06-11 21:40 UTC (permalink / raw)
To: Nicolas Pitre
Cc: Sam Vilain, Steven Grimm, Shawn O. Pearce, Junio C Hamano,
Daniel Barkalow, Theodore Ts'o, Git Mailing List
In-Reply-To: <alpine.LFD.0.99.0706110930170.12885@xanadu.home>
Hi,
On Mon, 11 Jun 2007, Nicolas Pitre wrote:
> But you'd better have a concrete data set and result numbers to convince
> me. Designing software for hypothetical situations before they actually
> exist leads to bloatware.
Right you are. So I'll not mention it until I have it ;-)
Ciao,
Dscho
^ permalink raw reply
* Problem with a push
From: Alex R.M. Turner @ 2007-06-11 21:32 UTC (permalink / raw)
To: git
I get the following error when pushing after a merge:
updating 'refs/heads/master'
from c18f9e4350c26e6b45d0a282ff32991784becbdd
to 39b7d927720c9f2810e0af5311975119c0d7c7bd
updating 'refs/remotes/origin/HEAD'
from 1e631edb3078ec3a4d1fa598c8f410f6a61659b0
to c18f9e4350c26e6b45d0a282ff32991784becbdd
updating 'refs/remotes/origin/master'
from 1e631edb3078ec3a4d1fa598c8f410f6a61659b0
to c18f9e4350c26e6b45d0a282ff32991784becbdd
Generating pack...
Done counting 26 objects.
Result has 10 objects.
Deltifying 10 objects...
100% (10/10) done
Writing 10 objects...
100% (10/10) done
Total 10 (delta 7), reused 0 (delta 0)
refs/heads/master: c18f9e4350c26e6b45d0a282ff32991784becbdd ->
39b7d927720c9f2810e0af5311975119c0d7c7bd
ng refs/remotes/origin/master failed to lock
refs/remotes/origin/HEAD: 1e631edb3078ec3a4d1fa598c8f410f6a61659b0 ->
c18f9e4350c26e6b45d0a282ff32991784becbdd
error: Ref refs/remotes/origin/master is at
c18f9e4350c26e6b45d0a282ff32991784becbdd but expected
1e631edb3078ec3a4d1fa598c8f410f6a61659b0
error: failed to lock refs/remotes/origin/master
error: failed to push to 'ssh://aturner@svn.mintpixels.com/data/git/mls'
but when I try it again, it just says Everything up-to-date.
Alex
^ permalink raw reply
* Re: [PATCH] git-p4: check for existence of repo dir before trying to create [Was: Asking again... [Re: how to properly import perforce history?]]
From: Simon Hausmann @ 2007-06-11 21:32 UTC (permalink / raw)
To: Kevin Green; +Cc: git
In-Reply-To: <20070611205140.GN25093@menevado.ms.com>
[-- Attachment #1: Type: text/plain, Size: 1862 bytes --]
On Monday 11 June 2007 22:51:40 Kevin Green wrote:
[...]
> Anyway, grabbed git-p4 and tried it three ways:
>
> 1) git-p4 clone //depot/path/repo@all
>
> I don't like this because it creates a git repository under "repo"
> subdir. To make a long store short, we have a very strict namespace for
> development... The path ends in src and I'd like the .git repository to
> be under src.
Fair enough :)
> So, I tried this one level up:
>
> 2) git-p4 clone //depot/path/repo@all src
>
> But that dies with a mkdir error because 'src' already exists. I want to
> submit a patch, but wanted to check with you first to see if that's the
> desired behaviour (I don't think it should fail though) because maybe you
> want to stop someone from scribbling on an already present git repository?
>
> I would want to just go for a "if it doesn't exist yet, create it,
> otherwise, forge ahead" behaviour. I attach the patch after my .sig...
Thanks for the patch. Applied and pushed out.
> 3) Tried without clone:
>
> $ git init
> $ git-p4 sync //depot/path/repo@all
>
> This looks like it's pulling down all the revisions, but it doesn't
> actually put any code in there. I'm left with the same situation as
> git-p4import.py.
>
> Actually, not even. I don't even have the commit history...
Actually... the import worked just fine, but I admit that it is not obvious
_where_ the import went. I've just pushed out a change that makes git-p4 sync
in this case also print out the ref. By default git-p4 sync imports into
refs/remotes/p4/master, so after the above command a simple
git branch -r
should print
p4/HEAD
p4/master
so you could for example just create a new master branch based on your p4
import using
git branch master p4
git checkout master
I hope this helps :)
Simon
[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: Asking again... [Re: how to properly import perforce history?]
From: Scott Lamb @ 2007-06-11 21:20 UTC (permalink / raw)
To: Alex Riesen; +Cc: Simon Hausmann, git
In-Reply-To: <20070611201232.GA4649@steel.home>
Alex Riesen wrote:
> Simon Hausmann, Mon, Jun 11, 2007 20:42:12 +0200:
>> On Monday 11 June 2007 17:44:04 Alex Riesen wrote:
>>> On 6/11/07, Simon Hausmann <simon@lst.de> wrote:
>>>> *plug* You could try with git-p4 from http://repo.or.cz/w/fast-export.git
>>>> . It should be just a matter of calling
>>>>
>>>> git-p4 clone //depot/path
>>> Can I suggest you add a target directory mapping to your tool?
>>> Something like:
>>>
>>> git-p4 clone //depot/project/path [libs/project/path] [rev-range]
>> I'm not sure I understand the libs/project/path part, ...
>
> Your client contains the mappings. It defines how the pathnames on the
> p4 server relate to that on your computer. In the example above file
> from the depot path //depot/project/path can be found in the directory
> of the p4 client in the subdirectories libs/project/path.
git-p4 doesn't even use a p4 client, so the result is simply as it was
on the server. It just does a "p4 print" on depot paths.
>> Han-Wen implemented also support for importing multiple depot paths at the
>> same time (and tracking them in one git branch).
>
> And where does he put the depot paths? As they are in depot? How does
> this corelate to the setups done by genuine P4 users (the poor souls)
> where the mappings are not always 1-to-1 right from the root? Or you
> haven't got any?
Could you give a concrete example of what you have and what you are
trying to produce?
>
>> The environment I'm working in is not too big and fairly liberal and
>> reasonably disciplined.
>
> You must be very strange environment indeed. Carefully balanced.
Not that strange. My company's setup is pretty simple, too. The project
I'm working on just uses has each branch under
"//depot/project/BRANCH/...". Maybe your environment is the odd one?
>>> And, BTW, don't you have a small problem with filenames with
>>> spaces and quoting?
>> I'm not aware of any problems. For example in our depot we have filenames with
>> spaces in them and they appear just fine in my git import. Did you run into
>> any specific case? It could very well be that there's a bug somewhere that
>> I'm just not hitting myself, so I'm curious :)
>
> No, I just looking at the source. Does python have some magic for
> running programs with system() when passed a format string? Like here:
>
> for f in filesToAdd:
> system("p4 add %s" % f)
> for f in filesToDelete:
> system("p4 revert %s" % f)
> system("p4 delete %s" % f)
>
> BTW, sometimes you quote the names, but obviously wrong (think about
> filenames containing double quotes):
>
> system("p4 edit \"%s\"" % path)
> editedFiles.add(path)
No, there's no magic. I can't imagine how these could work properly with
complex filenames. They also don't do any checking of return values. I'm
planning on sending in patches to make git-p4 use the Python subprocess
module to do this better (as I did for git-p4import.py). It might take
me a while to get to that item on my todo list, though - rather busy at
work right now.
--
Scott Lamb <http://www.slamb.org/>
^ permalink raw reply
* Passing **envp around in git.c
From: Stephen Cuppett @ 2007-06-11 21:15 UTC (permalink / raw)
To: git
Is there a reason for passing char** envp around in git.c or is it a
vestige of something older? It's sent into handle_internal_command
from main; however, it's never used. Looks like it might have been
used before, but then replaced with getenv. The code probably gets
optimized out at compile time, but to clean up:
diff --git a/git.c b/git.c
index 29b55a1..614baed 100644
--- a/git.c
+++ b/git.c
@@ -216,7 +216,7 @@ const char git_version_string[] = GIT_VERSION;
*/
#define NOT_BARE (1<<2)
-static void handle_internal_command(int argc, const char **argv, char **envp)
+static void handle_internal_command(int argc, const char **argv)
{
const char *cmd = argv[0];
static struct cmd_struct {
@@ -358,7 +358,7 @@ int main(int argc, const char **argv, char **envp)
if (!prefixcmp(cmd, "git-")) {
cmd += 4;
argv[0] = cmd;
- handle_internal_command(argc, argv, envp);
+ handle_internal_command(argc, argv);
die("cannot handle %s internally", cmd);
}
@@ -390,7 +390,7 @@ int main(int argc, const char **argv, char **envp)
while (1) {
/* See if it's an internal command */
- handle_internal_command(argc, argv, envp);
+ handle_internal_command(argc, argv);
/* .. then try the external ones */
execv_git_cmd(argv);
^ permalink raw reply related
* [PATCH] git-p4: check for existence of repo dir before trying to create [Was: Asking again... [Re: how to properly import perforce history?]]
From: Kevin Green @ 2007-06-11 20:51 UTC (permalink / raw)
To: Simon Hausmann; +Cc: git
In-Reply-To: <200706112159.34181.simon@lst.de>
On 06/11/07 15:59:30, Simon Hausmann wrote:
> On Monday 11 June 2007 21:44:50 you wrote:
> > On 06/11/07 10:56:33, Simon Hausmann wrote:
> > > *plug* You could try with git-p4 from http://repo.or.cz/w/fast-export.git
> > > . It should be just a matter of calling
> >
> > hmmm.... Failed with this:
> >
> > $ git clone http://repo.or.cz/w/fast-export.git
> > Initialized empty Git repository in /var/tmp/kgreen/dev/fast-export/.git/
> > /ms/dist/fsf/PROJ/git/1.5.2.1/bin/git-clone: line 381: cd:
> > /var/tmp/kgreen/dev/fast-export/.git/refs/remotes/origin: No such file or
> > directory
> > fatal: Not a valid object name HEAD
> >
> > I then tried the mirror I found at the git revision history site:
> >
> > $ git clone http://repo.or.cz/r/fast-export.git
> > Initialized empty Git repository in /var/tmp/kgreen/dev/fast-export/.git/
> > Getting alternates list for http://repo.or.cz/r/fast-export.git
> > Getting pack list for http://repo.or.cz/r/fast-export.git
> > Getting index for pack 66d95396fcacd053b385a4ed71edb2b1bc15e074
> > ...
> >
> >
> > Don't know if they're the same, but I'll give it a shot now...
>
> The latter seems indeed like the right URL for a HTTP based clone off of
> repo.or.cz. I would recommend using the git protocol though if possible :)
>
Not possible unfortunately...
Anyway, grabbed git-p4 and tried it three ways:
1) git-p4 clone //depot/path/repo@all
I don't like this because it creates a git repository under "repo" subdir.
To make a long store short, we have a very strict namespace for
development... The path ends in src and I'd like the .git repository to be
under src.
So, I tried this one level up:
2) git-p4 clone //depot/path/repo@all src
But that dies with a mkdir error because 'src' already exists. I want to
submit a patch, but wanted to check with you first to see if that's the
desired behaviour (I don't think it should fail though) because maybe you
want to stop someone from scribbling on an already present git repository?
I would want to just go for a "if it doesn't exist yet, create it,
otherwise, forge ahead" behaviour. I attach the patch after my .sig...
3) Tried without clone:
$ git init
$ git-p4 sync //depot/path/repo@all
This looks like it's pulling down all the revisions, but it doesn't
actually put any code in there. I'm left with the same situation as
git-p4import.py.
Actually, not even. I don't even have the commit history...
I would like to get 3 working properly because it's clunky to do #2. But with
the patch, #2 does what I want and gets me started...
Patch attached. Please let me know what I'm doing wrong with #3 above...
Thanks
--Kevin
>From c14f906b255a310db0c674ce567fd776aad8f397 Mon Sep 17 00:00:00 2001
From: Kevin Green <Kevin.Green@morganstanley.com>
Date: Mon, 11 Jun 2007 16:48:07 -0400
Subject: [PATCH] git-p4: check for existence of repo dir before trying to create
When using git-p4 in this manner:
git-p4 clone //depot/path/project myproject
If "myproject" already exists as a dir, but not a valid git repo, it fails
to create the directory.
Signed-off-by: Kevin Green <Kevin.Green@morganstanley.com>
---
git-p4 | 3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/git-p4 b/git-p4
index e380c14..cababc7 100755
--- a/git-p4
+++ b/git-p4
@@ -1400,7 +1400,8 @@ class P4Clone(P4Sync):
self.cloneDestination = self.defaultDestination(args)
print "Importing from %s into %s" % (', '.join(depotPaths), self.cloneDestination)
- os.makedirs(self.cloneDestination)
+ if not os.path.exists(self.cloneDestination):
+ os.makedirs(self.cloneDestination)
os.chdir(self.cloneDestination)
system("git init")
self.gitdir = os.getcwd() + "/.git"
--
1.5.2.1
^ permalink raw reply related
* Re: Asking again... [Re: how to properly import perforce history?]
From: Alex Riesen @ 2007-06-11 20:28 UTC (permalink / raw)
To: Simon Hausmann, git
In-Reply-To: <20070611164127.GS25093@menevado.ms.com>
Kevin Green, Mon, Jun 11, 2007 18:41:27 +0200:
> Is git-p4import.py still used and maintained?
Not really: there is only 5 changes which touch the file and only two
of them have something to do with the import.
> I submitted a patch to fix something trivial on Friday, but didn't
> here any response to that either, which led me to believe that it's
> not the tool being used most often for p4->git migration...
That's not the tool. It is the migration from p4 to anything which
does not happen too often: this company did very good job tying the
customers to this product. Once you reached some critical mass in
your perforce repo you cannot simply stop using it and go with
something else. Not without much pain, anyway.
Getting the development history out of it is the hardest. I'd say it
is impossible, as the states of development directories, unloaded in
"clients", are fluid and not recoverable after they are changed.
Imagine git with just index and no object database support.
^ permalink raw reply
* [RFC] Teach diff to imply --find-copies-harder upon -C -C
From: Johannes Schindelin @ 2007-06-11 20:12 UTC (permalink / raw)
To: git
earlier, a second "-C" on the command line had no effect. But since I use
"--find-copies-harder" quite a bit, and it is so long to type, and I am
an inherently lazy person, I'd like the second "-C" to be a shortcut for
"--find-copies-harder".
Signed-off-by: Johannes Schindelin <Johannes.Schindelin@gmx.de>
---
diff.c | 2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/diff.c b/diff.c
index 1d234d3..4aa9bbc 100644
--- a/diff.c
+++ b/diff.c
@@ -2201,6 +2201,8 @@ int diff_opt_parse(struct diff_options *options, const char **av, int ac)
options->detect_rename = DIFF_DETECT_RENAME;
}
else if (!prefixcmp(arg, "-C")) {
+ if (options->detect_rename == DIFF_DETECT_COPY)
+ options->find_copies_harder = 1;
if ((options->rename_score =
diff_scoreopt_parse(arg)) == -1)
return -1;
^ permalink raw reply related
* Re: Asking again... [Re: how to properly import perforce history?]
From: Alex Riesen @ 2007-06-11 20:12 UTC (permalink / raw)
To: Simon Hausmann; +Cc: git
In-Reply-To: <200706112042.16331.simon@lst.de>
Simon Hausmann, Mon, Jun 11, 2007 20:42:12 +0200:
> On Monday 11 June 2007 17:44:04 Alex Riesen wrote:
> > On 6/11/07, Simon Hausmann <simon@lst.de> wrote:
> > > *plug* You could try with git-p4 from http://repo.or.cz/w/fast-export.git
> > > . It should be just a matter of calling
> > >
> > > git-p4 clone //depot/path
> >
> > Can I suggest you add a target directory mapping to your tool?
> > Something like:
> >
> > git-p4 clone //depot/project/path [libs/project/path] [rev-range]
>
> I'm not sure I understand the libs/project/path part, ...
Your client contains the mappings. It defines how the pathnames on the
p4 server relate to that on your computer. In the example above file
from the depot path //depot/project/path can be found in the directory
of the p4 client in the subdirectories libs/project/path.
> Han-Wen implemented also support for importing multiple depot paths at the
> same time (and tracking them in one git branch).
And where does he put the depot paths? As they are in depot? How does
this corelate to the setups done by genuine P4 users (the poor souls)
where the mappings are not always 1-to-1 right from the root? Or you
haven't got any?
> The environment I'm working in is not too big and fairly liberal and
> reasonably disciplined.
You must be very strange environment indeed. Carefully balanced.
> > And, BTW, don't you have a small problem with filenames with
> > spaces and quoting?
>
> I'm not aware of any problems. For example in our depot we have filenames with
> spaces in them and they appear just fine in my git import. Did you run into
> any specific case? It could very well be that there's a bug somewhere that
> I'm just not hitting myself, so I'm curious :)
No, I just looking at the source. Does python have some magic for
running programs with system() when passed a format string? Like here:
for f in filesToAdd:
system("p4 add %s" % f)
for f in filesToDelete:
system("p4 revert %s" % f)
system("p4 delete %s" % f)
BTW, sometimes you quote the names, but obviously wrong (think about
filenames containing double quotes):
system("p4 edit \"%s\"" % path)
editedFiles.add(path)
^ permalink raw reply
* [PATCH 3/5] Rename sections from "module" to "submodule" in .gitmodules
From: Lars Hjemli @ 2007-06-11 19:12 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <1181589146478-git-send-email-hjemli@gmail.com>
On 6/10/07, Junio C Hamano <gitster@pobox.com> wrote:
> "Lars Hjemli" <hjemli@gmail.com> writes:
>
> > Hmm, maybe I should just rename [module] to [submodule] right now? It
> > would be better forward compatible with the proposed extension, it
> > would 'harmonize' the section names used in .gitmodules and
> > .git/config, and it would offer a clean break from what's currently
> > supported in 'master'.
>
> Yes, the difference between '[submodule]' vs '[module]' in
> .git/config and .gitmodules confused me while looking at your
> latest patch series. I am in favor of unifying them. We would
> not be breaking any released version if we harmonize them now.
Here it is.
Signed-off-by: Lars Hjemli <hjemli@gmail.com>
---
git-submodule.sh | 2 +-
t/t7400-submodule-basic.sh | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/git-submodule.sh b/git-submodule.sh
index 4a6d64d..6c83c52 100755
--- a/git-submodule.sh
+++ b/git-submodule.sh
@@ -66,7 +66,7 @@ modules_init()
url=$(git-config submodule."$path".url)
test -z "$url" || continue
- url=$(GIT_CONFIG=.gitmodules git-config module."$path".url)
+ url=$(GIT_CONFIG=.gitmodules git-config submodule."$path".url)
test -z "$url" &&
die "No url found for submodule '$path' in .gitmodules"
diff --git a/t/t7400-submodule-basic.sh b/t/t7400-submodule-basic.sh
index 74fafce..9f2d4f9 100755
--- a/t/t7400-submodule-basic.sh
+++ b/t/t7400-submodule-basic.sh
@@ -40,7 +40,7 @@ test_expect_success 'Prepare submodule testing' '
git-add a lib z &&
git-commit -m "super commit 1" &&
mv lib .subrepo &&
- GIT_CONFIG=.gitmodules git-config module.lib.url git://example.com/lib.git
+ GIT_CONFIG=.gitmodules git-config submodule.lib.url git://example.com/lib.git
'
test_expect_success 'status should only print one line' '
--
1.5.2.1.914.gbd3a7
^ permalink raw reply related
* [PATCH 3/5] Rename sections from "module" to "submodule" in .gitmodules
From: Lars Hjemli @ 2007-06-11 19:55 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
On 6/10/07, Junio C Hamano <gitster@pobox.com> wrote:
> "Lars Hjemli" <hjemli@gmail.com> writes:
>
> > Hmm, maybe I should just rename [module] to [submodule] right now? It
> > would be better forward compatible with the proposed extension, it
> > would 'harmonize' the section names used in .gitmodules and
> > .git/config, and it would offer a clean break from what's currently
> > supported in 'master'.
>
> Yes, the difference between '[submodule]' vs '[module]' in
> .git/config and .gitmodules confused me while looking at your
> latest patch series. I am in favor of unifying them. We would
> not be breaking any released version if we harmonize them now.
Here it is.
Signed-off-by: Lars Hjemli <hjemli@gmail.com>
---
This seem to be a bad mail day for me. I'm resending this patch since
someone apparently ate the previous one :-(
git-submodule.sh | 2 +-
t/t7400-submodule-basic.sh | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/git-submodule.sh b/git-submodule.sh
index 4a6d64d..6c83c52 100755
--- a/git-submodule.sh
+++ b/git-submodule.sh
@@ -66,7 +66,7 @@ modules_init()
url=$(git-config submodule."$path".url)
test -z "$url" || continue
- url=$(GIT_CONFIG=.gitmodules git-config module."$path".url)
+ url=$(GIT_CONFIG=.gitmodules git-config submodule."$path".url)
test -z "$url" &&
die "No url found for submodule '$path' in .gitmodules"
diff --git a/t/t7400-submodule-basic.sh b/t/t7400-submodule-basic.sh
index 74fafce..9f2d4f9 100755
--- a/t/t7400-submodule-basic.sh
+++ b/t/t7400-submodule-basic.sh
@@ -40,7 +40,7 @@ test_expect_success 'Prepare submodule testing' '
git-add a lib z &&
git-commit -m "super commit 1" &&
mv lib .subrepo &&
- GIT_CONFIG=.gitmodules git-config module.lib.url git://example.com/lib.git
+ GIT_CONFIG=.gitmodules git-config submodule.lib.url git://example.com/lib.git
'
test_expect_success 'status should only print one line' '
--
1.5.2.1.914.gbd3a7
^ permalink raw reply related
* Re: [PATCH 3/3] builtin-add: simplify (and increase accuracy of) exclude handling
From: Jeff King @ 2007-06-11 19:48 UTC (permalink / raw)
To: Jonas Fonseca; +Cc: Junio C Hamano, git
In-Reply-To: <20070611191554.GA32151@diku.dk>
On Mon, Jun 11, 2007 at 09:15:54PM +0200, Jonas Fonseca wrote:
> > I don't have time to work on it now, but I might look at it more tonight
> > or tomorrow (but please, if you are interested, take a crack at it).
>
> Yes, I think it might be nice for me to do if you don't mind. I would
> like some more experience with the git code. Maybe even redo the whole
> patch series to also fix the concerns about the alloc_grow macro.
Great, feel free to rework the series as you see fit. My "tonight"
timeframe was a bit optimistic anyway, as we have a new baby here. :)
-Peff
^ permalink raw reply
* Re: [PATCH 1/3] refactor dir_add_name
From: Jeff King @ 2007-06-11 19:46 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Jonas Fonseca, git
In-Reply-To: <7vk5uaqx3q.fsf@assigned-by-dhcp.pobox.com>
On Mon, Jun 11, 2007 at 09:23:05AM -0700, Junio C Hamano wrote:
> > +#define alloc_grow(x, nr, alloc) do { \
> > + if(nr >= alloc) { \
> > + alloc = alloc_nr(alloc); \
> > + x = xrealloc((x), alloc * sizeof(*(x))); \
> > + } \
> > +} while(0)
>
> worry a bit about macro safety. I think the presence of an
Agreed. The multiple evaluation of 'x' means that growing foo[i++] will
cause quite a confusing bug. I would prefer it as an inline, but at
least the sizeof requires macro magic. Not to mention the ugliness of
moving all those lvalues as pointers. But we could do something like
(totally untested):
#define alloc_grow(x, nr, alloc) \
alloc_grow_helper(&(x), nr, &(alloc), sizeof(*(x)))
inline
void alloc_grow_helper(void **x, int nr, int *alloc, int size)
{
if (nr >= *alloc) {
*alloc = alloc_nr(*alloc);
*x = xrealloc(*x, *alloc * size);
}
}
Horribly ugly (I'm seeing stars!) but probably a bit safer in the long
run, and nobody needs to look at it most of the time. :)
What do you think?
> assignment to alloc and x would make sure we would catch an
> error to pass non lvalue as 'alloc' and 'x', so it may be Ok as
Even lvalues can have side effects, so multiple evaluation is still a
problem.
> is. A comment before the macro, and a space between 'if' and
> opening parenthesis, would be good things to have.
Yes, sorry, my fingers are always forgetting the git whitespace
conventions. I (or Jonas) will submit a better commented version, but do
let us know which version you like.
-Peff
^ permalink raw reply
* Re: [PATCH 3/3] builtin-add: simplify (and increase accuracy of) exclude handling
From: Jonas Fonseca @ 2007-06-11 19:15 UTC (permalink / raw)
To: Jeff King; +Cc: Junio C Hamano, git
In-Reply-To: <20070611155425.GA9316@coredump.intra.peff.net>
Jeff King <peff@peff.net> wrote Mon, Jun 11, 2007:
> On Mon, Jun 11, 2007 at 05:01:23PM +0200, Jonas Fonseca wrote:
> > I think you could even get rid of has_ignored with something like this.
>
> Nope, I had originally wanted to do that, but the dir_struct.ignored
> list contains _all_ ignored items, not just those that were originally
> in the pathspec. The prune_ignored call sets uninteresting ones to
> NULL. That function could compact the list and re-set ignored_nr, but
> it doesn't currently do so.
Ah, I see.
> An even more elegant solution would be for read_directory to mark
> whether an ignored file comes from a pathspec, or was found through
> recursion. That would be more efficient, and it would remove the
> prune_ignored thing, which is IMHO a little hack-ish.
>
> I don't have time to work on it now, but I might look at it more tonight
> or tomorrow (but please, if you are interested, take a crack at it).
Yes, I think it might be nice for me to do if you don't mind. I would
like some more experience with the git code. Maybe even redo the whole
patch series to also fix the concerns about the alloc_grow macro.
--
Jonas Fonseca
^ permalink raw reply
* [PATCH 1/5] t7400: barf if git-submodule removes or replaces a file
From: Lars Hjemli @ 2007-06-11 19:12 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <11815891453464-git-send-email-hjemli@gmail.com>
The test for an unmolested file wouldn't fail properly if the file had been
removed or replaced by something other than a regular file. This fixes it.
Signed-off-by: Lars Hjemli <hjemli@gmail.com>
---
t/t7400-submodule-basic.sh | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/t/t7400-submodule-basic.sh b/t/t7400-submodule-basic.sh
index 3940433..74fafce 100755
--- a/t/t7400-submodule-basic.sh
+++ b/t/t7400-submodule-basic.sh
@@ -72,7 +72,7 @@ test_expect_success 'update should fail when path is used by a file' '
then
echo "[OOPS] update should have failed"
false
- elif test -f lib && test "$(cat lib)" != "hello"
+ elif test "$(cat lib)" != "hello"
then
echo "[OOPS] update failed but lib file was molested"
false
--
1.5.2.1.914.gbd3a7
^ permalink raw reply related
* [PATCH 5/5] Add gitmodules(5)
From: Lars Hjemli @ 2007-06-11 19:12 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <1181589146188-git-send-email-hjemli@gmail.com>
This adds documentation for the .gitmodules file.
Signed-off-by: Lars Hjemli <hjemli@gmail.com>
---
Documentation/Makefile | 2 +-
Documentation/gitmodules.txt | 62 ++++++++++++++++++++++++++++++++++++++++++
2 files changed, 63 insertions(+), 1 deletions(-)
create mode 100644 Documentation/gitmodules.txt
diff --git a/Documentation/Makefile b/Documentation/Makefile
index 9cef480..2ad18e0 100644
--- a/Documentation/Makefile
+++ b/Documentation/Makefile
@@ -2,7 +2,7 @@ MAN1_TXT= \
$(filter-out $(addsuffix .txt, $(ARTICLES) $(SP_ARTICLES)), \
$(wildcard git-*.txt)) \
gitk.txt
-MAN5_TXT=gitattributes.txt gitignore.txt
+MAN5_TXT=gitattributes.txt gitignore.txt gitmodules.txt
MAN7_TXT=git.txt
DOC_HTML=$(patsubst %.txt,%.html,$(MAN1_TXT) $(MAN5_TXT) $(MAN7_TXT))
diff --git a/Documentation/gitmodules.txt b/Documentation/gitmodules.txt
new file mode 100644
index 0000000..6c7d9bf
--- /dev/null
+++ b/Documentation/gitmodules.txt
@@ -0,0 +1,62 @@
+gitmodules(5)
+=============
+
+NAME
+----
+gitmodules - defining submodule properties
+
+SYNOPSIS
+--------
+.gitmodules
+
+
+DESCRIPTION
+-----------
+
+The `.gitmodules` file, located in the top-level directory of a git
+working tree, is a text file with a syntax matching the requirements
+of gitlink:git-config[1].
+
+The file contains one subsection per submodule, and the subsection value
+is the name of the submodule. Each submodule section also contains the
+following required keys:
+
+submodule.<name>.path::
+ Defines the path, relative to the top-level directory of the git
+ working tree, where the submodule is expected to be checked out.
+ The path name must not end with a `/`. All submodule paths must
+ be unique within the .gitmodules file.
+
+submodule.<name>.url::
+ Defines an url from where the submodule repository can be cloned.
+
+
+EXAMPLES
+--------
+
+Consider the following .gitmodules file:
+
+ [submodule 'libfoo']
+ path = include/foo
+ url = git://foo.com/git/lib.git
+
+ [submodule 'libbar']
+ path = include/bar
+ url = git://bar.com/git/lib.git
+
+
+This defines two submodules, `libfoo` and `libbar`. These are expected to
+be checked out in the paths 'include/foo' and 'include/bar', and for both
+submodules an url is specified which can be used for cloning the submodules.
+
+SEE ALSO
+--------
+gitlink:git-submodule[1] gitlink:git-config[1]
+
+DOCUMENTATION
+-------------
+Documentation by Lars Hjemli <hjemli@gmail.com>
+
+GIT
+---
+Part of the gitlink:git[7] suite
--
1.5.2.1.914.gbd3a7
^ permalink raw reply related
* [PATCH 4/5] git-submodule: give submodules proper names
From: Lars Hjemli @ 2007-06-11 19:12 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <1181589146685-git-send-email-hjemli@gmail.com>
This changes the way git-submodule uses .gitmodules: Subsections no longer
specify the submodule path, they now specify the submodule name. The
submodule path is found under the new key "submodule.<name>.path", which is
a required key.
With this change a submodule can be moved between different 'checkout paths'
without upsetting git-submodule.
Signed-off-by: Lars Hjemli <hjemli@gmail.com>
---
git-submodule.sh | 45 ++++++++++++++++++++++++++++++-------------
t/t7400-submodule-basic.sh | 20 +++++++++++++++---
2 files changed, 47 insertions(+), 18 deletions(-)
diff --git a/git-submodule.sh b/git-submodule.sh
index 6c83c52..89a3885 100755
--- a/git-submodule.sh
+++ b/git-submodule.sh
@@ -25,6 +25,19 @@ say()
fi
}
+#
+# Map submodule path to submodule name
+#
+# $1 = path
+#
+module_name()
+{
+ name=$(GIT_CONFIG=.gitmodules git-config --get-regexp '^submodule\..*\.path$' "$1" |
+ sed -nre 's/^submodule\.(.+)\.path .+$/\1/p')
+ test -z "$name" &&
+ die "No submodule mapping found in .gitmodules for path '$path'"
+ echo "$name"
+}
#
# Clone a submodule
@@ -49,7 +62,7 @@ module_clone()
die "A file already exist at path '$path'"
git-clone -n "$url" "$path" ||
- die "Clone of submodule '$path' failed"
+ die "Clone of '$url' into submodule path '$path' failed"
}
#
@@ -63,17 +76,18 @@ modules_init()
while read mode sha1 stage path
do
# Skip already registered paths
- url=$(git-config submodule."$path".url)
+ name=$(module_name "$path") || exit
+ url=$(git-config submodule."$name".url)
test -z "$url" || continue
- url=$(GIT_CONFIG=.gitmodules git-config submodule."$path".url)
+ url=$(GIT_CONFIG=.gitmodules git-config submodule."$name".url)
test -z "$url" &&
- die "No url found for submodule '$path' in .gitmodules"
+ die "No url found for submodule path '$path' in .gitmodules"
- git-config submodule."$path".url "$url" ||
- die "Failed to register url for submodule '$path'"
+ git-config submodule."$name".url "$url" ||
+ die "Failed to register url for submodule path '$path'"
- say "Submodule '$path' registered with url '$url'"
+ say "Submodule '$name' ($url) registered for path '$path'"
done
}
@@ -87,13 +101,14 @@ modules_update()
git ls-files --stage -- "$@" | grep -e '^160000 ' |
while read mode sha1 stage path
do
- url=$(git-config submodule."$path".url)
+ name=$(module_name "$path") || exit
+ url=$(git-config submodule."$name".url)
if test -z "$url"
then
# Only mention uninitialized submodules when its
# path have been specified
test "$#" != "0" &&
- say "Submodule '$path' not initialized"
+ say "Submodule path '$path' not initialized"
continue
fi
@@ -104,22 +119,22 @@ modules_update()
else
subsha1=$(unset GIT_DIR && cd "$path" &&
git-rev-parse --verify HEAD) ||
- die "Unable to find current revision of submodule '$path'"
+ die "Unable to find current revision in submodule path '$path'"
fi
if test "$subsha1" != "$sha1"
then
(unset GIT_DIR && cd "$path" && git-fetch &&
git-checkout -q "$sha1") ||
- die "Unable to checkout '$sha1' in submodule '$path'"
+ die "Unable to checkout '$sha1' in submodule path '$path'"
- say "Submodule '$path': checked out '$sha1'"
+ say "Submodule path '$path': checked out '$sha1'"
fi
done
}
#
-# List all registered submodules, prefixed with:
+# List all submodules, prefixed with:
# - submodule not initialized
# + different revision checked out
#
@@ -133,7 +148,9 @@ modules_list()
git ls-files --stage -- "$@" | grep -e '^160000 ' |
while read mode sha1 stage path
do
- if ! test -d "$path"/.git
+ name=$(module_name "$path") || exit
+ url=$(git-config submodule."$name".url)
+ if test -z "url" || ! test -d "$path"/.git
then
say "-$sha1 $path"
continue;
diff --git a/t/t7400-submodule-basic.sh b/t/t7400-submodule-basic.sh
index 9f2d4f9..7a9b505 100755
--- a/t/t7400-submodule-basic.sh
+++ b/t/t7400-submodule-basic.sh
@@ -18,7 +18,7 @@ subcommands of git-submodule.
# -add directory lib to 'superproject', this creates a DIRLINK entry
# -add a couple of regular files to enable testing of submodule filtering
# -mv lib subrepo
-# -add an entry to .gitmodules for path 'lib'
+# -add an entry to .gitmodules for submodule 'example'
#
test_expect_success 'Prepare submodule testing' '
mkdir lib &&
@@ -40,7 +40,19 @@ test_expect_success 'Prepare submodule testing' '
git-add a lib z &&
git-commit -m "super commit 1" &&
mv lib .subrepo &&
- GIT_CONFIG=.gitmodules git-config submodule.lib.url git://example.com/lib.git
+ GIT_CONFIG=.gitmodules git-config submodule.example.url git://example.com/lib.git
+'
+
+test_expect_success 'status should fail for unmapped paths' '
+ if git-submodule status
+ then
+ echo "[OOPS] submodule status succeeded"
+ false
+ elif ! GIT_CONFIG=.gitmodules git-config submodule.example.path lib
+ then
+ echo "[OOPS] git-config failed to update .gitmodules"
+ false
+ fi
'
test_expect_success 'status should only print one line' '
@@ -54,12 +66,12 @@ test_expect_success 'status should initially be "missing"' '
test_expect_success 'init should register submodule url in .git/config' '
git-submodule init &&
- url=$(git-config submodule.lib.url) &&
+ url=$(git-config submodule.example.url) &&
if test "$url" != "git://example.com/lib.git"
then
echo "[OOPS] init succeeded but submodule url is wrong"
false
- elif ! git-config submodule.lib.url ./.subrepo
+ elif ! git-config submodule.example.url ./.subrepo
then
echo "[OOPS] init succeeded but update of url failed"
false
--
1.5.2.1.914.gbd3a7
^ permalink raw reply related
* [PATCH 2/5] git-submodule: remember to checkout after clone
From: Lars Hjemli @ 2007-06-11 19:12 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <11815891451258-git-send-email-hjemli@gmail.com>
After the initial clone of a submodule, no files would be checked out in
the submodule directory if the submodule HEAD was equal to the SHA-1
specified in the index of the containing repository. This fixes the problem
by simply ignoring submodule HEAD for a fresh clone.
Signed-off-by: Lars Hjemli <hjemli@gmail.com>
---
git-submodule.sh | 9 +++++----
1 files changed, 5 insertions(+), 4 deletions(-)
diff --git a/git-submodule.sh b/git-submodule.sh
index 8bdd99a..4a6d64d 100755
--- a/git-submodule.sh
+++ b/git-submodule.sh
@@ -100,12 +100,13 @@ modules_update()
if ! test -d "$path"/.git
then
module_clone "$path" "$url" || exit
+ subsha1=
+ else
+ subsha1=$(unset GIT_DIR && cd "$path" &&
+ git-rev-parse --verify HEAD) ||
+ die "Unable to find current revision of submodule '$path'"
fi
- subsha1=$(unset GIT_DIR && cd "$path" &&
- git-rev-parse --verify HEAD) ||
- die "Unable to find current revision of submodule '$path'"
-
if test "$subsha1" != "$sha1"
then
(unset GIT_DIR && cd "$path" && git-fetch &&
--
1.5.2.1.914.gbd3a7
^ permalink raw reply related
* Re: Does anyone have any benchmarks against CVS?
From: Andy Parkins @ 2007-06-11 19:09 UTC (permalink / raw)
To: git; +Cc: Johannes Schindelin, David Kastrup
In-Reply-To: <Pine.LNX.4.64.0706111042110.4059@racer.site>
On Monday 2007, June 11, Johannes Schindelin wrote:
> I even presented Git to an svn user last week (not his fault, really,
> he was more than willing to try Git), and he was surprised that you
> could _continue_ working in the _same_ working directory as before,
> after git-init...
I always forget what a useful feature that is; I've become so used to
running git-init everywhere I turn that the memory of the
ridiculousness of SCMs that can't do that has already faded. :-)
Andy
--
Dr Andy Parkins, M Eng (hons), MIET
andyparkins@gmail.com
^ permalink raw reply
* [PATCH 0/5] misc. submodule related changes
From: Lars Hjemli @ 2007-06-11 19:12 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
Here is a reworked patch-series for git-submodule, trying to cater for
the issues with the previous series.
Shortlog:
[1/5] t7400: barf if git-submodule removes or replaces a file
[2/5] git-submodule: remember to checkout after clone
[3/5] Rename sections from "module" to "submodule" in .gitmodules
[4/5] git-submodule: give submodules proper names
[5/5] Add gitmodules(5)
Diffstat:
Documentation/Makefile | 2 +-
Documentation/gitmodules.txt | 63 ++++++++++++++++++++++++++++++++++++++++++
git-submodule.sh | 52 +++++++++++++++++++++++-----------
t/t7400-submodule-basic.sh | 22 +++++++++++---
4 files changed, 116 insertions(+), 23 deletions(-)
^ permalink raw reply
* Re: [PATCH 0/5] misc. submodule related changes
From: Lars Hjemli @ 2007-06-11 19:06 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git@vger.kernel.org
In-Reply-To: <7vtztepc33.fsf@assigned-by-dhcp.pobox.com>
On 6/11/07, Junio C Hamano <gitster@pobox.com> wrote:
> All of these patches have annoying whitespace breakage. It
> appears your MUA is adding an extra SP at the beginning of every
> single line that begins with a SP, or something.
Hmph. My ISP's smtp-server was down last night so I tried using
sendmail, but neither vger nor mx-all.pobox.com liked my (dyn)dns. So
I ended up using Opera against gmail. Next time I'll just wait for my
ISP to come back from lunch ;-)
>
> Care to redo the series?
Sure.
--
larsh
^ permalink raw reply
* Re: [RFC] git integrated bugtracking
From: Jon Loeliger @ 2007-06-11 18:51 UTC (permalink / raw)
To: Jan Hudec; +Cc: Junio C Hamano, Martin Langhoff, Git List
In-Reply-To: <20070610085044.GD4084@efreet.light.src>
On Sun, 2007-06-10 at 03:50, Jan Hudec wrote:
>
> It would be really useful to have a tool, that could link a bug report to
> a test case demonstrating it and reporting whenever output of that test case
> changes. This would make it much easier for developer to see which bugs he
> might have fixed when doing a refactoring.
I think the inverse is interesting too. That is, applying
keywords to tests and then making the test database
keywords searchable.
I used to work for a company that had a huge collection
of test cases for its product. It would take days to run
a validation run for some of the simplest of changes that
were introduced during development.
Often what I wanted, and what was needed, was a simple
sanity check that verified that the proposed change was
not brain-dead from the start.
Over time, I found that certain tests proved to be good
at detecting failures in particular portions of the code.
Often, that test was not necessarily directly related to
the concept it was _supposed_ to be designed to test, but
incidentally was good at some _other_ concept too.
The developer who made the change, and ran the tests,
then was able to state "Test t42 from suite Frotz is good
at detecting changes to the <SomeModule>."
The trick is to now associate with that test the keyword
"SomeModule" so that in the future, another developer
could ask: "Say, I just modified <SomeModule>, are there
any tests that are good at proving my changes sound?"
A test driver could then focus some test cycles quickly.
Now, for git, it's not likely a problem to just run
through all of its tests. At ${PriorCompany} it was
essential to pare down the test suites to a manageable
size, yet still have assurance that your coverage was
reasonably good.
jdl
^ permalink raw reply
* Re: [PATCH 0/5] misc. submodule related changes
From: Junio C Hamano @ 2007-06-11 18:42 UTC (permalink / raw)
To: Lars Hjemli; +Cc: git@vger.kernel.org
In-Reply-To: <op.ttqcxap09pspc6@localhost>
All of these patches have annoying whitespace breakage. It
appears your MUA is adding an extra SP at the beginning of every
single line that begins with a SP, or something.
Care to redo the series?
^ permalink raw reply
* Re: Asking again... [Re: how to properly import perforce history?]
From: Simon Hausmann @ 2007-06-11 18:42 UTC (permalink / raw)
To: Alex Riesen; +Cc: git
In-Reply-To: <81b0412b0706110844i12ebe52m21735815cc06effa@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 2069 bytes --]
On Monday 11 June 2007 17:44:04 Alex Riesen wrote:
> On 6/11/07, Simon Hausmann <simon@lst.de> wrote:
> > *plug* You could try with git-p4 from http://repo.or.cz/w/fast-export.git
> > . It should be just a matter of calling
> >
> > git-p4 clone //depot/path
>
> Can I suggest you add a target directory mapping to your tool?
> Something like:
>
> git-p4 clone //depot/project/path [libs/project/path] [rev-range]
I'm not sure I understand the libs/project/path part, but the revision range
can be specified in p4-like syntax as part of the depot path. For example
git-p4 clone //depot/path@12,435
to import from revision 12 up to 435. The revision range is more or less
passed directly to "p4 changes", with the exception of "@all".
Han-Wen implemented also support for importing multiple depot paths at the
same time (and tracking them in one git branch).
> The way Perforce handles branches and directories leads to
> the problem that it actually cannot cleanly support neither of
> them, and it is very hard to untangle a big repo which
> historically has had many projects living in it.
> Especially if some idiot actually tried to "do branching".
I agree, even with a lot of discipline it's very hard to do a 100% accurate
import with logical branches.
The environment I'm working in is not too big and fairly liberal and
reasonably disciplined. I'm using p4 branch mappings to "map" some branches
from perforce to git, which for sure isn't perfect but works overall fine. Of
course that doesn't cover p4 integration changes, but just for tracking
multiple "logical" p4 branches it works great (for me at least :).
> And, BTW, don't you have a small problem with filenames with
> spaces and quoting?
I'm not aware of any problems. For example in our depot we have filenames with
spaces in them and they appear just fine in my git import. Did you run into
any specific case? It could very well be that there's a bug somewhere that
I'm just not hitting myself, so I'm curious :)
Simon
[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* [PATCH] Unquote From line from patch before comparing with given from address.
From: Kristian Høgsberg @ 2007-06-11 17:04 UTC (permalink / raw)
To: git
This makes --suppress-from actually work when you're unfortunate enough
to have non-ASCII in your name. Also, if there's a match use the optionally
RFC2047 quoted version from the email.
Signed-off-by: Kristian Høgsberg <krh@redhat.com>
---
git-send-email.perl | 3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/git-send-email.perl b/git-send-email.perl
index eb876f8..7c0c90b 100755
--- a/git-send-email.perl
+++ b/git-send-email.perl
@@ -561,7 +561,8 @@ foreach my $t (@files) {
$subject = $1;
} elsif (/^(Cc|From):\s+(.*)$/) {
- if ($2 eq $from) {
+ if (unquote_rfc2047($2) eq $from) {
+ $from = $2;
next if ($suppress_from);
}
elsif ($1 eq 'From') {
--
1.5.2.GIT
^ permalink raw reply related
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