* 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
* Re: Delta-transfer using thin-pack
From: Martin Langhoff @ 2006-02-21 2:05 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7voe13exoq.fsf@assigned-by-dhcp.cox.net>
On 2/20/06, Junio C Hamano <junkio@cox.net> wrote:
> I'll be sending out three experimental patches that would come
> on top of "next". With them, you should be able to:
I see that an updated version of this has made it to next & pu.
Cool stuff -- fetched, made, and playing w it ;-)
m
^ permalink raw reply
* Re: contrib/ area
From: Ben Clifford @ 2006-02-21 1:41 UTC (permalink / raw)
To: git; +Cc: Junio C Hamano, Aneesh Kumar
In-Reply-To: <7vmzgq451m.fsf@assigned-by-dhcp.cox.net>
> As some of you may be aware, I've added contrib/ area to git.git
> repository. Currently there are git-svn from Eric and gitview
> from Aneesh.
>
> The intention is to keep interesting tools around git, maybe
> even experimental ones, to give users an easier access to them,
> and to give tools wider exposure, so that they can be improved
> faster.
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/.
Cogito has the cogito bits of the above already included.
Stg doesn't.
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.
Ben
--
^ permalink raw reply
* Ideas for qgit
From: Pavel Roskin @ 2006-02-21 1:16 UTC (permalink / raw)
To: Marco Costalba, git
Hello, Marco!
Many thanks for releasing qgit 1.1! Here are things I'd like to be
fixed in the next version.
The pop-up menu on revisions gets duplicate entries for tags after using
the file viewer (try qgit on the qgit repository). This is a pure bug
that may merit a minor release (1.1.1 perhaps).
Tags should be in a submenu. There are too many of them in some
projects. Maybe there should be a limit of e.g. 10 tags, and the "more
tags" entry that would invoke a dialog for searching tags (and possibly
other things).
If all branches are loaded, it would be nice to be able to switch
between branches in a similar way.
The "check working dir" feature picks up files unknown to git, such as
editor backups and diff files. It is very rare that a commit only has
added files but no files are modified. Maybe I need to learn a habit of
adding any file I'm not going to commit to .gitignore, but as it stands
now, this feature of qgit seems too obtrusive to me. Neither "cg-diff"
not "stg diff" will pick untracked files, and it's not even an option
for either of them.
Current StGIT creates entries for all patches under .git/refs/patches,
which makes all corresponding entries purple. I think qgit should
specifically recognize entries under .git/refs/patches
and .git/refs/bases and use other ways to highlight them. At very
least, .git/refs/patches should be ignored. More elaborate approach
would be to draw applied StGIT patches differently, e.g. as pluses or
hollow circles.
qgit doesn't display tags except by yellow highlight. There is no tag
name and no way to see the tag object. I think one way to do it would
be to draw marks in the description column, like gitk does. Another
approach would be to put all corresponding information in the patch
description pane, perhaps highlighted.
It would be great to store the cache file somewhere under .git, perhaps
under a simpler name, such as .git/qgit-cache. The trailing ".z" should
probably be dropped, since the users are not supposed to decompress the
file or know anything about its internal structure.
Settings should be reviewed for usefulness. Some show go to the menu,
such as "Relative time in date column". It's hard to imagine that
somebody would use this option permanently. "Diff against working dir"
is already in the menu, and I don't think it merits to be in the
settings. qgit can simply remember the menu setting. "Load file names
in background" should probably become a pair of radio buttons, since the
antithesis is not obvious.
As far as I know, qgit is unique among git front-ends for being written
in a non-interpreted language. This fits well with git being designed
for speed. It would be great if qgit received its fair share of
attention from GUI experts that happen to be in the git list ;-)
--
Regards,
Pavel Roskin
^ permalink raw reply
* [PATCH] Use symlinks with rsync in core tutorial
From: Ron Parker @ 2006-02-21 0:37 UTC (permalink / raw)
To: git
From: Ron Parker <rdp@inthefaith.net>
Date: Mon Feb 20 18:05:39 2006 -0600
* Documentation/core-tutorial.txt: Use rsync -rl instead of -rL.
Signed-off-by: Ron Parker <rdp@inthefaith.net>
---
I think there is a typo in the core tutorial. It appears that symlinks
must be preserved when doing an rsync otherwise HEAD does not point to
the right ref, it becomes a copy of it. If I:
$ rsync -rL rsync://rsync.kernel.org/pub/scm/git/git.git/ .git
Then when IS
$ git-read-tree HEAD
fatal: Not a git repository
is what I get. However, doing:
$ rsync -rl ...
seems to work. The only noticeable difference is that the second
creates HEAD as a symlink.
Documentation/core-tutorial.txt | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
79ac94c0b7f8e195cf07a51c393115e7d0636069
diff --git a/Documentation/core-tutorial.txt b/Documentation/core-tutorial.txt
index 4211c81..461f845 100644
--- a/Documentation/core-tutorial.txt
+++ b/Documentation/core-tutorial.txt
@@ -724,7 +724,7 @@ create your own copy of the git reposito
----------------
$ mkdir my-git
$ cd my-git
-$ rsync -rL rsync://rsync.kernel.org/pub/scm/git/git.git/ .git
+$ rsync -rl rsync://rsync.kernel.org/pub/scm/git/git.git/ .git
----------------
followed by
--
1.2.1
^ permalink raw reply related
* Re: [PATCH] Add git-annotate, a tool for assigning blame.
From: Junio C Hamano @ 2006-02-21 0:01 UTC (permalink / raw)
To: Fredrik Kuivinen; +Cc: git, Ryan Anderson
In-Reply-To: <20060220234054.GA7903@c165.ib.student.liu.se>
Fredrik Kuivinen <freku045@student.liu.se> writes:
> I have also been working on a blame program.
Very nice to see these two.
Obviously I prefer this one for its performance ;-).
Its interface is probably friendlier when used as a preprocessor
by other tools. I can imagine GUI source viewer that fontifies
the source code and prefers to get just the origin information
from a "blame backend".
BTW, these days I always compile things with
-Wall -Wdeclaration-after-statement
which caught quite a many.
Also I have my templates/hooks--pre-commit enabled so you might
want to lindent it before inclusion.
I'll play with both a bit. Thanks for nice toys, both of you!
^ permalink raw reply
* Re: [PATCH] Makefile tweaks: Solaris 9+ dont need iconv / move up uname variables
From: Paul Jakma @ 2006-02-20 23:53 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7v3bid8umq.fsf@assigned-by-dhcp.cox.net>
On Mon, 20 Feb 2006, Junio C Hamano wrote:
> The latter two makes sense to me.
Yeah, it's handy for installs to shared volumes, e.g. I like to set
bindir to $(prefix)/arch/$(uname_P)/bin.
> I'd appreciate independent confirmations from people with Solaris 8
> and/or Solaris 9 boxes.
Seems wise ;).
Note that it doesn't change things for S8. Also, I've tested this on
Solaris 10 and fairly recent Solaris dev snapshots (snv_31). I didn't
try a test compile on S9, however I did check on an S9u7 box and
there is no libiconv to link against.
regards,
--
Paul Jakma paul@clubi.ie paul@jakma.org Key ID: 64A2FF6A
Fortune:
"Ada is the work of an architect, not a computer scientist."
- Jean Icbiah, inventor of Ada, weenie
^ permalink raw reply
* Re: [PATCH] Add git-annotate, a tool for assigning blame.
From: Fredrik Kuivinen @ 2006-02-20 23:40 UTC (permalink / raw)
To: Ryan Anderson; +Cc: Junio C Hamano, git
In-Reply-To: <11404323692193-git-send-email-ryan@michonline.com>
On Mon, Feb 20, 2006 at 05:46:09AM -0500, Ryan Anderson wrote:
> Signed-off-by: Ryan Anderson <ryan@michonline.com>
>
> ---
>
> (Pull from http://h4x0r5.com/~ryan/git/ryan.git/ annotate-upstream )
>
> I'm pretty sure this version (finally) gets the edge cases correct.
>
> I would appreciate some other testing on this, as I can't find a case
> where it falls down, but the files with a lot of history tend to have a
> lot of lines, making them hard to spotcheck without having been an
> intimate part of that history.
>
> Oh, this is the "functional" version, but it might not qualify as "nice
> looking" yet, pleaes, feel free to complain.
>
Nice work!
I have also been working on a blame program. The algorithm is pretty
much the one described by Junio in his blame.perl. My variant doesn't
handle renames, but it shouldn't be too hard to add that. The output
is minimal, just the line number followed by the commit SHA1.
An interesting observation is that the output from my git-blame and
your git-annotate doesn't match on all files in the git
repository. One example where several lines differ is read-cache.c. I
haven't investigated it further to find out which one is correct.
The code should be considered as a work in progress. It certainly has
a couple of rough edges. The output looks fairly sane on the few files
I have tested it on, but it wouldn't be too surprising if it gets some
cases wrong.
Signed-off-by: Fredrik Kuivinen <freku045@student.liu.se>
---
Makefile | 2
blame.c | 444 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
2 files changed, 445 insertions(+), 1 deletions(-)
create mode 100644 blame.c
afe1466a4f94bc72b42dce5fd1fed480c5aa4c49
diff --git a/Makefile b/Makefile
index 317be3c..4a3ffe9 100644
--- a/Makefile
+++ b/Makefile
@@ -153,7 +153,7 @@ PROGRAMS = \
git-upload-pack$X git-verify-pack$X git-write-tree$X \
git-update-ref$X git-symbolic-ref$X git-check-ref-format$X \
git-name-rev$X git-pack-redundant$X git-repo-config$X git-var$X \
- git-describe$X
+ git-describe$X git-blame$X
# what 'all' will build and 'install' will install, in gitexecdir
ALL_PROGRAMS = $(PROGRAMS) $(SIMPLE_PROGRAMS) $(SCRIPTS)
diff --git a/blame.c b/blame.c
new file mode 100644
index 0000000..d4a2fad
--- /dev/null
+++ b/blame.c
@@ -0,0 +1,444 @@
+#include <assert.h>
+
+#include "cache.h"
+#include "refs.h"
+#include "tag.h"
+#include "commit.h"
+#include "tree.h"
+#include "blob.h"
+#include "epoch.h"
+#include "diff.h"
+
+#define DEBUG 0
+
+struct commit** blame_lines;
+int num_blame_lines;
+
+struct util_info
+{
+ int* line_map;
+ int num_lines;
+ unsigned char sha1[20]; /* blob sha, not commit! */
+ char* buf;
+ unsigned long size;
+// const char* path;
+};
+
+struct chunk
+{
+ int off1, len1; // ---
+ int off2, len2; // +++
+};
+
+struct patch
+{
+ struct chunk* chunks;
+ int num;
+};
+
+static void get_blob(struct commit* commit);
+
+int num_get_patch = 0;
+int num_commits = 0;
+
+struct patch* get_patch(struct commit* commit, struct commit* other)
+{
+ struct patch* ret = xmalloc(sizeof(struct patch));
+ ret->chunks = NULL;
+ ret->num = 0;
+
+ struct util_info* info_c = (struct util_info*) commit->object.util;
+ struct util_info* info_o = (struct util_info*) other->object.util;
+
+ if(!memcmp(info_c->sha1, info_o->sha1, 20))
+ return ret;
+
+ get_blob(commit);
+ get_blob(other);
+
+ FILE* fout = fopen("/tmp/git-blame-tmp1", "w");
+ if(!fout)
+ die("fopen tmp1 failed: %s", strerror(errno));
+
+ if(fwrite(info_c->buf, info_c->size, 1, fout) != 1)
+ die("fwrite 1 failed: %s", strerror(errno));
+ fclose(fout);
+
+ fout = fopen("/tmp/git-blame-tmp2", "w");
+ if(!fout)
+ die("fopen tmp2 failed: %s", strerror(errno));
+
+ if(fwrite(info_o->buf, info_o->size, 1, fout) != 1)
+ die("fwrite 2 failed: %s", strerror(errno));
+ fclose(fout);
+
+ FILE* fin = popen("diff -u0 /tmp/git-blame-tmp1 /tmp/git-blame-tmp2", "r");
+ if(!fin)
+ die("popen failed: %s", strerror(errno));
+
+
+ char buf[1024];
+ while(fgets(buf, sizeof(buf), fin)) {
+ if(buf[0] != '@' || buf[1] != '@')
+ continue;
+
+ if(DEBUG)
+ printf("chunk line: %s", buf);
+ ret->num++;
+ ret->chunks = xrealloc(ret->chunks, sizeof(struct chunk)*ret->num);
+ struct chunk* chunk = &ret->chunks[ret->num-1];
+
+ assert(!strncmp(buf, "@@ -", 4));
+
+ char* start = buf+4;
+ char* sp = index(start, ' ');
+ *sp = '\0';
+ if(index(start, ',')) {
+ int ret = sscanf(start, "%d,%d", &chunk->off1, &chunk->len1);
+ assert(ret == 2);
+ } else {
+ int ret = sscanf(start, "%d", &chunk->off1);
+ assert(ret == 1);
+ chunk->len1 = 1;
+ }
+ *sp = ' ';
+
+ start = sp+1;
+ sp = index(start, ' ');
+ *sp = '\0';
+ if(index(start, ',')) {
+ int ret = sscanf(start, "%d,%d", &chunk->off2, &chunk->len2);
+ assert(ret == 2);
+ } else {
+ int ret = sscanf(start, "%d", &chunk->off2);
+ assert(ret == 1);
+ chunk->len2 = 1;
+ }
+ *sp = ' ';
+
+ if(chunk->off1 > 0)
+ chunk->off1 -= 1;
+ if(chunk->off2 > 0)
+ chunk->off2 -= 1;
+
+ assert(chunk->off1 >= 0);
+ assert(chunk->off2 >= 0);
+ }
+ fclose(fin);
+
+ num_get_patch++;
+ return ret;
+}
+
+void free_patch(struct patch* p)
+{
+ free(p->chunks);
+ free(p);
+}
+
+static int get_blob_sha1_internal(unsigned char *sha1, const char *base, int baselen,
+ const char *pathname, unsigned mode, int stage);
+
+
+static unsigned char blob_sha1[20];
+static int get_blob_sha1(struct tree* t, const char* pathname, unsigned char* sha1)
+{
+ const char *pathspec[2];
+ pathspec[0] = pathname;
+ pathspec[1] = NULL;
+ memset(blob_sha1, 0, sizeof(blob_sha1));
+ read_tree_recursive(t, "", 0, 0, pathspec, get_blob_sha1_internal);
+
+ int i;
+ for(i = 0; i < 20; i++) {
+ if(blob_sha1[i] != 0)
+ break;
+ }
+
+ if(i == 20)
+ return -1;
+
+ memcpy(sha1, blob_sha1, 20);
+ return 0;
+}
+
+static int get_blob_sha1_internal(unsigned char *sha1, const char *base, int baselen,
+ const char *pathname, unsigned mode, int stage)
+{
+// printf("Got blob: %s base: '%s' baselen: %d pathname: '%s' mode: %o stage: %d\n",
+// sha1_to_hex(sha1), base, baselen, pathname, mode, stage);
+
+ if(S_ISDIR(mode))
+ return READ_TREE_RECURSIVE;
+
+ memcpy(blob_sha1, sha1, 20);
+ return -1;
+}
+
+static void get_blob(struct commit* commit)
+{
+ struct util_info* info = commit->object.util;
+ char type[20];
+
+ if(info->buf)
+ return;
+
+ info->buf = read_sha1_file(info->sha1, type, &info->size);
+ assert(!strcmp(type, "blob"));
+}
+
+void print_patch(struct patch* p)
+{
+ printf("Num chunks: %d\n", p->num);
+ int i;
+ for(i = 0; i < p->num; i++) {
+ printf("%d,%d %d,%d\n", p->chunks[i].off1, p->chunks[i].len1, p->chunks[i].off2, p->chunks[i].len2);
+ }
+}
+
+
+// p is a patch from commit to other.
+void fill_line_map(struct commit* commit, struct commit* other, struct patch* p)
+{
+ int num_lines = ((struct util_info*) commit->object.util)->num_lines;
+ int* line_map = ((struct util_info*) commit->object.util)->line_map;
+ int num_lines2 = ((struct util_info*) other->object.util)->num_lines;
+ int* line_map2 = ((struct util_info*) other->object.util)->line_map;
+ int cur_chunk = 0;
+ int i1, i2;
+
+ if(p->num && DEBUG)
+ print_patch(p);
+
+ for(i1 = 0; i1 < num_lines; i1++)
+ line_map[i1] = -1;
+
+ if(DEBUG)
+ printf("num lines 1: %d num lines 2: %d\n", num_lines, num_lines2);
+
+ for(i1 = 0, i2 = 0; i1 < num_lines; i1++, i2++) {
+ if(DEBUG > 1)
+ printf("%d %d\n", i1, i2);
+
+ if(i2 >= num_lines2)
+ break;
+
+ line_map[i1] = line_map2[i2];
+
+ struct chunk* chunk = NULL;
+ if(cur_chunk < p->num)
+ chunk = &p->chunks[cur_chunk];
+
+ if(chunk && chunk->off1 == i1) {
+ i2 = chunk->off2;
+
+ if(chunk->len1 > 0)
+ i1 += chunk->len1-1;
+ if(chunk->len2 > 0)
+ i2 += chunk->len2-1;
+ cur_chunk++;
+ }
+ }
+}
+
+int map_line(struct commit* commit, int line)
+{
+ struct util_info* info = commit->object.util;
+ assert(line >= 0 && line < info->num_lines);
+ return info->line_map[line];
+}
+
+int fill_util_info(struct commit* commit, const char* path)
+{
+ if(commit->object.util)
+ return 0;
+
+ struct util_info* util = xmalloc(sizeof(struct util_info));
+ util->buf = NULL;
+ util->size = 0;
+ util->num_lines = -1;
+ util->line_map = NULL;
+
+ commit->object.util = util;
+
+ if(get_blob_sha1(commit->tree, path, util->sha1))
+ return -1;
+
+ return 0;
+}
+
+void alloc_line_map(struct commit* commit)
+{
+ struct util_info* util = commit->object.util;
+
+ if(util->line_map)
+ return;
+
+ get_blob(commit);
+
+ int i;
+ util->num_lines = 0;
+ for(i = 0; i < util->size; i++) {
+ if(util->buf[i] == '\n')
+ util->num_lines++;
+ }
+ util->line_map = xmalloc(sizeof(int)*util->num_lines);
+}
+
+void copy_line_map(struct commit* dst, struct commit* src)
+{
+ struct util_info* u_dst = dst->object.util;
+ struct util_info* u_src = src->object.util;
+
+ u_dst->line_map = u_src->line_map;
+ u_dst->num_lines = u_src->num_lines;
+ u_dst->buf = u_src->buf;
+ u_dst->size = u_src->size;
+}
+
+void process_commits(struct commit_list* list, const char* path)
+{
+ int i;
+
+ while(list) {
+ struct commit* commit = pop_commit(&list);
+ struct commit_list* parents;
+ struct util_info* info;
+
+ info = commit->object.util;
+ num_commits++;
+ if(DEBUG)
+ printf("\nProcessing commit: %d %s\n", num_commits, sha1_to_hex(commit->object.sha1));
+ for(parents = commit->parents;
+ parents != NULL; parents = parents->next) {
+ struct commit* parent = parents->item;
+
+ if(parse_commit(parent) < 0)
+ die("parse_commit error");
+
+ if(DEBUG)
+ printf("parent: %s\n", sha1_to_hex(parent->object.sha1));
+
+ if(fill_util_info(parent, path))
+ continue;
+
+ // Temporarily assign everything to the parent.
+ int num_blame = 0;
+ for(i = 0; i < num_blame_lines; i++) {
+ if(blame_lines[i] == commit) {
+ num_blame++;
+ blame_lines[i] = parent;
+ }
+ }
+
+ if(num_blame == 0)
+ continue;
+
+ struct patch* patch = get_patch(parent, commit);
+ if(patch->num == 0) {
+ copy_line_map(parent, commit);
+ } else {
+ alloc_line_map(parent);
+ fill_line_map(parent, commit, patch);
+ }
+
+ for(i = 0; i < patch->num; i++) {
+ int l;
+ for(l = 0; l < patch->chunks[i].len2; l++) {
+ int mapped_line = map_line(commit, patch->chunks[i].off2 + l);
+ if(mapped_line != -1 && blame_lines[mapped_line] == parent)
+ blame_lines[mapped_line] = commit;
+ }
+ }
+ free_patch(patch);
+ }
+ }
+}
+
+#define SEEN 1
+struct commit_list* get_commit_list(struct commit* commit, const char* pathname)
+{
+ struct commit_list* ret = NULL;
+ struct commit_list* process = NULL;
+ unsigned char sha1[20];
+
+ commit_list_insert(commit, &process);
+
+ while(process) {
+ struct commit* com = pop_commit(&process);
+ if(com->object.flags & SEEN)
+ continue;
+
+ com->object.flags |= SEEN;
+ commit_list_insert(com, &ret);
+ struct commit_list* parents;
+
+ parse_commit(com);
+
+ for(parents = com->parents;
+ parents != NULL; parents = parents->next) {
+ struct commit* parent = parents->item;
+
+ parse_commit(parent);
+
+ if(!get_blob_sha1(parent->tree, pathname, sha1))
+ commit_list_insert(parent, &process);
+ }
+ }
+
+ return ret;
+}
+
+int main(int argc, const char **argv)
+{
+ unsigned char sha1[20];
+ struct commit *commit;
+ const char* filename;
+ int i;
+
+ setup_git_directory();
+
+ if (argc != 3)
+ die("Usage: blame commit-ish file");
+
+ if (get_sha1(argv[1], sha1))
+ die("get_sha1 failed");
+
+ commit = lookup_commit_reference(sha1);
+
+ filename = argv[2];
+
+ struct commit_list* list = get_commit_list(commit, filename);
+ sort_in_topological_order(&list, 1);
+
+ if(fill_util_info(commit, filename)) {
+ printf("%s not found in %s\n", filename, argv[1]);
+ return 0;
+ }
+ alloc_line_map(commit);
+
+ struct util_info* util = commit->object.util;
+ num_blame_lines = util->num_lines;
+ blame_lines = xmalloc(sizeof(struct commit*)*num_blame_lines);
+
+
+ for(i = 0; i < num_blame_lines; i++) {
+ blame_lines[i] = commit;
+
+ ((struct util_info*) commit->object.util)->line_map[i] = i;
+ }
+
+ process_commits(list, filename);
+
+ for(i = 0; i < num_blame_lines; i++) {
+ printf("%d %s\n", i+1-1, sha1_to_hex(blame_lines[i]->object.sha1));
+// printf("%d %s\n", i+1-1, find_unique_abbrev(blame_lines[i]->object.sha1, 6));
+ }
+
+ if(DEBUG) {
+ printf("num get patch: %d\n", num_get_patch);
+ printf("num commits: %d\n", num_commits);
+ }
+
+ return 0;
+}
--
1.2.1.g62a4-dirty
^ permalink raw reply related
* [PATCH] Makefile tweaks: Solaris 9+ dont need iconv / move up uname variables
From: Paul Jakma @ 2006-02-20 23:36 UTC (permalink / raw)
To: git list; +Cc: Junio C Hamano
- Solaris 9 and up do not need -liconv, so NEEDS_LIBICONV should be set
only for S8.
- Move the declaration of the uname variables to early in the Makefile
so they can be referenced by prefix and gitexecdir variables.
- gitexecdir defaults to being same as bindir, it might as well reference
that variable.
Signed-off-by: Paul Jakma <paul@quagga.net>
---
Makefile | 15 ++++++++-------
1 files changed, 8 insertions(+), 7 deletions(-)
6ee3566e9b5408b7bfedbb6ffcdbac1be6bafbbb
diff --git a/Makefile b/Makefile
index 317be3c..a225e9c 100644
--- a/Makefile
+++ b/Makefile
@@ -70,7 +70,12 @@ all:
GIT-VERSION-FILE: .FORCE-GIT-VERSION-FILE
@$(SHELL_PATH) ./GIT-VERSION-GEN
--include GIT-VERSION-FILE
+
+uname_S := $(shell sh -c 'uname -s 2>/dev/null || echo not')
+uname_M := $(shell sh -c 'uname -m 2>/dev/null || echo not')
+uname_O := $(shell sh -c 'uname -o 2>/dev/null || echo not')
+uname_R := $(shell sh -c 'uname -r 2>/dev/null || echo not')
+uname_P := $(shell sh -c 'uname -p 2>/dev/null || echo not')
# CFLAGS and LDFLAGS are for the users to override from the command line.
@@ -82,7 +87,7 @@ STRIP ?= strip
prefix = $(HOME)
bindir = $(prefix)/bin
-gitexecdir = $(prefix)/bin
+gitexecdir = $(bindir)
template_dir = $(prefix)/share/git-core/templates/
GIT_PYTHON_DIR = $(prefix)/share/git-core/python
# DESTDIR=
@@ -212,10 +217,6 @@ shellquote = '$(call shq,$(1))'
# We choose to avoid "if .. else if .. else .. endif endif"
# because maintaining the nesting to match is a pain. If
# we had "elif" things would have been much nicer...
-uname_S := $(shell sh -c 'uname -s 2>/dev/null || echo not')
-uname_M := $(shell sh -c 'uname -m 2>/dev/null || echo not')
-uname_O := $(shell sh -c 'uname -o 2>/dev/null || echo not')
-uname_R := $(shell sh -c 'uname -r 2>/dev/null || echo not')
ifeq ($(uname_S),Darwin)
NEEDS_SSL_WITH_CRYPTO = YesPlease
@@ -230,10 +231,10 @@ endif
ifeq ($(uname_S),SunOS)
NEEDS_SOCKET = YesPlease
NEEDS_NSL = YesPlease
- NEEDS_LIBICONV = YesPlease
SHELL_PATH = /bin/bash
NO_STRCASESTR = YesPlease
ifeq ($(uname_R),5.8)
+ NEEDS_LIBICONV = YesPlease
NO_UNSETENV = YesPlease
NO_SETENV = YesPlease
endif
--
1.2.1
^ permalink raw reply related
* Re: [PATCH] Add git-annotate, a tool for assigning blame.
From: Junio C Hamano @ 2006-02-20 22:54 UTC (permalink / raw)
To: Ryan Anderson; +Cc: git
In-Reply-To: <11404323692193-git-send-email-ryan@michonline.com>
Ryan Anderson <ryan@michonline.com> writes:
> I would appreciate some other testing on this, as I can't find a case
> where it falls down, but the files with a lot of history tend to have a
> lot of lines, making them hard to spotcheck without having been an
> intimate part of that history.
I looked at a couple of files, including pack-objects.c,
rev-list.c (in "pu"), and svnimport.perl; what I saw made sense.
I think however we would want to check things with a lot of
merges, so git repository may not be a good guinea pig.
> Oh, this is the "functional" version, but it might not qualify as "nice
> looking" yet, pleaes, feel free to complain.
Nice.
Two design glitches and an implementation:
- You seem to rely on the working tree file to be clean relative to
HEAD.
- You do not take anything other than HEAD as the starting point.
Maybe an additional -r<this-version> option which defaults to
HEAD, plus reading the blob always from that tree as the
starting point would be helpful.
> + open(P,"-|","git-rev-list","--parents","--remove-empty",$rev,"--",$file)
Johannes noticed I slipped this form which Perl 5.6 does not
grok in another program. Eric pointed out he uses a backward
compatible idiom in his code.
We would need to make this one safe; something like this, perhaps:
sub open_read_pipe {
my ($fh, @cmd) = @_;
my $pid = open($fh, '-|');
die "$!" unless defined($pid);
if (!$pid) {
exec(@cmd) or die "$!";
}
return $fh;
}
...
open_read_pipe(\*P, qw(git-rev-list --parents --remove-empty),
$rev, '--', $file);
> + open(P,"-|","git-diff-tree", "-M50", "-r","--name-status", "-z","$rev")
> + or die "Failed to exec git-diff: $!";
If you do not mean "I want -M50" but you meant "I want whatever
is default", I'd leave that 50 out.
It is probably premature to talk about issues for UI that can be
built on top of this, but what I found interesting was this.
While looking at the annotate output, whenever I got curious
about one line ("Oh, this is an ancient change and by somebody
who does not feed patches to git regularly -- what was the
change about???"), I grabbed the SHA1 of the commit on the line
and threw it at "git show". It was a good way to see how the
change to the line was done in context. Maybe a two-pane UI
that shows annotate on the top pane, and activating one line
from it shows "git show" output on the bottom pane to show the
commit log plus changes the commit introduced to the file and
other files.
^ permalink raw reply
* Re: [PATCH 2/2] Add 'stg uncommit' command
From: Catalin Marinas @ 2006-02-20 22:49 UTC (permalink / raw)
To: Karl Hasselström; +Cc: git
In-Reply-To: <20060220173048.GC23501@diana.vm.bytemark.co.uk>
On 20/02/06, Karl Hasselström <kha@treskal.com> wrote:
> On 2006-02-20 17:20:47 +0000, Catalin Marinas wrote:
> > I fixed the escaping in the name_email* functions (I'll push it
> > tonight). It was adding a \ for every character it didn't know. It
> > now only escapes the quotes and back-slashes. This is needed when
> > passing the strings via the GIT_AUTHOR_* variables.
>
> 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. Maybe it's your terminal showing braces.
--
Catalin
^ permalink raw reply
* [PATCH] cvsimport: avoid open "-|" list form for Perl 5.6
From: Junio C Hamano @ 2006-02-20 22:19 UTC (permalink / raw)
To: git; +Cc: Eric Wong, Matthias Urlichs, Martin Langhoff
In-Reply-To: <7vr75xbs8w.fsf_-_@assigned-by-dhcp.cox.net>
Signed-off-by: Junio C Hamano <junkio@cox.net>
---
* Fifth of the four patch series. I cannot count ;-).
git-cvsimport.perl | 6 +++++-
1 files changed, 5 insertions(+), 1 deletions(-)
eb815c1bb8a40ae18d80e99f8547137ea05318bf
diff --git a/git-cvsimport.perl b/git-cvsimport.perl
index 24f9834..b46469a 100755
--- a/git-cvsimport.perl
+++ b/git-cvsimport.perl
@@ -846,8 +846,12 @@ while(<CVS>) {
print "Drop $fn\n" if $opt_v;
} else {
print "".($init ? "New" : "Update")." $fn: $size bytes\n" if $opt_v;
- open my $F, '-|', "git-hash-object -w $tmpname"
+ my $pid = open(my $F, '-|');
+ die $! unless defined $pid;
+ if (!$pid) {
+ exec("git-hash-object", "-w", $tmpname)
or die "Cannot create object: $!\n";
+ }
my $sha = <$F>;
chomp $sha;
close $F;
--
1.2.2.g5be4ea
^ permalink raw reply related
* [PATCH] send-email: avoid open "-|" list form for Perl 5.6
From: Junio C Hamano @ 2006-02-20 22:12 UTC (permalink / raw)
To: git; +Cc: Eric Wong, Ryan Anderson
In-Reply-To: <7vr75xbs8w.fsf_-_@assigned-by-dhcp.cox.net>
Signed-off-by: Junio C Hamano <junkio@cox.net>
---
git-send-email.perl | 39 ++++++++++++++++++++++-----------------
1 files changed, 22 insertions(+), 17 deletions(-)
044ece3bc8bde227babd2f710f8216f2cb631034
diff --git a/git-send-email.perl b/git-send-email.perl
index 13b85dd..b4f04f9 100755
--- a/git-send-email.perl
+++ b/git-send-email.perl
@@ -59,24 +59,29 @@ my $rc = GetOptions("from=s" => \$from,
# Now, let's fill any that aren't set in with defaults:
-open(GITVAR,"-|","git-var","-l")
- or die "Failed to open pipe from git-var: $!";
-
-my ($author,$committer);
-while(<GITVAR>) {
- chomp;
- my ($var,$data) = split /=/,$_,2;
- my @fields = split /\s+/, $data;
-
- my $ident = join(" ", @fields[0...(@fields-3)]);
-
- if ($var eq 'GIT_AUTHOR_IDENT') {
- $author = $ident;
- } elsif ($var eq 'GIT_COMMITTER_IDENT') {
- $committer = $ident;
- }
+sub gitvar {
+ my ($var) = @_;
+ my $fh;
+ my $pid = open($fh, '-|');
+ die "$!" unless defined $pid;
+ if (!$pid) {
+ exec('git-var', $var) or die "$!";
+ }
+ my ($val) = <$fh>;
+ close $fh or die "$!";
+ chomp($val);
+ return $val;
+}
+
+sub gitvar_ident {
+ my ($name) = @_;
+ my $val = gitvar($name);
+ my @field = split(/\s+/, $val);
+ return join(' ', @field[0...(@field-3)]);
}
-close(GITVAR);
+
+$author = gitvar_ident('GIT_AUTHOR_IDENT');
+$committer = gitvar_ident('GIT_COMMITTER_IDENT');
my $prompting = 0;
if (!defined $from) {
--
1.2.2.g5be4ea
^ permalink raw reply related
* [PATCH] svmimport: avoid open "-|" list form for Perl 5.6
From: Junio C Hamano @ 2006-02-20 22:12 UTC (permalink / raw)
To: git; +Cc: Eric Wong, Matthias Urlichs
In-Reply-To: <7vr75xbs8w.fsf_-_@assigned-by-dhcp.cox.net>
Signed-off-by: Junio C Hamano <junkio@cox.net>
---
git-svnimport.perl | 20 ++++++++++++++++----
1 files changed, 16 insertions(+), 4 deletions(-)
f7e8f8415c5c88082daecac44cfbba561113a3d9
diff --git a/git-svnimport.perl b/git-svnimport.perl
index c536d70..ee2940f 100755
--- a/git-svnimport.perl
+++ b/git-svnimport.perl
@@ -10,7 +10,6 @@
# The head revision is on branch "origin" by default.
# You can change that with the '-o' option.
-require 5.008; # for shell-safe open("-|",LIST)
use strict;
use warnings;
use Getopt::Std;
@@ -322,8 +321,12 @@ sub get_file($$$) {
return undef unless defined $name;
}
- open my $F, '-|', "git-hash-object", "-w", $name
+ my $pid = open(my $F, '-|');
+ die $! unless defined $pid;
+ if (!$pid) {
+ exec("git-hash-object", "-w", $name)
or die "Cannot create object: $!\n";
+ }
my $sha = <$F>;
chomp $sha;
close $F;
@@ -398,7 +401,12 @@ sub copy_path($$$$$$$$) {
$srcpath =~ s#/*$#/#;
}
- open my $f,"-|","git-ls-tree","-r","-z",$gitrev,$srcpath;
+ my $pid = open my $f,'-|';
+ die $! unless defined $pid;
+ if (!$pid) {
+ exec("git-ls-tree","-r","-z",$gitrev,$srcpath)
+ or die $!;
+ }
local $/ = "\0";
while(<$f>) {
chomp;
@@ -554,7 +562,11 @@ sub commit {
@o1 = @old;
@old = ();
}
- open my $F, "-|", "git-ls-files", "-z", @o1 or die $!;
+ my $pid = open my $F, "-|";
+ die "$!" unless defined $pid;
+ if (!$pid) {
+ exec("git-ls-files", "-z", @o1) or die $!;
+ }
@o1 = ();
local $/ = "\0";
while(<$F>) {
--
1.2.2.g5be4ea
^ permalink raw reply related
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