* Re: perhaps time to remove git_blame from gitweb, and git-annotate?
From: Martin Langhoff (CatalystIT) @ 2006-10-07 5:37 UTC (permalink / raw)
To: ltuikov
Cc: Johannes Schindelin, Junio C Hamano, git, Petr Baudis,
Jakub Narebski, Ryan Anderson, Martyn Smith, Fredrik Kuivinen,
Linus Torvalds
In-Reply-To: <20061006175234.41182.qmail@web31810.mail.mud.yahoo.com>
Luben Tuikov wrote:
>>>Do people have reason to favor annotate over blame? To keep
>>>existing people's scripts working I think we should add a small
>>>amount of code to blame.c to default to compatibility mode when
>>>the command is called as git-annotate at least for a while, but
>>>other than that I do not see much issue against scheduling for
>>>annotate's removal.
>>
>>+1. Although I would leave git-annotate in git, if only to meet
>>expectations of new git users.
>
>
> I agree with Junio's assessment of the situation.
+1 -- I need to test that the switch to git-blame for git-cvsserver
works well for Eclipse end users. Will try and fit that next week
somehow ;-)
martin
--
-----------------------------------------------------------------------
Martin @ Catalyst .Net .NZ Ltd, PO Box 11-053, Manners St, Wellington
WEB: http://catalyst.net.nz/ PHYS: Level 2, 150-154 Willis St
OFFICE: +64(4)916-7224 MOB: +64(21)364-017
Make things as simple as possible, but no simpler - Einstein
-----------------------------------------------------------------------
^ permalink raw reply
* Re: gitweb: using quotemeta
From: Junio C Hamano @ 2006-10-07 5:08 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git
In-Reply-To: <200610061438.50965.jnareb@gmail.com>
Jakub Narebski <jnareb@gmail.com> writes:
> I'd rather add (and use) separate subroutine for quoting/escaping
> values in HTTP headers, or to be more exact for the filename part
> of HTTP header "Content-Disposition:". This way if we decide to
> not replace all characters outside US-ASCII in suggested filename
> to save with '?', but only qoublequote '"' and linefeed '\n' characters,
> or even implement RFC 2047 to do the encoding (of course if browsers
> can read it), we could do this in one place.
Sounds sane. quote_filename?
^ permalink raw reply
* Re: git-send-email w/ headers
From: Len Brown @ 2006-10-07 4:40 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7v1wpm2cxd.fsf@assigned-by-dhcp.cox.net>
On Friday 06 October 2006 02:09, Junio C Hamano wrote:
> Len Brown <len.brown@intel.com> writes:
>
> > But the Signed-off-by: line from the original message body has
> > now been swallowed up into the message header -- so my mailer
> > doesn't display it.
>
> Sorry, what I sent out has worse breakage than not having your
> custom header. It would eat the first paragraph of your message
> X-<.
>
> A replacement patch is attached.
Latest patch seems to be doing the right thing (included below).
However, I've discovered another rough edge.
git-send-email offers to --compose an initial message, but it doesn't
pick up the .git/config header like git-format-patch does:
$ cat .git/config
[format]
headers = Reply-To: Len Brown <lenb@kernel.org>\nOrganization: Intel Open Source Technology Center\n
thanks,
-Len
Return-Path: <len.brown@intel.com>
Received: from sccrmhc13.comcast.net (sccrmhc13.comcast.net [63.240.77.83])
by hera.kernel.org (8.13.7/8.13.7) with ESMTP id k974Of6m010205
for <lenb@kernel.org>; Sat, 7 Oct 2006 04:25:09 GMT
Received: from localhost.localdomain (c-65-96-213-102.hsd1.ma.comcast.net[65.96.213.102])
by comcast.net (sccrmhc13) with SMTP
id <2006100704243601300452mke>; Sat, 7 Oct 2006 04:24:36 +0000
From: Len Brown <len.brown@intel.com>
To: lenb@kernel.org
Cc: Len Brown <len.brown@intel.com>
Subject: [PATCH 1/14] test: create junk
Date: Sat, 7 Oct 2006 00:27:35 -0400
Message-Id: <11601952702774-git-send-email-len.brown@intel.com>
X-Mailer: git-send-email 1.4.2.3.gabd6-dirty
In-Reply-To: <11601952681813-git-send-email-len.brown@intel.com>
References: <11601952681813-git-send-email-len.brown@intel.com>
Message-Id: <7488d8f01c21a6411ad99c1d16e95ecd6e1542a6.1160195250.git.len.brown@intel.com>
Date: Wed, 4 Oct 2006 01:11:12 -0400
Reply-To: Len Brown <lenb@kernel.org>
Organization: Intel Open Source Technology Center
X-Virus-Scanned: ClamAV 0.88.4/2002/Fri Oct 6 22:58:03 2006 on hera.kernel.org
X-Virus-Status: Clean
X-Spam-Status: No, score=-1.0 required=5.0 tests=AWL,BAYES_00,
FORGED_RCVD_HELO,INVALID_DATE autolearn=no version=3.1.3
X-Spam-Checker-Version: SpamAssassin 3.1.3 (2006-06-01) on hera.kernel.org
Status: R
X-Status: NGC
X-KMail-EncryptionState:
X-KMail-SignatureState:
X-KMail-MDN-Sent:
Signed-off-by: Len Brown <len.brown@intel.com>
---
junk | 1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/junk b/junk
new file mode 100644
index 0000000..9ecf3cf
--- /dev/null
+++ b/junk
@@ -0,0 +1 @@
+this
--
1.4.2.3.gabd6-dirty
^ permalink raw reply related
* [RFC PATCH] Add WEBDAV timeout to http-fetch.
From: Sean @ 2006-10-07 2:04 UTC (permalink / raw)
To: Sean; +Cc: Panagiotis Issaris, git
In-Reply-To: <BAYC1-PASMTP08A34A8FB0703E4D2ABAF9AE130@CEZ.ICE>
If a server is having problems delivering the Git repo over WEBDAV,
timeout after two minutes so that a regular http transfer can
be tried.
---
http-fetch.c | 1 +
1 files changed, 1 insertions(+), 0 deletions(-)
Not sure if this is the correct fix, but it should improve the situation
for cloning and fetching from servers like Takis's. When connecting to
his server WEBDAV doesn't respond after the initial connection. Nothing
proceeds until the OS connection times out many minutes later.
This patch sets the CURL timeout to two minutes so that things proceed
sooner. Even with this patch it takes two extra minutes of "dead time"
to complete all operations; obivously this still sucks.
However, I don't know if the two minute timeout is long enough for
all cases with a server where WEBDAV is functioning properly.
Hopefully someone who knows more about Curl can comment and perhaps
offer another solution.
Maybe the real solution is just to figure out and fix whatever is
going on with the WEBDAV server and forget this patch.
Sean
diff --git a/http-fetch.c b/http-fetch.c
index bc74f30..046245a 100644
--- a/http-fetch.c
+++ b/http-fetch.c
@@ -861,6 +861,7 @@ static int remote_ls(struct alt_base *re
curl_easy_setopt(slot->curl, CURLOPT_UPLOAD, 1);
curl_easy_setopt(slot->curl, CURLOPT_CUSTOMREQUEST, DAV_PROPFIND);
curl_easy_setopt(slot->curl, CURLOPT_HTTPHEADER, dav_headers);
+ curl_easy_setopt(slot->curl, CURLOPT_TIMEOUT, 120);
if (start_active_slot(slot)) {
run_active_slot(slot);
--
1.4.2.3.gabd697
^ permalink raw reply related
* Re: Problem cloning packed-and-pruned http repository
From: Sean @ 2006-10-06 23:49 UTC (permalink / raw)
To: Panagiotis Issaris; +Cc: git
In-Reply-To: <20061006220542.GA5890@lumumba.uhasselt.be>
On Sat, 7 Oct 2006 00:05:42 +0200
takis@lumumba.uhasselt.be (Panagiotis Issaris) wrote:
> Apparently, it does work :-/ After a _long_ time I noticed that the
> repository indeed got cloned... I am not sure if this is normal behavior
> or not, it seemed to take a _really_ long. I would have thought
> downloading 14MiB should not take a long time on my ADSL line.
It's not normal. There's something odd going on. I can clone your
repo with wget in about two minutes, while Git still hadn't downloaded
anything after 12 minutes when I killed it.
Poked around a bit, and found that if I comment out these lines from
http-fetch.c:
#ifndef NO_EXPAT
if (remote_ls(repo, "objects/pack/", PROCESS_FILES,
process_ls_pack, NULL) == 0)
return 0;
#endif
Then everything downloads nice and fast. Does anyone have a guess
why that would be?
Sean
^ permalink raw reply
* [PATCH 2/2] git-archive --format=zip: add symlink support
From: Rene Scharfe @ 2006-10-06 23:47 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Git Mailing List, Franck Bui-Huu
Add symlink support to ZIP file creation, and a few tests.
This implementation sets the "version made by" field
(creator_version) to Unix for symlinks, only; regular files and
directories are still marked as originating from FAT/VFAT/NTFS.
Also set "external file attributes" (attr2) to 0 for regular
files and 16 for directories (FAT attribute), and to the file
mode for symlinks.
We could always set the creator_version to Unix and include the
mode, but then Info-ZIP unzip would set the mode of the extracted
files to *exactly* the value stored in attr2. The FAT trick
makes it apply the umask instead. Note: FAT has no executable
bit, so this information is not stored in the ZIP file.
Signed-off-by: Rene Scharfe <rene.scharfe@lsrfire.ath.cx>
---
I tested this change only using Info-ZIP unzip 5.52 on Linux. I
wonder what PKZIP or WinZIP would do with symlink entries.
All calls of git-tar-tree in the test script should be converted
to git-archive --format=tar, then the script can be renamed to
t5000-archive.sh. Later.
archive-zip.c | 13 +++++++++----
t/t5000-tar-tree.sh | 35 +++++++++++++++++++++++++++++++++++
2 files changed, 44 insertions(+), 4 deletions(-)
diff --git a/archive-zip.c b/archive-zip.c
index ae74623..d8317f8 100644
--- a/archive-zip.c
+++ b/archive-zip.c
@@ -145,6 +145,7 @@ static int write_zip_entry(const unsigne
{
struct zip_local_header header;
struct zip_dir_header dirent;
+ unsigned long attr2;
unsigned long compressed_size;
unsigned long uncompressed_size;
unsigned long crc;
@@ -172,12 +173,16 @@ static int write_zip_entry(const unsigne
if (S_ISDIR(mode)) {
method = 0;
+ attr2 = 16;
result = READ_TREE_RECURSIVE;
out = NULL;
uncompressed_size = 0;
compressed_size = 0;
- } else if (S_ISREG(mode)) {
- method = zlib_compression_level == 0 ? 0 : 8;
+ } else if (S_ISREG(mode) || S_ISLNK(mode)) {
+ method = 0;
+ attr2 = S_ISLNK(mode) ? ((mode | 0777) << 16) : 0;
+ if (S_ISREG(mode) && zlib_compression_level != 0)
+ method = 8;
result = 0;
buffer = read_sha1_file(sha1, type, &size);
if (!buffer)
@@ -213,7 +218,7 @@ static int write_zip_entry(const unsigne
}
copy_le32(dirent.magic, 0x02014b50);
- copy_le16(dirent.creator_version, 0);
+ copy_le16(dirent.creator_version, S_ISLNK(mode) ? 0x0317 : 0);
copy_le16(dirent.version, 10);
copy_le16(dirent.flags, 0);
copy_le16(dirent.compression_method, method);
@@ -227,7 +232,7 @@ static int write_zip_entry(const unsigne
copy_le16(dirent.comment_length, 0);
copy_le16(dirent.disk, 0);
copy_le16(dirent.attr1, 0);
- copy_le32(dirent.attr2, 0);
+ copy_le32(dirent.attr2, attr2);
copy_le32(dirent.offset, zip_offset);
memcpy(zip_dir + zip_dir_offset, &dirent, sizeof(struct zip_dir_header));
zip_dir_offset += sizeof(struct zip_dir_header);
diff --git a/t/t5000-tar-tree.sh b/t/t5000-tar-tree.sh
index 278eb66..cf08e92 100755
--- a/t/t5000-tar-tree.sh
+++ b/t/t5000-tar-tree.sh
@@ -26,6 +26,7 @@ commit id embedding:
. ./test-lib.sh
TAR=${TAR:-tar}
+UNZIP=${UNZIP:-unzip}
test_expect_success \
'populate workdir' \
@@ -95,4 +96,38 @@ test_expect_success \
'validate file contents with prefix' \
'diff -r a c/prefix/a'
+test_expect_success \
+ 'git-archive --format=zip' \
+ 'git-archive --format=zip HEAD >d.zip'
+
+test_expect_success \
+ 'extract ZIP archive' \
+ '(mkdir d && cd d && $UNZIP ../d.zip)'
+
+test_expect_success \
+ 'validate filenames' \
+ '(cd d/a && find .) | sort >d.lst &&
+ diff a.lst d.lst'
+
+test_expect_success \
+ 'validate file contents' \
+ 'diff -r a d/a'
+
+test_expect_success \
+ 'git-archive --format=zip with prefix' \
+ 'git-archive --format=zip --prefix=prefix/ HEAD >e.zip'
+
+test_expect_success \
+ 'extract ZIP archive with prefix' \
+ '(mkdir e && cd e && $UNZIP ../e.zip)'
+
+test_expect_success \
+ 'validate filenames with prefix' \
+ '(cd e/prefix/a && find .) | sort >e.lst &&
+ diff a.lst e.lst'
+
+test_expect_success \
+ 'validate file contents with prefix' \
+ 'diff -r a e/prefix/a'
+
test_done
--
1.4.2.3.gf59615
^ permalink raw reply related
* [PATCH 1/2] git-archive --format=zip: use default version ID
From: Rene Scharfe @ 2006-10-06 23:47 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Git Mailing List, Franck Bui-Huu
Use 10 for the "version needed to extract" field. This is the
default value, and we want to use it because we don't do anything
special. Info-ZIP's zip uses it, too.
Signed-off-by: Rene Scharfe <rene.scharfe@lsrfire.ath.cx>
---
archive-zip.c | 4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/archive-zip.c b/archive-zip.c
index 3ffdad6..ae74623 100644
--- a/archive-zip.c
+++ b/archive-zip.c
@@ -214,7 +214,7 @@ static int write_zip_entry(const unsigne
copy_le32(dirent.magic, 0x02014b50);
copy_le16(dirent.creator_version, 0);
- copy_le16(dirent.version, 20);
+ copy_le16(dirent.version, 10);
copy_le16(dirent.flags, 0);
copy_le16(dirent.compression_method, method);
copy_le16(dirent.mtime, zip_time);
@@ -236,7 +236,7 @@ static int write_zip_entry(const unsigne
zip_dir_entries++;
copy_le32(header.magic, 0x04034b50);
- copy_le16(header.version, 20);
+ copy_le16(header.version, 10);
copy_le16(header.flags, 0);
copy_le16(header.compression_method, method);
copy_le16(header.mtime, zip_time);
--
1.4.2.3.gf59615
^ permalink raw reply related
* Re: Problem cloning packed-and-pruned http repository
From: Panagiotis Issaris @ 2006-10-06 22:05 UTC (permalink / raw)
To: git
In-Reply-To: <20061006212616.GA5175@lumumba.uhasselt.be>
Hi
On Fri, Oct 06, 2006 at 11:26:16PM +0200 or thereabouts, wrote:
> [...]
> I've been having trouble setting up a public repository using GIT. After
> I have pushed my repository to a directory within ~/public_html, I can
> clone it. But the repository is _big_ (261M).
>
> So, I use "git-repack" on it and a "git-prune-packed". This makes it
> nicely fit in 14MiB. If I try to clone this pruned/packed repository
> again both cg-clone hangs on it (as does git-clone).
> [...]
> takis@poseidon:/tmp$ cg-clone http://lumumba.uhasselt.be/takis/git/ffmpeg-h264-test.git
> defaulting to local storage area
> Fetching head...
> Fetching objects...
> Getting alternates list for http://lumumba.uhasselt.be/takis/git/ffmpeg-h264-test.git/
> Getting pack list for http://lumumba.uhasselt.be/takis/git/ffmpeg-h264-test.git/
> progress: 0 objects, 0 bytes
> cg-clone: interrupted
>
Apparently, it does work :-/ After a _long_ time I noticed that the
repository indeed got cloned... I am not sure if this is normal behavior
or not, it seemed to take a _really_ long. I would have thought
downloading 14MiB should not take a long time on my ADSL line.
With friendly regards,
Takis
--
OpenPGP key: http://lumumba.uhasselt.be/takis/takis_public_key.txt
fingerprint: 6571 13A3 33D9 3726 F728 AA98 F643 B12E ECF3 E029
^ permalink raw reply
* Re: [PATCH] gitweb: Do not print "log" and "shortlog" redundantly in commit view
From: Luben Tuikov @ 2006-10-06 22:16 UTC (permalink / raw)
To: Jakub Narebski, git
In-Reply-To: <eg51fi$7rs$2@sea.gmane.org>
--- Jakub Narebski <jnareb@gmail.com> wrote:
> Gaah, the whole cae1862a3b55b487731e9857f2213ac59d5646d commit
> "gitweb: More per-view navigation bar links" is somewhat broken.
> Up to this point we used top navigation bar for commit (hash base)
> or whole project related links, while bottom part of navigation
> bar for "formats" i.e. links related to current view (passing hash)
> or for pagination.
>
> So while "snapshot" link has it's place in top navigation bar
> (but by modyfying git_print_page_nav subroutine, not by adding it
> by hand), "history" for example IMHO doesn't; history link should be
> present in the bottom part of navigation bar. Perhaps we could
> reuse git_print_page_nav for formats, for example blob wiew would have
> blob | _blame_ | _history_ | _raw_ | _HEAD_
> while tree view would have
> tree | _snapshot_ | _history_ | _HEAD_
> (where _text_ indices link). Perhaps _snapshot_ in tree view
> shouldn't be repeated, although top one might mean snapshot of commitish,
> bottom one snapshot of tree.
Only a single one: of committish please.
Luben
^ permalink raw reply
* Problem cloning packed-and-pruned http repository
From: Panagiotis Issaris @ 2006-10-06 21:26 UTC (permalink / raw)
To: git
Hi
I've been having trouble setting up a public repository using GIT. After
I have pushed my repository to a directory within ~/public_html, I can
clone it. But the repository is _big_ (261M).
So, I use "git-repack" on it and a "git-prune-packed". This makes it
nicely fit in 14MiB. If I try to clone this pruned/packed repository
again both cg-clone hangs on it (as does git-clone).
Here's two outputs demonstrating this. One repository was a "cp -lr"
clone [1] of the other, and one was packed/pruned, the other wasn't:
takis@poseidon:/tmp$ cg-clone http://lumumba.uhasselt.be/takis/git/ffmpeg-h264.git
defaulting to local storage area
Fetching head...
Fetching objects...
progress: 38 objects, 159434 bytes
cg-clone: interrupted
takis@poseidon:/tmp$ cg-clone http://lumumba.uhasselt.be/takis/git/ffmpeg-h264-test.git
defaulting to local storage area
Fetching head...
Fetching objects...
Getting alternates list for http://lumumba.uhasselt.be/takis/git/ffmpeg-h264-test.git/
Getting pack list for http://lumumba.uhasselt.be/takis/git/ffmpeg-h264-test.git/
progress: 0 objects, 0 bytes
cg-clone: interrupted
So, I tried tracing it, to see what was going on:
takis@poseidon:/tmp/a$ ps x|grep git
18386 pts/9 S+ 0:00 /bin/sh /home/takis/bin/git-clone http://lumumba.uhasselt.be/takis/git/ffmpeg-h264-test.git
18400 pts/9 S+ 0:00 git-http-fetch -v -a -w heads/master heads/master http://lumumba.uhasselt.be/takis/git/ffmpeg-h264-test.git/
18416 pts/10 S+ 0:00 grep git
takis@poseidon:/tmp/a$ strace -f -p 18400
Process 18400 attached - interrupt to quit
select(0, [], [], [], {0, 48000}) = 0 (Timeout)
poll([{fd=4, events=POLLIN}], 1, 0) = 0
gettimeofday({1160169868, 454932}, NULL) = 0
gettimeofday({1160169868, 454989}, NULL) = 0
select(0, [], [], [], {0, 50000}) = 0 (Timeout)
poll([{fd=4, events=POLLIN}], 1, 0) = 0
gettimeofday({1160169868, 506226}, NULL) = 0
gettimeofday({1160169868, 506277}, NULL) = 0
select(0, [], [], [], {0, 50000}) = 0 (Timeout)
poll([{fd=4, events=POLLIN}], 1, 0) = 0
gettimeofday({1160169868, 558245}, NULL) = 0
gettimeofday({1160169868, 558296}, NULL) = 0
select(0, [], [], [], {0, 50000}) = 0 (Timeout)
poll([{fd=4, events=POLLIN}], 1, 0) = 0
gettimeofday({1160169868, 610227}, NULL) = 0
gettimeofday({1160169868, 610277}, NULL) = 0
select(0, [], [], [], {0, 50000}) = 0 (Timeout)
...
And this keeps going on... so I can't see any data getting in :-(
Any hints what I might be doing wrong?
Thanks in advance for any replies! :)
With friendly regards,
Takis
[1] I am aware of "git-clone -l -s" but wanted to make fully
independent copy and wasn't sure about any links between them if only
using "-l".
--
OpenPGP key: http://lumumba.uhasselt.be/takis/takis_public_key.txt
fingerprint: 6571 13A3 33D9 3726 F728 AA98 F643 B12E ECF3 E029
^ permalink raw reply
* Problem setting up public packed repository
From: Panagiotis Issaris @ 2006-10-06 21:49 UTC (permalink / raw)
To: git
Hi
I'm having trouble setting up a public GIT repository. After using git-push
everything works fine, but the repository is _big_ (261MB). But, I can clone it
without any problem. If I "git-pack -a -d" and "git-prune-packed" it, the
repository is nicely shrinked to 14MB _but_ I can't clone it anymore. It starts
alright and seems to look for the pack, but it just hangs at that point...
To illustrate this, I have made a "cp -lr" copy of that public tree [1], one as it
was after git-push (well in fact, it it a packed/prune-packed one, unpacked
again) and another which is packed/prune-packed (the 14MiB one).
Trying to clone it shows this (both with git-clone and cg-clone):
takis@poseidon:/tmp$ cg-clone http://lumumba.uhasselt.be/takis/git/ffmpeg-h264.git
defaulting to local storage area
Fetching head...
Fetching objects...
progress: 38 objects, 159434 bytes
cg-clone: interrupted
takis@poseidon:/tmp$ cg-clone http://lumumba.uhasselt.be/takis/git/ffmpeg-h264-test.git
defaulting to local storage area
Fetching head...
Fetching objects...
Getting alternates list for http://lumumba.uhasselt.be/takis/git/ffmpeg-h264-test.git/
Getting pack list for http://lumumba.uhasselt.be/takis/git/ffmpeg-h264-test.git/
progress: 0 objects, 0 bytes
cg-clone: interrupted
With the packed/prune-packed repository it just hangs with the "progress: 0
objects, 0 bytes" message. So, I decided to have look what might be going on, if
any data was actually getting in and that I was maybe just being to impatient:
takis@poseidon:/tmp/a$ ps x|grep git
18386 pts/9 S+ 0:00 /bin/sh /home/takis/bin/git-clone http://lumumba.uhasselt.be/takis/git/ffmpeg-h264-test.git
18400 pts/9 S+ 0:00 git-http-fetch -v -a -w heads/master heads/master http://lumumba.uhasselt.be/takis/git/ffmpeg-h264-test.git/
18416 pts/10 S+ 0:00 grep git
takis@poseidon:/tmp/a$ strace -f -p 18400
Process 18400 attached - interrupt to quit
select(0, [], [], [], {0, 48000}) = 0 (Timeout)
poll([{fd=4, events=POLLIN}], 1, 0) = 0
gettimeofday({1160169868, 454932}, NULL) = 0
gettimeofday({1160169868, 454989}, NULL) = 0
select(0, [], [], [], {0, 50000}) = 0 (Timeout)
poll([{fd=4, events=POLLIN}], 1, 0) = 0
gettimeofday({1160169868, 506226}, NULL) = 0
gettimeofday({1160169868, 506277}, NULL) = 0
select(0, [], [], [], {0, 50000}) = 0 (Timeout)
poll([{fd=4, events=POLLIN}], 1, 0) = 0
gettimeofday({1160169868, 558245}, NULL) = 0
gettimeofday({1160169868, 558296}, NULL) = 0
select(0, [], [], [], {0, 50000}) = 0 (Timeout)
poll([{fd=4, events=POLLIN}], 1, 0) = 0
gettimeofday({1160169868, 610227}, NULL) = 0
gettimeofday({1160169868, 610277}, NULL) = 0
...
And this goes on and on and on... and there seems to be no data getting in.
(Ofcourse at first I had just done a "du -h" of the clone target dir, but that
didn't grow. To make sure git wasn't using a hidden dir somewhere or keeping all
the pulled-in-data in-memory or something, I decided to look with strace).
What am I doing wrong? Any hints?
I am using the current git-GIT.
Thanks in advance for any replies! :)
With friendly regards,
Takis
[1] I know about the "-l" and "-s" flags, but I wanted to be 100% sure that it
were just copies, and no references would be pointing from here to there...
^ permalink raw reply
* Re: [PATCH] gitweb: [commit view] Do not suppress commitdiff link in root commit
From: Jakub Narebski @ 2006-10-06 20:57 UTC (permalink / raw)
To: git
In-Reply-To: <20061006165933.4127.72491.stgit@rover>
Petr Baudis wrote:
> There's no reason for that, the commitdiff view is meaningful for the
> root commit as well and we link to it everywhere else.
It not used to be. It is since we added '--root' as hash_parent ('hp')
parameter for parentless commits.
--
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git
^ permalink raw reply
* Make git-send-email detect mbox-style patches more readily
From: Matthew Wilcox @ 2006-10-06 20:24 UTC (permalink / raw)
To: git
Earlier today, I embarrassed myself by trying to construct a patch that
git-send-email would send, and I missed out the putting
>From garbage
line on the front, which led it to send the patches with a
Subject: From: Matthew Wilcox <matthew@wil.cx>
line. Bad.
This patch makes git-send-email detect an mbox-style file more readily,
and correctly handles the patches I constructed.
--- git-core-willy/git-send-email.perl 2006-07-24 23:45:08.000000000 -0400
+++ git-core-1.4.1.1/git-send-email.perl 2006-10-06 16:02:37.000000000 -0400
@@ -451,6 +451,7 @@
if (!$header_done) {
$found_mbox = 1, next if (/^From /);
chomp;
+ $found_mbox = 1 if (/^(From|Date|Cc|Subject):/);
if ($found_mbox) {
if (/^Subject:\s+(.*)$/) {
^ permalink raw reply
* Re: perhaps time to remove git_blame from gitweb, and git-annotate?
From: Luben Tuikov @ 2006-10-06 20:21 UTC (permalink / raw)
To: Petr Baudis; +Cc: Junio C Hamano, git, Jakub Narebski
In-Reply-To: <20061006190850.GA4827@pasky.or.cz>
--- Petr Baudis <pasky@suse.cz> wrote:
> (Trimmed cc list to people caring about gitweb.)
>
> Dear diary, on Fri, Oct 06, 2006 at 08:55:29PM CEST, I got a letter
> where Luben Tuikov <ltuikov@yahoo.com> said that...
> > --- Petr Baudis <pasky@suse.cz> wrote:
> > > I will not mourn git-annotate disappearance (perhaps it could stay an
> > > alias to git-blame -c; I don't like this UI-wise but we already do this
> > > kind of thing with git-log / git-whatchanged). I still like gitweb blame
> > > better than blame2 but I'll just patch blame to look like blame2 (or
> > > better) and be happy with that.
> >
> > That's exactly what I don't want to happen. blame2 is much less
> > bloated than blame both in code and in visual appearance and in using
> > git. And this was the whole point: quick, short, fast and straight
> > to the point.
> >
> > I'd like to keep the blame interface as simple as possible, more
> > window estate given to the code lines, and as little as possible to
> > the commit id: a clickable commit-8 and now we also have clickable
> > line_no to show us the state of the file, is more than enough.
> >
> > So far, blame2 has been by far the better "annotate" (as it is called
> > in the other SCMs) interface I've seen in four other SCMs (some proprietary).
> > Let's keep it like this.
> >
> > When data-mining code, what I'm interested in is: where did this line
> > of code come from (commit-8), is it a part of a larger chunk (zebra
> > coloring) and how it relates to the surrounding code. Blame2 is more
> > than efficient at this.
>
> And _I_ like to have some general idea about who and when touched given
> line of code, without having to click on a bunch of commit ids or spend
> a minute hovering over them patiently. ;-)
Well understood.
Although, when I'm chasing after a problem, I care much about
tracing back through the commit history as opposed to who did
what and when, not until I've nailed the regressive commit (is when
I care who/what/when/how).
> If you really feel strongly about it, we should be able to make the
> individual columns hideable at view time, e.g. by a tiny bit of
> javascript just changing the display CSS property, which would be really
> comfortable. My idea about the output would be cg-log -s format, which
> is still reasonably tense. OTOH, there's still some space to burn in the
> Line column.
Point taken.
Now since I don't want to turn blame2 into a circus, and since the whole
point of blame2 (over blame) was to stay away from it being a circus,
and to be fast and to the point, can we just keep git_blame() around
which gives you this extra information right in the main screen?
Luben
P.S. The alternative is to create a next git_blame{N+1}() each time
git_blameN() becomes git_blame{N-1}().
^ permalink raw reply
* [PATCH] add commit count options to git-shortlog
From: Nicolas Pitre @ 2006-10-06 19:39 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
This patch does 3 things:
1) Output the number of commits along with the name for each author
(nice to know for long lists spending more than a screen worth of
commit lines).
2) Provide a switch (-n) to sort authors according to their number of
commits instead of author alphabetic order.
3) Provide a switch (-s) to supress commit lines and only keep a
summary of authors and the number of commits for each of them.
And for good measure a short usage is displayed with -h.
Signed-off-by: Nicolas Pitre <nico@cam.org>
---
I'm far from a Perl expert. I just hope that Perl gurus out there won't
throw up too badly.
With this it is possible to have nice statistics quickly, and
demonstrate that Junio is really our King. ;-)
diff --git a/Documentation/git-shortlog.txt b/Documentation/git-shortlog.txt
index 7486ebe..1601d22 100644
--- a/Documentation/git-shortlog.txt
+++ b/Documentation/git-shortlog.txt
@@ -7,16 +7,29 @@ git-shortlog - Summarize 'git log' outpu
SYNOPSIS
--------
-git-log --pretty=short | 'git-shortlog'
+git-log --pretty=short | 'git-shortlog' [-h] [-n] [-s]
DESCRIPTION
-----------
Summarizes 'git log' output in a format suitable for inclusion
-in release announcements. Each commit will be grouped by author
+in release announcements. Each commit will be grouped by author and
the first line of the commit message will be shown.
Additionally, "[PATCH]" will be stripped from the commit description.
+OPTIONS
+-------
+
+-h::
+ Print a short usage message and exit.
+
+-n::
+ Sort output according to the number of commits per author instead
+ of author alphabetic order.
+
+-s:
+ Supress commit description and Provide a commit count summary only.
+
FILES
-----
'.mailmap'::
diff --git a/git-shortlog.perl b/git-shortlog.perl
index 0b14f83..138c4c5 100755
--- a/git-shortlog.perl
+++ b/git-shortlog.perl
@@ -1,6 +1,18 @@
#!/usr/bin/perl -w
use strict;
+use Getopt::Std;
+use File::Basename qw(basename dirname);
+
+our ($opt_h, $opt_n, $opt_s);
+getopts('hns');
+
+$opt_h && usage();
+
+sub usage {
+ print STDERR "Usage: ${\basename $0} [-h] [-n] [-s] < <log_data>\n";
+ exit(1);
+}
my (%mailmap);
my (%email);
@@ -38,16 +50,37 @@ sub by_name($$) {
uc($a) cmp uc($b);
}
+sub by_nbentries($$) {
+ my ($a, $b) = @_;
+ my $a_entries = $map{$a};
+ my $b_entries = $map{$b};
+
+ @$b_entries - @$a_entries || by_name $a, $b;
+}
+
+my $sort_method = $opt_n ? \&by_nbentries : \&by_name;
+
+sub summary_output {
+ my ($obj, $num, $key);
+
+ foreach $key (sort $sort_method keys %map) {
+ $obj = $map{$key};
+ $num = @$obj;
+ printf "%s: %u\n", $key, $num;
+ }
+}
sub shortlog_output {
- my ($obj, $key, $desc);
+ my ($obj, $num, $key, $desc);
+
+ foreach $key (sort $sort_method keys %map) {
+ $obj = $map{$key};
+ $num = @$obj;
- foreach $key (sort by_name keys %map) {
# output author
- printf "%s:\n", $key;
+ printf "%s (%u):\n", $key, $num;
# output author's 1-line summaries
- $obj = $map{$key};
foreach $desc (reverse @$obj) {
print " $desc\n";
$n_output++;
@@ -152,7 +185,7 @@ sub finalize {
&setup_mailmap;
&changelog_input;
-&shortlog_output;
+$opt_s ? &summary_output : &shortlog_output;
&finalize;
exit(0);
^ permalink raw reply related
* Re: [PATCH] gitweb: Convert Content-Disposition filenames into qtext
From: Luben Tuikov @ 2006-10-06 19:30 UTC (permalink / raw)
To: Petr Baudis; +Cc: git
In-Reply-To: <20061006192006.GW20017@pasky.or.cz>
--- Petr Baudis <pasky@suse.cz> wrote:
> Dear diary, on Fri, Oct 06, 2006 at 09:18:01PM CEST, I got a letter
> where Luben Tuikov <ltuikov@yahoo.com> said that...
> > Convert a string (e.g. a filename) into qtext as defined
> > in RFC 822, from RFC 2183. To be used by Content-Disposition.
> >
> > Signed-off-by: Luben Tuikov <ltuikov@yahoo.com>
> > ---
> > gitweb/gitweb.perl | 18 ++++++++++++++----
> > 1 files changed, 14 insertions(+), 4 deletions(-)
>
> Content-Description: 1207600725-p1.txt
> > diff --git a/gitweb/gitweb.perl b/gitweb/gitweb.perl
> > index f848648..a35d02c 100755
> > --- a/gitweb/gitweb.perl
> > +++ b/gitweb/gitweb.perl
> > @@ -520,6 +520,16 @@ sub esc_html {
> > return $str;
> > }
> >
> > +# Convert a string (e.g. a filename) into qtext as defined
> > +# in RFC 822, from RFC 2183. To be used by Content-Disposition.
> > +sub to_qtext {
> > + my $str = shift;
> > + $str =~ s/\\/\\\\/g;
> > + $str =~ s/\"/\\\"/g;
> > + $str =~ s/\r/\\r/g;
>
> \r? Not \n?
Yes, \r, not \n.
\n is LF, \r is CR, from ASCII(7).
LF is legal in qtext as defined in RFC 822.
The illegals in qtext are CR, backslash and double quote.
Luben
>
> > + return $str;
> > +}
> > +
> > # git may return quoted and escaped filenames
> > sub unquote {
> > my $str = shift;
>
> Other than that,
>
> Acked-by: Petr Baudis <pasky@suse.cz>
>
> --
> 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
> lK[d2%Sa2/d0$^Ixp"|dc`;s/\W//g;$_=pack('H*',/((..)*)$/)
>
^ permalink raw reply
* Re: Commit to more than one branch at once?
From: Stefan Richter @ 2006-10-06 19:23 UTC (permalink / raw)
To: Sean; +Cc: git
In-Reply-To: <BAYC1-PASMTP020F3D66B3E46CDBE82D40AE130@CEZ.ICE>
Sean wrote:
> Only merging the branches will make the commit show up in branch B with
> the same SHA1 number (or identity) that it had in branch A. This is a
> fundamental part of Git. The sha1 of each commit is based in part on
> the sha1 of its parent. Thus it's impossible[1] to copy a commit to
> another branch (ie. reparent it) without changing its identity.
>
> Sean
>
> [1] Okay, more or less impossible.. don't ask me do the math.
Ah, I didn't see the wood for the trees. And this dependence of a
commit's identity on the history is also a (or the) reason why mergers
are necessarily spliced in as commits with unique identity too...
--
Stefan Richter
-=====-=-==- =-=- --==-
http://arcgraph.de/sr/
^ permalink raw reply
* Re: [PATCH] gitweb: Convert Content-Disposition filenames into qtext
From: Petr Baudis @ 2006-10-06 19:20 UTC (permalink / raw)
To: Luben Tuikov; +Cc: git
In-Reply-To: <20061006191801.68649.qmail@web31815.mail.mud.yahoo.com>
Dear diary, on Fri, Oct 06, 2006 at 09:18:01PM CEST, I got a letter
where Luben Tuikov <ltuikov@yahoo.com> said that...
> Convert a string (e.g. a filename) into qtext as defined
> in RFC 822, from RFC 2183. To be used by Content-Disposition.
>
> Signed-off-by: Luben Tuikov <ltuikov@yahoo.com>
> ---
> gitweb/gitweb.perl | 18 ++++++++++++++----
> 1 files changed, 14 insertions(+), 4 deletions(-)
Content-Description: 1207600725-p1.txt
> diff --git a/gitweb/gitweb.perl b/gitweb/gitweb.perl
> index f848648..a35d02c 100755
> --- a/gitweb/gitweb.perl
> +++ b/gitweb/gitweb.perl
> @@ -520,6 +520,16 @@ sub esc_html {
> return $str;
> }
>
> +# Convert a string (e.g. a filename) into qtext as defined
> +# in RFC 822, from RFC 2183. To be used by Content-Disposition.
> +sub to_qtext {
> + my $str = shift;
> + $str =~ s/\\/\\\\/g;
> + $str =~ s/\"/\\\"/g;
> + $str =~ s/\r/\\r/g;
\r? Not \n?
> + return $str;
> +}
> +
> # git may return quoted and escaped filenames
> sub unquote {
> my $str = shift;
Other than that,
Acked-by: Petr Baudis <pasky@suse.cz>
--
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
lK[d2%Sa2/d0$^Ixp"|dc`;s/\W//g;$_=pack('H*',/((..)*)$/)
^ permalink raw reply
* [PATCH] gitweb: Convert Content-Disposition filenames into qtext
From: Luben Tuikov @ 2006-10-06 19:18 UTC (permalink / raw)
To: git
[-- Attachment #1: Type: text/plain, Size: 270 bytes --]
Convert a string (e.g. a filename) into qtext as defined
in RFC 822, from RFC 2183. To be used by Content-Disposition.
Signed-off-by: Luben Tuikov <ltuikov@yahoo.com>
---
gitweb/gitweb.perl | 18 ++++++++++++++----
1 files changed, 14 insertions(+), 4 deletions(-)
[-- Attachment #2: 1207600725-p1.txt --]
[-- Type: text/plain, Size: 1893 bytes --]
diff --git a/gitweb/gitweb.perl b/gitweb/gitweb.perl
index f848648..a35d02c 100755
--- a/gitweb/gitweb.perl
+++ b/gitweb/gitweb.perl
@@ -520,6 +520,16 @@ sub esc_html {
return $str;
}
+# Convert a string (e.g. a filename) into qtext as defined
+# in RFC 822, from RFC 2183. To be used by Content-Disposition.
+sub to_qtext {
+ my $str = shift;
+ $str =~ s/\\/\\\\/g;
+ $str =~ s/\"/\\\"/g;
+ $str =~ s/\r/\\r/g;
+ return $str;
+}
+
# git may return quoted and escaped filenames
sub unquote {
my $str = shift;
@@ -2742,7 +2752,7 @@ sub git_blob_plain {
print $cgi->header(
-type => "$type",
-expires=>$expires,
- -content_disposition => 'inline; filename="' . "$save_as" . '"');
+ -content_disposition => 'inline; filename="' . to_qtext("$save_as") . '"');
undef $/;
binmode STDOUT, ':raw';
print <$fd>;
@@ -2917,7 +2927,7 @@ sub git_snapshot {
print $cgi->header(
-type => 'application/x-tar',
-content_encoding => $ctype,
- -content_disposition => 'inline; filename="' . "$filename" . '"',
+ -content_disposition => 'inline; filename="' . to_qtext("$filename") . '"',
-status => '200 OK');
my $git = git_cmd_str();
@@ -3224,7 +3234,7 @@ sub git_blobdiff {
-type => 'text/plain',
-charset => 'utf-8',
-expires => $expires,
- -content_disposition => 'inline; filename="' . "$file_name" . '.patch"');
+ -content_disposition => 'inline; filename="' . to_qtext("$file_name") . '.patch"');
print "X-Git-Url: " . $cgi->self_url() . "\n\n";
@@ -3327,7 +3337,7 @@ sub git_commitdiff {
-type => 'text/plain',
-charset => 'utf-8',
-expires => $expires,
- -content_disposition => 'inline; filename="' . "$filename" . '"');
+ -content_disposition => 'inline; filename="' . to_qtext("$filename") . '"');
my %ad = parse_date($co{'author_epoch'}, $co{'author_tz'});
print <<TEXT;
From: $co{'author'}
--
1.4.2.3.g0954
^ permalink raw reply related
* Re: perhaps time to remove git_blame from gitweb, and git-annotate?
From: Petr Baudis @ 2006-10-06 19:08 UTC (permalink / raw)
To: Luben Tuikov; +Cc: Junio C Hamano, git, Jakub Narebski
In-Reply-To: <20061006185529.9481.qmail@web31802.mail.mud.yahoo.com>
(Trimmed cc list to people caring about gitweb.)
Dear diary, on Fri, Oct 06, 2006 at 08:55:29PM CEST, I got a letter
where Luben Tuikov <ltuikov@yahoo.com> said that...
> --- Petr Baudis <pasky@suse.cz> wrote:
> > I will not mourn git-annotate disappearance (perhaps it could stay an
> > alias to git-blame -c; I don't like this UI-wise but we already do this
> > kind of thing with git-log / git-whatchanged). I still like gitweb blame
> > better than blame2 but I'll just patch blame to look like blame2 (or
> > better) and be happy with that.
>
> That's exactly what I don't want to happen. blame2 is much less
> bloated than blame both in code and in visual appearance and in using
> git. And this was the whole point: quick, short, fast and straight
> to the point.
>
> I'd like to keep the blame interface as simple as possible, more
> window estate given to the code lines, and as little as possible to
> the commit id: a clickable commit-8 and now we also have clickable
> line_no to show us the state of the file, is more than enough.
>
> So far, blame2 has been by far the better "annotate" (as it is called
> in the other SCMs) interface I've seen in four other SCMs (some proprietary).
> Let's keep it like this.
>
> When data-mining code, what I'm interested in is: where did this line
> of code come from (commit-8), is it a part of a larger chunk (zebra
> coloring) and how it relates to the surrounding code. Blame2 is more
> than efficient at this.
And _I_ like to have some general idea about who and when touched given
line of code, without having to click on a bunch of commit ids or spend
a minute hovering over them patiently. ;-)
If you really feel strongly about it, we should be able to make the
individual columns hideable at view time, e.g. by a tiny bit of
javascript just changing the display CSS property, which would be really
comfortable. My idea about the output would be cg-log -s format, which
is still reasonably tense. OTOH, there's still some space to burn in the
Line column.
There should be no additional load caused by this since we already
extract this information anyway - we show it as a tooltip.
--
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
lK[d2%Sa2/d0$^Ixp"|dc`;s/\W//g;$_=pack('H*',/((..)*)$/)
^ permalink raw reply
* Re: git show and gitweb gives different result for kernel
From: Linus Torvalds @ 2006-10-06 19:08 UTC (permalink / raw)
To: Martin Waitz; +Cc: Aneesh Kumar K.V, git
In-Reply-To: <20061006183054.GU2871@admingilde.org>
On Fri, 6 Oct 2006, Martin Waitz wrote:
>
> But perhaps gitweb should use --cc, too.
Both have their uses.
For example, the diff against the first parent is really broken in some
cases (if a _downstream_ developer synchronizes up with the upstream, the
diff ends up being potentially absolutely huge, and most of the time it's
exactly the wrogn diff to show), but in other cases it's a really
wonderful diff.
So for the kernel, the current gitweb behaviour tends to be exactly what
you want if it's a merge that I did, especially if it was a smallish
merge.
In contrast, the default for "git show" (--cc) always shows something that
makes sense, but it's not necessarily going to always be _useful_. It just
shows the conflicting parts, which is something that is sensible
regardless of which way the merge went, but it obviously doesn't really
say anything about what the real _changes_ were.
So gitweb often shows what people want it to show, but then at other times
it shows totally pointless stuff. While --cc always shows something
"relevant" (and often that's the empty set), but it's relevant only in a
very specific way: it is about how the merge fixed up data conflicts, and
that's not necessarily anything most people are even interested in.
I think it might make sense for gitweb to just have the option to show the
diff against any of the parents _or_ to show the conflicting parts (--cc).
Simply because different people and different uses will have different
ideas of what they find useful.
Linus
^ permalink raw reply
* Re: perhaps time to remove git_blame from gitweb, and git-annotate?
From: Luben Tuikov @ 2006-10-06 18:55 UTC (permalink / raw)
To: Petr Baudis, Junio C Hamano
Cc: git, Luben Tuikov, Jakub Narebski, Ryan Anderson,
Johannes Schindelin, Martin Langhoff, Martyn Smith,
Fredrik Kuivinen, Linus Torvalds
In-Reply-To: <20061006161637.GS20017@pasky.or.cz>
--- Petr Baudis <pasky@suse.cz> wrote:
> Dear diary, on Thu, Oct 05, 2006 at 10:13:15AM CEST, I got a letter
> where Junio C Hamano <junkio@cox.net> said that...
> > It's been a while since we lost git_blame from %actions list. I
> > am wondering maybe it's time to remove it, after 1.4.3 happens.
>
> I will not mourn git-annotate disappearance (perhaps it could stay an
> alias to git-blame -c; I don't like this UI-wise but we already do this
> kind of thing with git-log / git-whatchanged). I still like gitweb blame
> better than blame2 but I'll just patch blame to look like blame2 (or
> better) and be happy with that.
That's exactly what I don't want to happen. blame2 is much less
bloated than blame both in code and in visual appearance and in using
git. And this was the whole point: quick, short, fast and straight
to the point.
I'd like to keep the blame interface as simple as possible, more
window estate given to the code lines, and as little as possible to
the commit id: a clickable commit-8 and now we also have clickable
line_no to show us the state of the file, is more than enough.
So far, blame2 has been by far the better "annotate" (as it is called
in the other SCMs) interface I've seen in four other SCMs (some proprietary).
Let's keep it like this.
When data-mining code, what I'm interested in is: where did this line
of code come from (commit-8), is it a part of a larger chunk (zebra
coloring) and how it relates to the surrounding code. Blame2 is more
than efficient at this.
Luben
>
> --
> 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
> lK[d2%Sa2/d0$^Ixp"|dc`;s/\W//g;$_=pack('H*',/((..)*)$/)
>
^ permalink raw reply
* Re: Commit to more than one branch at once?
From: Petr Baudis @ 2006-10-06 18:52 UTC (permalink / raw)
To: Stefan Richter; +Cc: git
In-Reply-To: <45269E02.50407@s5r6.in-berlin.de>
Dear diary, on Fri, Oct 06, 2006 at 08:18:42PM CEST, I got a letter
where Stefan Richter <stefanr@s5r6.in-berlin.de> said that...
> if I git-cherry-pick a commit from branch A into branch B, this is shown
> as a difference in "git-log B..A".
>
> Is it possible to commit a change to two or more branches but preserve
> the identity of the change? IOW, is there an alternative to
> git-cherry-pick that does not have above mentioned side effect?
Philosophical answer:
This is a point where it shows that Git is snapshot-based, not
changeset-based version control system. So you are not committing a
change, you are committing a snapshot taken after the change. So only
snapshots have identity and if the snapshots differ, they obviously have
different identity. Thus your commit has to have different identity.
Furthermore the commit ties the snapshot with some history (and only
this is the first moment where the concept of the 'change' emerges), and
if you have different history, identity of your commit cannot be
the same 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
lK[d2%Sa2/d0$^Ixp"|dc`;s/\W//g;$_=pack('H*',/((..)*)$/)
^ permalink raw reply
* Re: gitweb: using quotemeta
From: Petr Baudis @ 2006-10-06 18:45 UTC (permalink / raw)
To: Luben Tuikov; +Cc: Jakub Narebski, git
In-Reply-To: <20061006182105.17519.qmail@web31806.mail.mud.yahoo.com>
Dear diary, on Fri, Oct 06, 2006 at 08:21:05PM CEST, I got a letter
where Luben Tuikov <ltuikov@yahoo.com> said that...
> > According to RFC2183, the filename is a value. According to RFC2045, a
> > value is either a token (uninteresting) or a quoted-string. According to
> > RFC822:
> >
> > quoted-string = <"> *(qtext/quoted-pair) <">; Regular qtext or
> > ; quoted chars.
> >
> > qtext = <any CHAR excepting <">, ; => may be folded
> > "\" & CR, and including
> > linear-white-space>
> >
> > quoted-pair = "\" CHAR ; may quote any char
> >
> > So what we emit is completely correct.
>
> (Your quotations do not seem correct according to
> ftp://ftp.rfc-editor.org/in-notes/rfc2045.txt !)
Wow, you caused my GNOME at work to do something totally horrible after
me clicking on that link... ;-)
I'm not sure how is RFC2045 relevant - this is from RFC822, RFC2045 does
not define those non-terminals.
> Petr, I agree with your that what we emit is "completely correct".
>
> But is is _mangled_. I.e. why mangle the filename from "a.b" to
> "a\.b" ? Indeed the latter _is_ qtext but it is not the original name
> given to the file.
..snip..
> Sorry, I ment to say that the latter doesn't appear to be qtext.
>
> Bottomline is that quotemeta does not convert into qtext, and as thus
> should never have been used.
It's a moot point now, but I don't see that - inside qtext, any
character can be quoted, so what we do is technically ok.
--
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
lK[d2%Sa2/d0$^Ixp"|dc`;s/\W//g;$_=pack('H*',/((..)*)$/)
^ permalink raw reply
* Re: Commit to more than one branch at once?
From: Sean @ 2006-10-06 18:38 UTC (permalink / raw)
To: Stefan Richter; +Cc: git
In-Reply-To: <45269E02.50407@s5r6.in-berlin.de>
On Fri, 06 Oct 2006 20:18:42 +0200
Stefan Richter <stefanr@s5r6.in-berlin.de> wrote:
> if I git-cherry-pick a commit from branch A into branch B, this is shown
> as a difference in "git-log B..A".
>
> Is it possible to commit a change to two or more branches but preserve
> the identity of the change? IOW, is there an alternative to
> git-cherry-pick that does not have above mentioned side effect?
Short answer:
No.
Slightly longer answer:
Only merging the branches will make the commit show up in branch B with
the same SHA1 number (or identity) that it had in branch A. This is a
fundamental part of Git. The sha1 of each commit is based in part on
the sha1 of its parent. Thus it's impossible[1] to copy a commit to
another branch (ie. reparent it) without changing its identity.
Sean
[1] Okay, more or less impossible.. don't ask me do the math.
^ 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