* Re: files are disappearing in git
From: Linus Torvalds @ 2005-11-25 19:12 UTC (permalink / raw)
To: Nico -telmich- Schottelius; +Cc: Ryan Anderson, Git ML, Petr Baudis
In-Reply-To: <20051125103048.GB30691@schottelius.org>
Ok,
Nico gave me private access to the tree, so I quickly cloned it and
started bisecting it to figure out where the problem was. I haven't looked
at the source code, and all the commit messages seem to be in German
(which I can kind of understand if I work at it, but not very well), but
it definitely turns out none of that matters.
The problem is a bad merge. And in fact, that merge lost _more_ than just
the three files under Code/Spikes/Statistik/, it also lost a file called
Code/lw1/Client/Pics/icon/lw1-icon.png.
I don't quite see _how_ it lost them. The merge in question is a totally
trivial in-index merge, and when I re-do it, I don't lose those files. In
this case, all the lost files were from the "other branch" of the merge,
and they were new to that branch. IOW, in git-merge-one-file parlance, it
is that trivial "added in one" case.
Pasky - do you know of any historical cogito problems like this?
Nico: the files were added in commit
- 9e9b91166bfca448a8f1ddeb4580d73ac8ea0986:
Neuer Spike: Statistik ...
and they stayed around in that branch until commit (which is still good):
- dcd70e89dc7b2280260628fd699aa906c319c68f:
Bug 359 - Defektmeldungen ...
but they disappeared when the that branch was merged with commit
- 056c65efea28066b7b241240f0d8421d3204b624
Bug 195 - Tagesarbeitsplan: ...
and the result is the bad merge commit:
- 228b94dd0a7aa1516eb867674cdf8c7c7b2bfd4c:
Merge with /home/server/git/walderlift.git
After that merge, those new files are gone - they were never added by the
merge.
Quite frankly, this is clearly a bug, and it looks very much like a really
serious bug in cg-merge. It's not in the core git: even old versions of
git should never have been able to generate that broken merge.
But when I try to do that same merge with current cogito, I can't make it
break _either_. In all cases, regardless of how I do the merge, when I do
(bad-merge is the merge in your tree, "cg-test" in this case is the merge
I did using cogito):
git-diff-tree -r bad-merge cg-test
I get
:000000 100644 0000000000000000000000000000000000000000 5c8c47d855ee0f78a7fb81c4a49224b1607a88b7 A Code/Spikes/Statistik/Project.dpr
:000000 100644 0000000000000000000000000000000000000000 7bd2de9b7142999bc6bbadde06e73267d1b5ee0e A Code/Spikes/Statistik/Statistik.pas
:000000 100644 0000000000000000000000000000000000000000 a0fb45e2b906bdac7929cfd8174053015ab629b4 A Code/Spikes/Statistik/Statistik.xfm
:000000 100644 0000000000000000000000000000000000000000 24f8254c06ea5efc89944a3a9f52d2c79c841c0b A Code/lw1/Client/Pics/icon/lw1-icon.png
ie the "bad merge" thing (commit 228b94dd0a7aa1516eb867674cdf8c7c7b2bfd4c
in your tree) will not have those four files, and the good merge (whether
I use the git "recursive" or git "resolve" merge, or use "cg-merge" to do
it) will always have those four files.
So I do not see how that bad commit happened, especially since it's even
a fairly recent commit (the date of the merge is 2005-11-17).
I wonder if there's a really old and broken version of cogito somewhere
around. If so, it's on "srsyg03".
I also went through every single merge in your tree, and apart from two
merges that had merge conflicts and were fixed up by hand (and that I thus
didn't check), all other merges looked ok. So as far as I can tell it's
only that 228b94dd0a7aa1516eb867674cdf8c7c7b2bfd4c merge that is bad.
(And the two commits that needed manual merging _look_ fine. No lost files
at least, except for one of the merges losing "bitte_bitte_loesch_mich",
which judging by it's name _should_ be lost ;)
Finally: Nico, I've deleted the trees on my machine, and you can remove my
ssh key. I don't think I can tell you anything more.
Linus
^ permalink raw reply
* Re: files are disappearing in git
From: Petr Baudis @ 2005-11-25 19:39 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Nico -telmich- Schottelius, Ryan Anderson, Git ML
In-Reply-To: <Pine.LNX.4.64.0511251022360.13959@g5.osdl.org>
Dear diary, on Fri, Nov 25, 2005 at 08:12:00PM CET, I got a letter
where Linus Torvalds <torvalds@osdl.org> said that...
> The problem is a bad merge. And in fact, that merge lost _more_ than just
> the three files under Code/Spikes/Statistik/, it also lost a file called
> Code/lw1/Client/Pics/icon/lw1-icon.png.
>
> I don't quite see _how_ it lost them. The merge in question is a totally
> trivial in-index merge, and when I re-do it, I don't lose those files. In
> this case, all the lost files were from the "other branch" of the merge,
> and they were new to that branch. IOW, in git-merge-one-file parlance, it
> is that trivial "added in one" case.
>
> Pasky - do you know of any historical cogito problems like this?
Puzzling. In the past, cg-merge might get confused by merging on top of
tree with some uncommitted changes (either deleting them, or possibly
intermixing them with the merge - not sure about the latter now), but a
quick scan of Cogito changes over the last few months shows no other
bugs, and I can't remember any major bugfixes besides this either.
Any idea what Cogito version (roughly) could have been used to perform
the merge, Nico?
--
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
VI has two modes: the one in which it beeps and the one in which
it doesn't.
^ permalink raw reply
* Re: files are disappearing in git
From: Ryan Anderson @ 2005-11-25 19:51 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Nico -telmich- Schottelius, Git ML, Petr Baudis
In-Reply-To: <Pine.LNX.4.64.0511251022360.13959@g5.osdl.org>
On Fri, Nov 25, 2005 at 11:12:00AM -0800, Linus Torvalds wrote:
>
> Ok,
>
> Nico gave me private access to the tree, so I quickly cloned it and
> started bisecting it to figure out where the problem was. I haven't looked
> at the source code, and all the commit messages seem to be in German
> (which I can kind of understand if I work at it, but not very well), but
> it definitely turns out none of that matters.
>
> The problem is a bad merge. And in fact, that merge lost _more_ than just
> the three files under Code/Spikes/Statistik/, it also lost a file called
> Code/lw1/Client/Pics/icon/lw1-icon.png.
>
> I don't quite see _how_ it lost them. The merge in question is a totally
> trivial in-index merge, and when I re-do it, I don't lose those files. In
> this case, all the lost files were from the "other branch" of the merge,
> and they were new to that branch. IOW, in git-merge-one-file parlance, it
> is that trivial "added in one" case.
Can something like this sequence do it?
git-init-db
git add file1 ; git commit -m "1"
(cd .. ; git clone tree1 tree2 )
(cd .. ; git clone tree1 tree3 )
git add file2 ; git commit -m "2"
git push ../tree2/
git add file3 ; git commit -m "3"
cd ../tree3/
git add file4
git commit -m "4"
cd ../tree2/
git pull ../tree3/
The key point being that the merge is done in a tree that has its index
out of sync with its HEAD (git push ../tree2/ .... git pull ../tree3/ )
I think that's the situation where I've personally managed to lose
and/or revert some changes.
--
Ryan Anderson
sometimes Pug Majere
^ permalink raw reply
* Re: Why not clone to a remote directory over SSH
From: Nick Hengeveld @ 2005-11-25 20:26 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Andreas Ericsson, git
In-Reply-To: <Pine.LNX.4.63.0511241136370.12985@wbgn013.biozentrum.uni-wuerzburg.de>
On Thu, Nov 24, 2005 at 11:36:58AM +0100, Johannes Schindelin wrote:
> > > For that matter, is it possible to generate the file(s) needed for a dumb
> > > server on the client side?
> >
> > Which files are those? I've been working on a way to update info/refs
> > and eventually objects/info/packs.
>
> These I meant.
Yes - it should be straightforward to generate those files on the client
side. A PROPFIND request for the remote directory with Depth: 1 will
return a list of files in the directory, so refs and objects/packs can
be crawled to generate the contents of the server info files. That's
assuming that packs and tags are being pushed of course.
Come to think of it, PROPFIND is probably a more efficient way to check
for the existence of an object in the remote repo as well. That would
make it feasible to remove the --complete option and always verify the
full history.
--
For a successful technology, reality must take precedence over public
relations, for nature cannot be fooled.
^ permalink raw reply
* Re: files are disappearing in git
From: Junio C Hamano @ 2005-11-25 21:28 UTC (permalink / raw)
To: Ryan Anderson; +Cc: git
In-Reply-To: <20051125195121.GG16995@mythryan2.michonline.com>
Ryan Anderson <ryan@michonline.com> writes:
> Can something like this sequence do it?
>
> ...
>
> The key point being that the merge is done in a tree that has its index
> out of sync with its HEAD (git push ../tree2/ .... git pull ../tree3/ )
>
> I think that's the situation where I've personally managed to lose
> and/or revert some changes.
The moral of the story is not to push into the checked-out
branch of a non-naked repository, or you need to do what you are
doing if you choose to do so. It might have made sense if index
file recorded which tree object its contents came from, but I am
not sure what tools is responsible for recording that if we
choose to extend index file to store that information. Probably
read-tree is, but it should not do that unconditionally.
In any case, the workflow presented by Nick is that individual
developers use cg-* commands in CVS like workflow where the only
place you push into is the central repository and everybody
pulls from there, so I do not think the above example applies.
^ permalink raw reply
* Re: files are disappearing in git
From: Nico -telmich- Schottelius @ 2005-11-25 21:28 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Ryan Anderson, Git ML, Petr Baudis
In-Reply-To: <Pine.LNX.4.64.0511251022360.13959@g5.osdl.org>
[-- Attachment #1: Type: text/plain, Size: 2655 bytes --]
Good evening,
Linus Torvalds [Fri, Nov 25, 2005 at 11:12:00AM -0800]:
> Nico gave me private access to the tree, so I quickly cloned it and
> started bisecting it to figure out where the problem was. I haven't looked
> at the source code, and all the commit messages seem to be in German
> (which I can kind of understand if I work at it, but not very well), but
> it definitely turns out none of that matters.
Well, there's still a broken username, but that's our problem with
iso8859-1 in passwd.
> The problem is a bad merge. And in fact, that merge lost _more_ than just
> the three files under Code/Spikes/Statistik/, it also lost a file called
> Code/lw1/Client/Pics/icon/lw1-icon.png.
Good to know, we didn't that we lost it until now :)
> Pasky - do you know of any historical cogito problems like this?
For information:
[22:07] srsyg03:packages% ls -l /usr/packages
insgesamt 28
drwxr-xr-x 4 root root 4096 Nov 10 15:52 cogito-/
drwxr-xr-x 4 root root 4096 Okt 14 15:15 cogito-0.15/
drwxr-xr-x 4 root root 4096 Nov 23 13:31 cogito-73874dddeec2d0a8e5cd343eec762d98314def63/
drwxr-xr-x 4 root root 4096 Okt 14 15:15 cvsps-2.1/
drwxr-xr-x 4 root root 4096 Nov 10 15:52 git-/
drwxr-xr-x 4 root root 4096 Okt 17 14:09 git-20051016.git/
drwxr-xr-x 4 root root 4096 Nov 23 13:31 git-c61642185d411e5e3350566a68483e358ca392b9/
At the time of 2005-11-17 we'll have used a cogito and git version,
which was from 2005-11-10.
> [...]
> So I do not see how that bad commit happened, especially since it's even
> a fairly recent commit (the date of the merge is 2005-11-17).
>
> I wonder if there's a really old and broken version of cogito somewhere
> around. If so, it's on "srsyg03".
Above you see the versions of which were/are installed. I always
link the latest binaries to /usr/local/bin/, so our developers do not
need to care about what version we have.
> (And the two commits that needed manual merging _look_ fine. No lost files
> at least, except for one of the merges losing "bitte_bitte_loesch_mich",
> which judging by it's name _should_ be lost ;)
Those were some lessons in our house. Our developers had to test
if everything works, including deleting :)
> Finally: Nico, I've deleted the trees on my machine, and you can remove my
> ssh key. I don't think I can tell you anything more.
Ok. Thanks for your help! I think we'll add those four files
back to git on monday and continue to work with them.
Nico
--
Latest project: cinit-0.2.1 (http://linux.schottelius.org/cinit/)
Open Source nutures open minds and free, creative developers.
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 827 bytes --]
^ permalink raw reply
* Re: files are disappearing in git
From: Linus Torvalds @ 2005-11-25 22:11 UTC (permalink / raw)
To: Ryan Anderson; +Cc: Nico -telmich- Schottelius, Git ML, Petr Baudis
In-Reply-To: <20051125195121.GG16995@mythryan2.michonline.com>
On Fri, 25 Nov 2005, Ryan Anderson wrote:
>
> Can something like this sequence do it?
Nope, I don't think that should matter. Also, that doesn't seem to match
what Nico & co are doing, but that's hard to tell..
A merge result should be totally independent of the index file(s)
involved.
A dirty index file can cause a merge to _fail_, in that git may refuse to
do the merge at all because of the index not matching the original branch,
but a successful automated merge should never have any dependencies on
what happens to be in the index at the time the merge was done.
So you can think of a merge as being totally specified by the trees
involved, unless we have some bug, of course. I can't think of any.
Now, what _can_ happen (I think) is that if a merge is a failure (and
there, a dirty index can certainly be the _cause_ of that failure), then
when you fix it up and commit, there's some mix-up at _that_ stage.
For example, let's say that you had a dirty tree or something, and then
the merge failed, and you didn't see anything wrong, so you just end up
doing a "git commit". At _that_ point, what you had in the index matters
very much, of course, since the index is what will be committed.
> I think that's the situation where I've personally managed to lose
> and/or revert some changes.
Hmm.. Can you elaborate?
(Side note: all my commentary is purely about the "raw git" interfaces. I
don't know what cogito may do on top of it).
Linus
^ permalink raw reply
* [PATCH] config.c: remove unnecessary header in minimum configuration file.
From: Junio C Hamano @ 2005-11-25 22:22 UTC (permalink / raw)
To: git; +Cc: Johannes Schindelin
It is just silly to start the file called "config" with a
comment that says "This is the config file."
Signed-off-by: Junio C Hamano <junkio@cox.net>
---
config.c | 8 --------
t/t1300-repo-config.sh | 20 --------------------
2 files changed, 0 insertions(+), 28 deletions(-)
applies-to: f316bfd81eaa2064c1d9e01a336eaed8d7a5bd4f
55c2454c6f18323b5ff04504593603848084aa4d
diff --git a/config.c b/config.c
index 5cc8535..52659f9 100644
--- a/config.c
+++ b/config.c
@@ -445,12 +445,6 @@ int git_config_set_multivar(const char*
* If .git/config does not exist yet, write a minimal version.
*/
if (stat(config_filename, &st)) {
- static const char contents[] =
- "#\n"
- "# This is the config file\n"
- "#\n"
- "\n";
-
free(store.key);
/* if nothing to unset, error out */
@@ -461,8 +455,6 @@ int git_config_set_multivar(const char*
}
store.key = (char*)key;
-
- write(fd, contents, sizeof(contents)-1);
store_write_section(fd, key);
store_write_pair(fd, key, value);
} else{
diff --git a/t/t1300-repo-config.sh b/t/t1300-repo-config.sh
index 5e994ff..207dd3d 100644
--- a/t/t1300-repo-config.sh
+++ b/t/t1300-repo-config.sh
@@ -12,10 +12,6 @@ test -f .git/config && rm .git/config
git-repo-config core.penguin "little blue"
cat > expect << EOF
-#
-# This is the config file
-#
-
[core]
penguin = little blue
EOF
@@ -25,10 +21,6 @@ test_expect_success 'initial' 'cmp .git/
git-repo-config Core.Movie BadPhysics
cat > expect << EOF
-#
-# This is the config file
-#
-
[core]
penguin = little blue
Movie = BadPhysics
@@ -39,10 +31,6 @@ test_expect_success 'mixed case' 'cmp .g
git-repo-config Cores.WhatEver Second
cat > expect << EOF
-#
-# This is the config file
-#
-
[core]
penguin = little blue
Movie = BadPhysics
@@ -55,10 +43,6 @@ test_expect_success 'similar section' 'c
git-repo-config CORE.UPPERCASE true
cat > expect << EOF
-#
-# This is the config file
-#
-
[core]
penguin = little blue
Movie = BadPhysics
@@ -76,10 +60,6 @@ test_expect_success 'replace with non-ma
'git-repo-config core.penguin "very blue" !kingpin'
cat > expect << EOF
-#
-# This is the config file
-#
-
[core]
penguin = very blue
Movie = BadPhysics
---
0.99.9.GIT
^ permalink raw reply related
* [PATCH] config.c: remove unnecessary header in minimum configuration file.
From: Junio C Hamano @ 2005-11-25 22:22 UTC (permalink / raw)
To: git; +Cc: Johannes Schindelin
It is just silly to start the file called "config" a comment
that says "This is the config file."
Signed-off-by: Junio C Hamano <junkio@cox.net>
---
config.c | 8 --------
t/t1300-repo-config.sh | 20 --------------------
2 files changed, 0 insertions(+), 28 deletions(-)
applies-to: f316bfd81eaa2064c1d9e01a336eaed8d7a5bd4f
55c2454c6f18323b5ff04504593603848084aa4d
diff --git a/config.c b/config.c
index 5cc8535..52659f9 100644
--- a/config.c
+++ b/config.c
@@ -445,12 +445,6 @@ int git_config_set_multivar(const char*
* If .git/config does not exist yet, write a minimal version.
*/
if (stat(config_filename, &st)) {
- static const char contents[] =
- "#\n"
- "# This is the config file\n"
- "#\n"
- "\n";
-
free(store.key);
/* if nothing to unset, error out */
@@ -461,8 +455,6 @@ int git_config_set_multivar(const char*
}
store.key = (char*)key;
-
- write(fd, contents, sizeof(contents)-1);
store_write_section(fd, key);
store_write_pair(fd, key, value);
} else{
diff --git a/t/t1300-repo-config.sh b/t/t1300-repo-config.sh
index 5e994ff..207dd3d 100644
--- a/t/t1300-repo-config.sh
+++ b/t/t1300-repo-config.sh
@@ -12,10 +12,6 @@ test -f .git/config && rm .git/config
git-repo-config core.penguin "little blue"
cat > expect << EOF
-#
-# This is the config file
-#
-
[core]
penguin = little blue
EOF
@@ -25,10 +21,6 @@ test_expect_success 'initial' 'cmp .git/
git-repo-config Core.Movie BadPhysics
cat > expect << EOF
-#
-# This is the config file
-#
-
[core]
penguin = little blue
Movie = BadPhysics
@@ -39,10 +31,6 @@ test_expect_success 'mixed case' 'cmp .g
git-repo-config Cores.WhatEver Second
cat > expect << EOF
-#
-# This is the config file
-#
-
[core]
penguin = little blue
Movie = BadPhysics
@@ -55,10 +43,6 @@ test_expect_success 'similar section' 'c
git-repo-config CORE.UPPERCASE true
cat > expect << EOF
-#
-# This is the config file
-#
-
[core]
penguin = little blue
Movie = BadPhysics
@@ -76,10 +60,6 @@ test_expect_success 'replace with non-ma
'git-repo-config core.penguin "very blue" !kingpin'
cat > expect << EOF
-#
-# This is the config file
-#
-
[core]
penguin = very blue
Movie = BadPhysics
---
0.99.9.GIT
^ permalink raw reply related
* Re: files are disappearing in git
From: Petr Baudis @ 2005-11-25 22:48 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Ryan Anderson, Nico -telmich- Schottelius, Git ML
In-Reply-To: <Pine.LNX.4.64.0511251400570.13959@g5.osdl.org>
Dear diary, on Fri, Nov 25, 2005 at 11:11:22PM CET, I got a letter
where Linus Torvalds <torvalds@osdl.org> said that...
> For example, let's say that you had a dirty tree or something, and then
> the merge failed, and you didn't see anything wrong, so you just end up
> doing a "git commit". At _that_ point, what you had in the index matters
> very much, of course, since the index is what will be committed.
>
> > I think that's the situation where I've personally managed to lose
> > and/or revert some changes.
>
> Hmm.. Can you elaborate?
>
> (Side note: all my commentary is purely about the "raw git" interfaces. I
> don't know what cogito may do on top of it).
Note that Cogito is now (v0.15.1 or later) supposed to handle merges on
top of trees with local changes fine - it will either error out, or in
case the merge is done on unrelated files it will temporarily ignore
your local changes and cg-commit won't mix them up (even if you do some
conflict fixups).
--
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
VI has two modes: the one in which it beeps and the one in which
it doesn't.
^ permalink raw reply
* Re: files are disappearing in git
From: Petr Baudis @ 2005-11-25 22:57 UTC (permalink / raw)
To: Nico -telmich- Schottelius; +Cc: Linus Torvalds, Ryan Anderson, Git ML
In-Reply-To: <20051125212846.GB5434@schottelius.org>
Dear diary, on Fri, Nov 25, 2005 at 10:28:46PM CET, I got a letter
where Nico -telmich- Schottelius <nico-linux-git@schottelius.org> said that...
> > Pasky - do you know of any historical cogito problems like this?
>
> For information:
>
> [22:07] srsyg03:packages% ls -l /usr/packages
> insgesamt 28
> drwxr-xr-x 4 root root 4096 Nov 10 15:52 cogito-/
> drwxr-xr-x 4 root root 4096 Okt 14 15:15 cogito-0.15/
> drwxr-xr-x 4 root root 4096 Nov 23 13:31 cogito-73874dddeec2d0a8e5cd343eec762d98314def63/
> drwxr-xr-x 4 root root 4096 Okt 14 15:15 cvsps-2.1/
> drwxr-xr-x 4 root root 4096 Nov 10 15:52 git-/
> drwxr-xr-x 4 root root 4096 Okt 17 14:09 git-20051016.git/
> drwxr-xr-x 4 root root 4096 Nov 23 13:31 git-c61642185d411e5e3350566a68483e358ca392b9/
>
> At the time of 2005-11-17 we'll have used a cogito and git version,
> which was from 2005-11-10.
That's really weird - I can't see anything since then that could
influence it. The only possibility is that you were working on those
files before, left them modified but uncommitted, then did a merge which
would touch them, the merge would fail because of local changes, then
you would delete your local instances of the files and try the merge
again.
That's something I fixed only very recently and the fix is not even in
any public release yet; I didn't realize that it could have such
dangerous consequences, but apparently it does. I guess I will release
0.16 final tomorrow.
--
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
VI has two modes: the one in which it beeps and the one in which
it doesn't.
^ permalink raw reply
* [PATCH 0/4] Repository format version check series.
From: Junio C Hamano @ 2005-11-26 1:15 UTC (permalink / raw)
To: git
This series is what I've been cooking for the past several days,
partly based on patch from Martin Atukunda but with hopefully
smaller impact.
[PATCH 1/4] Repository format version check.
[PATCH 2/4] Check repository format version in enter_repo().
[PATCH 3/4] init-db: check template and repository format.
[PATCH 4/4] setup_git_directory(): check repository format version.
The first in the series adds the core.repositoryformatversion
configuration item. The current repository format version is
defined as version 0, and is the same as not having that in the
configuration file.
The second one adds a repository format version check to
enter_repo(). This function is used to verify the path given by
the user, either from the command line or over the network, is a
valid git repository by daemon, upload-pack (which runs on the
other end when you run fetch-pack or clone-pack), and
receive-pack (which runs on the other end when you run
send-pack).
The third one makes sure we do not reinitialize a repository
whose format version we do not understand, do not copy
template files from unmatching version into a new repository,
and record the repository format version in a newly created
repository.
The last bit in the series adds the same check code to
setup_git_directory(). Along with the earlier change to
git-sh-setup that uses git-var to verify the repository, this
gives the shell scripts the same repository format version
check.
I'll push this out to the "master" sometime over the weekend,
and hopefully merge it into "maint" and cut the next 1.0rc on
Wednesday. Let's hope that will be the last 1.0rc.
^ permalink raw reply
* [PATCH 2/4] Check repository format version in enter_repo().
From: Junio C Hamano @ 2005-11-26 1:15 UTC (permalink / raw)
To: git
After daemon, upload-pack and receive-pack find out where the
git directory is and chdir() there, make sure that repository is
in a format we understand, after putenv("GIT_DIR=.") so that it
knows to pick up the configuration file from there.
Signed-off-by: Junio C Hamano <junkio@cox.net>
---
path.c | 1 +
1 files changed, 1 insertions(+), 0 deletions(-)
applies-to: 936ce54dedc7c7cfcf8f83a742325b3329eb95a1
ed2f604235d7f400ee5fa01a591158cdabd65197
diff --git a/path.c b/path.c
index 4d88947..2c077c0 100644
--- a/path.c
+++ b/path.c
@@ -199,6 +199,7 @@ char *enter_repo(char *path, int strict)
if(access("objects", X_OK) == 0 && access("refs", X_OK) == 0 &&
validate_symref("HEAD") == 0) {
putenv("GIT_DIR=.");
+ check_repository_format();
return current_dir();
}
---
0.99.9.GIT
^ permalink raw reply related
* [PATCH 1/4] Repository format version check.
From: Junio C Hamano @ 2005-11-26 1:15 UTC (permalink / raw)
To: git
This adds the repository format version code, first done by
Martin Atukunda.
Signed-off-by: Junio C Hamano <junkio@cox.net>
---
cache.h | 5 +++++
environment.c | 1 +
setup.c | 16 ++++++++++++++++
3 files changed, 22 insertions(+), 0 deletions(-)
applies-to: 31b3c7eeb719c61a19922f3e8bf5abd46b49b5bb
58fd7fb9718df942773862c9acd2358533c672d4
diff --git a/cache.h b/cache.h
index 6ac94c5..de53f41 100644
--- a/cache.h
+++ b/cache.h
@@ -182,6 +182,10 @@ extern int trust_executable_bit;
extern int only_use_symrefs;
extern int diff_rename_limit_default;
+#define GIT_REPO_VERSION 0
+extern int repository_format_version;
+extern int check_repository_format(void);
+
#define MTIME_CHANGED 0x0001
#define CTIME_CHANGED 0x0002
#define OWNER_CHANGED 0x0004
@@ -388,6 +392,7 @@ extern int git_config_int(const char *,
extern int git_config_bool(const char *, const char *);
extern int git_config_set(const char *, const char *);
extern int git_config_set_multivar(const char *, const char *, const char *, int);
+extern int check_repository_format_version(const char *var, const char *value);
#define MAX_GITNAME (1000)
extern char git_default_email[MAX_GITNAME];
diff --git a/environment.c b/environment.c
index b5026f1..3f19473 100644
--- a/environment.c
+++ b/environment.c
@@ -13,6 +13,7 @@ char git_default_email[MAX_GITNAME];
char git_default_name[MAX_GITNAME];
int trust_executable_bit = 1;
int only_use_symrefs = 0;
+int repository_format_version = 0;
static char *git_dir, *git_object_dir, *git_index_file, *git_refs_dir,
*git_graft_file;
diff --git a/setup.c b/setup.c
index ab3c778..0e2e3c8 100644
--- a/setup.c
+++ b/setup.c
@@ -154,6 +154,22 @@ static const char *setup_git_directory_1
return cwd + offset;
}
+int check_repository_format_version(const char *var, const char *value)
+{
+ if (strcmp(var, "core.repositoryformatversion") == 0)
+ repository_format_version = git_config_int(var, value);
+ return 0;
+}
+
+int check_repository_format(void)
+{
+ git_config(check_repository_format_version);
+ if (GIT_REPO_VERSION < repository_format_version)
+ die ("Expected git repo version <= %d, found %d",
+ GIT_REPO_VERSION, repository_format_version);
+ return 0;
+}
+
const char *setup_git_directory(void)
{
const char *retval = setup_git_directory_1();
---
0.99.9.GIT
^ permalink raw reply related
* [PATCH 3/4] init-db: check template and repository format.
From: Junio C Hamano @ 2005-11-26 1:15 UTC (permalink / raw)
To: git
This makes init-db repository version aware.
It checks if an existing config file says the repository being
reinitialized is of a wrong version and aborts before doing
further harm.
When copying the templates, it makes sure the they are of the
right repository format version. Otherwise the templates are
ignored with an warning message.
It copies the templates before creating the HEAD, and if the
config file is copied from the template directory, reads it,
primarily to pick up the value of core.symrefsonly.
It changes the way the result of the filemode reliability test
is written to the configuration file using git_config_set().
The test is done even if the config file was copied from the
templates.
And finally, our own repository format version is written to the
config file.
Signed-off-by: Junio C Hamano <junkio@cox.net>
---
cache.h | 1 +
config.c | 16 ++++++++---
init-db.c | 89 +++++++++++++++++++++++++++++++++++--------------------------
3 files changed, 64 insertions(+), 42 deletions(-)
applies-to: 3478f0c15277931430f7db669a8004da52c1a887
654494dfddb135db6187a3f00917e24c1dbcd569
diff --git a/cache.h b/cache.h
index de53f41..61bf884 100644
--- a/cache.h
+++ b/cache.h
@@ -387,6 +387,7 @@ extern int gitfakemunmap(void *start, si
typedef int (*config_fn_t)(const char *, const char *);
extern int git_default_config(const char *, const char *);
+extern int git_config_from_file(config_fn_t fn, const char *);
extern int git_config(config_fn_t fn);
extern int git_config_int(const char *, const char *);
extern int git_config_bool(const char *, const char *);
diff --git a/config.c b/config.c
index 5cc8535..0c43d76 100644
--- a/config.c
+++ b/config.c
@@ -11,6 +11,7 @@
#define MAXNAME (256)
static FILE *config_file;
+static char *config_file_name;
static int config_linenr;
static int get_next_char(void)
{
@@ -186,7 +187,7 @@ static int git_parse_file(config_fn_t fn
if (get_value(fn, var, baselen+1) < 0)
break;
}
- die("bad config file line %d", config_linenr);
+ die("bad config file line %d in %s", config_linenr, config_file_name);
}
int git_config_int(const char *name, const char *value)
@@ -197,7 +198,7 @@ int git_config_int(const char *name, con
if (!*end)
return val;
}
- die("bad config value for '%s'", name);
+ die("bad config value for '%s' in %s", name, config_file_name);
}
int git_config_bool(const char *name, const char *value)
@@ -240,21 +241,28 @@ int git_default_config(const char *var,
return 0;
}
-int git_config(config_fn_t fn)
+int git_config_from_file(config_fn_t fn, const char *filename)
{
int ret;
- FILE *f = fopen(git_path("config"), "r");
+ FILE *f = fopen(filename, "r");
ret = -1;
if (f) {
config_file = f;
+ config_file_name = filename;
config_linenr = 1;
ret = git_parse_file(fn);
fclose(f);
+ config_file_name = NULL;
}
return ret;
}
+int git_config(config_fn_t fn)
+{
+ return git_config_from_file(fn, git_path("config"));
+}
+
/*
* Find all the stuff for git_config_set() below.
*/
diff --git a/init-db.c b/init-db.c
index bd88291..8195b68 100644
--- a/init-db.c
+++ b/init-db.c
@@ -132,6 +132,23 @@ static void copy_templates(const char *g
return;
}
+ /* Make sure that template is from the correct vintage */
+ strcpy(template_path + template_len, "config");
+ repository_format_version = 0;
+ git_config_from_file(check_repository_format_version,
+ template_path);
+ template_path[template_len] = 0;
+
+ if (repository_format_version &&
+ repository_format_version != GIT_REPO_VERSION) {
+ fprintf(stderr, "warning: not copying templates of "
+ "a wrong format version %d from '%s'\n",
+ repository_format_version,
+ template_dir);
+ closedir(dir);
+ return;
+ }
+
memcpy(path, git_dir, len);
path[len] = 0;
copy_templates_1(path, len,
@@ -140,12 +157,13 @@ static void copy_templates(const char *g
closedir(dir);
}
-static void create_default_files(const char *git_dir,
- char *template_path)
+static void create_default_files(const char *git_dir, char *template_path)
{
unsigned len = strlen(git_dir);
static char path[PATH_MAX];
unsigned char sha1[20];
+ struct stat st1;
+ char repo_version_string[10];
if (len > sizeof(path)-50)
die("insane git directory %s", git_dir);
@@ -164,6 +182,15 @@ static void create_default_files(const c
strcpy(path + len, "refs/tags");
safe_create_dir(path);
+ /* First copy the templates -- we might have the default
+ * config file there, in which case we would want to read
+ * from it after installing.
+ */
+ path[len] = 0;
+ copy_templates(path, len, template_path);
+
+ git_config(git_default_config);
+
/*
* Create the default symlink from ".git/HEAD" to the "master"
* branch, if it does not exist yet.
@@ -173,44 +200,22 @@ static void create_default_files(const c
if (create_symref(path, "refs/heads/master") < 0)
exit(1);
}
- path[len] = 0;
- copy_templates(path, len, template_path);
- /*
- * Find out if we can trust the executable bit.
- */
- safe_create_dir(path);
+ /* This forces creation of new config file */
+ sprintf(repo_version_string, "%d", GIT_REPO_VERSION);
+ git_config_set("core.repositoryformatversion", repo_version_string);
+
+ path[len] = 0;
strcpy(path + len, "config");
- if (access(path, R_OK) < 0) {
- static const char contents[] =
- "#\n"
- "# This is the config file\n"
- "#\n"
- "\n"
- "; core variables\n"
- "[core]\n"
- " ; Don't trust file modes\n"
- " filemode = false\n"
- "\n";
- FILE *config = fopen(path, "w");
- struct stat st;
-
- if (!config)
- die("Can not write to %s?", path);
-
- fwrite(contents, sizeof(contents)-1, 1, config);
-
- fclose(config);
-
- if (!lstat(path, &st)) {
- struct stat st2;
- if (!chmod(path, st.st_mode ^ S_IXUSR) &&
- !lstat(path, &st2) &&
- st.st_mode != st2.st_mode)
- unlink(path);
- else
- fprintf(stderr, "Ignoring file modes\n");
- }
+
+ /* Check filemode trustability */
+ if (!lstat(path, &st1)) {
+ struct stat st2;
+ int filemode = (!chmod(path, st1.st_mode ^ S_IXUSR) &&
+ !lstat(path, &st2) &&
+ st1.st_mode != st2.st_mode);
+ git_config_set("core.filemode",
+ filemode ? "true" : "false");
}
}
@@ -249,6 +254,14 @@ int main(int argc, char **argv)
fprintf(stderr, "defaulting to local storage area\n");
}
safe_create_dir(git_dir);
+
+ /* Check to see if the repository version is right.
+ * Note that a newly created repository does not have
+ * config file, so this will not fail. What we are catching
+ * is an attempt to reinitialize new repository with an old tool.
+ */
+ check_repository_format();
+
create_default_files(git_dir, template_dir);
/*
---
0.99.9.GIT
^ permalink raw reply related
* [PATCH 4/4] setup_git_directory(): check repository format version.
From: Junio C Hamano @ 2005-11-26 1:15 UTC (permalink / raw)
To: git
After figuring out the GIT_DIR location, make sure the
repository is of the right vintage, by calling
check_repository_format(). .
Signed-off-by: Junio C Hamano <junkio@cox.net>
---
setup.c | 1 +
1 files changed, 1 insertions(+), 0 deletions(-)
applies-to: 780a67370b48b5230c31092b613533a109eb57f8
f30efdb616487d90c037c6d0c4088e151b960016
diff --git a/setup.c b/setup.c
index 0e2e3c8..cc44a72 100644
--- a/setup.c
+++ b/setup.c
@@ -173,5 +173,6 @@ int check_repository_format(void)
const char *setup_git_directory(void)
{
const char *retval = setup_git_directory_1();
+ check_repository_format();
return retval;
}
---
0.99.9.GIT
^ permalink raw reply related
* Re: [PATCH] Rename git-config-set to git-repo-config
From: Junio C Hamano @ 2005-11-26 2:22 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git
In-Reply-To: <Pine.LNX.4.63.0511242252080.26485@wbgn013.biozentrum.uni-wuerzburg.de>
Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
>> - Natively, they work only from the project toplevel. Period.
>
> How about changing *that*?
I once advocated for an environment to name the top of working
tree directory --- it might make sense to resurrect that one.
"natively" was a bad choice of word. What I meant by the above
was that the core library part (what is in read-cache,
sha1_file, etc) works on canonical path, which is defined to be
project toplevel relative. I do not think changing that is wise
nor necessary.
The setup_git_directory() interface is a good way to take path
arguments given by the end user and convert them into canonical
path form. So instead of punting when GIT_DIR is specified that
we have no way knowing where the working tree top is, we could
use GIT_WORKING_TREE, if exists, and use that location as the
toplevel when we need to access the working tree. That implies
we chdir() to that directory and do necessary prefix adjustments
before returning. But I'd rather postpone that after 1.0.
^ permalink raw reply
* Re: [PATCH] Make git-mv work in subdirectories, too
From: Junio C Hamano @ 2005-11-26 2:45 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git
In-Reply-To: <Pine.LNX.4.63.0511251236060.30796@wbgn013.biozentrum.uni-wuerzburg.de>
Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> Turns out, all git programs git-mv uses are capable of operating in
> a subdirectory just fine. So don't complain about it.
>
> Signed-off-by: Johannes Schindelin <Johannes.Schindelin@gmx.de>
>
> ---
>
> I am no Perl guru, so this might not be the best way to go
> about it. Also, if people agree, I would like to remove the
> extra check for GIT_DIR validity, since git-rev-parse --git-dir
> does that already.
I think that sounds sane. You need to grab the exit status from
`git-rev-parse --git-dir`, so the patch would become something
like the attached. I haven't seriously used git-mv myself, so
somebody needs to test it, and if it actually works and Ack on
it, please.
---
diff --git a/git-mv.perl b/git-mv.perl
index bf54c38..6dda333 100755
--- a/git-mv.perl
+++ b/git-mv.perl
@@ -33,15 +33,9 @@ EOT
exit(1);
}
-# Sanity checks:
-my $GIT_DIR = $ENV{'GIT_DIR'} || ".git";
-
-unless ( -d $GIT_DIR && -d $GIT_DIR . "/objects" &&
- -d $GIT_DIR . "/objects/" && -d $GIT_DIR . "/refs") {
- print "Git repository not found.";
- usage();
-}
-
+my $GIT_DIR = `git rev-parse --git-dir`;
+exit 1 if $?; # rev-parse would have given "not a git dir" message.
+chomp($GIT_DIR);
our ($opt_n, $opt_f, $opt_h, $opt_k, $opt_v);
getopts("hnfkv") || usage;
^ permalink raw reply related
* [PATCH] Fix off-by-one error.
From: A Large Angry SCM @ 2005-11-26 3:37 UTC (permalink / raw)
To: Junio C Hamano, git
Signed-off-by: A Large Angry SCM <gitzilla@gmail.com>
---
name-rev.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
applies-to: 31b3c7eeb719c61a19922f3e8bf5abd46b49b5bb
d689edabc1af589855047a16d3682dba8fd3f1e5
diff --git a/name-rev.c b/name-rev.c
index 817e36b..2a25958 100644
--- a/name-rev.c
+++ b/name-rev.c
@@ -227,7 +227,7 @@ int main(int argc, char **argv)
/* flush */
if (p_start != p)
- fwrite(p_start, p - p_start, 1, stdout);
+ fwrite(p_start, p - p_start + 1, 1, stdout);
}
} else if (all) {
int i;
---
0.99.9.GIT
^ permalink raw reply related
* Re: [PATCH] Rename git-config-set to git-repo-config
From: Linus Torvalds @ 2005-11-26 4:05 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Johannes Schindelin, git
In-Reply-To: <7vy83cdu7r.fsf@assigned-by-dhcp.cox.net>
On Fri, 25 Nov 2005, Junio C Hamano wrote:
>
> Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
>
> >> - Natively, they work only from the project toplevel. Period.
> >
> > How about changing *that*?
>
> I once advocated for an environment to name the top of working
> tree directory --- it might make sense to resurrect that one.
Please don't.
We should just make the scripts do it automatically instead.
"git-rev-parse" already has support for all of this, and you can do
GIT_DIR=$(git-rev-parse --git-dir)
GIT_PREFIX=$(git-rev-parse --show-prefix)
where the first one shows the GIT_DIR, and the second one shows where in a
git directory we are (empty if we're at the root).
And most of the git commands written in C (where it makes sense) can
already handle being inside a subdirectory. So can a number of the
shell-scripts (for example, doing a "git log" inside a subdirectory
already does the log for just that subdirectory).
In fact, I'd prefer if _every_ command just did the right thing inside a
subdirectory.
I sent out this patch a week or two ago - it still applies, and it still
mostly does the right thing. It makes at least "gitk" work right inside a
subdirectory, and might make things like "git commit" and friends do the
same.
More testing still needed, but I think this is going in the right
direction.
Comments? I got none the first time around.
Linus
----
NOTE! This has some seriously far-reaching implications. One of them is
that a few programs will automagically start working inside some random
directories.
And probably others won't. Instead of saying "Not a git archive", they
might run and do strange things.
The patch is definitely a big step in the right direction: it makes the
shell scripts that include "git-sh-setup" act a lot more like the programs
that automatically find the git directory. But everybody that includes
git-sh-setup should be verified.
This fixes gitk to also work the same way, btw.
---
diff --git a/git-sh-setup.sh b/git-sh-setup.sh
index dbb9884..044b0b4 100755
--- a/git-sh-setup.sh
+++ b/git-sh-setup.sh
@@ -3,7 +3,7 @@
# Set up GIT_DIR and GIT_OBJECT_DIRECTORY
# and return true if everything looks ok
#
-: ${GIT_DIR=.git}
+: ${GIT_DIR=$(git-rev-parse --git-dir)} || exit
: ${GIT_OBJECT_DIRECTORY="$GIT_DIR/objects"}
# Having this variable in your environment would break scripts because
diff --git a/gitk b/gitk
index a9d37d9..a934255 100755
--- a/gitk
+++ b/gitk
@@ -12,7 +12,7 @@ proc gitdir {} {
if {[info exists env(GIT_DIR)]} {
return $env(GIT_DIR)
} else {
- return ".git"
+ return [exec git-rev-parse --git-dir]
}
}
diff --git a/setup.c b/setup.c
index c487d7e..96085dd 100644
--- a/setup.c
+++ b/setup.c
@@ -53,11 +53,10 @@ const char **get_pathspec(const char *pr
const char **p;
int prefixlen;
- if (!prefix && !entry)
- return NULL;
-
if (!entry) {
static const char *spec[2];
+ if (!prefix || !*prefix)
+ return NULL;
spec[0] = prefix;
spec[1] = NULL;
return spec;
@@ -120,9 +119,19 @@ const char *setup_git_directory(void)
if (offset == len)
return NULL;
-
/* Make "offset" point to past the '/', and add a '/' at the end */
offset++;
+
+ /*
+ * If we're inside the ".git" directory, we have an empty prefix
+ */
+ if (!strncmp(cwd + offset, ".git", 4)) {
+ switch (cwd[offset+4]) {
+ case '\0': case '/':
+ return "";
+ }
+ }
+
cwd[len++] = '/';
cwd[len] = 0;
return cwd + offset;
^ permalink raw reply related
* Re: [PATCH] Rename git-config-set to git-repo-config
From: Linus Torvalds @ 2005-11-26 4:07 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Johannes Schindelin, git
In-Reply-To: <Pine.LNX.4.64.0511251953081.13959@g5.osdl.org>
On Fri, 25 Nov 2005, Linus Torvalds wrote:
>
> In fact, I'd prefer if _every_ command just did the right thing inside a
> subdirectory.
Side note: the thing I like best about the patch I just sent out is that
it also makes things automagically work when you're inside the ".git"
directory. So you should be able to do a "git log" inside a "raw" archive
without setting GIT_DIR=. explicitly.
Linus
^ permalink raw reply
* Re: [PATCH] Rename git-config-set to git-repo-config
From: Junio C Hamano @ 2005-11-26 5:52 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Johannes Schindelin, git
In-Reply-To: <7vmzjtn3h1.fsf@assigned-by-dhcp.cox.net>
Linus Torvalds <torvalds@osdl.org> writes:
> Please don't.
>
> We should just make the scripts do it automatically instead.
Don't worry, we are in agreement about that goal.
> "git-rev-parse" already has support for all of this, and you can do
>
> GIT_DIR=$(git-rev-parse --git-dir)
> GIT_PREFIX=$(git-rev-parse --show-prefix)
>
> where the first one shows the GIT_DIR, and the second one shows where in a
> git directory we are (empty if we're at the root).
Not in one case -- out-of-tree GIT_DIR. That is what
GIT_WORKING_TREE is about.
> In fact, I'd prefer if _every_ command just did the right thing inside a
> subdirectory.
Of course.
The case your patch does not cover that I am worried about is
where GIT_DIR is totally out of the tree. Something like
GIT_DIR=/home/torvalds/uemacs.git and working tree at
/tmp/uemacs. There is currently no way for the tools to figure
out where the working tree toplevel is in such an arrangement,
and that is when GIT_WORKING_TREE becomes useful.
Under normal use pattern, with GIT_DIR not in such a funny place
but immediately under working tree root, you do not need GIT_DIR
nor GIT_WORKING_TREE. We can figure things ourselves by
chdir()-up and looking for '.git/' directory.
> I sent out this patch a week or two ago - it still applies, and it still
> mostly does the right thing. It makes at least "gitk" work right inside a
> subdirectory, and might make things like "git commit" and friends do the
> same.
I am afraid it needs more work --- as long as a script uses only
C-level that use setup_git_directory(), everything should work,
and in such a case you do not even need sh-setup --- asking
"git-rev-parse --git-dir" is enough, just like you did in
git-add. If the script does not have to know where GIT_DIR is
(and I do not think gitk needs to know it, although it digs
there by hand), it does not even need to do that. As you said,
git-log and git-whatchanged works without any funny trick and
are fine examples of that.
> More testing still needed, but I think this is going in the right
> direction.
>
> Comments? I got none the first time around.
Among the ones I looked at that use git-sh-setup in
Documentation directory of git.git:
- git-checkout nor git-reset do not work because git-read-tree
does not use setup_git_directory(), and git-sh-setup does not
export GIT_DIR.
And exporting GIT_DIR from git-sh-setup is not a solution.
To setup_git_directory(), existence of GIT_DIR environment
currently means you cannot tell where your toplevel is
anymore. We could check GIT_DIR against getcwd() and if it
is a grand*parent directory, do an appropriate thing
including chdir("$GIT_DIR/..") and returning an adjusted
prefix, but we don't. And that would not work if GIT_DIR is
really out-of-tree anyway.
That is why I keep saying GIT_WORKING_TREE. We could export
both GIT_DIR and GIT_WORKING_TREE from git-sh-setup, and
teach the C-level commands that need access to working tree
to look at it, just like we default GIT_OBJECT_DIRECTORY from
git-sh-setup. People with out of tree GIT_DIR needs to
export both GIT_DIR and GIT_WORKING_TREE to override both,
just like people with object directory in nonstandard place
need to export GIT_OBJECT_DIRECTORY.
Maybe GIT_WORKING_TREE can default to "$GIT_DIR/..", just
like GIT_OBJECT_DIRECTORY defaults to "$GIT_DIR/objects".
Another obvious approach is to stop supporting out-of-tree
GIT_DIR, but I suspect that probably means we should ignore
GIT_DIR environment and always chdir()-up to find .git/
(which is fine and sane but is probably an uncomfortably big
change).
- git-prune does not work because git-fsck-objects does not
know where GIT_DIR is (again, GIT_DIR not exported).
- git-tag works.
Here is a list of C-level and their subdirectory-readiness
status.
These do not look at .git at all -- automatically subdirectory
ready ;-):
check-ref-format get-tar-commit-id git index-pack
mailinfo mailsplit patch-id shell show-index stripspace
verify-pack
Uses setup_git_directory() and subdirectory ready:
cat-file config-set diff-files diff-index diff-stages
diff-tree ls-files name-rev rev-list rev-parse
show-branch symbolic-ref update-index update-ref var
Uses enter_repo() to work from the toplevel:
daemon receive-pack upload-pack
Wants GIT_DIR to know where it is and working tree access is
always toplevel:
apply checkout-index clone-pack commit-tree
convert-objects fetch-pack fsck-objects hash-object
http-fetch http-push init-db local-fetch ls-tree
merge-base merge-index mktag pack-objects pack-redundant
peek-remote prune-packed read-tree send-pack ssh-fetch
ssh-upload tar-tree unpack-file unpack-objects
update-server-info write-tree
^ permalink raw reply
* [PATCH] Fix off-by-one error.
From: A Large Angry SCM @ 2005-11-26 7:59 UTC (permalink / raw)
To: Junio C Hamano, git
Signed-off-by: A Large Angry SCM <gitzilla@gmail.com>
---
Fixed the correct line and tested this time.
name-rev.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
applies-to: 196314fa7461a36f09ad1bab9b76dd190ad1925d
0fdee45c794131cd4cc1a4914cc34ab90511d173
diff --git a/name-rev.c b/name-rev.c
index 817e36b..96a87d3 100644
--- a/name-rev.c
+++ b/name-rev.c
@@ -217,7 +217,7 @@ int main(int argc, char **argv)
if (!strcmp(name, "undefined"))
continue;
- fwrite(p_start, p - p_start, 1, stdout);
+ fwrite(p_start, p - p_start + 1, 1, stdout);
fputc('(', stdout);
fputs(name, stdout);
fputc(')', stdout);
---
0.99.9.GIT
^ permalink raw reply related
* [PATCH 0/8] Make C-level operable from subdirectories
From: Junio C Hamano @ 2005-11-26 9:51 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Johannes Schindelin, git
In-Reply-To: <Pine.LNX.4.64.0511251953081.13959@g5.osdl.org>
Linus Torvalds <torvalds@osdl.org> writes:
> On Fri, 25 Nov 2005, Junio C Hamano wrote:
>>
>> I once advocated for an environment to name the top of working
>> tree directory --- it might make sense to resurrect that one.
>
> Please don't.
>
> We should just make the scripts do it automatically instead.
Here comes an 8-patch series.
[PATCH 1/8] git-apply: work from subdirectory.
[PATCH 2/8] peek-remote: honor proxy config even from subdirectory.
[PATCH 3/8] fsck-objects: work from subdirectory.
[PATCH 4/8] checkout-index: work from subdirectory.
[PATCH 5/8] hash-object: work within subdirectory.
[PATCH 6/8] ls-tree: work from subdirectory.
[PATCH 7/8] Make networking commands to work from a subdirectory.
[PATCH 8/8] Make the rest of commands work from a subdirectory.
^ permalink raw reply
* [PATCH 1/8] git-apply: work from subdirectory.
From: Junio C Hamano @ 2005-11-26 9:56 UTC (permalink / raw)
To: Linus Torvalds; +Cc: git
In-Reply-To: <7vmzjtn3h1.fsf@assigned-by-dhcp.cox.net>
This adds three things:
- prefix_filename() is like prefix_path() but can be used to
name any file on the filesystem, not the files that might go
into the index file.
- git-apply uses setup_git_directory() to find out the GIT_DIR
and reads configuration file. Later this would allow us to
affect the behaviour of the command from the configuration.
- When git-apply is run from a subdirectory, it applies the
given patch only to the files under the current directory and
below.
Signed-off-by: Junio C Hamano <junkio@cox.net>
---
apply.c | 15 +++++++++++++++
cache.h | 1 +
setup.c | 15 +++++++++++++++
3 files changed, 31 insertions(+), 0 deletions(-)
applies-to: 9ccf8849fa9b522a344645c2f28f12ab036e30d5
c20b8d006edfa964b3df5e4c5cc28cb93edcb240
diff --git a/apply.c b/apply.c
index 50be8f3..ae06d41 100644
--- a/apply.c
+++ b/apply.c
@@ -16,6 +16,9 @@
// --numstat does numeric diffstat, and doesn't actually apply
// --index-info shows the old and new index info for paths if available.
//
+static const char *prefix;
+static int prefix_length;
+
static int allow_binary_replacement = 0;
static int check_index = 0;
static int write_index = 0;
@@ -1706,6 +1709,12 @@ static int use_patch(struct patch *p)
return 0;
x = x->next;
}
+ if (prefix && *prefix) {
+ int pathlen = strlen(pathname);
+ if (pathlen <= prefix_length ||
+ memcmp(prefix, pathname, prefix_length))
+ return 0;
+ }
return 1;
}
@@ -1784,6 +1793,10 @@ int main(int argc, char **argv)
int i;
int read_stdin = 1;
+ prefix = setup_git_directory();
+ prefix_length = prefix ? strlen(prefix) : 0;
+ git_config(git_default_config);
+
for (i = 1; i < argc; i++) {
const char *arg = argv[i];
int fd;
@@ -1845,6 +1858,8 @@ int main(int argc, char **argv)
line_termination = 0;
continue;
}
+ arg = prefix_filename(prefix, prefix_length, arg);
+
fd = open(arg, O_RDONLY);
if (fd < 0)
usage(apply_usage);
diff --git a/cache.h b/cache.h
index 6ac94c5..62920ce 100644
--- a/cache.h
+++ b/cache.h
@@ -149,6 +149,7 @@ extern char *get_graft_file(void);
extern const char **get_pathspec(const char *prefix, const char **pathspec);
extern const char *setup_git_directory(void);
extern const char *prefix_path(const char *prefix, int len, const char *path);
+extern const char *prefix_filename(const char *prefix, int len, const char *path);
#define alloc_nr(x) (((x)+16)*3/2)
diff --git a/setup.c b/setup.c
index ab3c778..54f6a34 100644
--- a/setup.c
+++ b/setup.c
@@ -47,6 +47,21 @@ const char *prefix_path(const char *pref
return path;
}
+/*
+ * Unlike prefix_path, this should be used if the named file does
+ * not have to interact with index entry; i.e. name of a random file
+ * on the filesystem.
+ */
+const char *prefix_filename(const char *pfx, int pfx_len, const char *arg)
+{
+ static char path[PATH_MAX];
+ if (!pfx || !*pfx || arg[0] == '/')
+ return arg;
+ memcpy(path, pfx, pfx_len);
+ strcpy(path + pfx_len, arg);
+ return path;
+}
+
const char **get_pathspec(const char *prefix, const char **pathspec)
{
const char *entry = *pathspec;
---
0.99.9.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