* [PATCH] Don't sent objects for refs we're not going to update.
From: Stephen C. Tweedie @ 2006-02-21 18:48 UTC (permalink / raw)
To: git mailing list; +Cc: Stephen Tweedie
In-Reply-To: <1140547568.5509.21.camel@orbit.scot.redhat.com>
send_pack() sends only those refs we've asked to be updated on the
destination---either via an explicit refspec or by matching local and
remote refs. But rev_list() builds an object list for *all* refs it
can find. For a tree with many tags/heads, this means that it is
impossible to push updates even to a single refspec, as exec_rev_list()
overflows its arg length limit.
Fix this by skipping refs with no peer_ref set in exec_rev_list().
send_pack() already skips it when sending refs; we need to skip it
when building the object list for the pack too.
Signed-off-by: Stephen Tweedie <sct@redhat.com>
---
send-pack.c | 5 +++--
1 files changed, 3 insertions(+), 2 deletions(-)
4aa39c0920eea37987ca8a6b10861da7a87b5c14
diff --git a/send-pack.c b/send-pack.c
index 990be3f..d2a39d9 100644
--- a/send-pack.c
+++ b/send-pack.c
@@ -42,8 +42,10 @@ static void exec_rev_list(struct ref *re
args[i++] = "rev-list"; /* 0 */
args[i++] = "--objects"; /* 1 */
- while (refs) {
+ for (; refs; refs = refs->next) {
char *buf = malloc(100);
+ if (!refs->peer_ref)
+ continue;
if (i > 900)
die("git-rev-list environment overflow");
if (!is_zero_sha1(refs->old_sha1) &&
@@ -56,7 +58,6 @@ static void exec_rev_list(struct ref *re
args[i++] = buf;
snprintf(buf, 50, "%s", sha1_to_hex(refs->new_sha1));
}
- refs = refs->next;
}
args[i] = NULL;
execv_git_cmd(args);
--
1.2.2.g6643-dirty
^ permalink raw reply related
* Git cannot push to repository with too many tags/heads
From: Stephen C. Tweedie @ 2006-02-21 18:46 UTC (permalink / raw)
To: git mailing list; +Cc: Stephen Tweedie
Hi,
I'm using git's cvs import to track the Fedora kernel rpm repository,
and it has just passed a watermark that git cannot currently cope with.
The problem is the large number of branches and tags on this repository.
A tag for every build means that the number builds up rapidly, and
git-send-pack has an internal limit of 900 refs to query when building a
pack.
I hoped this wouldn't be a problem. In theory, I should just be able to
push to a single refspec and avoid that limit entirely. But no ---
unfortunately, git is determined to push out the objects for *every* ref
that matches between src and dst when building the pack, even if it's
not actually going to update the remote ref. And in building the
git-rev-list argument list for that colossal update, it exceeds the
internal limit of 900 refs in exec_rev_list().
I think exec_rev_list() is doing the wrong thing here. If I specify an
explicit refspec list for git-send-pack, then when send_pack() calls
match_refs(), we break out to match_explicit_refs() and set
dst->peer_ref only for the ref[s] which match the refspec. send_pack()
then skips all other refs by doing a
if (!ref->peer_ref)
continue;
Unfortunately, exec_rev_list() is missing this, and it tries to ask
git-rev-list for the commit objects of *every* ref on the remote_refs
list, even if they have been explicitly excluded by match_refs() and
have no peer_ref. So with this huge repository, I can't even push a
single refspec without bumping into the limit of 900 refs.
The immediate consequence to me is that I can't push to this particular
repository. But if I'm following the code right, a consequence is that
git-send-pack is accidentally sending all objects for refs that the
remote end is prepared to receive, even if we've supplied a refspec
asking for only a subset of those refs to actually be updated.
I think we can fix this just by adding a test for ref->peer_ref to
exec_rev_list(). That seems to fix the immediate problem for me, at
least. Patch to follow.
--Stephen
^ permalink raw reply
* merging problems with Linus' kernel tree.
From: Dave Jones @ 2006-02-21 18:33 UTC (permalink / raw)
To: git
I did my morning 'git pull' on Linus' tree to a clean tree
that I never make any commits to, and got this ...
$ git pull
Unpacking 2425 objects
100% (2425/2425) done
* refs/heads/origin: fast forward to branch 'master' of git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6
Auto-following refs/tags/v2.6.16-rc3
Auto-following refs/tags/v2.6.16-rc4
Unpacking 2 objects
100% (2/2) done
* refs/tags/v2.6.16-rc4: storing tag 'v2.6.16-rc4' of git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6
* refs/tags/v2.6.16-rc3: storing tag 'v2.6.16-rc3' of git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6
Updating from 418aade459f03318defd18ef0b11981a63bd81b0 to 5914811acf36c3ff091f860a6964808f668f27d0.
Documentation/cpu-hotplug.txt: needs update
fatal: Entry 'Documentation/cpu-hotplug.txt' would be overwritten by merge. Cannot merge.
$ git-fsck-objects
dangling commit 5914811acf36c3ff091f860a6964808f668f27d0
$ git-cat-file commit 5914811acf36c3ff091f860a6964 808f668f27d0
tree 04317a64fa5e76a13f29de655fe354abd627445d
parent 6d7b9efacba9f4e5f4d5ca165b1a4350da52ddd7
author Bj�rn Steinbrink <B.Steinbrink@gmx.de> 1140282763 +0100
committer Linus Torvalds <torvalds@g5.osdl.org> 1140496058 -0800
[PATCH] kjournald keeps reference to namespace
In daemonize() a new thread gets cleaned up and 'merged' with init_task.
The current fs_struct is handled there, but not the current namespace.
This adds the namespace part.
[ Eric Biederman pointed out the namespace wrappers, and also notes that
we can't ever count on using our parents namespace because we already
have called exit_fs(), which is the only way to the namespace from a
process. ]
Signed-off-by: Björn Steinbrink <B.Steinbrink@gmx.de>
Acked-by: Eric Biederman <ebiederm@xmission.com>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
I ran a fsck on the disk, and that turned up nothing, so I'm
not expecting any local fs corruption.
What's up with this, and how do I fix it?
Dave
^ permalink raw reply
* Re: [PATCH] git-mktree: reverse of git-ls-tree.
From: Linus Torvalds @ 2006-02-21 18:00 UTC (permalink / raw)
To: Keith Packard; +Cc: Junio C Hamano, Tommi Virtanen, git
In-Reply-To: <1140543982.16926.145.camel@evo.keithp.com>
On Tue, 21 Feb 2006, Keith Packard wrote:
>
> Yes, all three are equivalent, my only point was that '(c)' is
> meaningless. Which, as I noted is just pedantry.
Pedantry is fine on a mailing list. But meaningless pedantry in a lawyer
is bad. My point was that your _lawyers_ are bad. Tell them to concentrate
on something that matters.
Linus
^ permalink raw reply
* Re: [PATCH] git-mktree: reverse of git-ls-tree.
From: Linus Torvalds @ 2006-02-21 17:57 UTC (permalink / raw)
To: Keith Packard; +Cc: Junio C Hamano, Andreas Ericsson, git
In-Reply-To: <1140542628.16926.125.camel@evo.keithp.com>
[-- Attachment #1: Type: TEXT/PLAIN, Size: 603 bytes --]
On Tue, 21 Feb 2006, Keith Packard wrote:
>
> Precisely. I'd say either remove the (c) or replace it with the correct
> symbol.
Taking that to its logical conclusion, you should remove the whole line,
since none of it is in any way required and it's all unnecessary.
The thing is, the string "(c)" is a _lot_ more readable than the sanest
alternative for © (\c2\a9, ie the appropriate UTF8 string). Because even
that sane representation will actually show up as something else in a
_lot_ of editors, and is often hard to type for people.
There's a reason people use "(c)" rather "©".
Linus
^ permalink raw reply
* Re: [PATCH] git-mktree: reverse of git-ls-tree.
From: Keith Packard @ 2006-02-21 17:46 UTC (permalink / raw)
To: Linus Torvalds; +Cc: keithp, Junio C Hamano, Tommi Virtanen, git
In-Reply-To: <Pine.LNX.4.64.0602210915320.30245@g5.osdl.org>
[-- Attachment #1: Type: text/plain, Size: 362 bytes --]
On Tue, 2006-02-21 at 09:40 -0800, Linus Torvalds wrote:
> Which mentions the © letter, but makes it very very
> clear that "Copyright" or the abbreviation "Copr." are totally
> interchangeable in the US.
Yes, all three are equivalent, my only point was that '(c)' is
meaningless. Which, as I noted is just pedantry.
--
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] git-mktree: reverse of git-ls-tree.
From: Linus Torvalds @ 2006-02-21 17:40 UTC (permalink / raw)
To: Keith Packard; +Cc: Junio C Hamano, Tommi Virtanen, git
In-Reply-To: <1140504750.16926.111.camel@evo.keithp.com>
[-- Attachment #1: Type: TEXT/PLAIN, Size: 2509 bytes --]
On Mon, 20 Feb 2006, Keith Packard wrote:
>
> > + * Copyright (c) Junio C Hamano, 2006
>
> I've been told by at least two lawyers that the string '(c)' has no
> legal meaning in the US. If you want to indicate copyright, the only
> symbol which does carry legal weight is the c-in-a-circle mark '©'.
You should change lawyers, methinks.
The thing is, once the same line says "Copyright", the string '(c)' may be
meaningless, but more importantly, your lawyers are wasting your time with
pointless and mindless "punktknulleri" (literal meaning: "the f*cking of
points", aka being anal retentive).
Of course, they are probably also charging you for that time they are
wasting, which is why you should fire them and find somebody who tells you
anything relevant.
The FACT is that
(a) You can write out the word "copyright" in its entirety.
(b) the US legal system very much takes intent into account, so even if
you don't, if the meaning is clear, it's not like it matters. This
is even more true on most of the rest of the civilized world, btw (ie
Europe in general gives authors _more_ rights than the US, since they
recognize the notion of "moral rights")
(c) you own the copyright anyway ever since 1988, when the US ratified
the Berne convention. In fact, even before then, the US had adopted
the notion of automatic copyrights, and any work created after 1978
falls under this.
Anyway, for more details if you _really_ care, look up "Circular 3" by the
United States Copyright Office. The very first sentence of that paper
talks about how the notice isn't even required any more, but if you want
to talk to your punktknullande lawyers, point them to the section called
"form of notice". Which mentions the © letter, but makes it very very
clear that "Copyright" or the abbreviation "Copr." are totally
interchangeable in the US.
Now, in some _other_ countries, the © mark may be special, but quite
frankly, you won't really care. If it matters, those countries haven't
ratified the Berne convention, and you'll never ever in a million years
care about them. It's absolutely certainly not the case in any relevant
country.
Any country where "©" matters likely has many bigger problems wrt
copyrights, like not honoring them at all.
So: if you care about the copyright law in Ulan Bator, you may have to use
the © character. But the likelihood is that it's not an issue even there.
So tell your lawyers to f*ck the hell off.
Linus
^ permalink raw reply
* Re: [PATCH] fmt-merge-msg: avoid open "-|" list form for Perl 5.6
From: Alex Riesen @ 2006-02-21 17:30 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Johannes Schindelin, Eric Wong, git
In-Reply-To: <7vr75xbs8w.fsf_-_@assigned-by-dhcp.cox.net>
On 2/20/06, Junio C Hamano <junkio@cox.net> wrote:
> * Eric, thanks for the hint. I have this four-patch series.
> Could people with perl 5.6 please check them?
Does not work here (ActiveState Build 811, Perl 5.8.6):
$ perl -e 'open(F, "-|")'
'-' is not recognized as an internal or external command,
operable program or batch file.
^ permalink raw reply
* Re: [PATCH] git-mktree: reverse of git-ls-tree.
From: Keith Packard @ 2006-02-21 17:23 UTC (permalink / raw)
To: Junio C Hamano; +Cc: keithp, Andreas Ericsson, git
In-Reply-To: <7vr75x11or.fsf@assigned-by-dhcp.cox.net>
[-- Attachment #1: Type: text/plain, Size: 931 bytes --]
On Tue, 2006-02-21 at 01:49 -0800, Junio C Hamano wrote:
> Keith is saying that unlike ciecle-c, (c) is meaningless. While
> he is right about that, it does not matter, as long as he is
> talking about "legal meaning in the US". It is my understanding
> that spelled out "Copyright" (or its abbreviation, "Copr.")
> weighs as much as the circle-c mark.
Precisely. I'd say either remove the (c) or replace it with the correct
symbol. As including the correct symbol requires selecting between an
8859 and 10646 encoding, one shows one's i18n-fu by including the © in
UTF-8.
Once this choice is firmly in place, the opportunties for excessive
character usage really flourish:
http://gitweb.freedesktop.org/?p=cairo;a=blobdiff;h=1c63adec9b6547c6446548dc3a877e1e4ba29bfd;hp=a6ebc5e04773c8b544cfb721b635ef5534be235f;hb=cc890b9cf4d2a38e13ae48e16589c4fd02678f99;f=src/cairo-pen.c
--
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: fix git-fmt-merge-msg on ActiveState Perl
From: Alex Riesen @ 2006-02-21 15:48 UTC (permalink / raw)
To: Git Mailing List; +Cc: Junio C Hamano
In-Reply-To: <81b0412b0602210745i637692d3p5462c2b3a00df793@mail.gmail.com>
On 2/21/06, Alex Riesen <raa.lkml@gmail.com> wrote:
> For people who stuck with ActiveState Perl, as there seem to be
> no chance for it to support the list form of "open" in foreseeable future.
Too late... Sorry :)
^ permalink raw reply
* PATCH: fix git-fmt-merge-msg on ActiveState Perl
From: Alex Riesen @ 2006-02-21 15:45 UTC (permalink / raw)
To: Git Mailing List; +Cc: Junio C Hamano
[-- Attachment #1: Type: text/plain, Size: 248 bytes --]
For people who stuck with ActiveState Perl, as there seem to be
no chance for it to support the list form of "open" in foreseeable future.
Working it around again.
Should be harmless, as there are only sha1s passed
---
@#$%^&* windows!!!
[-- Attachment #2: 0001-fix-git-fmt-merge-msg-on-activestate-perl.txt --]
[-- Type: text/plain, Size: 1263 bytes --]
>From nobody Mon Sep 17 00:00:00 2001
From: Alex Riesen <raa.lkml@gmail.com>
Date: Tue Feb 21 15:53:39 2006 +0100
Subject: fix git-fmt-merge-msg on activestate perl
---
git-fmt-merge-msg.perl | 7 +++----
1 files changed, 3 insertions(+), 4 deletions(-)
65ca8f2e90b9816c1748847fc406d26a56b7ad2d
diff --git a/git-fmt-merge-msg.perl b/git-fmt-merge-msg.perl
index 9071312..f4ecd13 100755
--- a/git-fmt-merge-msg.perl
+++ b/git-fmt-merge-msg.perl
@@ -33,7 +33,7 @@ sub repoconfig {
my $fh;
my $val;
eval {
- open $fh, '-|', 'git-repo-config', '--get', 'merge.summary'
+ open($fh, 'git-repo-config --get merge.summary |')
or die "$!";
($val) = <$fh>;
close $fh;
@@ -43,7 +43,7 @@ sub repoconfig {
sub current_branch {
my $fh;
- open $fh, '-|', 'git-symbolic-ref', 'HEAD' or die "$!";
+ open($fh, 'git-symbolic-ref HEAD |') or die "$!";
my ($bra) = <$fh>;
chomp($bra);
$bra =~ s|^refs/heads/||;
@@ -59,8 +59,7 @@ sub current_branch {
sub shortlog {
my ($tip) = @_;
my ($fh, @result);
- open $fh, '-|', ('git-log', '--topo-order',
- '--pretty=oneline', $tip, '^HEAD')
+ open($fh, "git-log --topo-order --pretty=oneline $tip ^HEAD |")
or die "$!";
while (<$fh>) {
s/^[0-9a-f]{40}\s+//;
--
1.2.2.g65ca8
^ permalink raw reply related
* gitk: error on find
From: Michael @ 2006-02-21 13:44 UTC (permalink / raw)
To: git
On GIT repository:
~/git$ git --version
git version 1.2.0
~/git$ gitk --all -d
if I search for "1.0.0" and hit "return", gitk gives:
error:
invalid command name "contmergediff"
invalid command name "contmergediff"
while executing
"contmergediff $ids"
(procedure "gettreediffline" line 14)
invoked from within
"gettreediffline file5 c894168631e4b7da66ed3993a4c92380d38599a8"
...and goes to commit 8d712aafd2df3c1f5147a28947f98cefe667cf76, while the
first commit containing "1.0.0" is c894168631e4b7da66ed3993a4c92380d38599a8
In general, pressing <return> instead of clicking "find", causes gitk to skip
a commit (without other errors). This behaviour is present since (at last)
GIT version 1.0.0.
Searching for "1.0.0" but clicking on "find" gives no errors.
I think "contmergediff" is an old procedure, but I don't know how to fix it
(nor exactly what was meant to do). The error was first introduced with
commit b77b02785d2f589ca336fc449ee1c27837263dac (it was a big change, so the
"contmergediff" line was probably forgotten).
^ permalink raw reply
* [RFC] Using GIT techniques to backup and synchronize file systems - replica
From: Herbert Nachtnebel @ 2006-02-21 13:21 UTC (permalink / raw)
To: git
Hi,
in the last weeks some ideas were floated here on the list to make git
usable not only for source code tracking, but also for synchronizing
mail storage folders or even complete file systems. Time to throw some
code to the list:
http://members.chello.at/replica/replica-20060220-1.tar.gz
In advance of the description of the code, I want to point out some
interesting properties of git. Git has some similarities with two
distinct application areas: backup and synchronisation. Consider the
object database alone, it contains snapshots in time of the state of the
file system - exactly the same what a backup application does.
Currently, git only holds a subset of the complete meta data of the
files in it's database and should gain some support for directory meta
data, non-regular files, statically linked files, and sparse files. But
then it would be comparable to tar or other backup tools.
Regarding the second point, synchronisation with others is clearly what
git is all about. Furthermore, in contrast to synchronising file systems
like coda, intermezzo and what ever they are called, git's merging tools
are far more sophisticated. In fact too sophisticated for synchronizing
file systems. On file systems merging on the level of files is fully
sufficient and without additional knowledge over the properties and
meaning of the individual files even dangerous! Combining these two
points, it is self-evident that git is more than a source code control
system and folks are looking for ways to use it in other ways.
A little drawback of git sacrifices the portability to other
architectures: the frequent use of scripting languages to implement
important parts of functionality. Of course, for git that's an advantage
since the development is so much faster. But for a porting git to
architectures beside Unix, it's a real problem. I for one would love to
use it to synchronize between Sun, Linux and Windows machines in our
department. Additional, when git is used for synchronizing large
datasets, the scripts may easily become a performance bottleneck. I
realize that it is nearly impossible to change git to not depend on
scripting in the near future but for the application I have in mind, I
would like to solve that; that's the cause I started to playing around
with the code presented above.
Speaking of performance, looking on the index file handling code I
suspect that it is not fast enough to handle really large datasets. For
instance, reading an index file is O(N) since it is reading in each
individual dataset and interprets it then. The same applies to
operations on the index file - a pointer to each dataset is held in a
linear array which must be manipulated when inserting or deleting a
dataset - or writing out the index file. I expect that that could be
improved if the layout of the index file is changed slightly; each
dataset should have the same size. And as Linus has recently shown, more
speed improvements could be gained if merging is handled directly on
tree files instead of in the index: more evidence to play around with
some code.
But one difference in the usage pattern between the source code version
control and backup/synchronizing requires some basic changes to the git
algorithms which I suspect will not be acceptable and therefore requires
a distinct implementation: when checking in source code, it is known
that the files checked in do not change on disc. In the case of backup
and synchronization such garanties can _not_ be made. Such an
application should be a background task, hence stopping the generation
of new data or altering existing data is generally no option. But it's
interesting that the git techniques are a natural solution to this
problem: the index file together with the object database allows to
split the task needed to synchronize with other sides into three phases.
First, updating the index from the file system and altering the object
database, then merging the _constant_ index file with the other sides
and finally, updating the file system (may be altered in the mean time)
with the updates stored in the index file, but not altering changed data
in the file system. What does this change in git? Only one basic
assumption. The size of blobs are stored in the blob header and in git
it is assumed, that this size is correct. In the backup/synchronization
usage case this can not be held. During reading-in data files into the
object database they may change their size on disk and the header of the
blob may become out of sync. But this should be tolerated.
In summary, using git techniques for backup and synchronisation is an
interesting possibility, if some shortcomings could be solved. First, it
should handle all file types like tar handles them. Second, the merging
tools should be simplified; merging on file level is sufficient: when
conflicts occure tell the user, but don't try to merge automatically.
Third, it would be fine if it would be completely implemented in C to
make it easily portable. Forth, it should handle any amount of data
efficiently and should be able to synchronize arbitrarily contents
between synchronization partners; of course even complete git
repositories (another hint that that what I have in mind should be
realized outside of git).
And there we go, the presented application, replica, tries to realize
the above points. It is ment to be a distributed synchronization tool.
Think of it as a two-way rsync with a permanent state (therefore
minimizing the workload on the servers). What is implemented so far?
Well, not that much: reading in a filesystem into the object database
and generating tree (filenames converted to unicode) and commit objects
and some debugging code. Therefore, synchronization with other sides is
comming next, but I think, you should be made aware about my current
efforts. One difference to git is the index file handling; it may become
interesting also for git itself. I have tried to implement it in a
simple but efficient way. Basically, may version of the index file is
built up of AVL trees with an 1:1 relationship to the directory tree
store on disk. In difference to git, also directory entries representing
subdirectories are held in the index file together with their meta data.
Hence, even empty directories may be handled as expected by the user.
I want to highlight the realisation of the AVL trees. The most
interesting property of them is that they are position independent. One
is able to map the index file into the memory space and then use it
directly without changing any values in it. Hence, reading the index
file and writing it out is essentially O(1); well, neglecting the time
needed to read the contents from disk or writing it out of course. All
AVL tree pointers are not pointers per se, but are realized as offsets
to their neighbors. I think (and hope), this implementation may prove
useful to be used in git also.
Herbert.
PS.: Sorry about this long posting but hopefully, some may find my work
interesting.
^ permalink raw reply
* What's in git.git (with specific RFHs)
From: Junio C Hamano @ 2006-02-21 11:23 UTC (permalink / raw)
To: git
* The 'master' branch has these since the last announcement.
- more portability bits from Johannes.
I'm holding off Makefile changes because it seems to trigger
"make -j" breakage. Testing, diagnosing and fixing the
version in the 'next' branch by more knowledgeable people is
very much appreciated.
- merge-tree by Linus.
- git-mktree: reverse of git-ls-tree.
I am hoping that this may help a new merge engine based on
merge-tree by Linus, but maybe not. It depends on how you
use merge-tree output.
- loosening "empty ident" errors.
Enough people seem to have been bitten by this since 1.2.0
was released.
- Fix fmt-merge-msg counting.
- cherry-pick/revert: rewording error-help message.
- git-svn updates from Erig Wong (contrib/).
* The 'next' branch, in addition, has these.
- "Assume unchanged git".
I have been using this in production for some time, without
usin CE_VALID, and am reasonably sure this does not break
anything for normal use. I am hoping to push this one to
'master' sometime this week. If people can find missing or
incomplete docs in this part, help is appreciated.
- Solaris 9+ portability bits from Paul Jakma.
Testing by people with Solaris 8 boxes to make sure this does
not regress and/or people with Solaris 9 or 10 boxes to see
if this help is appreciated. Quite likely to be "master"
material without further changes.
- Reusing data from existing packs, and "Thin pack" bandwidth
reduction for "git push" and "git fetch".
I am holding these off not because they are risky (I've been
using them in the production over the long weekend), but I'm
keeping them to entice people to try out the 'next' branch
;-). Quite likely to be "master" material without further
changes.
- Perl 5.6 backward compatibility.
Instead of open($fh, '-|', @list), use a bit older equivalent
form. Thanks for Johannes and Eric Wong. Quite likely to be
"master" material without further changes.
- git-annotate by Ryan and git-blame by Fredrik.
The one by Fredrik, being all in C, doing all git things
internally and forking only diff, seems much faster, but it
seems to have inherited bugs from my original blame script
implementation from long time ago. Ryan's one seems to be
computing sensible results.
* The 'pu' branch, in addition, has these.
- "Bash completion" in Ben Clifford (contrib/)
Without requests from the list, I am not particularly
interested in carrying this in my tree, but I wanted to try
out "an even cooler merge" myself, just like Linus did with
gitk merge.
- "Bound commit" lowlevel machinery for subprojects support.
Honestly, I am not very interested in this myself. If
somebody is interested in gitlink based subproject support,
the parts this touches would interfere with it -- in which
case I'd drop this.
^ permalink raw reply
* Re: [PATCH] git-mktree: reverse of git-ls-tree.
From: Martin Langhoff @ 2006-02-21 10:20 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Andreas Ericsson, git, Keith Packard
In-Reply-To: <7vr75x11or.fsf@assigned-by-dhcp.cox.net>
On 2/21/06, Junio C Hamano <junkio@cox.net> wrote:
> Keith is saying that unlike ciecle-c, (c) is meaningless. While
> he is right about that, it does not matter, as long as he is
> talking about "legal meaning in the US". It is my understanding
> that spelled out "Copyright" (or its abbreviation, "Copr.")
> weighs as much as the circle-c mark.
>
> And it matters even less these days. US law traditionally
> required copyright notice to be protected, but after 1989 US
> Copyright Act, made in line with Berne convention, the notice is
> not even necessary. It used to be that you would want circle-c,
> Copyright and "All Rights Reserved", if you really wanted to be
> anal. Buenos Aires signatories are all Berne members these
> days, it became just obsolete inertia.
Not entirely useless though. It serves as an indication of who to
contact for permission to copy. It's not as good as it should be
("which of the 35 L.Torvalds in the phonebook does this mean?").
Copyright law reform proponents do sometimes talk of a central
database with contact details for copyright owners and other measures
to facilitate brokerage of licenses.
It also serves as a reminder of the need for a license, though legally
it's not required. Just like a lock in the door, while often easy to
pick or crack open and definitely not required, reminds people that
trespassing is a crime.
Bah, social mores, laws and other vices of humanity...
martin
^ permalink raw reply
* Re: [PATCH] git-mktree: reverse of git-ls-tree.
From: Junio C Hamano @ 2006-02-21 9:49 UTC (permalink / raw)
To: Andreas Ericsson; +Cc: git, Keith Packard
In-Reply-To: <43FAD35E.5080401@op5.se>
Andreas Ericsson <ae@op5.se> writes:
> Keith Packard wrote:
>> <internationalization-pedant-mode>
>> On Mon, 2006-02-20 at 22:37 -0800, Junio C Hamano wrote:
>>
>>>+ * Copyright (c) Junio C Hamano, 2006
>> I've been told by at least two lawyers that the string '(c)' has no
>> legal meaning in the US. If you want to indicate copyright, the only
>> symbol which does carry legal weight is the c-in-a-circle mark
>...
> I'm not sure how mad such a law can be written, but what you describe
> go against both common sense and common practice since it puts the
> burden of protection on the victim-to-be before the crime is even
> committed...
Keith is saying that unlike ciecle-c, (c) is meaningless. While
he is right about that, it does not matter, as long as he is
talking about "legal meaning in the US". It is my understanding
that spelled out "Copyright" (or its abbreviation, "Copr.")
weighs as much as the circle-c mark.
And it matters even less these days. US law traditionally
required copyright notice to be protected, but after 1989 US
Copyright Act, made in line with Berne convention, the notice is
not even necessary. It used to be that you would want circle-c,
Copyright and "All Rights Reserved", if you really wanted to be
anal. Buenos Aires signatories are all Berne members these
days, it became just obsolete inertia.
^ permalink raw reply
* Re: [PATCH] git-mktree: reverse of git-ls-tree.
From: Andreas Ericsson @ 2006-02-21 8:46 UTC (permalink / raw)
To: Keith Packard; +Cc: Junio C Hamano, Tommi Virtanen, git
In-Reply-To: <1140504750.16926.111.camel@evo.keithp.com>
Keith Packard wrote:
> <internationalization-pedant-mode>
> On Mon, 2006-02-20 at 22:37 -0800, Junio C Hamano wrote:
>
>
>>+ * Copyright (c) Junio C Hamano, 2006
>
>
> I've been told by at least two lawyers that the string '(c)' has no
> legal meaning in the US. If you want to indicate copyright, the only
> symbol which does carry legal weight is the c-in-a-circle mark '©'.
>
> Of course, this does force the issue of what encoding to present source
> files in. I suggest that sources should be UTF-8, which also provides
> opportunities to encode author names correctly, rather than
> transliterating them to Latin. X.org uses UTF-8 for source files now
> without difficulty across a wide range of compilers. Of course,
> non-ascii glyphs are present only in comments.
>
> </internationalization-pedant-mode>
In most countries the copyright is implied unless explicitly void by the
author.
In other sane countries (I don't argue that USA is necessarily any such
country), the law is such that if the copier understands that there is a
copyright and violates it, he or she is in error and thus liable.
I'm not sure how mad such a law can be written, but what you describe go
against both common sense and common practice since it puts the burden
of protection on the victim-to-be before the crime is even committed. It
would be like a rapist being let off because his victims were where he
happened to be.
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
^ permalink raw reply
* Re: RFC: Subprojects
From: Junio C Hamano @ 2006-02-21 7:57 UTC (permalink / raw)
To: Uwe Zeisberger; +Cc: git
In-Reply-To: <20060220131659.GA8613@informatik.uni-freiburg.de>
Uwe Zeisberger <zeisberg@informatik.uni-freiburg.de> writes:
> I'd prefer to have the objects needed to get the linux-2.6 tree in the
> object db of the containing project. Then "url" is not needed, and you
> could directly use the commit as value for the link.
... which is actually closer to what bind commit approach gives
you. The tree object in a commit of the containing project has
the full tree object at path linux-2.6/. The "bind" lines in
the commit object are just notes that tell you where those
trees happen to came from.
> ... Moreover the condition that the
> "containing" tree must not have an entry named linux-2.6 is handled
> implicitly with links.
I had an impression that two approaches were more or less
equivalent, especially the last round of bound commit approach.
It does not let anything to exist at the bound path in the
containing project either ("read-tree --prefix" rejects it).
> Please correct me if I'm wrong somewhere. It's some time ago I read the
> patches and this thread. This mail is the result of some thoughts in my
> vacation.
I have to admit that I haven't thought about the issues involved
for a long time, having no great need nor desire for subprojects
myself, and especially with more generally useful stuff like
performance enhancement for pack generation to occupy me. I am
not sure I am much more qualified to comment than you are at
this point.
The bound commit lowlevel changes have been sitting in "pu" for
about a month by now, but nobody seems to be interested enough
to start prototyping Porcelain around it. Neither the gitlink
approach. After seeing not much interest on the list, I was
hoping that I could retire both WIPs.
^ permalink raw reply
* Re: [PATCH 2/2] Add 'stg uncommit' command
From: Karl Hasselström @ 2006-02-21 7:55 UTC (permalink / raw)
To: Catalin Marinas; +Cc: git
In-Reply-To: <b0943d9e0602201449j15541f8aw@mail.gmail.com>
On 2006-02-20 22:49:22 +0000, Catalin Marinas wrote:
> On 20/02/06, Karl Hasselström <kha@treskal.com> wrote:
>
> > It put curly braces around the name as well.
>
> It wasn't StGIT. Running "git log" on my machine only shows \'s and
> some weird characters.
Those weird characters are the two bytes that make up the character
"ö" (o with two dots on top of it) in utf8. That's what the utf8
variant of my name looks like when displayed in latin1. :-/
> Maybe it's your terminal showing braces.
You're right, they don't show when I use git-log, so I guess they
aren't really there after all. But they do show up in gitk.
Hopefully all this weirdness will go away with the backslashes. :-)
--
Karl Hasselström, kha@treskal.com
www.treskal.com/kalle
^ permalink raw reply
* rewriting pathnames in history
From: Jeff King @ 2006-02-21 7:53 UTC (permalink / raw)
To: git
I recently ran into an interesting situation with git. I created a
repository that consisted of several directories (and files in them).
Later, after many commits, I realized I would prefer each directory have
its own git repository. That is, given a repo with the files:
foo/bar
baz/bleep
I wanted two repos, "foo" containing the file "bar" and "baz" containing
the file "bleep".
Obviously, one could simply make new repositories (one for each
directory), rename the files, and commit. However, I wanted to keep the
history for each new repo tidy, as well. So my solution was to replay
the history once for each new repo, omitting any revisions which had no
effect, and rewriting paths to move "dir/foo" to "foo".
The script I used is included at the end of this mail. I'm posting in
case anyone else finds it useful (comments are also welcome).
I also have a question regarding this task. I wanted to split the whole
history, so I wanted a "blank" commit to start adding my replay to (that
is, a commit with no files and no parent). What's the best way using
git to get a blank commit? I ended up creating a new repo (with cogito,
which I regularly use), and then fetching it into the original repo and
switching to it as a branch.
-Peff
--------------
#!/usr/bin/perl
# Rewrite history by replaying and modifying pathnames.
# Public domain.
#
# 1. Switch your HEAD to the head where the rewritten history will go.
# 2. Figure out which revs you want to replay (e.g., git-rev-list master)
# 3. Figure out which paths you want to include (e.g., '/^prefix/)
# 4. Figure out how you want to modify the path (e.g., 's!^prefix/!!')
# 5. Run the script:
# git-rev-list master | perl rewrite.pl /^prefix/ 's!^prefix/!!'
my $USAGE = 'usage: rewrite.pl match rewrite';
my $match = shift or die "$USAGE, halting";
my $rewrite = shift or die "$USAGE, halting";
my @revs = ('HEAD', reverse(map { chomp; $_ } <>));
foreach my $i (1 .. $#revs) {
my @files = difftree($revs[$i-1], $revs[$i]);
@files = grep { match($match, $_) } @files
or next;
@files = map { rewrite($rewrite, $_) } @files;
update_index(@files);
commit($revs[$i]);
}
sub difftree {
my ($x, $y) = @_;
my @files;
open(my $fh, "git-diff-tree -r $x $y|")
or die "unable to open git-diff-tree: $!, halting";
while(my $line = <$fh>) {
chomp $line;
$line =~ /^:\d+ (\d+) [0-9a-f]+ ([0-9a-f]+) .\t(.*)/
or die "bad diff-tree output: $line, halting";
push @files, [$1, $2, $3];
}
$? and die "git-diff-tree returned error: $!, halting";
return @files;
}
sub match {
my $m = shift;
my $f = shift;
local $_ = $f->[2];
return eval $m;
}
sub rewrite {
my $r = shift;
my $f = shift;
local $_ = $f->[2];
eval $r;
$@ and die $@;
$f->[2] = $_;
return $f;
}
sub update_index {
open(my $fh, '|git-update-index --index-info')
or die "unable to open git-update-index, halting";
foreach my $f (@_) {
print $fh "$f->[0] $f->[1]\t$f->[2]\n";
}
close($fh);
$? and die "git-update-index reported failure, halting";
}
sub commit {
my $r = shift;
system("git-commit -C $r")
and die "git-commit reported failure, halting";
}
^ permalink raw reply
* Re: contrib/ area
From: Petr Baudis @ 2006-02-21 7:43 UTC (permalink / raw)
To: Ben Clifford; +Cc: Junio C Hamano, git
In-Reply-To: <b7bc5ebe0602202110l53418b32q@mail.gmail.com>
Dear diary, on Tue, Feb 21, 2006 at 06:10:05AM CET, I got a letter
where Ben Clifford <benc@hawaga.org.uk> said that...
> > As a practice for doing "even cooler merge", I did the
> > following, to see if I can treat it just like I treat gitk.
>
> neat.
>
> one thing that bothers me a bit about that is that the cogito code
> then ends up in both the git and cogito repositories (actually the way
> its done manually for cogito contrib/ at the moment bothers me
> anyway).
Well, in the long term, Jonas is working on a bash completion generated
automagically from the cg sources (anything maintained externally is bad
'coz it gets out of sync, mm'kay? ;).
In the short term, I can just accept patches from you - they do not even
need to get the filenames right, I can rewrite that. You see, I don't
have the cool recursive merge strategy so merging into a subdirectory is
painful (and that bothers me too; we'll see yet).
Thanks,
--
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
Of the 3 great composers Mozart tells us what it's like to be human,
Beethoven tells us what it's like to be Beethoven and Bach tells us
what it's like to be the universe. -- Douglas Adams
^ permalink raw reply
* majordomo@vger.kernel.org
From: Jeff King @ 2006-02-21 7:29 UTC (permalink / raw)
To: git
subscribe git
^ permalink raw reply
* Re: [PATCH] git-mktree: reverse of git-ls-tree.
From: Keith Packard @ 2006-02-21 6:52 UTC (permalink / raw)
To: Junio C Hamano; +Cc: keithp, Tommi Virtanen, git
In-Reply-To: <7vk6bp43qm.fsf@assigned-by-dhcp.cox.net>
[-- Attachment #1: Type: text/plain, Size: 809 bytes --]
<internationalization-pedant-mode>
On Mon, 2006-02-20 at 22:37 -0800, Junio C Hamano wrote:
> + * Copyright (c) Junio C Hamano, 2006
I've been told by at least two lawyers that the string '(c)' has no
legal meaning in the US. If you want to indicate copyright, the only
symbol which does carry legal weight is the c-in-a-circle mark '©'.
Of course, this does force the issue of what encoding to present source
files in. I suggest that sources should be UTF-8, which also provides
opportunities to encode author names correctly, rather than
transliterating them to Latin. X.org uses UTF-8 for source files now
without difficulty across a wide range of compilers. Of course,
non-ascii glyphs are present only in comments.
</internationalization-pedant-mode>
--
keith.packard@intel.com
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* [PATCH] git-mktree: reverse of git-ls-tree.
From: Junio C Hamano @ 2006-02-21 6:37 UTC (permalink / raw)
To: Tommi Virtanen; +Cc: git
This reads data in the format a (non recursive) ls-tree outputs
and writes a tree object to the object database. The created
tree object name is output to the standard output.
For convenience, the input data does not need to be sorted; the
command sorts the input lines internally.
Signed-off-by: Junio C Hamano <junkio@cox.net>
---
* For the purposes of filesystem backend, I think completely
bypassing the index and having a way to handcraft a tree
object, especially if you are writing things in Python, would
be much easier to use. Hence this command.
Comments?
Makefile | 2 -
mktree.c | 137 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
2 files changed, 138 insertions(+), 1 deletions(-)
create mode 100644 mktree.c
7e37266ced5edd9a70b03ea07b5eca0d7ee82039
diff --git a/Makefile b/Makefile
index 317be3c..2f73b86 100644
--- a/Makefile
+++ b/Makefile
@@ -143,7 +143,7 @@ PROGRAMS = \
git-diff-tree$X git-fetch-pack$X git-fsck-objects$X \
git-hash-object$X git-index-pack$X git-init-db$X \
git-local-fetch$X git-ls-files$X git-ls-tree$X git-merge-base$X \
- git-merge-index$X git-mktag$X git-pack-objects$X git-patch-id$X \
+ git-merge-index$X git-mktag$X git-mktree$X git-pack-objects$X git-patch-id$X \
git-peek-remote$X git-prune-packed$X git-read-tree$X \
git-receive-pack$X git-rev-list$X git-rev-parse$X \
git-send-pack$X git-show-branch$X git-shell$X \
diff --git a/mktree.c b/mktree.c
new file mode 100644
index 0000000..f853585
--- /dev/null
+++ b/mktree.c
@@ -0,0 +1,137 @@
+/*
+ * GIT - the stupid content tracker
+ *
+ * Copyright (c) Junio C Hamano, 2006
+ */
+#include "cache.h"
+#include "strbuf.h"
+#include "quote.h"
+
+static struct treeent {
+ unsigned mode;
+ unsigned char sha1[20];
+ int len;
+ char name[FLEX_ARRAY];
+} **entries;
+static int alloc, used;
+
+static void append_to_tree(unsigned mode, unsigned char *sha1, char *path)
+{
+ struct treeent *ent;
+ int len = strlen(path);
+ if (strchr(path, '/'))
+ die("path %s contains slash", path);
+
+ if (alloc <= used) {
+ alloc = alloc_nr(used);
+ entries = xrealloc(entries, sizeof(*entries) * alloc);
+ }
+ ent = entries[used++] = xmalloc(sizeof(**entries) + len + 1);
+ ent->mode = mode;
+ ent->len = len;
+ memcpy(ent->sha1, sha1, 20);
+ memcpy(ent->name, path, len+1);
+}
+
+static int ent_compare(const void *a_, const void *b_)
+{
+ struct treeent *a = *(struct treeent **)a_;
+ struct treeent *b = *(struct treeent **)b_;
+ return base_name_compare(a->name, a->len, a->mode,
+ b->name, b->len, b->mode);
+}
+
+static void write_tree(unsigned char *sha1)
+{
+ char *buffer;
+ unsigned long size, offset;
+ int i;
+
+ qsort(entries, used, sizeof(*entries), ent_compare);
+ size = 100;
+ for (size = i = 0; i < used; i++)
+ size += 32 + entries[i]->len;
+ buffer = xmalloc(size);
+ offset = 0;
+
+ for (i = 0; i < used; i++) {
+ struct treeent *ent = entries[i];
+
+ if (offset + ent->len + 100 < size) {
+ size = alloc_nr(offset + ent->len + 100);
+ buffer = xrealloc(buffer, size);
+ }
+ offset += sprintf(buffer + offset, "%o ", ent->mode);
+ offset += sprintf(buffer + offset, "%s", ent->name);
+ buffer[offset++] = 0;
+ memcpy(buffer + offset, ent->sha1, 20);
+ offset += 20;
+ }
+ write_sha1_file(buffer, offset, "tree", sha1);
+}
+
+static const char mktree_usage[] = "mktree [-z]";
+
+int main(int ac, char **av)
+{
+ struct strbuf sb;
+ unsigned char sha1[20];
+ int line_termination = '\n';
+
+ setup_git_directory();
+
+ while ((1 < ac) && av[1][0] == '-') {
+ char *arg = av[1];
+ if (!strcmp("-z", arg))
+ line_termination = 0;
+ else
+ usage(mktree_usage);
+ ac--;
+ av++;
+ }
+
+ strbuf_init(&sb);
+ while (1) {
+ int len;
+ char *ptr, *ntr;
+ unsigned mode;
+ char type[20];
+ char *path;
+
+ read_line(&sb, stdin, line_termination);
+ if (sb.eof)
+ break;
+ len = sb.len;
+ ptr = sb.buf;
+ /* Input is non-recursive ls-tree output format
+ * mode SP type SP sha1 TAB name
+ */
+ mode = strtoul(ptr, &ntr, 8);
+ if (ptr == ntr || !ntr || *ntr != ' ')
+ die("input format error: %s", sb.buf);
+ ptr = ntr + 1; /* type */
+ ntr = strchr(ptr, ' ');
+ if (!ntr || sb.buf + len <= ntr + 41 ||
+ ntr[41] != '\t' ||
+ get_sha1_hex(ntr + 1, sha1))
+ die("input format error: %s", sb.buf);
+ if (sha1_object_info(sha1, type, NULL))
+ die("object %s unavailable", sha1_to_hex(sha1));
+ *ntr++ = 0; /* now at the beginning of SHA1 */
+ if (strcmp(ptr, type))
+ die("object type %s mismatch (%s)", ptr, type);
+ ntr += 41; /* at the beginning of name */
+ if (line_termination && ntr[0] == '"')
+ path = unquote_c_style(ntr, NULL);
+ else
+ path = ntr;
+
+ append_to_tree(mode, sha1, path);
+
+ if (path != ntr)
+ free(path);
+ }
+ write_tree(sha1);
+ puts(sha1_to_hex(sha1));
+ exit(0);
+}
--
1.2.2.g9896
^ permalink raw reply related
* Re: contrib/ area
From: Junio C Hamano @ 2006-02-21 3:58 UTC (permalink / raw)
To: git; +Cc: Ben Clifford
In-Reply-To: <Pine.OSX.4.64.0602201737260.16179@piva.hawaga.org.uk>
Ben Clifford <benc@hawaga.org.uk> writes:
> I have been keeping some (lazily-maintained) bash completion code at:
>
> http://www.hawaga.org.uk/ben/tech/gitcompletion/
>
> It isn't clear to me whether it should stay there or be merged into
> git/contrib/.
> ...
> The path of least resistence for me is to keep it at the above
> hawaga.org.uk URL, but it may be that some people would prefer it in
> the main repos.
I am OK either way. They are small enough to be in contrib/
area, and bash users may appreciate easier availability. What I
would _refuse_ to do is to maintain code for other people ;-).
As long as you or somebody else is going to keep them updated as
needed, I do not mind carrying them in contrib/.
As a practice for doing "even cooler merge", I did the
following, to see if I can treat it just like I treat gitk.
(1) give you a topic branch.
$ git checkout -b bc/completion master
(2) fetch your tip
$ git fetch http://www.hawaga.org.uk/gitcompletion.git/
(3) for a practice of a later "renaming" merge, pretend you were
one rev behind than you actually are.
$ COMMIT=`git rev-parse FETCH_HEAD^`
(4) extract things under contrib/completion/
$ git read-tree $COMMIT
$ git checkout-index --prefix=contrib/completion/ -a
(5) throw the index away, and add the files back into the real index.
$ git reset
$ git add contrib/completion
(6) write the result of "even cooler merge" out, with a merge
commit message:
$ T=`git-write-tree`
$ sed -e 's/^[0-9a-f]*/'$COMMIT/ <.git/FETCH_HEAD |
git-fmt-merge-msg |
git commit-tree $T -p `git rev-parse HEAD` -p $COMMIT
(7) a practice of later merge
$ git pull -s recursive http://www.hawaga.org.uk/gitcompletion.git/
The result is sitting at the tip of "pu" branch.
^ 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