* Re: git reset --hard not removing some files
From: Junio C Hamano @ 2006-06-02 14:57 UTC (permalink / raw)
To: Linus Torvalds; +Cc: git, Martin Waitz
In-Reply-To: <Pine.LNX.4.64.0606010918060.5498@g5.osdl.org>
Linus Torvalds <torvalds@osdl.org> writes:
> On Thu, 1 Jun 2006, Martin Waitz wrote:
>>
>> I have the following problem:
>
> It's not a problem, it's a feature.
>...
> Those files were _never_ tracked.
I would agree in the reproduction recipe Martin gave there is no
problem but feature, but at the same time I suspect the recent
"reset --hard simplification" has introduced a true regression.
$ mkdir test || exit
$ cd test || exit
$ git init-db
defaulting to local storage area
$ echo init >file0
$ echo init >file1
$ git add file0 file1
$ git commit -m initial
Committing initial tree de84dc367842fdbbb3acad3b3ed252f8c984296f
$ git branch side
$ rm -f file1
$ echo second >file2
$ git add file2
$ git commit -a -m 'master adds file2 and deletes file1'
$ git checkout side
$ echo modified >file1
$ git commit -a -m 'side edits file1'
$ git checkout master
$ ls
file0 file2
$ git pull . side
Trying really trivial in-index merge...
fatal: Merge requires file-level merging
Nope.
Merging HEAD with 7934c9c383f611cf2b9895a46cf95b815569beef
Merging:
b684570dc1141552d0da950a18f2d84a3ffadbc1 master adds file2 and deletes file1
7934c9c383f611cf2b9895a46cf95b815569beef side edits file1
found 1 common ancestor(s):
598d6491f72b6057ca87683d43cf64b08d90ddaf initial
CONFLICT (delete/modify): file1 deleted in HEAD and modified in 7934c9c383f611cf2b9895a46cf95b815569beef. Version 7934c9c383f611cf2b9895a46cf95b815569beef of file1 left in tree.
Automatic merge failed; fix conflicts and then commit the result.
$ git ls-files -u
100644 b1b716105590454bfc4c0247f193a04088f39c7f 1 file1
100644 2e0996000b7e9019eabcad29391bf0f5c7702f0b 3 file1
$ ls
file0 file1 file2
$ git reset --hard
$ ls
file0 file1 file2
We used to remove file1 from the working tree in this case. One
of the most important reason to use "git reset --hard" is to
recover from a conflicted, failed merge.
Leaving file1 in the working tree around in this case has
unpleasant consequences. After the above:
$ git checkout side
fatal: Untracked working tree file 'file1' would be overwritten by merge.
^ permalink raw reply
* [PATCH] handle concurrent pruning of packed objects
From: Jeff King @ 2006-06-02 15:32 UTC (permalink / raw)
To: git
This patch causes read_sha1_file and sha1_object_info to re-examine the
list of packs if an object cannot be found. It works by re-running
prepare_packed_git() after an object fails to be found.
It does not attempt to clean up the old pack list. Old packs which are in
use can continue to be used (until unused by lru selection). New packs
are placed at the front of the list and will thus be examined before old
packs.
Signed-off-by: Jeff King <peff@peff.net>
---
This is a repost, since there was no response last time. Linus
indicated this approach was reasonable; see:
<Pine.LNX.4.64.0605300752430.5623@g5.osdl.org>
I tested this by making a simple repo with three commits: a, b, and c.
I ran git diff-tree --stdin, and then did the following:
1. fed 'a b' to diff-tree
2. ran git repack -a -d
3. fed 'b c' to diff-tree
Vanilla git complains about the lack of object, whereas this version
provides the correct diff-tree output.
sha1_file.c | 24 ++++++++++++++++++------
1 files changed, 18 insertions(+), 6 deletions(-)
diff --git a/sha1_file.c b/sha1_file.c
index f77c189..696e53f 100644
--- a/sha1_file.c
+++ b/sha1_file.c
@@ -626,12 +626,12 @@ static void prepare_packed_git_one(char
closedir(dir);
}
+static int prepare_packed_git_run_once = 0;
void prepare_packed_git(void)
{
- static int run_once = 0;
struct alternate_object_database *alt;
- if (run_once)
+ if (prepare_packed_git_run_once)
return;
prepare_packed_git_one(get_object_directory(), 1);
prepare_alt_odb();
@@ -640,7 +640,13 @@ void prepare_packed_git(void)
prepare_packed_git_one(alt->base, 0);
alt->name[-1] = '/';
}
- run_once = 1;
+ prepare_packed_git_run_once = 1;
+}
+
+static void reprepare_packed_git(void)
+{
+ prepare_packed_git_run_once = 0;
+ prepare_packed_git();
}
int check_sha1_signature(const unsigned char *sha1, void *map, unsigned long size, const char *type)
@@ -1212,9 +1218,12 @@ int sha1_object_info(const unsigned char
if (!map) {
struct pack_entry e;
- if (!find_pack_entry(sha1, &e))
- return error("unable to find %s", sha1_to_hex(sha1));
- return packed_object_info(&e, type, sizep);
+ if (find_pack_entry(sha1, &e))
+ return packed_object_info(&e, type, sizep);
+ reprepare_packed_git();
+ if (find_pack_entry(sha1, &e))
+ return packed_object_info(&e, type, sizep);
+ return error("unable to find %s", sha1_to_hex(sha1));
}
if (unpack_sha1_header(&stream, map, mapsize, hdr, sizeof(hdr)) < 0)
status = error("unable to unpack %s header",
@@ -1256,6 +1265,9 @@ void * read_sha1_file(const unsigned cha
munmap(map, mapsize);
return buf;
}
+ reprepare_packed_git();
+ if (find_pack_entry(sha1, &e))
+ return read_packed_sha1(sha1, type, size);
return NULL;
}
--
1.3.3.g331f
-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
----- End forwarded message -----
^ permalink raw reply related
* git-http-fetch segfault backtrace
From: Becky Bruce @ 2006-06-02 15:47 UTC (permalink / raw)
To: git
I've been having problems with git-http-fetch segfaulting for several
git versions now. I've been watching the list and have seen other
complaints about similar problems, but the issue I'm hitting seems to
be slightly different. Any insight anyone has here is greatly
appreciated. I've included what information I have, and if there's
any other information or experiments anyone would like me to try,
I'll be happy to give it a go.
Some information:
- the git version is top of tree as of 1pm 6/1. I pulled it from
http://www.kernel.org/pub/scm/git/git.git
- I am running on an i686 Linux machine: uname -a returns
Linux machinename 2.4.21-32.EL #1 Fri Apr 15 21:29:19 EDT 2005 i686
i686 i386 GNU/Linux
- my curl version is
curl 7.10.6 (i386-redhat-linux-gnu) libcurl/7.10.6 OpenSSL/0.9.7a
ipv6 zlib/1.1.4. git with the same curl version appears to work fine
on x86_64 systems here.
- As far as I can tell, this problem seems to have appeared sometime
after git 1.2.4
I compiled git without optimizations and ran git-http-fetch via gdb
to see what's going on. Here's the backtrace:
(gdb) run -v -a -w heads/html heads/html http://www.kernel.org/pub/
scm/git/git.git/
Starting program: /tmp/install/bin/git-http-fetch -v -a -w heads/html
heads/html http://www.kernel.org/pub/scm/git/git.git/
walk bb8fb05ed082c81af81f9eecf356f993e2ef83b7
walk f31d9f5bcd0a1c236d8277df39c74927917ffb8f
Getting alternates list for http://www.kernel.org/pub/scm/git/git.git/
Getting pack list for http://www.kernel.org/pub/scm/git/git.git/
Program received signal SIGSEGV, Segmentation fault.
0x00eed07c in memcpy () from /lib/tls/libc.so.6
(gdb) bt
#0 0x00eed07c in memcpy () from /lib/tls/libc.so.6
#1 0x0804a6db in fread_buffer (ptr=0x9323a01, eltsize=1,
nmemb=16384, buffer=0xbfffb830)
at http.c:38
#2 0x0012c438 in Curl_getinfo () from /usr/lib/libcurl.so.2
#3 0x0012ce49 in Curl_readwrite () from /usr/lib/libcurl.so.2
#4 0x001314f2 in curl_multi_perform () from /usr/lib/libcurl.so.2
#5 0x0804afb9 in get_active_slot () at http.c:304
#6 0x0804d41d in fetch_indices (repo=0x9309498) at http-fetch.c:910
#7 0x0804d666 in fetch_pack (repo=0x9309498, sha1=0x9312390 "Ѥ???r#
\032??&?\aC??:?+'[?\005\b")
at http-fetch.c:977
#8 0x0804dd41 in fetch (sha1=0x9312390 "Ѥ???r#\032??&?\aC??:?+'[?\005
\b") at http-fetch.c:1129
#9 0x0804a4a9 in loop () at fetch.c:166
#10 0x0804a64f in pull (target=0xbfffefe1 "heads/html") at fetch.c:218
#11 0x0804e2c9 in main (argc=7, argv=0xbfffcae4) at http-fetch.c:1269
I also did some poking around, and it looks like the call to
fread_buffer that causes the problem (it's the 3rd call, in this
case) has a potentially bogus buffer->posn (at least, it seems a
little ridiculous to me).... Note that the previous call to fread
resulted in a 0 size.
Starting program: /tmp/install/bin/git-http-fetch -v -a -w heads/html
heads/html http://www.kernel.org/pub/scm/git/git.git/
[/_TOOLS_/plat/local-/ppc-/login]
Installing oss-/1.0.0
walk bb8fb05ed082c81af81f9eecf356f993e2ef83b7
walk f31d9f5bcd0a1c236d8277df39c74927917ffb8f
Getting alternates list for http://www.kernel.org/pub/scm/git/git.git/
Getting pack list for http://www.kernel.org/pub/scm/git/git.git/
Breakpoint 1, fread_buffer (ptr=0x914fa01, eltsize=1, nmemb=16384,
buffer=0xbfffb9a0)
at http.c:35
35 size_t size = eltsize * nmemb;
(gdb) step
36 if (size > buffer->size - buffer->posn)
(gdb) step
37 size = buffer->size - buffer->posn;
(gdb) p/x size
$1 = 0x4000
(gdb) p/x buffer->size
$2 = 0x5e
(gdb) p/x buffer->posn
$3 = 0x0
(gdb) c
Continuing.
Breakpoint 1, fread_buffer (ptr=0x914fa01, eltsize=1, nmemb=16384,
buffer=0xbfffb9a0)
at http.c:35
35 size_t size = eltsize * nmemb;
(gdb) step
36 if (size > buffer->size - buffer->posn)
(gdb) p/x size
$4 = 0x4000
(gdb) p/x buffer->size
$5 = 0x5e
(gdb) p/x buffer->posn
$6 = 0x5e
(gdb) c
Continuing.
Breakpoint 1, fread_buffer (ptr=0x914fa01, eltsize=1, nmemb=16384,
buffer=0xbfffb9a0)
at http.c:35
35 size_t size = eltsize * nmemb;
(gdb) step
36 if (size > buffer->size - buffer->posn)
(gdb) p/x size
$7 = 0x4000
(gdb) p/x buffer->size
$8 = 0x7
(gdb) p/x buffer->posn
$9 = 0xbfffcc54
(gdb)
We thought perhaps the problem was related to CURL MULTI, but we set
http.maxrequests to 1, we get the same behavior. FYI - if you turn
off USE_CURL_MULTI, git no longer builds. There is stuff that uses
the curlm variable that is not inside the ifdefs.
Thanks,
B
^ permalink raw reply
* Re: Importing Mozilla CVS into git
From: Linus Torvalds @ 2006-06-02 15:53 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vac8wdpr5.fsf@assigned-by-dhcp.cox.net>
On Thu, 1 Jun 2006, Junio C Hamano wrote:
> > You're much better off using "gitk --all" if you want to see the result,
> > the "show-branch" this is really broken. It is using the old algorithm
> > that we used to use for "git-rev-tree", and got rid of about a year ago
> > there in favour of git-rev-list ;)
>
> Are you sure about it? My recollection is it uses the
> merge-base logic, naturally enhanced for multiple heads.
Well, it's all the same algorithm, where just the bit usage differs.
git-rev-tree is slightly closer, if only because the original
git-merge-base only did two heads, if I recall correctly (while
git-rev-tree did 16 - the ability of git-show-branch to do 29 came from
just using all the free bits rather than the high bits like rev-tree did)
> And enhancing it to support more than one int wide bitmap should
> not be too difficult, although looking at the output would be
> very taxing for human eye, so I do not know if it is worth it.
Yeah, I don't think there is any reason to really support it. If you have
more than a few heads, you really do need the graphical version to see
what is going on, and git-show-branch doesn't buy you anything.
Linus
^ permalink raw reply
* Re: [PATCH] handle concurrent pruning of packed objects
From: Junio C Hamano @ 2006-06-02 15:53 UTC (permalink / raw)
To: Jeff King; +Cc: git
In-Reply-To: <20060602153223.GA4223@coredump.intra.peff.net>
Jeff King <peff@peff.net> writes:
> This is a repost, since there was no response last time. Linus
> indicated this approach was reasonable; see:
> <Pine.LNX.4.64.0605300752430.5623@g5.osdl.org>
I haven't forgotten about it, but I have been sick.
I am uncertain about not re-examining the packs it originally
thought it had. By prepending the new ones (and the same old
surviving ones) at the beginning you are effectively hiding the
old packs, which sounds reasonable in the usual case.
Also I suspect this might have funny interaction with the case
where there are hand-added packs (see how verify-pack does it).
We do not silently "fix" missing object problems we discover
there.
^ permalink raw reply
* Re: Importing Mozilla CVS into git
From: Junio C Hamano @ 2006-06-02 16:00 UTC (permalink / raw)
To: Linus Torvalds; +Cc: git
In-Reply-To: <Pine.LNX.4.64.0606020849390.5498@g5.osdl.org>
Linus Torvalds <torvalds@osdl.org> writes:
> Yeah, I don't think there is any reason to really support it. If you have
> more than a few heads, you really do need the graphical version to see
> what is going on, and git-show-branch doesn't buy you anything.
The real reason it uses a bit per given ref is what it wants to
show is different from what gitk shows. It wants to show which
ones are reachable from which head on each commit -- in gitk the
user has to follow the line to find it out.
However, to track 300 branches, you would need a terminal with
360 columns or so, _and_ you have to count columns to see if a
given commit is reachable from the ref you are interested in, so
it is not useful at all in practice to do more than a handful
refs at a time.
^ permalink raw reply
* Re: [PATCH] handle concurrent pruning of packed objects
From: Junio C Hamano @ 2006-06-02 16:03 UTC (permalink / raw)
To: Jeff King; +Cc: git
In-Reply-To: <7vwtbzblkf.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano <junkio@cox.net> writes:
> Also I suspect this might have funny interaction with the case
> where there are hand-added packs (see how verify-pack does it).
> We do not silently "fix" missing object problems we discover
> there.
The last sentence should read 'We do not want to silently...'.
Sorry.
^ permalink raw reply
* Re: [PATCH] handle concurrent pruning of packed objects
From: Jeff King @ 2006-06-02 16:04 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vwtbzblkf.fsf@assigned-by-dhcp.cox.net>
On Fri, Jun 02, 2006 at 08:53:52AM -0700, Junio C Hamano wrote:
> I am uncertain about not re-examining the packs it originally
> thought it had. By prepending the new ones (and the same old
> surviving ones) at the beginning you are effectively hiding the
> old packs, which sounds reasonable in the usual case.
That shouldn't make a difference for correctness, even if the old packs
are still there. If you have an object in two packs, then it doesn't
matter which one you pull it from. The main impacts I can think of are:
1. The old pack may already be mapped, and it would be more efficient
to use it. However, the new pack will be mapped on first use, so it
will be used from then on.
2. The pack list can grow without bound. However, for this to matter,
you'd have to do many prunes during the course of a single git
command.
> Also I suspect this might have funny interaction with the case
> where there are hand-added packs (see how verify-pack does it).
> We do not silently "fix" missing object problems we discover
> there.
I will take a look at this.
-Peff
^ permalink raw reply
* Re: [PATCH] handle concurrent pruning of packed objects
From: Junio C Hamano @ 2006-06-02 16:10 UTC (permalink / raw)
To: Jeff King; +Cc: git
In-Reply-To: <20060602160456.GA8957@coredump.intra.peff.net>
Jeff King <peff@peff.net> writes:
> That shouldn't make a difference for correctness, even if the old packs
> are still there. If you have an object in two packs, then it doesn't
> matter which one you pull it from. The main impacts I can think of are:
> 1. The old pack may already be mapped, and it would be more efficient
> to use it. However, the new pack will be mapped on first use, so it
> will be used from then on.
> 2. The pack list can grow without bound. However, for this to matter,
> you'd have to do many prunes during the course of a single git
> command.
I agree 100% on "shouldn't" part. What I wonder is if everybody
works correctly if we mmap the same file (all available .idx are
mapped all the time, and we map .pack LRU) twice. But I realize
we have NO_MMAP configuration for unfortunate platforms to work
it around so that wouldn't be a big deal.
^ permalink raw reply
* [PATCH] sha1_file: avoid re-preparing duplicate packs
From: Jeff King @ 2006-06-02 16:49 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vk67zbksv.fsf@assigned-by-dhcp.cox.net>
When adding packs, skip the pack if we already have it in the packed_git
list. This might happen if we are re-preparing our packs because of a
missing object.
---
On Fri, Jun 02, 2006 at 09:10:24AM -0700, Junio C Hamano wrote:
> I agree 100% on "shouldn't" part. What I wonder is if everybody
> works correctly if we mmap the same file (all available .idx are
This patch avoids duplicates in the packed_git list. It's not necessary
under Linux, at least, but it just seems cleaner, and it's simple to do.
The list might still have packs that are now gone. I didn't want to
purge anything from the packed_git list since I'm not clear on whether
other code might have pointers into the mmap'd portion.
sha1_file.c | 6 ++++++
1 files changed, 6 insertions(+), 0 deletions(-)
diff --git a/sha1_file.c b/sha1_file.c
index 696e53f..aea0f40 100644
--- a/sha1_file.c
+++ b/sha1_file.c
@@ -617,6 +617,12 @@ static void prepare_packed_git_one(char
/* we have .idx. Is it a file we can map? */
strcpy(path + len, de->d_name);
+ for (p = packed_git; p; p = p->next) {
+ if (!memcmp(path, p->pack_name, len + namelen - 4))
+ break;
+ }
+ if (p)
+ continue;
p = add_packed_git(path, len + namelen, local);
if (!p)
continue;
--
1.3.3.gfb825
^ permalink raw reply related
* http-fetch troubles
From: Junio C Hamano @ 2006-06-02 17:38 UTC (permalink / raw)
To: git, Becky Bruce; +Cc: Nick Hengeveld
In-Reply-To: <7vhd34dptq.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano <junkio@cox.net> writes:
> Nick Hengeveld <nickh@reactrix.com> writes:
>
>> - "git push" seems to pass --thin by default to http-push, which
>> subsequently barfs because that's not a valid http-push option.
>> Should it be? Should it be silently ignored? Should git-push not
>> default to --thin when pushing with HTTP transport?
>
> The way I understand http-push works is that it does not use
> packed transfer, so I presume even if we give --thin as a hint
> it cannot even take advantage of it. Probably we should stop
> passing --thin to http transport (git native one uses it as a
> cue that it can generate baseless deltas in the resulting pack).
>
>> - when I clone, http-fetch outputs a whole bunch of
>> "error: Could not read ..." messages - is that expected?
>
> The clone over http seems to be severely broken in "next" right
> now. The one in "master" seems to be OK. bisecting suggests
> the breakage is coming from the tree parser rewrite.
>
> bisect points at 136f2e548a34f1f504b0f062f87ddf33e8d6e83b.
I've pushed out Nick's http-fetch fixes in "master" to see if it
fixes problems for people. Right now the one in "next" branch
seems to be having unrelated problems coming from another topic
which I haven't started tracking down yet.
^ permalink raw reply
* Re: [PATCH] sha1_file: avoid re-preparing duplicate packs
From: Linus Torvalds @ 2006-06-02 17:47 UTC (permalink / raw)
To: Jeff King; +Cc: Junio C Hamano, git
In-Reply-To: <20060602164932.GA10216@coredump.intra.peff.net>
On Fri, 2 Jun 2006, Jeff King wrote:
>
> This patch avoids duplicates in the packed_git list. It's not necessary
> under Linux, at least, but it just seems cleaner, and it's simple to do.
I think it's a good idea even under Linux, since on 32-bit machines, one
of the constraints we have may simply be virtual memory space to map
things into. With big packs, avoiding mapping them twice is a good idea.
Linus
^ permalink raw reply
* Re: Clean up sha1 file writing
From: H. Peter Anvin @ 2006-06-02 18:44 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Matthias Lederhofer, Git Mailing List
In-Reply-To: <Pine.LNX.4.64.0605241145490.5623@g5.osdl.org>
Linus Torvalds wrote:
>
> On Wed, 24 May 2006, Matthias Lederhofer wrote:
>
>>> checking for partial writes
>> Just out of interest: is this to be safe on any OS or should this
>> be checked always?
>
> Any POSIX-conformant OS/filesystem should always do a full write for a
> regular file, unless a serious error happens.
>
Actually, at least Linux won't, if the object is larger than 2 GB on a 64-bit system :)
-hpa
^ permalink raw reply
* Re: [PATCH] Ability to automaticaly push tags to remote repositories.
From: Petr Baudis @ 2006-06-02 20:58 UTC (permalink / raw)
To: Krzysiek Pawlik; +Cc: Git Mailing List
In-Reply-To: <442BD562.3030207@people.pl>
Dear diary, on Thu, Mar 30, 2006 at 02:56:02PM CEST, I got a letter
where Krzysiek Pawlik <krzysiek.pawlik@people.pl> said that...
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
>
> - From `cg-push --long-help`:
>
> - -t TAG::
> Tells cg-push to also push the given tag. Note that in the
> future, cg-push should push tags automatically. Also note
> that even if you pass `cg-push` the '-t' arguments, your
> HEAD is still pushed as well in addition to the tags.
>
> One of possible ways of doing it is in attached patch. Comments,
> suggestions?
Well, this works properly only when you ever push to a single
repository, which many people don't. Besides, if you have two branches,
push branch A but tag a commit only on branch B, you will now be pushing
an invalid tag since the other end won't have the branch B and thus the
tagged commit.
A better way would be to use git-ls-remote --tags to get the list of
remote tags and compare that with the list of local tags, then push
those tags that tag commits on the branch we are pushing and the other
end does not have them.
--
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
A person is just about as big as the things that make them angry.
^ permalink raw reply
* Re: Clean up sha1 file writing
From: Linus Torvalds @ 2006-06-02 21:17 UTC (permalink / raw)
To: H. Peter Anvin; +Cc: Matthias Lederhofer, Git Mailing List
In-Reply-To: <44808710.1080000@zytor.com>
On Fri, 2 Jun 2006, H. Peter Anvin wrote:
> Linus Torvalds wrote:
> >
> > Any POSIX-conformant OS/filesystem should always do a full write for a
> > regular file, unless a serious error happens.
> >
>
> Actually, at least Linux won't, if the object is larger than 2 GB on a 64-bit
> system :)
Yeah, true.
In the end, you should always have the loop. That way, you never have to
worry about what kind of file descriptor it is, what kind of filesystem
you're running on, and what the limits of ssize_t might be.
Linus
^ permalink raw reply
* Re: [PATCH] A Perforce importer for git.
From: Alex Riesen @ 2006-06-02 21:20 UTC (permalink / raw)
To: Sean; +Cc: git
In-Reply-To: <20060602094357.ee3d8407.seanlkml@sympatico.ca>
Sean, Fri, Jun 02, 2006 15:43:57 +0200:
> "Alex Riesen" <raa.lkml@gmail.com> wrote:
>
> > BTW, can I suggest to import the _currently_ synced state?
> >
>
> Note that it never syncs specifically to head, it explicitly asks for
> each revision along the branch and tt doesn't know anything about your
> working state, it can only import commits.
So did get that part right (I didn't actually tried your script, just
read the code).
> Are you looking for the ability to create a single git branch which has
Well, I'm not quite sure it's at all possible... Perforce has a
strange ways for doing history: it is kept for each file (as in CVS),
but you can bundle changes in many files into one "change".
Perforce also has no branches (in the GIT's meaning of the term).
These by Perforce are just server-side directories, without any
relevance to the source whatsoever (just copies).
> the history of the combined view of your stitched together client mappings
> rather than the independent branches held by the server?
I'm rather looking for a ability to manage a single branch where
import "sync" events appear as a merge of changes to the files
involved in the sync. I just haven't figured out yet how to "break" a
Perforce change into changes to single files and import that broken up
commit into git as a merge.
I hope that was clear enough... I think understanding how cvs/svn
imports work should help here - Perforce is actually nothing very
different from them.
^ permalink raw reply
* Re: [PATCH] ciabot: fix post-update hook description
From: Petr Baudis @ 2006-06-02 21:50 UTC (permalink / raw)
To: Jonas Fonseca; +Cc: git
In-Reply-To: <20060529000959.GA2061@diku.dk>
Thanks, all four patches applied. :)
--
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
A person is just about as big as the things that make them angry.
^ permalink raw reply
* Re: http-fetch troubles
From: Junio C Hamano @ 2006-06-02 22:15 UTC (permalink / raw)
To: Nick Hengeveld; +Cc: git, Linus Torvalds
In-Reply-To: <7vac8vbgqg.fsf_-_@assigned-by-dhcp.cox.net>
I think this fixes the http trouble with tree parser change in
the "next" branch.
-- >8 --
fetch.c: do not call process_tree() from process_tree().
This function reads a freshly fetched tree object, and schedules
the objects pointed by it for further fetching, so calling lookup-tree
and doing process_tree() recursively from there does not make
much sense. We need to use process() on it to make sure we
fetch it first.
Signed-off-by: Junio C Hamano <junkio@cox.net>
---
diff --git a/fetch.c b/fetch.c
index ec2d8c3..107504b 100644
--- a/fetch.c
+++ b/fetch.c
@@ -46,13 +46,20 @@ static int process_tree(struct tree *tre
desc.buf = tree->buffer;
desc.size = tree->size;
while (tree_entry(&desc, &entry)) {
+ struct object *obj = NULL;
+
if (S_ISDIR(entry.mode)) {
struct tree *tree = lookup_tree(entry.sha1);
- process_tree(tree);
- } else {
+ if (tree)
+ obj = &tree->object;
+ }
+ else {
struct blob *blob = lookup_blob(entry.sha1);
- process(&blob->object);
+ if (blob)
+ obj = &blob->object;
}
+ if (!obj || process(obj))
+ return -1;
}
free(tree->buffer);
tree->buffer = NULL;
^ permalink raw reply related
* Re: http-fetch troubles
From: Linus Torvalds @ 2006-06-02 22:34 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Nick Hengeveld, git
In-Reply-To: <7vmzcv9pba.fsf@assigned-by-dhcp.cox.net>
On Fri, 2 Jun 2006, Junio C Hamano wrote:
>
> I think this fixes the http trouble with tree parser change in
> the "next" branch.
Ahh, my bad. That happened as a bug in my original understanding of that
fetch.c thing.
Your fix looks obviously fine,
Linus
^ permalink raw reply
* Re: Importing Mozilla CVS into git
From: Jon Smirl @ 2006-06-03 0:09 UTC (permalink / raw)
To: Keith Packard; +Cc: git
In-Reply-To: <1149220518.5521.43.camel@neko.keithp.com>
If I parsecvs this pair it fails:
/home/jonsmirl/mozilla/mozilla/dom/src/base/nsFocusController.h,v
/home/jonsmirl/mozilla/mozilla/dom/src/base/nsGlobalWindow.cpp,v
[jonsmirl@jonsmirl foo]$ ../parsecvs <sm2
defaulting to local storage area
Load: nsGlobalWindow.cpp,v ....................* 2 of 2
Warning: branch point MOZILLA_1_0_BRANCH -> master matched by date
fatal: Not a valid object name (null)
git-read-tree '(null)' failed
[jonsmirl@jonsmirl foo]$
But parsecvs works on each of them individually.
--
Jon Smirl
jonsmirl@gmail.com
^ permalink raw reply
* Re: http-fetch troubles
From: Becky Bruce @ 2006-06-03 1:13 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Nick Hengeveld
In-Reply-To: <7vac8vbgqg.fsf_-_@assigned-by-dhcp.cox.net>
Woohoo! The stuff you moved to master (which is what I was building
from, not "next", as Nick pointed out) has fixed the git-http-fetch
segfault problem I was seeing.
Thanks!
-Becky
On Jun 2, 2006, at 12:38 PM, Junio C Hamano wrote:
> Junio C Hamano <junkio@cox.net> writes:
>
>> Nick Hengeveld <nickh@reactrix.com> writes:
>>
>>> - "git push" seems to pass --thin by default to http-push, which
>>> subsequently barfs because that's not a valid http-push option.
>>> Should it be? Should it be silently ignored? Should git-push not
>>> default to --thin when pushing with HTTP transport?
>>
>> The way I understand http-push works is that it does not use
>> packed transfer, so I presume even if we give --thin as a hint
>> it cannot even take advantage of it. Probably we should stop
>> passing --thin to http transport (git native one uses it as a
>> cue that it can generate baseless deltas in the resulting pack).
>>
>>> - when I clone, http-fetch outputs a whole bunch of
>>> "error: Could not read ..." messages - is that expected?
>>
>> The clone over http seems to be severely broken in "next" right
>> now. The one in "master" seems to be OK. bisecting suggests
>> the breakage is coming from the tree parser rewrite.
>>
>> bisect points at 136f2e548a34f1f504b0f062f87ddf33e8d6e83b.
>
> I've pushed out Nick's http-fetch fixes in "master" to see if it
> fixes problems for people. Right now the one in "next" branch
> seems to be having unrelated problems coming from another topic
> which I haven't started tracking down yet.
>
>
^ permalink raw reply
* Re: http-fetch troubles
From: Junio C Hamano @ 2006-06-03 1:24 UTC (permalink / raw)
To: Becky Bruce; +Cc: git, Nick Hengeveld
In-Reply-To: <1C422237-D48C-4A30-9BDD-5C165222873D@freescale.com>
Becky Bruce <Becky.Bruce@freescale.com> writes:
> Woohoo! The stuff you moved to master (which is what I was building
> from, not "next", as Nick pointed out) has fixed the git-http-fetch
> segfault problem I was seeing.
>
> Thanks!
Thanks Nick for fixing, and Becky for confirming.
... and I take all the credit ;-).
I haven't pushed it out yet, but I believe "next" is also good
to go.
^ permalink raw reply
* Re: http-fetch troubles
From: Linus Torvalds @ 2006-06-03 2:26 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Becky Bruce, git, Nick Hengeveld
In-Reply-To: <7virnj9gkf.fsf@assigned-by-dhcp.cox.net>
On Fri, 2 Jun 2006, Junio C Hamano wrote:
>
> ... and I take all the credit ;-).
I always knew you'd work out as a maintainer.
Linus
^ permalink raw reply
* Re: Importing Mozilla CVS into git
From: Jon Smirl @ 2006-06-03 4:28 UTC (permalink / raw)
Cc: git
In-Reply-To: <9e4733910606011755n29a149f2m1409c5a23888f1c5@mail.gmail.com>
On 6/1/06, Jon Smirl <jonsmirl@gmail.com> wrote:
> With the attached patch you can parse the entire Mozilla tree. The
> tree has over 100,000 files in it and about 300 branches.
I was a little low with these counts, more like 110,000 files and some
parts of the tree have 1,000 branches. Total tree size is 3GB.
--
Jon Smirl
jonsmirl@gmail.com
^ permalink raw reply
* A test failing with python 2.2 -- ok?
From: Geoff Russell @ 2006-06-03 6:48 UTC (permalink / raw)
To: git
Hi,
I'm not sure how far back you are supporting, but I'm running a python
2.2 machine
and make test fails with a missing python module. Whatever criss-cross merges
are, I don't need them, but figured if you were intending to support older
environments, then you may be interested.
Cheers,
Geoff Russell
$ git --version
git version 1.3.3.g61ef-dirty
$ make test
*** t6021-merge-criss-cross.sh ***
....
Traceback (most recent call last):
File "/usr/local/LINUX/GIT/git/t/../git-merge-recursive", line 10, in ?
from heapq import heappush, heappop
ImportError: No module named heapq
-------------------------------------------------------
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox