* Re: parsecvs and unnamed branches
From: Keith Packard @ 2006-06-17 5:30 UTC (permalink / raw)
To: Jon Smirl; +Cc: keithp, Pavel Roskin, git
In-Reply-To: <9e4733910606162115g2165212bgf32a2e328cce751a@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 1445 bytes --]
On Sat, 2006-06-17 at 00:15 -0400, Jon Smirl wrote:
> >>But the real problem is why does it think the branches are in a loop?
I haven't figured it out yet either; mine didn't detect the loop though,
it just ended up spinning in the tsort code, unable to compute a valid
order to execute branches in. Something funky must be up with the
mozilla branches.
What this code does is find an order that will 'work' when computing
branch contents. The requirement is that the 'parent' branch be computed
before any 'child' branches.
It does this with a nice quadratic algorithm, building a list of 'ready'
branches who have no 'unready' dependencies in any of the incoming file
objects. If there are conflicts where one incoming file shows branch 'B'
as the parent of branch 'A' while another shows branch 'A' as the parent
of branch 'B', the sorting cannot succeed.
Ideally, I'd figure out a way to eliminate the parent/child relationship
and just treat the branches as peers with a common ancestor. I haven't
figure out how to manage that yet; attempting to find the precise
divergence point where the child forks from the parent remains
complicated, it seems like trying to do that without a strong
parent/child relationship would be even more error prone.
Better error messsages here would clearly help discover which branches
were in conflict, and show the files causing problems.
--
keith.packard@intel.com
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: [PATCH] auto-detect changed $prefix in Makefile and properly rebuild to avoid broken install
From: Junio C Hamano @ 2006-06-17 5:28 UTC (permalink / raw)
To: Yakov Lerner; +Cc: git
In-Reply-To: <f36b08ee0606150440l544455c7r5c52609b360d0f74@mail.gmail.com>
"Yakov Lerner" <iler.ml@gmail.com> writes:
> BTW, is it possible to have git use argv[0] to automatically determine
> the executable_dir without compiled-in paths ?
It is possible and I think we did that some time ago.
We fixed it since then, so that you can migrate away from
assuming bindir==gitexecdir.
^ permalink raw reply
* Re: [PATCH] auto-detect changed $prefix in Makefile and properly rebuild to avoid broken install
From: Junio C Hamano @ 2006-06-17 5:26 UTC (permalink / raw)
To: Santi; +Cc: git, Yakov Lerner
In-Reply-To: <8aa486160606150426q19b0a661s@mail.gmail.com>
Santi <sbejar@gmail.com> writes:
> Wed, 14 Jun 2006 22:26 +0300, Yakov Lerner <iler.ml@gmail.com>:
>> Many times, I mistakenly used 'make prefix=... install' where prefix value
>> was different from prefix value during build. This resulted in broken
>> install. This patch adds auto-detection of $prefix change to the Makefile.
>> This results in correct install whenever prefix is changed.
>
> I do this each time I install packages from source. I keep them with
> "stow" and the usual sequence is:
>
> make prefix=/home/santi/usr
> make install prefix=/home/santi/usr/stow/git
> cd /home/santi/usr/stow/
> stow -v git
>
> so with this auto-detection I'll compile some programs twice.
I do not know what "stow" is about, but if it is to allow you to
run make-install to install things in somewhere else, examine
the result, and then move the result to the real location
(implying that you should be able to nuke the "somewhere else"
after you have done so), with the patch, the above sequence
would install the binaries pointing at a wrong directory,
because the second compilation would make them point at the
temporary installation directory ~/usr/stow/git, not the final
location ~/usr/.
^ permalink raw reply
* Re: parsecvs and unnamed branches
From: Pavel Roskin @ 2006-06-17 4:35 UTC (permalink / raw)
To: Jon Smirl; +Cc: Keith Packard, git
In-Reply-To: <9e4733910606162115g2165212bgf32a2e328cce751a@mail.gmail.com>
On Sat, 2006-06-17 at 00:15 -0400, Jon Smirl wrote:
> I had already caught that one, the fix was a few mails back.
> git_dir is an atom and shouldn't be freed with free.
I see it now. My patch was wrong - there is another free(git_dir) in
the same function. Keith, please remove both.
> After five hours I hit this:
> fprintf (stderr, "Error: branch cycle\n");
This is more like a logical error. Maybe you actually have circling
branches due to causality violations or something :-)
Sure, Valgrind would be still useful to make sure it's not something
mundane.
--
Regards,
Pavel Roskin
^ permalink raw reply
* Re: parsecvs and unnamed branches
From: Jon Smirl @ 2006-06-17 4:15 UTC (permalink / raw)
To: Pavel Roskin; +Cc: Keith Packard, git
In-Reply-To: <1150517336.9144.8.camel@dv>
On 6/17/06, Pavel Roskin <proski@gnu.org> wrote:
> On Fri, 2006-06-16 at 23:31 -0400, Jon Smirl wrote:
>
> > Parsecvs was compiled '-O2 -g' why didn't it decode the addresses to symbols?
>
> Sorry, I was too quick to put blame on you. Maybe glibc can only list
> its own symbols.
>
> I could reproduce the problem trivially with a single file, and here's
> what Valgrind says:
>
> ==11154== Invalid free() / delete / delete[]
> ==11154== at 0x4905423: free (vg_replace_malloc.c:233)
> ==11154== by 0x40C136: git_pack_directory (git.c:620)
> ==11154== by 0x40C1B4: git_rev_list_pack (git.c:639)
> ==11154== by 0x4067DA: main (parsecvs.c:785)
>
>
> git_pack_directory() tries to free() the result of
> git_system_to_string(), which is in turn a result of atom(). My
> understanding is that atoms should not be freed. They are not freed in
> other cases.
>
> Patch:
>
> diff --git a/README b/README
> diff --git a/git.c b/git.c
> index 33b29c7..7312568 100644
> --- a/git.c
> +++ b/git.c
> @@ -617,7 +617,6 @@ git_pack_directory (void)
> }
> free (objects_dir);
> pack_dir = git_format_command ("%s/objects/pack", git_dir);
> - free (git_dir);
> if (!pack_dir)
> return NULL;
> if (access (pack_dir, F_OK) == -1 &&
I had already caught that one, the fix was a few mails back.
git_dir is an atom and shouldn't be freed with free.
After five hours I hit this:
fprintf (stderr, "Error: branch cycle\n");
static rev_ref *
rev_ref_tsort (rev_ref *refs, rev_list *head)
{
rev_ref *done = NULL;
rev_ref **done_tail = &done;
rev_ref *r, **prev;
// fprintf (stderr, "Tsort refs:\n");
while (refs) {
for (prev = &refs; (r = *prev); prev = &(*prev)->next) {
if (rev_ref_is_ready (r->name, head, done)) {
break;
}
}
if (!r) {
fprintf (stderr, "Error: branch cycle\n");
>> hit this test
return NULL;
}
*prev = r->next;
*done_tail = r;
// fprintf (stderr, "\t%s\n", r->name);
r->next = NULL;
done_tail = &r->next;
}
return done;
}
which returned null up to here
if (rev_mode == ExecuteGit && pack_objcount && autopack)
git_rev_list_pack (pack_start, strip);
load_status_next ();
rl = rev_list_merge (head);
>> null to here
if (rl) {
switch (rev_mode) {
case ExecuteGraph:
dump_rev_graph (rl, NULL);
break;
case ExecuteSplits:
dump_splits (rl);
break;
case ExecuteGit:
git_rev_list_commit (rl, strip);
break;
}
}
if (rl)
rev_list_free (rl, 0);
while (head) {
rl = head;
head = head->next;
rev_list_free (rl, 1);
>> tries to free the list, but the list is a loop.
>> after it wraps it will mangle memory
}
discard_atoms ();
rev_free_dirs ();
rev_commit_cleanup ();
git_free_author_map ();
return err;
>>But the real problem is why does it think the branches are in a loop?
--
Jon Smirl
jonsmirl@gmail.com
^ permalink raw reply
* Re: parsecvs and unnamed branches
From: Pavel Roskin @ 2006-06-17 4:08 UTC (permalink / raw)
To: Jon Smirl; +Cc: Keith Packard, git
In-Reply-To: <9e4733910606162031o69df27fdje50c88949ed990b5@mail.gmail.com>
On Fri, 2006-06-16 at 23:31 -0400, Jon Smirl wrote:
> Parsecvs was compiled '-O2 -g' why didn't it decode the addresses to symbols?
Sorry, I was too quick to put blame on you. Maybe glibc can only list
its own symbols.
I could reproduce the problem trivially with a single file, and here's
what Valgrind says:
==11154== Invalid free() / delete / delete[]
==11154== at 0x4905423: free (vg_replace_malloc.c:233)
==11154== by 0x40C136: git_pack_directory (git.c:620)
==11154== by 0x40C1B4: git_rev_list_pack (git.c:639)
==11154== by 0x4067DA: main (parsecvs.c:785)
git_pack_directory() tries to free() the result of
git_system_to_string(), which is in turn a result of atom(). My
understanding is that atoms should not be freed. They are not freed in
other cases.
Patch:
diff --git a/README b/README
diff --git a/git.c b/git.c
index 33b29c7..7312568 100644
--- a/git.c
+++ b/git.c
@@ -617,7 +617,6 @@ git_pack_directory (void)
}
free (objects_dir);
pack_dir = git_format_command ("%s/objects/pack", git_dir);
- free (git_dir);
if (!pack_dir)
return NULL;
if (access (pack_dir, F_OK) == -1 &&
--
Regards,
Pavel Roskin
^ permalink raw reply related
* Re: parsecvs and unnamed branches
From: Jon Smirl @ 2006-06-17 3:31 UTC (permalink / raw)
To: Pavel Roskin; +Cc: Keith Packard, git
In-Reply-To: <1150513943.29738.15.camel@dv>
On 6/16/06, Pavel Roskin <proski@gnu.org> wrote:
> Hi, Jon!
>
> On Fri, 2006-06-16 at 23:02 -0400, Jon Smirl wrote:
> > My parsecvs job died after 5 hours of CPU time. Does this tell you anything?
> >
> > Pack pack-e28915a5ea09143a9139e84e24534ed888bf1c45 created
> >
> > Error: branch cycle
> > *** glibc detected *** parsecvs: munmap_chunk(): invalid pointer: 0x0a820198 ***
> > *** glibc detected *** parsecvs: corrupted double-linked list: 0x45b1e158 ***
>
> Obviously, memory corruption. Valgrind is likely to help, but it may
> take 50 hours rather than 5. It may still be worth it. Make sure to
> use the latest version of Valgrind and compile parsecvs without
> optimization with full debug information. If you can get debug info for
> libc, install it (on Fedora: "yum install glibc-debuginfo").
>
> > /lib/libc.so.6(__libc_free+0x179)[0x45a554f0]
> > parsecvs[0x804dec8]
>
> You see, even some libc symbols can be found, but parsecvs is opaque.
> That's why debug information is useful. Make sure to keep the sources
> around for debugging.
Parsecvs was compiled '-O2 -g' why didn't it decode the addresses to symbols?
The 'Error: branch cycle' message was critical, the app was in the
process of doing exit clean up with the link list error was found. If
the list is linked in a circle it is likely that the routine freeing
it corrupted memory. So the real error is why did I get 'Error: branch
cycle'.
> --
> Regards,
> Pavel Roskin
>
>
--
Jon Smirl
jonsmirl@gmail.com
^ permalink raw reply
* Re: parsecvs and unnamed branches
From: Pavel Roskin @ 2006-06-17 3:12 UTC (permalink / raw)
To: Jon Smirl; +Cc: Keith Packard, git
In-Reply-To: <9e4733910606162002x508ec6ccjbc36e4220ca44fd6@mail.gmail.com>
Hi, Jon!
On Fri, 2006-06-16 at 23:02 -0400, Jon Smirl wrote:
> My parsecvs job died after 5 hours of CPU time. Does this tell you anything?
>
> Pack pack-e28915a5ea09143a9139e84e24534ed888bf1c45 created
>
> Error: branch cycle
> *** glibc detected *** parsecvs: munmap_chunk(): invalid pointer: 0x0a820198 ***
> *** glibc detected *** parsecvs: corrupted double-linked list: 0x45b1e158 ***
Obviously, memory corruption. Valgrind is likely to help, but it may
take 50 hours rather than 5. It may still be worth it. Make sure to
use the latest version of Valgrind and compile parsecvs without
optimization with full debug information. If you can get debug info for
libc, install it (on Fedora: "yum install glibc-debuginfo").
> /lib/libc.so.6(__libc_free+0x179)[0x45a554f0]
> parsecvs[0x804dec8]
You see, even some libc symbols can be found, but parsecvs is opaque.
That's why debug information is useful. Make sure to keep the sources
around for debugging.
--
Regards,
Pavel Roskin
^ permalink raw reply
* Re: parsecvs and unnamed branches
From: Jon Smirl @ 2006-06-17 3:02 UTC (permalink / raw)
To: Keith Packard; +Cc: git
In-Reply-To: <1150496362.6983.34.camel@neko.keithp.com>
My parsecvs job died after 5 hours of CPU time. Does this tell you anything?
Pack pack-e28915a5ea09143a9139e84e24534ed888bf1c45 created
Error: branch cycle
*** glibc detected *** parsecvs: munmap_chunk(): invalid pointer: 0x0a820198 ***
*** glibc detected *** parsecvs: corrupted double-linked list: 0x45b1e158 ***
======= Backtrace: =========
/lib/libc.so.6[0x45a502c6]
/lib/libc.so.6[0x45a5235a]
/lib/libc.so.6(calloc+0x8d)[0x45a539a1]
/lib/ld-linux.so.2[0x459db1ba]
/lib/ld-linux.so.2[0x459d6f8a]
/lib/ld-linux.so.2[0x459d91e1]
/lib/ld-linux.so.2[0x459e2204]
/lib/ld-linux.so.2[0x459de7b9]
/lib/ld-linux.so.2[0x459e1d0a]
/lib/libc.so.6[0x45ae9c3e]
/lib/ld-linux.so.2[0x459de7b9]
/lib/libc.so.6(__libc_dlopen_mode+0x55)[0x45ae9dc9]
/lib/libc.so.6[0x45ac90f6]
/lib/libc.so.6(backtrace+0x109)[0x45ac9295]
/lib/libc.so.6[0x45a4aa61]
/lib/libc.so.6(__libc_free+0x179)[0x45a554f0]
parsecvs[0x804dec8]
parsecvs[0x804df1e]
parsecvs[0x804ccce]
/lib/libc.so.6(__libc_start_main+0xdc)[0x45a03724]
parsecvs[0x8049cc1]
======= Memory map: ========
08048000-08065000 r-xp 00000000 09:01 4052384
/home/jonsmirl/workspace/parsecvs/parsecvs
08065000-08067000 rw-p 0001c000 09:01 4052384
/home/jonsmirl/workspace/parsecvs/parsecvs
08067000-459c9000 rw-p 08067000 00:00 0 [heap]
459d1000-459ea000 r-xp 00000000 03:06 4243239 /lib/ld-2.4.so
459ea000-459eb000 r--p 00018000 03:06 4243239 /lib/ld-2.4.so
459eb000-459ec000 rw-p 00019000 03:06 4243239 /lib/ld-2.4.so
459ee000-45b1b000 r-xp 00000000 03:06 4243241 /lib/libc-2.4.so
45b1b000-45b1d000 r--p 0012d000 03:06 4243241 /lib/libc-2.4.so
45b1d000-45b1e000 rw-p 0012f000 03:06 4243241 /lib/libc-2.4.so
45b1e000-45b21000 rw-p 45b1e000 00:00 0
45b23000-45b25000 r-xp 00000000 03:06 4243258 /lib/libdl-2.4.so
45b25000-45b26000 r--p 00001000 03:06 4243258 /lib/libdl-2.4.so
45b26000-45b27000 rw-p 00002000 03:06 4243258 /lib/libdl-2.4.so
45c6e000-45c80000 r-xp 00000000 03:06 1782100 /usr/lib/libz.so.1.2.3
45c80000-45c81000 rw-p 00011000 03:06 1782100 /usr/lib/libz.so.1.2.3
46497000-46499000 r-xp 00000000 03:06 4244426 /lib/libcom_err.so.2.1
46499000-4649a000 rw-p 00001000 03:06 4244426 /lib/libcom_err.so.2.1
4649c000-464ab000 r-xp 00000000 03:06 4244425 /lib/libresolv-2.4.so
464ab000-464ac000 r--p 0000e000 03:06 4244425 /lib/libresolv-2.4.so
464ac000-464ad000 rw-p 0000f000 03:06 4244425 /lib/libresolv-2.4.so
464ad000-464af000 rw-p 464ad000 00:00 0
464bb000-465da000 r-xp 00000000 03:06 4244427 /lib/libcrypto.so.0.9.8a
465da000-465ed000 rw-p 0011e000 03:06 4244427 /lib/libcrypto.so.0.9.8a
465ed000-465f0000 rw-p 465ed000 00:00 0
465f2000-465f5000 r-xp 00000000 03:06 1785207 /usr/lib/libkrb5support.so.0.0
465f5000-465f6000 rw-p 00002000 03:06 1785207 /usr/lib/libkrb5support.so.0.0
465f8000-4666b000 r-xp 00000000 03:06 1788263 /usr/lib/libkrb5.so.3.2
4666b000-4666d000 rw-p 00073000 03:06 1788263 /usr/lib/libkrb5.so.3.2
4666f000-46687000 r-xp 00000000 03:06 1788264 /usr/lib/libgssapi_krb5.so.2.2
46687000-46688000 rw-p 00017000 03:06 1788264 /usr/lib/libgssapi_krb5.so.2.2
4668a000-466ae000 r-xp 00000000 03:06 1788262 /usr/lib/libk5crypto.so.3.0
466ae000-466af000 rw-p 00024000 03:06 1788262 /usr/lib/libk5crypto.so.3.0
467e0000-46821000 r-xp 00000000 03:06 4244428 /lib/libssl.so.0.9.8a
46821000-46825000 rw-p 00040000 03:06 4244428 /lib/libssl.so.0.9.8a
84400000-84421000 rw-p 84400000 00:00 0
84421000-84500000 ---p 84421000 00:00 0
84518000-84523000 r-xp 00000000 03:06 4244801
/lib/libgcc_s-4.1.1-20060525.so.1
84523000-84524000 rw-p 0000a000 03:06 4244801
/lib/libgcc_s-4.1.1-20060525.so.1
84538000-85438000 rw-p 84538000 00:00 0
854bc000-856bc000 rw-p 854bc000 00:00 0
8577f000-86b7f000 rw-p 8577f000 00:00 0
86bc1000-86dc1000 rw-p 86bc1000 00:00 0
86e65000-88465000 rw-p 86e65000 00:00 0
884e8000-893e8000 rw-p 884e8000 00:00 0
893e9000-896e9000 rw-p 893e9000 00:00 0
896ea000-89bea000 rw-p 896ea000 00:00 0
89c2c000-89f2c000 rw-p 89c2c000 00:00 0
89f4d000-8a14d000 rw-p 89f4d000 00:00 0
8a16e000-8a76e000 rw-p 8a16e000 00:00 0
8a76f000-8af6f000 rw-p 8a76f000 00:00 0
8b056000-8b156000 rw-p 8b056000 00:00 0
8b177000-8b477000 rw-p 8b177000 00:00 0
8b478000-8b978000 rw-p 8b478000 00:00 0
8b979000-8ba79000 rw-p 8b979000 00:00 0
8ba9a000-8bc9a000 rw-p 8ba9a000 00:00 0
8bd1e000-8c11e000 rw-p 8bd1e000 00:00 0
8c11f000-8c41f000 rw-p 8c11f000 00:00 0
8c420000-8c520000 rw-p 8c420000 00:00 0
8c582000-8c682000 rw-p 8c582000 00:00 0
8c683000-8d383000 rw-p 8c683000 00:00 0
8d426000-8d5260Aborted
[jonsmirl@jonsmirl parsecvs]$
--
Jon Smirl
jonsmirl@gmail.com
^ permalink raw reply
* git-1.4.0 make problems
From: Michael Somos @ 2006-06-17 2:18 UTC (permalink / raw)
To: git
I downloaded the git-1.4.0.tar.bz2 recently and encountered a few problems.
1) The untar process creates a stray file "pax_global_header".
I am using GNU tar v1.13.22 and I get this message :
======================================================================
> tar jxf ~/u/source/git-1.4.0.tar.bz2
tar: pax_global_header: Unknown file type 'g', extracted as normal file
======================================================================
2) The make install process ignores the "prefix=..." argument. I have
to comment out one line for this :
======================================================================
> diff Makefile git-1.4.0/
94c94
< #prefix = $(HOME)
---
> prefix = $(HOME)
======================================================================
3) The make has a problem with "expat" include and libararies.
I have to add more lines to the Makefile to handle this like some
of the other include and libraries :
======================================================================
351,358c351
< endif
<
< ifndef NO_EXPAT
< ifdef EXPATDIR
< # This is still problematic -- gcc does not always want -R.
< ALL_CFLAGS += -I$(EXPATDIR)/include
< EXPAT_LIBEXPAT = -L$(EXPATDIR)/lib -R$(EXPATDIR)/lib -lexpat
< else
---
> ifndef NO_EXPAT
360c353
< endif
---
> endif
======================================================================
Other than that, it installed okay. I will have to read the docs and
use it to see how it goes otherwise.
^ permalink raw reply
* Re: Cygwin git and windows network shares
From: Christopher Faylor @ 2006-06-17 1:23 UTC (permalink / raw)
To: git, Juergen Ruehle
In-Reply-To: <17555.21858.292000.494454@lapjr.intranet.kiel.bmiag.de>
On Sat, Jun 17, 2006 at 03:05:38AM +0200, Juergen Ruehle wrote:
>Christopher Faylor writes:
> > I also meant to ask if there was an i is nonzero after the call to the
> > rename() above? If so, what was the errno? If not, it is a huge
> > problem if rename is reporting that it is able to rename a file but is
> > not actually doing it.
>
>After some testing the conclusion is that it's not lying, but only
>failing in interesting ways on my (and seemingly also Niklas') system:
>
> - rename on NTFS succeeds (and returns 0)
>
> - rename on FAT32 succeeds if target does not exist (and returns 0)
>
> rename on FAT32 fails if target exists with EACCESS
>
> (manual mv on commandline works)
>
> - rename on a network share always hangs for a while and then fails
> with EBUSY (even if target does not exist)
>
> (share served by XP, tested both NTFS and FAT32)
>
> (manual mv still works)
>
>Various combinations of server, ntsec, and smbntsec didn't seem to
>make a difference; /etc/{passwd,group} have been freshly created.
Thanks. I really appreciate the details. I've passed them on to the
last person to touch the rename code.
cgf
^ permalink raw reply
* Re: Cygwin git and windows network shares
From: Juergen Ruehle @ 2006-06-17 1:02 UTC (permalink / raw)
To: Niklas Frykholm, git
In-Reply-To: <17554.48926.852000.679014@lapjr.intranet.kiel.bmiag.de>
Juergen Ruehle writes:
> The following hack is a workaround, but is probably not safe.
Please just ignore it, it only helps on FAT32 partitions. Sorry for
the confusion.
jr
^ permalink raw reply
* Re: Porcelain specific metadata under .git?
From: Shawn Pearce @ 2006-06-17 0:43 UTC (permalink / raw)
To: Andreas Ericsson; +Cc: Jakub Narebski, git
In-Reply-To: <44900A2F.7050704@op5.se>
Andreas Ericsson <ae@op5.se> wrote:
> Jakub Narebski wrote:
> >Andreas Ericsson wrote:
> >
> >
> >>Shawn Pearce wrote:
> >>
> >>>I already assume/know that refs/heads and refs/tags are completely
> >>>off-limits as they are for user refs only.
> >>>
> >>>I also think the core GIT tools already assume that anything
> >>>directly under .git which is strictly a file and which is named
> >>>entirely with uppercase letters (aside from "HEAD") is strictly a
> >>>temporary/short-lived state type item (e.g. COMMIT_MSG) used by a
> >>>Porcelain.
> >>>
> >>>But is saying ".git/refs/eclipse-workspaces" is probably able to
> >>>be used for this purpose safe? :-)
> >>>
> >>
> >>.git/eclipse/whatever-you-like
> >>
> >>would probably be better. Heads can be stored directly under .git/refs
> >>too. Most likely, nothing will ever be stored under ./git/eclipse by
> >>either core git or the current (other) porcelains though.
> >
> >
> >I think if it is a ref, which one wants to be visible to git-fsck (and
> >git-prune), it should be under .git/refs.
> >
>
> Yes, but I understood him to mean "it's a tree-sha" instead of a
> branch/head thing, which would mean it doesn't fit the .git/refs
> definition of ref.
Sorry for the late response to this but I've been busy with real
work for the past few days and have not been able to get around to
fun work. :-)
Yes, its a tree-sha. There's no point in generating a commit for
this tree as it is serving a purpose similar to the index in core
GIT. It is a tree which represents the current directory state,
or something recently near to it anyway. Not enough information
exists to warrant building a commit however, nor is there really
any suitable parent for such a commit. Ditto with a tag.
I'm planning on periodically performing a write-tree of the current
working directory whenever Eclipse has notified the team provider of
tracked resources being modified, with the write-tree occuring no
more frequently then a user set threshold, or whenever the project
is closed or the workbench is shutdown.
I figure that if the user hasn't re-modified an already "known to
be changed" (due to different stat data) file in the last 5 minutes
and we haven't written a tree out (for any reason) in the last 15
minutes then maybe we should generate a tree right now as the user
is likely to commit one soon. Generating a tree in the background
on a low priority thread while the user is busy thinking will make
commits "go faster", especially if all I need to do is generate the
commit object itself as the tree is already made. :-)
It also just makes things easier, as I need the diff-tree code
anyway so making use of that to also track the working directory
just seems to make sense.
I want it under .git/refs as I don't really want my in progress
tree to go away due to a prune issued by the user. At least not
until I have a different tree stored there anyway.
So I'm going to store them under .git/refs/eclipse/some-path.
--
Shawn.
^ permalink raw reply
* Re: 2.6.17-rc6-mm2
From: Linus Torvalds @ 2006-06-17 0:22 UTC (permalink / raw)
To: H. Peter Anvin; +Cc: Goo GGooo, linux-kernel, git
In-Reply-To: <44931AFD.4070809@zytor.com>
On Fri, 16 Jun 2006, H. Peter Anvin wrote:
>
> Perhaps we shouldn't rely on stderr, and instead have a backchannel as part of
> the protocol itself.
Absolutely. I'm just irritated at myself for not going that way in the
first place, but when I originally wrote it, I had my eyes on other
issues, and the nice status updates got added later..
Linus
^ permalink raw reply
* Re: Collecting cvsps patches
From: Junio C Hamano @ 2006-06-16 23:22 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git
In-Reply-To: <e6v7vr$ila$1@sea.gmane.org>
Jakub Narebski <jnareb@gmail.com> writes:
> Yann Dirson wrote:
>
>> On Mon, Jun 12, 2006 at 11:27:37AM +0000, Anand Kumria wrote:
>>> On Mon, 12 Jun 2006 00:42:05 +0200, Yann Dirson wrote:
>>>
>>> > http://ydirson.free.fr/soft/git/cvsps.git
>>>
>>> I think you need to chmod +x hooks/post-update
>>>
>>> and then run 'git-update-server-info'.
>>
>> Unfortunately, I only have FTP access to push to this site, so I have
>> to run git-update-server-info myself, and occasionally forget. I'll
>> have to bring up-to-date my old cg-ftppush script some day :)
>
> Or extend git to allow push/pull also via ftp?
Patches welcome.
^ permalink raw reply
* Re: git-rebase nukes multiline comments
From: Junio C Hamano @ 2006-06-16 23:21 UTC (permalink / raw)
To: David Kowis; +Cc: git
In-Reply-To: <1150494975.DBA8A55@be12.dngr.org>
David Kowis <dkowis@shlrm.org> writes:
>>> commit c846bea8c61bec7cf0f7688c48abc42577b9ac7f
>>> Author: David Kowis <dkowis@kain.org>
>>> Date: Fri Jun 16 12:20:08 2006 -0500
>>>
>>> this is a multi
>>>
>>> line comment
>>> with three lines
>>>
>>>
>>> I'm using git 1.4.0. It added a blank line in there...
>>
>> Actually, this is an odd but intended behaviour ;-).
>
> Why is this behaviour intended? Just because I'm curoius. :)
You are not alone; sorry for the terse and confusing initial
response (I am just back from a long flight, finished
unpacking and quite tired).
At the lowest level of git that defines the object format, a
commit object consists of structural header in fixed format,
followed by any binary blob you feed git-commit-tree from the
standard input. I do not recall the details of the
implementation offhand, but we _might_ chomp at the first NUL
and if we did so I may say it is a bug -- commit-tree should not
care what "the log message" part consists of.
It is however quite a different story when it comes to the
higher level tools that come with git. The log summarize
facilities to let humans interact with the commits expect that a
commit log message consists of a one-line "summary", a blank
line, and then the body of the message. These "log listers" are:
. git log --pretty=oneline
. gitk
. gitweb
. gitview
. git shortlog
The "one-line summary plus body of the message" has a strong
correlation with how we communicate patches via e-mail. You do
not start a sentence on the "Subject: " header and continue on
to the body of the message, starting the body halfway of the
sentence. Instead, you try to make sure you write something
sensible by itself on the "Subject: " header to help the
recipient when later scanning for it among bunch of messages,
and you write a full paragraph that you can understand without
reading the subject line first. The following commands that
deal with e-mailed patches expect you to follow that convention:
. git am
. git applymbox
. git format-patch
Now, answer to your question why rebase bahaves that way are
because:
(1) I was lazy and reused the e-mailed patch machinery to
implement it, although rebase is something that _should_
work at a level closer to the core level than the human
level (e.g. it should be able to commute a patch that
affects binary content changes -- which it does).
(2) The user should be following the convention to make the
output from the log listers reasonable anyway, so the only
people who are harmed by reusing the e-mailed patch
machinery were people who did not finish a short-and-sweet
summary sentence on the first line, and it is better to
train users to do so anyway.
Having said that, I would say it is a bug. We should be able to
rebase, cherry-pick and/or rebase a patch with an arbitrary
binary garbage in the commit log message (I think the latter two
command do). But because of the reason (2) above, it is very
low on my priority to change it.
^ permalink raw reply
* Re: Lazy clone ideas
From: Elrond @ 2006-06-16 22:59 UTC (permalink / raw)
To: git
In-Reply-To: <e6e1jm$tes$1@sea.gmane.org>
Jakub Narebski <jnareb <at> gmail.com> writes:
>
> I've started new thread for lazy clone ideas,
> splitting from "Figured out how to get Mozilla into git"
[...]
I like the lazy clone idea, I think, I said that earlier.
> > This would probably require Eric Biederman's "direct access to blob"
> > patches, I guess, in order to be feasible.
Are those patches allowing the git: protocol to request a list of objects
directly? (Like my "remote git-cat-file" request?)
What's the status of the patch?
> And it would need place to store URI from where to doenload objects
> on-demand: perhaps 'remote alternatives'?
Yep, that would be the next step.
Having direct access to blobs would be needed first though.
Elrond
^ permalink raw reply
* Re: 2.6.17-rc6-mm2
From: Junio C Hamano @ 2006-06-16 22:52 UTC (permalink / raw)
To: H. Peter Anvin; +Cc: git, Linus Torvalds
In-Reply-To: <44931AFD.4070809@zytor.com>
"H. Peter Anvin" <hpa@zytor.com> writes:
> Perhaps we shouldn't rely on stderr, and instead have a backchannel as
> part of the protocol itself.
Concurred. This was one of the thing I was planning to do
anyway.
^ permalink raw reply
* Re: parsecvs and unnamed branches
From: Keith Packard @ 2006-06-16 22:51 UTC (permalink / raw)
To: Jon Smirl; +Cc: keithp, git
In-Reply-To: <9e4733910606161539t2485e3b3xa9f2852a4d2fc18f@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 695 bytes --]
On Fri, 2006-06-16 at 18:39 -0400, Jon Smirl wrote:
> There is a branch label for SeaMonkey_M8_BRANCH:1.36.0.4 that does
> seems to correspond to anything. Could that be the missing tag?
There's no particular reason to believe it should be; remember that
every file gets a 'magic branch' tag whenever you create a branch in the
repository, but only files with commits along that branch ever see the
revision tree information related to it, so you can expect to see many
branch tags without associated branch revisions in any particular ,v
file. Looking at the commits along 1.3.2, they don't seem particularily
related to the SeaMonkey_M8 branch.
--
keith.packard@intel.com
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: 2.6.17-rc6-mm2
From: bert hubert @ 2006-06-16 22:44 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Goo GGooo, linux-kernel, git
In-Reply-To: <Pine.LNX.4.64.0606152335130.5498@g5.osdl.org>
On Thu, Jun 15, 2006 at 11:39:35PM -0700, Linus Torvalds wrote:
> Except they only work over ssh, where we have a separate channel (for
> stderr), and with the native git protocol all that nice status work just
> gets flushed to /dev/null :(
It won't help passing firewalls one bit, but you might consider using SCTP
with multiple datastreams for this - theoretically :-)
Bert
--
http://www.PowerDNS.com Open source, database driven DNS Software
http://netherlabs.nl Open and Closed source services
^ permalink raw reply
* Re: parsecvs and unnamed branches
From: Jon Smirl @ 2006-06-16 22:39 UTC (permalink / raw)
To: Keith Packard; +Cc: git
In-Reply-To: <1150496362.6983.34.camel@neko.keithp.com>
On 6/16/06, Keith Packard <keithp@keithp.com> wrote:
> On Fri, 2006-06-16 at 17:44 -0400, Jon Smirl wrote:
> > I'm getting thousands of messages about unnamed branches and even
> > 'unnamed branch from master-UNNAMED-BRANCH'.
> >
> > How do you get unnamed branches into CVS, are these check-in errors or
> > are people actually working on unnamed branches? Or is parsecvs not
> > finding all of the branch info?
>
> branch names rely on a special 'branch tag' in the "symbols" section of
> the CVS file, but actual branches are flagged directly in the revision
> list. I don't know how it happens, but ,v files often end up with
> branches in the revision tree which haven't an associated tag. Go
> figure.
>
> For example, in the top level mozilla/Makefile.in,v file, you'll see a
> branch from version 1.36 with an initial commit 1.36.2.1. Using the
> wacky CVS branch revision numbering scheme, there should be an
> associated tag for version 1.36.0.2 (yes, the last two digits are
> flipped). But, none is present in the file.
There is a branch label for SeaMonkey_M8_BRANCH:1.36.0.4 that does
seems to correspond to anything. Could that be the missing tag?
>
> The reverse situation also occurs, with tags for branches that have no
> revisions in the file. This case makes sense -- until you make a change
> in a file along a branch, there will be no other record in the file of
> where the branch came from.
>
> I'd love to figure out a better mechanism for merging these nameless
> branches into the resulting repository, but I don't know how to
> correlate unnamed branches in one file with unnamed branches in other
> files.
>
> The current scheme of making up a fixed name and hoping that there
> aren't multiple unmamed branches from the same root is probably fraught
> with peril.
>
> --
> keith.packard@intel.com
>
>
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.3 (GNU/Linux)
>
> iD8DBQBEky5qQp8BWwlsTdMRAvI1AJ4nXKyzeupTDarXI+yM0zvuHaCoTQCdEBYC
> Kl7lEHIJgi5Tk24quc9FZyM=
> =FA7H
> -----END PGP SIGNATURE-----
>
>
>
--
Jon Smirl
jonsmirl@gmail.com
^ permalink raw reply
* Re: Cygwin git and windows network shares
From: Christopher Faylor @ 2006-06-16 22:30 UTC (permalink / raw)
To: Niklas Frykholm, git, Juergen Ruehle
In-Reply-To: <20060616221014.GA22181@trixie.casa.cgf.cx>
On Fri, Jun 16, 2006 at 06:10:14PM -0400, Christopher Faylor wrote:
>On Fri, Jun 16, 2006 at 04:24:30PM +0200, Juergen Ruehle wrote:
>>Niklas Frykholm writes:
>> > I'm trying to use cygwin git (compiled from the 1.4.0 tarball) to create
>> > repository on a windows network share, but I get an error message.
>> >
>> > $ cd //computer/git/project
>> > $ git init-db
>> > defaulting to local storage area
>> > Could not rename the lock file?
>>
>>cygwin's rename seems to be capable of overwriting an existing target
>>only on NTFS. The following hack is a workaround, but is probably not
>>safe.
>
>Actually, Cygwin's rename has a specific check to make sure that the
>file is deleted. It tries very hard to do things the right way but if
>your samba server doesn't return the correct error code then it is
>possible that it could be confused.
>diff --git a/lockfile.c b/lockfile.c
>index 2346e0e..5e78211 100644
>--- a/lockfile.c
>+++ b/lockfile.c
>@@ -48,6 +48,7 @@ int commit_lock_file(struct lock_file *l
> strcpy(result_file, lk->filename);
> i = strlen(result_file) - 5; /* .lock */
> result_file[i] = 0;
>+ unlink(result_file);
> i = rename(lk->filename, result_file);
> lk->filename[0] = 0;
> return i;
I also meant to ask if there was an i is nonzero after the call to the
rename() above? If so, what was the errno? If not, it is a huge
problem if rename is reporting that it is able to rename a file but is
not actually doing it.
cgf
(cygwin maintainer)
^ permalink raw reply
* Re: parsecvs and unnamed branches
From: Jon Smirl @ 2006-06-16 22:28 UTC (permalink / raw)
To: Keith Packard; +Cc: git
In-Reply-To: <1150496362.6983.34.camel@neko.keithp.com>
On 6/16/06, Keith Packard <keithp@keithp.com> wrote:
> On Fri, 2006-06-16 at 17:44 -0400, Jon Smirl wrote:
> > I'm getting thousands of messages about unnamed branches and even
> > 'unnamed branch from master-UNNAMED-BRANCH'.
> >
> > How do you get unnamed branches into CVS, are these check-in errors or
> > are people actually working on unnamed branches? Or is parsecvs not
> > finding all of the branch info?
>
> branch names rely on a special 'branch tag' in the "symbols" section of
> the CVS file, but actual branches are flagged directly in the revision
> list. I don't know how it happens, but ,v files often end up with
> branches in the revision tree which haven't an associated tag. Go
> figure.
>
> For example, in the top level mozilla/Makefile.in,v file, you'll see a
> branch from version 1.36 with an initial commit 1.36.2.1. Using the
> wacky CVS branch revision numbering scheme, there should be an
> associated tag for version 1.36.0.2 (yes, the last two digits are
> flipped). But, none is present in the file.
I was reading the CVS manual and it talks about magic branch number as
being the ones with zero in them. Doesn't go into a lot of detail.
Apparently they are autogenerated internally.
http://ximbiot.com/cvs/wiki/index.php?title=CVS--Concurrent_Versions_System_v1.12.12.1:_Branching_and_merging#Magic_branch_numbers
>
> The reverse situation also occurs, with tags for branches that have no
> revisions in the file. This case makes sense -- until you make a change
> in a file along a branch, there will be no other record in the file of
> where the branch came from.
>
> I'd love to figure out a better mechanism for merging these nameless
> branches into the resulting repository, but I don't know how to
> correlate unnamed branches in one file with unnamed branches in other
> files.
>
> The current scheme of making up a fixed name and hoping that there
> aren't multiple unmamed branches from the same root is probably fraught
> with peril.
>
> --
> keith.packard@intel.com
>
>
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.3 (GNU/Linux)
>
> iD8DBQBEky5qQp8BWwlsTdMRAvI1AJ4nXKyzeupTDarXI+yM0zvuHaCoTQCdEBYC
> Kl7lEHIJgi5Tk24quc9FZyM=
> =FA7H
> -----END PGP SIGNATURE-----
>
>
>
--
Jon Smirl
jonsmirl@gmail.com
^ permalink raw reply
* Re: parsecvs and unnamed branches
From: Keith Packard @ 2006-06-16 22:19 UTC (permalink / raw)
To: Jon Smirl; +Cc: keithp, git
In-Reply-To: <9e4733910606161444i2f996096sbd1f9b3f3ff3a32d@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 1615 bytes --]
On Fri, 2006-06-16 at 17:44 -0400, Jon Smirl wrote:
> I'm getting thousands of messages about unnamed branches and even
> 'unnamed branch from master-UNNAMED-BRANCH'.
>
> How do you get unnamed branches into CVS, are these check-in errors or
> are people actually working on unnamed branches? Or is parsecvs not
> finding all of the branch info?
branch names rely on a special 'branch tag' in the "symbols" section of
the CVS file, but actual branches are flagged directly in the revision
list. I don't know how it happens, but ,v files often end up with
branches in the revision tree which haven't an associated tag. Go
figure.
For example, in the top level mozilla/Makefile.in,v file, you'll see a
branch from version 1.36 with an initial commit 1.36.2.1. Using the
wacky CVS branch revision numbering scheme, there should be an
associated tag for version 1.36.0.2 (yes, the last two digits are
flipped). But, none is present in the file.
The reverse situation also occurs, with tags for branches that have no
revisions in the file. This case makes sense -- until you make a change
in a file along a branch, there will be no other record in the file of
where the branch came from.
I'd love to figure out a better mechanism for merging these nameless
branches into the resulting repository, but I don't know how to
correlate unnamed branches in one file with unnamed branches in other
files.
The current scheme of making up a fixed name and hoping that there
aren't multiple unmamed branches from the same root is probably fraught
with peril.
--
keith.packard@intel.com
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: Cygwin git and windows network shares
From: Christopher Faylor @ 2006-06-16 22:10 UTC (permalink / raw)
To: Niklas Frykholm, git, Juergen Ruehle
In-Reply-To: <17554.48926.852000.679014@lapjr.intranet.kiel.bmiag.de>
On Fri, Jun 16, 2006 at 04:24:30PM +0200, Juergen Ruehle wrote:
>Niklas Frykholm writes:
> > I'm trying to use cygwin git (compiled from the 1.4.0 tarball) to create
> > repository on a windows network share, but I get an error message.
> >
> > $ cd //computer/git/project
> > $ git init-db
> > defaulting to local storage area
> > Could not rename the lock file?
>
>cygwin's rename seems to be capable of overwriting an existing target
>only on NTFS. The following hack is a workaround, but is probably not
>safe.
Actually, Cygwin's rename has a specific check to make sure that the
file is deleted. It tries very hard to do things the right way but if
your samba server doesn't return the correct error code then it is
possible that it could be confused.
cgf
^ 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