* Re: [PATCH 2/2] Teach receive-pack how to keep pack files based on object count.
From: Nicolas Pitre @ 2006-10-31 19:56 UTC (permalink / raw)
To: Shawn Pearce; +Cc: Junio C Hamano, git
In-Reply-To: <20061031075704.GB7691@spearce.org>
On Tue, 31 Oct 2006, Shawn Pearce wrote:
> Since keeping a pushed pack or exploding it into loose objects
> should be a local repository decision this teaches receive-pack
> to decide if it should call unpack-objects or index-pack --stdin
> --fix-thin based on the setting of receive.unpackLimit and the
> number of objects contained in the received pack.
This works fine when used with my replacement patch for your [1/2] one.
> Currently this leaves every received pack as a kept pack. We really
> don't want that as received packs will tend to be small. Instead we
> want to delete the .keep file automatically after all refs have
> been updated. That is being left as room for future improvement.
I think this should be solved before rx packs are actually stored as
packs though. Otherwise people will end up with unwanted .keep files
left around. Maybe having a much bigger default for object number
treshold for the time being? (unless this patch is applied to "next" at
the same time as another one that actually deals with those .keep
files).
^ permalink raw reply
* Re: [PATCH 1/2] Allow pack header preprocessing before unpack-objects/index-pack.
From: Shawn Pearce @ 2006-10-31 20:08 UTC (permalink / raw)
To: Nicolas Pitre; +Cc: Junio C Hamano, git
In-Reply-To: <Pine.LNX.4.64.0610311400180.11384@xanadu.home>
Nicolas Pitre <nico@cam.org> wrote:
> On Tue, 31 Oct 2006, Shawn Pearce wrote:
>
> > However if the caller consumes the pack header from the input stream
> > then its no longer available for unpack-objects or index-pack --stdin,
> > both of which need the version and object count to process the stream.
> >
> > This change introduces --pack_header=ver,cnt as a command line option
> > that the caller can supply to indicate it has already consumed the
> > pack header and what version and object count were found in that
> > header. As this option is only meant for low level applications
> > such as receive-pack we are not documenting it at this time.
>
> This breaks index-pack, and unpack-objects with OBJ_OFS_DELTA, if
> --pack-header is used. The header is not accounted in the pack's offset
> and therefore every object's offset is wrong.
>
> What about this patch instead? This makes things much simpler IMHO.
Agreed. The idea you are using here came to me in my sleep last
night; I didn't have time to look at it until now however. You just
beat me to posting it. :-)
--
^ permalink raw reply
* Re: [PATCH 2/2] Teach receive-pack how to keep pack files based on object count.
From: Shawn Pearce @ 2006-10-31 20:11 UTC (permalink / raw)
To: Nicolas Pitre; +Cc: Junio C Hamano, git
In-Reply-To: <Pine.LNX.4.64.0610311447250.11384@xanadu.home>
Nicolas Pitre <nico@cam.org> wrote:
> On Tue, 31 Oct 2006, Shawn Pearce wrote:
>
> > Since keeping a pushed pack or exploding it into loose objects
> > should be a local repository decision this teaches receive-pack
> > to decide if it should call unpack-objects or index-pack --stdin
> > --fix-thin based on the setting of receive.unpackLimit and the
> > number of objects contained in the received pack.
>
> This works fine when used with my replacement patch for your [1/2] one.
>
> > Currently this leaves every received pack as a kept pack. We really
> > don't want that as received packs will tend to be small. Instead we
> > want to delete the .keep file automatically after all refs have
> > been updated. That is being left as room for future improvement.
>
> I think this should be solved before rx packs are actually stored as
> packs though. Otherwise people will end up with unwanted .keep files
> left around. Maybe having a much bigger default for object number
> treshold for the time being? (unless this patch is applied to "next" at
> the same time as another one that actually deals with those .keep
> files).
Its next on my list of things to do. Hopefully I'll be able to
implement it today.
I'm thinking of just brute forcing it: put enough identifying data
into the .keep file to make it unique, then go through every local
pack and look at their .keep file; if the content matches what
receive-pack asked index-pack to put there then remove it.
--
^ permalink raw reply
* Re: [PATCH 2/2] Teach receive-pack how to keep pack files based on object count.
From: Nicolas Pitre @ 2006-10-31 21:08 UTC (permalink / raw)
To: Shawn Pearce; +Cc: Junio C Hamano, git
In-Reply-To: <20061031201148.GD23671@spearce.org>
On Tue, 31 Oct 2006, Shawn Pearce wrote:
> Nicolas Pitre <nico@cam.org> wrote:
> > I think this should be solved before rx packs are actually stored as
> > packs though. Otherwise people will end up with unwanted .keep files
> > left around. Maybe having a much bigger default for object number
> > treshold for the time being? (unless this patch is applied to "next" at
> > the same time as another one that actually deals with those .keep
> > files).
>
> Its next on my list of things to do. Hopefully I'll be able to
> implement it today.
>
> I'm thinking of just brute forcing it: put enough identifying data
> into the .keep file to make it unique, then go through every local
> pack and look at their .keep file; if the content matches what
> receive-pack asked index-pack to put there then remove it.
Ouch. What about the patch below? It covers only the pull/fetch case,
but covering the push case shouldn't be that hard either (simply use a
pipe to read index-pack's stdout and capture the pack name).
I used "pack" <tab> <sha1> so it is easy to pick out of the list of refs
that usually comes over the stream in the fetch case (if I understood
that part right).
diff --git a/fetch-clone.c b/fetch-clone.c
index f629d8d..579307d 100644
--- a/fetch-clone.c
+++ b/fetch-clone.c
@@ -81,7 +81,18 @@ int receive_unpack_pack(int xd[2], const
int receive_keep_pack(int xd[2], const char *me, int quiet, int sideband)
{
- const char *argv[5] = { "index-pack", "--stdin", "--fix-thin",
- quiet ? NULL : "-v", NULL };
+ const char *argv[6];
+ char my_host[255], keep_arg[128 + 255];
+
+ if (gethostname(my_host, sizeof(my_host)))
+ strcpy(my_host, "localhost");
+ snprintf(keep_arg, sizeof(keep_arg), "--keep=fetch-pack %i on %s",
+ getpid(), my_host);
+ argv[0] = "index-pack";
+ argv[1] = "--stdin";
+ argv[2] = "--fix-thin";
+ argv[3] = keep_arg;
+ argv[4] = quiet ? NULL : "-v";
+ argv[5] = NULL;
return get_pack(xd, me, sideband, argv);
}
diff --git a/git-fetch.sh b/git-fetch.sh
index 539dff6..366014d 100755
--- a/git-fetch.sh
+++ b/git-fetch.sh
@@ -368,6 +368,7 @@ fetch_main () {
;; # we are already done.
*)
( : subshell because we muck with IFS
+ pack_lockfile=
IFS=" $LF"
(
git-fetch-pack $exec $keep "$remote" $rref || echo failed "$remote"
@@ -378,6 +379,10 @@ fetch_main () {
failed)
echo >&2 "Fetch failure: $remote"
exit 1 ;;
+ pack)
+ # special line coming from index-pack with the pack name
+ pack_lockfile="$GIT_OBJECT_DIRECTORY/pack/pack-$remote_name.keep"
+ continue ;;
esac
found=
single_force=
@@ -408,6 +413,7 @@ fetch_main () {
append_fetch_head "$sha1" "$remote" \
"$remote_name" "$remote_nick" "$local_name" "$not_for_merge"
done
+ [ "$pack_lockfile" ] && rm -f "$pack_lockfile"
) || exit ;;
esac
diff --git a/index-pack.c b/index-pack.c
index a3b55f9..c8f66da 100644
--- a/index-pack.c
+++ b/index-pack.c
@@ -767,18 +767,6 @@ static void final(const char *final_pack
if (err)
die("error while closing pack file: %s", strerror(errno));
chmod(curr_pack_name, 0444);
-
- /*
- * Let's just mimic git-unpack-objects here and write
- * the last part of the buffer to stdout.
- */
- while (input_len) {
- err = xwrite(1, input_buffer + input_offset, input_len);
- if (err <= 0)
- break;
- input_len -= err;
- input_offset += err;
- }
}
if (keep_msg) {
@@ -818,6 +806,27 @@ static void final(const char *final_pack
if (move_temp_to_file(curr_index_name, final_index_name))
die("cannot store index file");
}
+
+ if (!from_stdin) {
+ printf("%s\n", sha1_to_hex(sha1));
+ } else {
+ char buf[48];
+ int len = snprintf(buf, sizeof(buf), "pack\t%s\n",
+ sha1_to_hex(sha1));
+ xwrite(1, buf, len);
+
+ /*
+ * Let's just mimic git-unpack-objects here and write
+ * the last part of the input buffer to stdout.
+ */
+ while (input_len) {
+ err = xwrite(1, input_buffer + input_offset, input_len);
+ if (err <= 0)
+ break;
+ input_len -= err;
+ input_offset += err;
+ }
+ }
}
int main(int argc, char **argv)
@@ -934,8 +943,5 @@ int main(int argc, char **argv)
free(index_name_buf);
free(keep_name_buf);
- if (!from_stdin)
- printf("%s\n", sha1_to_hex(sha1));
-
return 0;
^ permalink raw reply related
* Re: [PATCH 2/2] Teach receive-pack how to keep pack files based on object count.
From: Shawn Pearce @ 2006-10-31 21:29 UTC (permalink / raw)
To: Nicolas Pitre; +Cc: Junio C Hamano, git
In-Reply-To: <Pine.LNX.4.64.0610311559150.11384@xanadu.home>
Nicolas Pitre <nico@cam.org> wrote:
> On Tue, 31 Oct 2006, Shawn Pearce wrote:
> > Nicolas Pitre <nico@cam.org> wrote:
> > > I think this should be solved before rx packs are actually stored as
> > > packs though. Otherwise people will end up with unwanted .keep files
> > > left around. Maybe having a much bigger default for object number
> > > treshold for the time being? (unless this patch is applied to "next" at
> > > the same time as another one that actually deals with those .keep
> > > files).
> >
> > Its next on my list of things to do. Hopefully I'll be able to
> > implement it today.
> >
> > I'm thinking of just brute forcing it: put enough identifying data
> > into the .keep file to make it unique, then go through every local
> > pack and look at their .keep file; if the content matches what
> > receive-pack asked index-pack to put there then remove it.
>
> Ouch. What about the patch below? It covers only the pull/fetch case,
> but covering the push case shouldn't be that hard either (simply use a
> pipe to read index-pack's stdout and capture the pack name).
>
> I used "pack" <tab> <sha1> so it is easy to pick out of the list of refs
> that usually comes over the stream in the fetch case (if I understood
> that part right).
I thought about using a pipe too, but in the case of receive-pack
it looked like index-pack was sending something back to the push
end of the connection. I didn't dig into the code enough to see
what that was and how to do the same in receive-pack itself. The
brute force approach is horrible but simple. ;-)
I'll look at your patch and what I need to do make a pipe work here,
because its clearly the better solution.
--
^ permalink raw reply
* [PATCH] make git-push a bit more verbose
From: Nicolas Pitre @ 2006-10-31 21:58 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
Currently git-push displays progress status for the local packing of
objects to send, but nothing once it starts to push it over the
connection. Having progress status in that later case is especially
nice when pushing lots of objects over a slow network link.
Signed-off-by: Nicolas Pitre <nico@cam.org>
---
diff --git a/builtin-pack-objects.c b/builtin-pack-objects.c
index 41e1e74..5f56a95 100644
--- a/builtin-pack-objects.c
+++ b/builtin-pack-objects.c
@@ -475,11 +475,12 @@ static void write_pack_file(void)
unsigned long offset;
struct pack_header hdr;
unsigned last_percent = 999;
- int do_progress = 0;
+ int do_progress;
- if (!base_name)
+ if (!base_name) {
f = sha1fd(1, "<stdout>");
- else {
+ do_progress = progress >> 1;
+ } else {
f = sha1create("%s-%s.%s", base_name,
sha1_to_hex(object_list_sha1), "pack");
do_progress = progress;
@@ -1524,6 +1525,10 @@ int cmd_pack_objects(int argc, const cha
progress = 1;
continue;
}
+ if (!strcmp("--all-progress", arg)) {
+ progress = 2;
+ continue;
+ }
if (!strcmp("--incremental", arg)) {
incremental = 1;
continue;
@@ -1641,7 +1646,7 @@ int cmd_pack_objects(int argc, const cha
else {
if (nr_result)
prepare_pack(window, depth);
- if (progress && pack_to_stdout) {
+ if (progress == 1 && pack_to_stdout) {
/* the other end usually displays progress itself */
struct itimerval v = {{0,},};
setitimer(ITIMER_REAL, &v, NULL);
diff --git a/send-pack.c b/send-pack.c
index fbd792c..4476666 100644
--- a/send-pack.c
+++ b/send-pack.c
@@ -29,6 +29,7 @@ static void exec_pack_objects(void)
{
static const char *args[] = {
"pack-objects",
+ "--all-progress",
"--stdout",
NULL
^ permalink raw reply related
* Re: [PATCH 2/2] Teach receive-pack how to keep pack files based on object count.
From: Nicolas Pitre @ 2006-10-31 22:06 UTC (permalink / raw)
To: Shawn Pearce; +Cc: Junio C Hamano, git
In-Reply-To: <20061031212942.GA24184@spearce.org>
On Tue, 31 Oct 2006, Shawn Pearce wrote:
> Nicolas Pitre <nico@cam.org> wrote:
> > I used "pack" <tab> <sha1> so it is easy to pick out of the list of refs
> > that usually comes over the stream in the fetch case (if I understood
> > that part right).
>
> I thought about using a pipe too, but in the case of receive-pack
> it looked like index-pack was sending something back to the push
> end of the connection. I didn't dig into the code enough to see
> what that was and how to do the same in receive-pack itself.
Well, I think it goes like this:
unpack-objects (and now index-pack --stdin) reads from stdin in 4kb
chunks. When the pack has been entirely parsed, it is possible that the
4kb chunk contains data from the stream past the actual pack data which
is why the remaining of the buffer is flushed out to stdout for the next
tool in the chain to pick up.
So if you use a pipe with index-pack to retrieve the pack name, you also
must consume all extra data from it and pass it on as well.
^ permalink raw reply
* Re: [PATCH] make git-push a bit more verbose
From: Jakub Narebski @ 2006-10-31 22:13 UTC (permalink / raw)
To: git
In-Reply-To: <Pine.LNX.4.64.0610311648220.11384@xanadu.home>
Nicolas Pitre wrote:
> Currently git-push displays progress status for the local packing of
> objects to send, but nothing once it starts to push it over the
> connection. Having progress status in that later case is especially
> nice when pushing lots of objects over a slow network link.
Thanks a lot!
--
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git
^ permalink raw reply
* Re: [PATCH 2/2] Teach receive-pack how to keep pack files based on object count.
From: Junio C Hamano @ 2006-10-31 22:27 UTC (permalink / raw)
To: Nicolas Pitre; +Cc: Shawn Pearce, git
In-Reply-To: <Pine.LNX.4.64.0610311559150.11384@xanadu.home>
Nicolas Pitre <nico@cam.org> writes:
> I used "pack" <tab> <sha1> so it is easy to pick out of the list of refs
> that usually comes over the stream in the fetch case (if I understood
> that part right).
This sounds like a very sane thing to do.
^ permalink raw reply
* Re: [PATCH/RFC (take 2)] gitweb: New improved patchset view
From: Edgar Toernig @ 2006-10-31 22:41 UTC (permalink / raw)
To: Jakub Narebski; +Cc: ltuikov, git
In-Reply-To: <200610302339.55128.jnareb@gmail.com>
Jakub Narebski wrote:
>
> Edgar Toernig wrote:
>
> > Btw, while the css version looks nice, Opera seems to have extreme
> > performance problems with gitweb's project page when there are a lot
> > of repositories. I.e. trying to view http://gitweb.freedesktop.org/
> > brings my system to its knees. Turning off style sheets cures it
> > but then diffs are unusable ...
>
> Strange. It's just a simple table. Could you and would you be able to
> debug it further (e.g. by bisecting CSS)?
It's the combination of tr.light/dark:hover and background-color.
Changing the foreground instead of the background color is fast.
Maybe it recalculates the complete table when the background of
a table cell changes.
I've reported the problem to Opera ...
^ permalink raw reply
* Re: [PATCH] git-svnimport: support for partial imports
From: Sasha Khapyorsky @ 2006-10-31 22:50 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Matthias Urlichs
In-Reply-To: <20061025225026.GA13031@sashak.voltaire.com>
On 00:50 Thu 26 Oct , Sasha Khapyorsky wrote:
> This adds support for partial svn imports. Let's assume that SVN
> repository layout looks like:
>
> $trunk/path/to/our/project
> $branches/path/to/our/project
> $tags/path/to/our/project
>
> , and we would like to import only tree under this specific
> 'path/to/our/project' and not whole tree under $trunk, $branches, etc..
> Now we will be be able to do it by using '-P path/to/our/project' option
> with git-svnimport.
>
> Signed-off-by: Sasha Khapyorsky <sashak@voltaire.com>
Any news about status of this patch?
^ permalink raw reply
* Re: Problem with git-push
From: Junio C Hamano @ 2006-10-31 23:39 UTC (permalink / raw)
To: Florent Thoumie; +Cc: git, Johannes Schindelin
In-Reply-To: <1162306098.41547.4.camel@mayday.esat.net>
Florent Thoumie <flz@xbsd.org> writes:
> I'm having some weird issues with git-push lately (1.4.1 on both ends):
Bear with some basic questions.
- "lately" means this used to work with earlier git on the same
machine with same configurations?
- the three runs seem to be pushing the same ref to the same
repository. Did you want to illustrate that it fails upon
writing out different objects and eventually succeeds?
- what operating system and what filesystem?
- are you working with a shared repository?
> : flz@cream:/tinderbox/portstrees/xorg-modular/ports; git push
> updating 'refs/heads/xorg'
> from 6d1e4fce0a22da799175ec8e168dc0767f1131ef
> to 496cbd4c75220c204aac4fd1ef9912e40e0314b2
> Generating pack...
> Done counting 16 objects.
> Result has 11 objects.
> Deltifying 11 objects.
> 100% (11/11) done
> Total 11, written 11 (delta 4), reused 0 (delta 0)
> Unpacking 11 objects
> unpack unpacker exited with error code
> ng refs/heads/xorg n/a (unpacker error)
> unable to write sha1 filename ./objects/2d: Is a directory
> fatal: failed to write object
This message comes from sha1_file.c::move_temp_to_file(). The
unpacker wrote the object whose name begins with 2d in a
temporary file .git/obj_XXXXXX by calling write_sha1_file(),
which in turn calls move_temp_to_file() to move it to its final
destination ".git/objects/2d/XXXXXX".
move_temp_to_file() first tries to make a hardlink in
.git/objects/2d/ directory, assuming that most of the time you
already have it. If it succeeds, then it runs unlink() on the
temporary file ".git/obj_XXXXXX". But taht is not what is
happening.
link_temp_to_file() function first tries to make a hardlink with
link(".git/obj_XXXXXX", ".git/objects/2d/XXXXXX"). This call
must be failing for you. Then it tries to create the leading
directory ".git/objects/2d", and does adjust_shared_perm and
when it fails it returns (but forgets to restore the slash it
removed earlier -- a patch to fix this is attached at the end).
This explains why the final filename is truncated at the last
slash, hence ./objects/2d in the error message. Also it
explains why repeated tries would succeed; the first run creates
.git/objects/2d/ directory so the second run will try hardlink
and will succeed.
So the next thing to see is why adjust_shared_perm() is failing
for you.
Oops.
I think this function is broken at the concept level. This is
to work around people's broken umask (when you are working with
other people, your umask should not be stronger than 007) and
tries to flip group writability bit on.
First of all, if the necessary bits are already on, it is not
necessary to run chmod(), but more importantly, if the directory
in question was created by somebody else, I do not think this
chmod() would succeed even if you are in the same group as the
owner (i.e. previous creator) of the directory.
[jc: I am CC'ing Johannes to blame him on commit 457f06d6;
git-pickaxe is turning out to be quite handy ;-)
git pickaxe -C -f L246,277 v1.4.1 -- path.c
]
A quick workaround until we sort this out would be:
- make sure all your developers have umask suitable for group
work (i.e. second octal-digit from the right should be zero
to give group members the same rights as you do).
- run "chmod g+w .git/objects/??" in the shared repository.
-- >8 --
diff --git a/sha1_file.c b/sha1_file.c
index e89d24c..5707069 100644
--- a/sha1_file.c
+++ b/sha1_file.c
@@ -1400,8 +1400,10 @@ static int link_temp_to_file(const char
if (dir) {
*dir = 0;
mkdir(filename, 0777);
- if (adjust_shared_perm(filename))
+ if (adjust_shared_perm(filename)) {
+ *dir = '/';
return -2;
+ }
*dir = '/';
if (!link(tmpfile, filename))
return 0;
^ permalink raw reply related
* Re: [PATCH] git-svnimport: support for partial imports
From: Junio C Hamano @ 2006-10-31 23:48 UTC (permalink / raw)
To: Sasha Khapyorsky; +Cc: git, Matthias Urlichs
In-Reply-To: <20061031225054.GA20211@sashak.voltaire.com>
Sasha Khapyorsky <sashak@voltaire.com> writes:
> On 00:50 Thu 26 Oct , Sasha Khapyorsky wrote:
>> This adds support for partial svn imports. Let's assume that SVN
>> repository layout looks like:
>>
>> $trunk/path/to/our/project
>> $branches/path/to/our/project
>> $tags/path/to/our/project
>>
>> , and we would like to import only tree under this specific
>> 'path/to/our/project' and not whole tree under $trunk, $branches, etc..
>> Now we will be be able to do it by using '-P path/to/our/project' option
>> with git-svnimport.
>>
>> Signed-off-by: Sasha Khapyorsky <sashak@voltaire.com>
>
> Any news about status of this patch?
Somebody mentioned this duplicates something that can be already
done, and I saw you refuted that. At that point I thought then
it would be Ok to add, and then I forgot about it. Sorry.
Will apply unless somebody objects immediately ;-).
^ permalink raw reply
* Re: [PATCH 1/2] Allow pack header preprocessing before unpack-objects/index-pack.
From: Junio C Hamano @ 2006-10-31 23:51 UTC (permalink / raw)
To: Shawn Pearce; +Cc: git
In-Reply-To: <20061031200841.GC23671@spearce.org>
Shawn Pearce <spearce@spearce.org> writes:
> Nicolas Pitre <nico@cam.org> wrote:
>> On Tue, 31 Oct 2006, Shawn Pearce wrote:
>>
>> > However if the caller consumes the pack header from the input stream
>> > then its no longer available for unpack-objects or index-pack --stdin,
>> > both of which need the version and object count to process the stream.
>> >
>> > This change introduces --pack_header=ver,cnt as a command line option
>> > that the caller can supply to indicate it has already consumed the
>> > pack header and what version and object count were found in that
>> > header. As this option is only meant for low level applications
>> > such as receive-pack we are not documenting it at this time.
>>
>> This breaks index-pack, and unpack-objects with OBJ_OFS_DELTA, if
>> --pack-header is used. The header is not accounted in the pack's offset
>> and therefore every object's offset is wrong.
>>
>> What about this patch instead? This makes things much simpler IMHO.
>
> Agreed. The idea you are using here came to me in my sleep last
> night; I didn't have time to look at it until now however. You just
> beat me to posting it. :-)
Will replace your [1/2] still in "pu".
^ permalink raw reply
* Re: [PATCH] make git-push a bit more verbose
From: Junio C Hamano @ 2006-10-31 23:52 UTC (permalink / raw)
To: Nicolas Pitre; +Cc: git
In-Reply-To: <Pine.LNX.4.64.0610311648220.11384@xanadu.home>
Thanks. Will apply.
^ permalink raw reply
* Re: [PATCH] make git-push a bit more verbose
From: Petr Baudis @ 2006-11-01 0:08 UTC (permalink / raw)
To: Nicolas Pitre; +Cc: Junio C Hamano, git
In-Reply-To: <Pine.LNX.4.64.0610311648220.11384@xanadu.home>
Dear diary, on Tue, Oct 31, 2006 at 10:58:32PM CET, I got a letter
where Nicolas Pitre <nico@cam.org> said that...
> Currently git-push displays progress status for the local packing of
> objects to send, but nothing once it starts to push it over the
> connection. Having progress status in that later case is especially
> nice when pushing lots of objects over a slow network link.
>
> Signed-off-by: Nicolas Pitre <nico@cam.org>
Yet Another Undocumented Feature? :-(
--
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
#!/bin/perl -sp0777i<X+d*lMLa^*lN%0]dsXx++lMlN/dsM0<j]dsj
$/=unpack('H*',$_);$_=`echo 16dio\U$k"SK$/SM$n\EsN0p[lN*1
^ permalink raw reply
* Re: git fetch with multiple remotes failing?
From: Petr Baudis @ 2006-11-01 0:12 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Michael S. Tsirkin, Git Mailing List
In-Reply-To: <Pine.LNX.4.64.0610310819170.25218@g5.osdl.org>
Dear diary, on Tue, Oct 31, 2006 at 05:32:06PM CET, I got a letter
where Linus Torvalds <torvalds@osdl.org> said that...
> On Tue, 31 Oct 2006, Michael S. Tsirkin wrote:
> > $ cat .git/remotes/origin
> > URL: git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git
> > Pull: +refs/heads/master:refs/heads/linus_master
> > $ cat .git/remotes/jejb-scsi-misc-2.6
> > URL: git://git.kernel.org/pub/scm/linux/kernel/git/jejb/scsi-misc-2.6.git
> > Pull: +refs/heads/master:refs/heads/jejb-scsi-misc-2.6
> > $ git fetch -f origin jejb-scsi-misc-2.6
> > error: no such remote ref refs/heads/jejb-scsi-misc-2.6
> > Fetch failure:
> > git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git
> >
> > Looks I must give remotes one by one?
>
> Yes. A single "fetch" will only ever connect to a single repository. If
> you want to fetch from multiple repositories, you have to do multiple
> connections, and thus multiple "fetch"es.
Note that I made a (hackish) patch for fetching from multiple
repositories in one connection (look for "Allow fetching from multiple
repositories at once"). It's currently in limbo since IIRC Junio wanted
some benchmarks, I don't have time to do them and the group I did this
for (the xorg people) has shown zero interest in testing the patch
either.
--
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
#!/bin/perl -sp0777i<X+d*lMLa^*lN%0]dsXx++lMlN/dsM0<j]dsj
$/=unpack('H*',$_);$_=`echo 16dio\U$k"SK$/SM$n\EsN0p[lN*1
^ permalink raw reply
* Re: [PATCH 4/n] gitweb: Secure against commit-ish/tree-ish with the same name as path
From: Junio C Hamano @ 2006-11-01 0:24 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git
In-Reply-To: <200610311753.20711.jnareb@gmail.com>
Jakub Narebski <jnareb@gmail.com> writes:
> Please remove this chunk from patch!. It makes gitweb "tree" view
> empty. I have forgot that git-ls-tree _requires_ <tree-ish> so there
> is no way to mistake pathspec with <tree-ish>.
To be honest, I dislike these */n series where the the end is
unknown. It just confuses me what's still surviving, what's
already shot down, and what's being rerolled.
Let's step back a bit and see if we share the same view as to
the status of each one:
[PATCH/RFC 1/n] gitweb: Better git-unquoting and gitweb-quoting of p...
Marked preliminary, perhaps need some discussion and rerolling
but I haven't looked at it.
[PATCH 2/n] gitweb: Use '&iquot;' instead of '?' in esc_path
Discussed; we agreed that showing byte values in different
colors is preferable. Waiting for re-roll.
[PATCH 3/n] gitweb: Use 's' regexp modifier to secure against filena...
I looked at it although haven't said anything yet. Probably a
safe and good change but I wonder how LF at the end of the line
matches /...(.+)$/s pattern; iow, if we do not use -z does it
still do the right thing? Otherwise I suspect you would perhaps
need to chomp?
[PATCH 4/n] gitweb: Secure against commit-ish/tree-ish with the same...
Good fix and even improves readability; will apply after
dropping -- from ls-tree args.
[PATCH 5/n] [take 3] gitweb: New improved patchset view
[PATCH 6/n] gitweb: Remove redundant "blob" links from git_difftree_...
[PATCH 7/n] gitweb: Output also empty patches in "commitdiff" view
[PATCH 8/n] gitweb: Fix two issues with quoted filenames in git_patc...
Haven't looked at them and I do not think people have had enough
time to comment on them yet.
^ permalink raw reply
* Re: [PATCH] Introduce git-mirror, a tool for exactly mirroring another repository.
From: Junio C Hamano @ 2006-11-01 0:32 UTC (permalink / raw)
To: Sergey Vlasov; +Cc: git, Petr Baudis, Shawn Pearce
In-Reply-To: <20061031174225.3c7c1e77.vsu@altlinux.ru>
Sergey Vlasov <vsu@altlinux.ru> writes:
> What is the current state of packed-refs implementation?
Scheduled for "master" probably tomorrow, with some disclaimers.
> BTW, I was thinking about the possibility to save removed refs under,
> e.g., refs/old/`date -I`/; maybe even non-fast-forward refs could be
> saved there - this will ensure that no object will ever disappear from
> the mirror, no matter what is done on the master side. Obviously, in
> this case remote refs like refs/old/* should be filtered.
I do not think that belongs to git-mirror. It might be better to
have that option in update-ref machinery so that you would even
be protected from a `git branch -d` ran by mistake.
^ permalink raw reply
* Re: [PATCH 4/n] gitweb: Secure against commit-ish/tree-ish with the same name as path
From: Jakub Narebski @ 2006-11-01 0:40 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vejsoovxu.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano wrote:
>
> To be honest, I dislike these */n series where the the end is
> unknown. It just confuses me what's still surviving, what's
> already shot down, and what's being rerolled.
Well, it looks like this patch series is closing to final patch.
The "New improved patchset view" is done.
> Let's step back a bit and see if we share the same view as to
> the status of each one:
>
> [PATCH/RFC 1/n] gitweb: Better git-unquoting and gitweb-quoting of p...
>
> Marked preliminary, perhaps need some discussion and rerolling
> but I haven't looked at it.
I'm not sure if without this patch (well, the unquote part) gitweb
can work with filenames which git quotes using escape sequences,
like ", \, LF, TAB. Former version didn't unquote fully, and it
passed partially unquoted filename to git.
> [PATCH 2/n] gitweb: Use '&iquot;' instead of '?' in esc_path
>
> Discussed; we agreed that showing byte values in different
> colors is preferable. Waiting for re-roll.
The problem with using text color or background color is that
the filenames tends to be shown with different color and background
color: "tree" view, parts of difftree, parts of diff header, etc.
Perhaps text-decoration: overline;? Just kidding...
> [PATCH 3/n] gitweb: Use 's' regexp modifier to secure against filena...
>
> I looked at it although haven't said anything yet. Probably a
> safe and good change but I wonder how LF at the end of the line
> matches /...(.+)$/s pattern; iow, if we do not use -z does it
> still do the right thing? Otherwise I suspect you would perhaps
> need to chomp?
We always pass chomped lines. First chunk is unnecessary (we care only
for type), without second "tree" view look strange for files with
embedded newline in filename.
> [PATCH 4/n] gitweb: Secure against commit-ish/tree-ish with the same...
>
> Good fix and even improves readability; will apply after
> dropping -- from ls-tree args.
As I said, noticed while testing gitweb with strange filenames
in 'gitweb/test' branch.
> [PATCH 5/n] [take 3] gitweb: New improved patchset view
> [PATCH 6/n] gitweb: Remove redundant "blob" links from git_difftree_...
> [PATCH 7/n] gitweb: Output also empty patches in "commitdiff" view
> [PATCH 8/n] gitweb: Fix two issues with quoted filenames in git_patc...
>
> Haven't looked at them and I do not think people have had enough
> time to comment on them yet.
Well, patch 5 and 8 could be collapsed.
--
Jakub Narebski
^ permalink raw reply
* Re: [PATCH] git-svnimport: support for partial imports
From: Sasha Khapyorsky @ 2006-11-01 0:51 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Matthias Urlichs
In-Reply-To: <7v1wooqc6j.fsf@assigned-by-dhcp.cox.net>
On 15:48 Tue 31 Oct , Junio C Hamano wrote:
> Sasha Khapyorsky <sashak@voltaire.com> writes:
>
> > On 00:50 Thu 26 Oct , Sasha Khapyorsky wrote:
> >> This adds support for partial svn imports. Let's assume that SVN
> >> repository layout looks like:
> >>
> >> $trunk/path/to/our/project
> >> $branches/path/to/our/project
> >> $tags/path/to/our/project
> >>
> >> , and we would like to import only tree under this specific
> >> 'path/to/our/project' and not whole tree under $trunk, $branches, etc..
> >> Now we will be be able to do it by using '-P path/to/our/project' option
> >> with git-svnimport.
> >>
> >> Signed-off-by: Sasha Khapyorsky <sashak@voltaire.com>
> >
> > Any news about status of this patch?
>
> Somebody mentioned this duplicates something that can be already
> done, and I saw you refuted that. At that point I thought then
> it would be Ok to add, and then I forgot about it. Sorry.
No problem.
^ permalink raw reply
* Re: [PATCH] Introduce git-mirror, a tool for exactly mirroring another repository.
From: Jakub Narebski @ 2006-11-01 1:08 UTC (permalink / raw)
To: git
In-Reply-To: <7vac3covlf.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano wrote:
> Sergey Vlasov <vsu@altlinux.ru> writes:
>
>> BTW, I was thinking about the possibility to save removed refs under,
>> e.g., refs/old/`date -I`/; maybe even non-fast-forward refs could be
>> saved there - this will ensure that no object will ever disappear from
>> the mirror, no matter what is done on the master side. Obviously, in
>> this case remote refs like refs/old/* should be filtered.
>
> I do not think that belongs to git-mirror. It might be better to
> have that option in update-ref machinery so that you would even
> be protected from a `git branch -d` ran by mistake.
Perhaps just don't remove log when branch is deleted. I tend for example
to be careful when reordering commits on a branch, and use git branch -f
instead of deleting and recreating branch to not lose reflog.
--
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git
^ permalink raw reply
* Re: how to ignore merge conflicts?
From: Len Brown @ 2006-11-01 7:51 UTC (permalink / raw)
To: Linus Torvalds; +Cc: git
In-Reply-To: <Pine.LNX.4.64.0610301223021.25218@g5.osdl.org>
On Monday 30 October 2006 15:29, Linus Torvalds wrote:
>
> On Mon, 30 Oct 2006, Len Brown wrote:
> >
> > Sometimes when a multiple-file merge give conflicts, I don't want to edit
> > one of the resulting <<<<<=====>>>>> files.
> > Instead, I just want to choose the version of that particular file that
> > existed in one of the two merged branches and commit that along with
> > the rest of the merge.
> >
> > How to do this?
>
> Well, if you promise not to do what has happened several times before in
> people who maintained their own CVS trees, for example (which is to just
> ignore all merge problems, and force _their_ version, even though the
> reason for the merge problem was that somebody else had fixed a bug, that
> was now unfixed by the "merge"), here's the trivial way to do it:
>
> git checkout HEAD the/file/you/wanted.c
>
> (or, if you want to take it from the source you are merging _from_, just
> use MERGE_HEAD instead of HEAD).
>
> And you're done.
Thank you. This worked, and it is simple enough that I can actually remember it:-)
No, obviously I wouldn't intentionally blow away a bug fix.
I believe this scenario is actually quite common, and this action justified.
Indeed, many years ago Larry McVoy ("He That Must Not Be Named" on this list?:-)
added commands to the nse-lite merge dialogue at my request to handle exactly this case.
Tonight, for example, I merged a big cleanup patch that removed a bunch of
unnecessary casts from many files, with a branch that includes a complete
re-write of one of those files.
So here I chose the re-written version of the file and discarded the cleaned up version
that now no longer makes any sense -- while keeping the rest of the cleanup patch
that does still make sense. Yes, key here is knowing that there was not a bugfix
bundled along in the branch with the cleanup that got thrown away.
thanks,
-Len
ps. Maybe residing at the "top of the tree" as you do, other folks do a lot of
^ permalink raw reply
* Re: Restore a single file in the index back to HEAD
From: Nguyen Thai Ngoc Duy @ 2006-11-01 7:58 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Andreas Ericsson, git
In-Reply-To: <7vac3igjpd.fsf@assigned-by-dhcp.cox.net>
On 10/27/06, Junio C Hamano <junkio@cox.net> wrote:
> On the other hand, I designed --index-info to be compatible with
> ls-tree output (it is not an accident, it was designed). In
>
> git ls-tree HEAD frotz | git update-index --index-info
>
> "frotz" part does not have to be the exact path but can be a
> directory name. It means "revert everything in this directory".
>
> This is quite heavy-handed and you would probably want to run
> update-index --refresh afterwards.
I would prefer "git update-index --reset frotz" or "git checkout
--index HEAD frotz". git ls-tree|git update-index is too cryptic for
me and too long for my fingers.
--
^ permalink raw reply
* Re: Restore a single file in the index back to HEAD
From: Junio C Hamano @ 2006-11-01 8:07 UTC (permalink / raw)
To: Nguyen Thai Ngoc Duy; +Cc: Andreas Ericsson, git
In-Reply-To: <fcaeb9bf0610312358g1176e4d8q8962b08c2e8ff2c6@mail.gmail.com>
"Nguyen Thai Ngoc Duy" <pclouds@gmail.com> writes:
> On 10/27/06, Junio C Hamano <junkio@cox.net> wrote:
>> On the other hand, I designed --index-info to be compatible with
>> ls-tree output (it is not an accident, it was designed). In
>>
>> git ls-tree HEAD frotz | git update-index --index-info
>>
>> "frotz" part does not have to be the exact path but can be a
>> directory name. It means "revert everything in this directory".
>>
>> This is quite heavy-handed and you would probably want to run
>> update-index --refresh afterwards.
>
> I would prefer "git update-index --reset frotz" or "git checkout
> --index HEAD frotz". git ls-tree|git update-index is too cryptic for
> me and too long for my fingers.
Then perhaps you can use "git checkout HEAD frotz", which is the
simplest?
^ 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