* Re: Question on GIT usage.
From: Linus Torvalds @ 2005-10-29 2:06 UTC (permalink / raw)
To: Ben Greear; +Cc: Git Mailing List
In-Reply-To: <4362C700.6020901@candelatech.com>
On Fri, 28 Oct 2005, Ben Greear wrote:
>
> I have a kernel GIT tree to hold my developing patches...
>
> I need to build this kernel for 4-5 different processors (c3, p2, p4, p4-smp,
> etc).
Sounds like you just want to use a separate build directory for the
kernel, which you can do quite independently of git (of course, not too
many people use it, so the separate-object-directory Kbuild infrastructure
has bugs every once in a while..)
The way it _should_ work is that you can do something like this:
.. have a clean source-tree in ~/src/linux ..
# set up the build tree
cd
mkdir build-tree
cd ~/src/linux
make O=~/build-tree oldconfig
# go there and build it
cd ~/build-tree
make
and now you can have a build-tree for each of your different
architectures.
Now, you _can_ certainly do the very same thing with just multiple git
repositories, and pull between them. That has its own set of advantages
too: you can have slight differences between the trees. Of course, if you
know you don't want any differences between the trees, that's not an
advantage, that's a disadvantage.
You can also have just one single real git repository, and then have that
one checked out multiple times. Use GIT_OBJECT_DIRECTORY to share the core
objects, and then you can have ten different git trees without duplicating
all your objects and pack-files.
> Is there any clever way to have this one git repository keep these
> other source trees in sync so that I can do incremental builds?
If you really want them 100%, the separate build trees is the best option.
That said, a lot of _other_ projects don't do separate build trees that
well (and as mentioned, sometimes it breaks for the kernel too), and git
certainly could be set up to be a "poor mans separate build tree".
Right now the easiest way to do that is to just have separate repositories
(and share at least _some_ objects by just using "git clone -l -s" to
clone them), but it could be hacked to be more geared explicitly towards
that..
Linus
^ permalink raw reply
* Re: Question on GIT usage.
From: Ryan Anderson @ 2005-10-29 1:43 UTC (permalink / raw)
To: Ben Greear; +Cc: Git Mailing List
In-Reply-To: <4362C700.6020901@candelatech.com>
[-- Attachment #1: Type: text/plain, Size: 846 bytes --]
Ben Greear wrote:
>
> I have a kernel GIT tree to hold my developing patches...
>
> I need to build this kernel for 4-5 different processors (c3, p2, p4,
> p4-smp, etc).
>
> Is there any clever way to have this one git repository keep these
> other source trees in sync so that I can do incremental builds?
>
> Should I perhaps have a unique git repo for each different build and
> just pull changes in from my master repo before building?
>
> If there's a simple command to set up slave repositories like this,
> please point me to it.
There isn't, not really - but in the kernel's case, you don't need one,
either.
Build with:
make O=/path/to/c3/tree
Put your .config in /path/to/c3/tree/
All your compiled stuff will drop into that tree, and your source tree
will stay untouched, so you can have a single GIT tree and source files.
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 256 bytes --]
^ permalink raw reply
* Question on GIT usage.
From: Ben Greear @ 2005-10-29 0:49 UTC (permalink / raw)
To: Git Mailing List
I have a kernel GIT tree to hold my developing patches...
I need to build this kernel for 4-5 different processors (c3, p2, p4, p4-smp, etc).
Is there any clever way to have this one git repository keep these
other source trees in sync so that I can do incremental builds?
Should I perhaps have a unique git repo for each different build and
just pull changes in from my master repo before building?
If there's a simple command to set up slave repositories like this,
please point me to it.
Thanks!
Ben
--
Ben Greear <greearb@candelatech.com>
Candela Technologies Inc http://www.candelatech.com
^ permalink raw reply
* Re: gitk shows an empty line between "Comments" and changed files
From: Linus Torvalds @ 2005-10-28 23:00 UTC (permalink / raw)
To: Pavel Roskin; +Cc: Junio C Hamano, git
In-Reply-To: <1130539503.10531.43.camel@dv>
On Fri, 28 Oct 2005, Pavel Roskin wrote:
> >
> > I do not oppose dropping the commit-id line from the default
> > output, but having it optionally available would be useful in
> > one application. Somebody _could_ write a tool that does
> > something like:
> >
> > git-rev-list ^$old_head $new_head |
> > git-diff-tree -p -m --stdin --with-commit-ids |
> > git-patch-id
>
> Sounds good. Perhaps the commit IDs should have a prefix identifying
> them.
Guys, why do you want to drop it? We've always had it, and it doesn't
really hurt.
Yes, gitk got a new empty line because I didn't realize that the output of
"git-diff-tree $commit" is slightly different from "git-diff-tree $t2
$t2", but hey, that was due to a gitk change, and I think it should be
trivial for gitk to just react to it.
So if we add a new flag, please make it go the other way: one that makes
the output really quiet, but keeps the standard output the same.
Linus
^ permalink raw reply
* Re: gitk shows an empty line between "Comments" and changed files
From: Pavel Roskin @ 2005-10-28 22:45 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7v4q72xavz.fsf@assigned-by-dhcp.cox.net>
Hi, Junio!
On Fri, 2005-10-28 at 02:13 -0700, Junio C Hamano wrote:
> Pavel Roskin <proski@gnu.org> writes:
>
> > git-patch-id is only used by git-cherry. git-cherry writes the second
> > SHA1 to some files in a temporary directory, but it never reads those
> > files, it only checks that they exist.
>
> I do not oppose dropping the commit-id line from the default
> output, but having it optionally available would be useful in
> one application. Somebody _could_ write a tool that does
> something like:
>
> git-rev-list ^$old_head $new_head |
> git-diff-tree -p -m --stdin --with-commit-ids |
> git-patch-id
Sounds good. Perhaps the commit IDs should have a prefix identifying
them.
Another approach would be to use something slightly more elaborate than
a pipe. If I understand correctly, the commit ID would be already known
from the git-rev-list output. Passing commit IDs through patch-id
without actually doing anything with them seems non-elegant. Maybe we
could teach git-patch-id (or another script) to get patches by commit-id
instead of using stdin?
--
Regards,
Pavel Roskin
^ permalink raw reply
* Re: [PATCH] Change git-cvsimport to handle slashes in CVS tags
From: H. Peter Anvin @ 2005-10-28 20:47 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Wayne Scott, Junio C Hamano, Git Mailing List
In-Reply-To: <Pine.LNX.4.64.0510281151450.4664@g5.osdl.org>
Linus Torvalds wrote:
>
> Is "_" the right thing to replace it with, though? To me, "_" replaces
> either a space or a dash, while a slash could be replaced by something
> more like a special character.
>
If nothing else it creates a nice symmetry, since CVS can't use '.' in
tags (which only is the most common character in nearly all versioning
schemes), and which is commonly replaced by '_'. We already have the -m
option to change that back to dots, so we'd go:
'/' -> '_' -> '.'
... which at least means no info loss.
-hpa
^ permalink raw reply
* Re: [PATCH] Change git-cvsimport to handle slashes in CVS tags
From: Junio C Hamano @ 2005-10-28 20:29 UTC (permalink / raw)
To: Linus Torvalds; +Cc: git
In-Reply-To: <Pine.LNX.4.64.0510281151450.4664@g5.osdl.org>
Linus Torvalds <torvalds@osdl.org> writes:
> I dunno. But maybe we do want the option of just keeping it as a slash,
> and teach git-cvsimport to create the proper subdirectory prefixes.
How about doing both?
I think patch by Johannes to allow replacing slash to arbitrary
string is a reasonable thing to have, but somebody who uses
cvsimport needs to sign that off for me -- I do not regularly
use git-ANYimport myself.
> I have no idea how to do that in perl, though. Right now it just does
>
> open(C,">$git_dir/refs/tags/$xtag")
>
> how would you do "create file with all path components"?
Something like this?
use File::Path;
my $file = "$git_dir/refs/tags/$xtag";
my ($dir) = $file =~ m/(.*)\//;
mkpath($dir) && open C, ">$file";
^ permalink raw reply
* Be more careful about reference parsing
From: Linus Torvalds @ 2005-10-28 19:41 UTC (permalink / raw)
To: Junio C Hamano, Git Mailing List
This does two things:
- we don't allow "." and ".." as components of a refname. Thus get_sha1()
will not accept "./refname" as being the same as "refname" any more.
- git-rev-parse stops doing revision translation after seeing a pathname,
to match the brhaviour of all the tools (once we see a pathname,
everything else will also be parsed as a pathname).
Basically, if you did
git log *
and "gitk" was somewhere in the "*", we don't want to replace the filename
"gitk" with the SHA1 of the branch with the same name.
Of course, if there is any change of ambiguity, you should always use "--"
to make it explicit what are filenames and what are revisions, but this
makes the normal cases sane. The refname rule also means that instead of
the "--", you can do the same thing we're used to doing with filenames
that start with a slash: use "./filename" instead, and now it's a
filename, not an option (and not a revision).
So "git log ./*.c" is now actually a perfectly valid thing to do, even if
the first C-file might have the same name as a branch.
Trivial test:
git-rev-parse gitk ./gitk gitk
should output something like
9843c3074dfbf57117565f6b7c93e3e6812857ee
./gitk
gitk
where the "./gitk" isn't seen as a revision, and the second "gitk" is a
filename simply because we've seen filenames already, and thus stopped
doing revision parsing.
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
----
I like my "ambiguous_path()" function. Now, admittedly it thinks that
".../" is also an ambigious path since it doesn't count the dots. But
since we already don't like ".." inside refnames, we don't much care.
diff --git a/rev-parse.c b/rev-parse.c
index adfc68c..169d0cc 100644
--- a/rev-parse.c
+++ b/rev-parse.c
@@ -292,6 +292,7 @@ int main(int argc, char **argv)
}
if (verify)
die("Needed a single revision");
+ as_is = 1;
show_file(arg);
}
show_default();
diff --git a/sha1_name.c b/sha1_name.c
index cc320d3..fe409fb 100644
--- a/sha1_name.c
+++ b/sha1_name.c
@@ -203,6 +203,29 @@ const char *find_unique_abbrev(const uns
return NULL;
}
+static int ambiguous_path(const char *path)
+{
+ int slash = 1;
+
+ for (;;) {
+ switch (*path++) {
+ case '\0':
+ break;
+ case '/':
+ if (slash)
+ break;
+ slash = 1;
+ continue;
+ case '.':
+ continue;
+ default:
+ slash = 0;
+ continue;
+ }
+ return slash;
+ }
+}
+
static int get_sha1_basic(const char *str, int len, unsigned char *sha1)
{
static const char *prefix[] = {
@@ -217,6 +240,10 @@ static int get_sha1_basic(const char *st
if (len == 40 && !get_sha1_hex(str, sha1))
return 0;
+ /* Accept only unambiguous ref paths. */
+ if (ambiguous_path(str))
+ return -1;
+
for (p = prefix; *p; p++) {
char *pathname = git_path("%s/%.*s", *p, len, str);
if (!read_ref(pathname, sha1))
^ permalink raw reply related
* Re: [PATCH] Change git-cvsimport to handle slashes in CVS tags
From: Linus Torvalds @ 2005-10-28 19:10 UTC (permalink / raw)
To: Wayne Scott, Junio C Hamano; +Cc: Git Mailing List
In-Reply-To: <59a6e5830510281146s7b25da76l8bf97287522b89f2@mail.gmail.com>
Hmm.. git can certainly handle slashes in tags, but you'd need to
basically "mkdir" the path up to there before creating them.
That's probably not the right thing to do for a tag that comes from the
outside, since in git, the slashes work like in a filesystem, and should
imply grouping (ie you might have a family of tags that is named by
usage, and be called something like "release/xyz" or whatever).
Is "_" the right thing to replace it with, though? To me, "_" replaces
either a space or a dash, while a slash could be replaced by something
more like a special character.
Maybe it's just me, but your example "dev-stubs-merge-8-1-3/9/99" might
look nicer either of these ways:
- dev-stubs-merge-8-1-3|9|99 (but "|" is hard to use with shell)
- dev-stubs-merge-8-1-3.9.99 (CVS tags can't contain '.', right?)
- dev-stubs-merge-8-1-3:9:99 (confuse with time?)
- dev-stubs-merge-8-1-3+9+99 (one arithmetic op replaced by another)
- dev-stubs-merge-8-1-3#9#99 (that's pretty ugly)
- dev-stubs-merge-8-1-3?9?99 (Wayne might be right after all)
- dev-stubs-merge-8-1-3_9_99 (maybe Wayne _is_ right?)
I dunno. But maybe we do want the option of just keeping it as a slash,
and teach git-cvsimport to create the proper subdirectory prefixes.
I have no idea how to do that in perl, though. Right now it just does
open(C,">$git_dir/refs/tags/$xtag")
how would you do "create file with all path components"?
Linus
^ permalink raw reply
* Re: [PATCH] Change git-cvsimport to handle slashes in CVS tags
From: Johannes Schindelin @ 2005-10-28 18:58 UTC (permalink / raw)
To: Wayne Scott; +Cc: git
In-Reply-To: <59a6e5830510281146s7b25da76l8bf97287522b89f2@mail.gmail.com>
Hi,
http://www.gelato.unsw.edu.au/archives/git/0508/7825.html
Ciao,
Dscho
^ permalink raw reply
* [PATCH] Change git-cvsimport to handle slashes in CVS tags
From: Wayne Scott @ 2005-10-28 18:46 UTC (permalink / raw)
To: git
The Tcl/Tk CVS tree contains some tags like this one:
dev-stubs-merge-8-1-3/9/99
CVS doesn't mind that tag, but git can't handle the slash
characters in the tag. Just change those to underscore
so imports can complete.
Signed-off-by: Wayne Scott <wsc9tt@gmail.com>
---
git-cvsimport.perl | 1 +
1 files changed, 1 insertions(+), 0 deletions(-)
applies-to: cf6439199f61d87dbb70fd7b43144e41462a359d
225c95454711467fc889c15cb3f7ca3230fce58d
diff --git a/git-cvsimport.perl b/git-cvsimport.perl
index bbb83fb..d71c30c 100755
--- a/git-cvsimport.perl
+++ b/git-cvsimport.perl
@@ -636,6 +636,7 @@ my $commit = sub {
my($xtag) = $tag;
$xtag =~ s/\s+\*\*.*$//; # Remove stuff like ** INVALID ** and *
* FUNKY **
$xtag =~ tr/_/\./ if ( $opt_u );
+ $xtag =~ tr/\//_/;
my $pid = open2($in, $out, 'git-mktag');
print $out "object $cid\n".
---
0.99.8.GIT
^ permalink raw reply related
* [PATCH] Documentation changes to recursive option for git-diff-tree
From: Chris Shoemaker @ 2005-10-28 17:04 UTC (permalink / raw)
To: git; +Cc: Junio C Hamano
Subject: [PATCH] Documentation changes to recursive option for git-diff-tree
Update docs and usages regarding '-r' recursive option for git-diff-tree.
Remove '-r' from common diff options, mention it only for git-diff-tree.
Remove one extraneous use of '-r' with git-diff-files in get-merge.sh.
Sync the synopsis and usage string for git-diff-tree.
Signed-off-by: Chris Shoemaker <c.shoemaker at cox.net>
---
My first real patch with git. Did I do it right?
-chris
Documentation/git-diff-tree.txt | 5 ++++-
diff-tree.c | 6 ++++--
diff.h | 1 -
git-merge.sh | 2 +-
4 files changed, 9 insertions(+), 5 deletions(-)
4b20f7c39762c54c414eb92d17180064c7ccbde9
diff --git a/Documentation/git-diff-tree.txt b/Documentation/git-diff-tree.txt
--- a/Documentation/git-diff-tree.txt
+++ b/Documentation/git-diff-tree.txt
@@ -8,7 +8,7 @@ git-diff-tree - Compares the content and
SYNOPSIS
--------
-'git-diff-tree' [--stdin] [-m] [-s] [-v] [--pretty] [-t] [<common diff options>] <tree-ish> [<tree-ish>] [<path>...]
+'git-diff-tree' [--stdin] [-m] [-s] [-v] [--pretty] [-t] [-r] [--root] [<common diff options>] <tree-ish> [<tree-ish>] [<path>...]
DESCRIPTION
-----------
@@ -33,6 +33,9 @@ include::diff-options.txt[]
Note that this parameter does not provide any wildcard or regexp
features.
+-r::
+ recurse into sub-trees
+
-t::
show tree entry itself as well as subtrees. Implies -r.
diff --git a/diff-tree.c b/diff-tree.c
--- a/diff-tree.c
+++ b/diff-tree.c
@@ -149,8 +149,10 @@ static int diff_tree_stdin(char *line)
}
static const char diff_tree_usage[] =
-"git-diff-tree [--stdin] [-m] [-s] [-v] [--pretty] [-t] "
-"[<common diff options>] <tree-ish> <tree-ish>"
+"git-diff-tree [--stdin] [-m] [-s] [-v] [--pretty] [-t] [-r] [--root] "
+"[<common diff options>] <tree-ish> [<tree-ish>] [<path>...]\n"
+" -r diff recursively\n"
+" --root include the initial commit as diff against /dev/null\n"
COMMON_DIFF_OPTIONS_HELP;
int main(int argc, const char **argv)
diff --git a/diff.h b/diff.h
--- a/diff.h
+++ b/diff.h
@@ -91,7 +91,6 @@ extern void diffcore_std_no_resolve(stru
#define COMMON_DIFF_OPTIONS_HELP \
"\ncommon diff options:\n" \
-" -r diff recursively (only meaningful in diff-tree)\n" \
" -z output diff-raw with lines terminated with NUL.\n" \
" -p output patch format.\n" \
" -u synonym for -p.\n" \
diff --git a/git-merge.sh b/git-merge.sh
--- a/git-merge.sh
+++ b/git-merge.sh
@@ -25,7 +25,7 @@ dropsave() {
savestate() {
# Stash away any local modifications.
- git-diff-index -r -z --name-only $head |
+ git-diff-index -z --name-only $head |
cpio -0 -o >"$GIT_DIR/MERGE_SAVE"
}
^ permalink raw reply
* Be marginally more careful about removing objects
From: Linus Torvalds @ 2005-10-28 16:45 UTC (permalink / raw)
To: Junio C Hamano, Git Mailing List
The git philosophy when it comes to disk accesses is "Laugh in the face of
danger".
Notably, since we never modify an existing object, we don't really care
that deeply about flushing things to disk, since even if the machine
crashes in the middle of a git operation, you can never really have lost
any old work. At most, you'd need to figure out the proper heads (which
git-fsck-objects can do for you) and re-do the operation.
However, there's two exceptions to this: pruning and repacking. Those
operations will actually _delete_ old objects that they know about in
other ways (ie that they just repacked, or that they have found in other
places).
However, since they actually modify old state, we should thus be a bit
more careful about them. If the machine crashes and the duplicate new
objects haven't been flushed to disk, you can actually be in trouble.
This is trivially stupid about it by calling "sync" before removing the
objects. Not very smart, but we're talking about special operations than
are usually done once a week if that.
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
---
diff --git a/git-prune.sh b/git-prune.sh
index b28630c..ef31bd2 100755
--- a/git-prune.sh
+++ b/git-prune.sh
@@ -15,6 +15,7 @@ do
shift;
done
+sync
git-fsck-objects --full --cache --unreachable "$@" |
sed -ne '/unreachable /{
s/unreachable [^ ][^ ]* //
diff --git a/git-repack.sh b/git-repack.sh
index 49547a7..d341966 100755
--- a/git-repack.sh
+++ b/git-repack.sh
@@ -62,6 +62,7 @@ then
# all-into-one is used.
if test "$all_into_one" != '' && test "$existing" != ''
then
+ sync
( cd "$PACKDIR" &&
for e in $existing
do
diff --git a/prune-packed.c b/prune-packed.c
index 16685d1..26123f7 100644
--- a/prune-packed.c
+++ b/prune-packed.c
@@ -71,6 +71,7 @@ int main(int argc, char **argv)
/* Handle arguments here .. */
usage(prune_packed_usage);
}
+ sync();
prune_packed_objects();
return 0;
}
^ permalink raw reply related
* Re: [PATCH gitweb] Visually indicating patch size with horizontal bars
From: Linus Torvalds @ 2005-10-28 16:02 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Martin Langhoff, Chris Shoemaker, git
In-Reply-To: <7vr7a6z4bc.fsf@assigned-by-dhcp.cox.net>
On Thu, 27 Oct 2005, Junio C Hamano wrote:
>
> Linus Torvalds <torvalds@osdl.org> writes:
>
> > Well, if you do full copy detection (and break detection), then
> > git-diff-tree will actually have effectively calculated the size of the
> > diff of each file. It just doesn't print them (well, it does a percentage
> > for the renames/copies).
>
> Unbroken in-place edit would never go through diffcore-rename,
> so that is a gross overstatement.
Well, the break detection will have _calculated_ the diff size.
The point being that all the work has been done - it's just not printed
out.
Linus
^ permalink raw reply
* Re: [PATCH] Link git-name-rev and git-symbolic-ref from the main git page
From: Johannes Schindelin @ 2005-10-28 9:36 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vzmouvw9r.fsf@assigned-by-dhcp.cox.net>
Hi,
On Fri, 28 Oct 2005, Junio C Hamano wrote:
> Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
>
> > I did not do it right away, because I did not expect that it
> > was merged into master *that* fast.
>
> Sorry, but I am more inclusive kind than Linus was.
That is wonderful! I only have to learn to test my patches thoroughly
before sending them out...
BTW I think I forgot to tell that my recent patch series supersedes what
is in pu.
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH gitweb] Visually indicating patch size with horizontal bars
From: Junio C Hamano @ 2005-10-28 9:31 UTC (permalink / raw)
To: Chris Shoemaker; +Cc: git
In-Reply-To: <20051028005029.GA2654@pe.Belkin>
Chris Shoemaker <c.shoemaker@cox.net> writes:
> Ok, but that cache would live inside GIT_DIR an be shared with gitk,
> right?
It is up to gitk. If your cache file format is simple, concise
and easy to access, then it might be useful for gitk to take
advantage of it. Although I doubt many people would run gitk
and gitweb on the same repository (usually the former is run on
the private developer repository and the latter public one).
Caching the 'git-diff-tree -p | git-apply --numstat' output
might be useful and compact enough. I often wonder if the
commit page (i.e. gitweb?p=$repository;a=commit;h=$sha1) might
be more useful if it had diffstat drawing on each blob line at
the end of the page, and the output from the above pipe can be
used for that.
I wonder how big that thing would become if we cache it for the
whole history, using something simple and lightweight like
berkeley db or dbm, 20-byte commit ID as the key (for now,
ignoring merges, but we could use 40-byte commit-parent ID pair
as the key) and a list of the number of insertions and deletions
for affected paths as the value. If we can do it quickly
enough, you could put the cache update in post-update hook, so
that every time you push into the public repository the
patch-size cache is updated for gitweb's use. This can be done
by the repository owner, and gitweb can stay read-only consumer
of the information.
Just in case people find this useful, here is a patch to
implement git-apply --numstat.
------------
[PATCH] git-apply --numstat
The new option, --numstat, shows number of inserted and deleted
lines for each path. It is similar to --stat output but is
meant to be more machine friendly by giving number of added and
deleted lines and unabbreviated paths.
Signed-off-by: Junio C Hamano <junkio@cox.net>
---
git diff
diff --git a/apply.c b/apply.c
index e5c0b7d..73dfd0c 100644
--- a/apply.c
+++ b/apply.c
@@ -13,18 +13,20 @@
// --check turns on checking that the working tree matches the
// files that are being modified, but doesn't apply the patch
// --stat does just a diffstat, and doesn't actually apply
+// --numstat does numeric diffstat, and doesn't actually apply
// --index-info shows the old and new index info for paths if available.
//
static int check_index = 0;
static int write_index = 0;
static int diffstat = 0;
+static int numstat = 0;
static int summary = 0;
static int check = 0;
static int apply = 1;
static int show_index_info = 0;
static int line_termination = '\n';
static const char apply_usage[] =
-"git-apply [--stat] [--summary] [--check] [--index] [--apply] [--index-info] [-z] <patch>...";
+"git-apply [--stat] [--numstat] [--summary] [--check] [--index] [--apply] [--index-info] [-z] <patch>...";
/*
* For "diff-stat" like behaviour, we keep track of the biggest change
@@ -1317,6 +1319,20 @@ static void stat_patch_list(struct patch
printf(" %d files changed, %d insertions(+), %d deletions(-)\n", files, adds, dels);
}
+static void numstat_patch_list(struct patch *patch)
+{
+ for ( ; patch; patch = patch->next) {
+ const char *name;
+ name = patch->old_name ? patch->old_name : patch->new_name;
+ printf("%d\t%d\t", patch->lines_added, patch->lines_deleted);
+ if (line_termination && quote_c_style(name, NULL, NULL, 0))
+ quote_c_style(name, NULL, stdout, 0);
+ else
+ fputs(name, stdout);
+ putchar('\n');
+ }
+}
+
static void show_file_mode_name(const char *newdelete, unsigned int mode, const char *name)
{
if (mode)
@@ -1650,6 +1666,9 @@ static int apply_patch(int fd)
if (diffstat)
stat_patch_list(list);
+ if (numstat)
+ numstat_patch_list(list);
+
if (summary)
summary_patch_list(list);
@@ -1683,6 +1702,11 @@ int main(int argc, char **argv)
diffstat = 1;
continue;
}
+ if (!strcmp(arg, "--numstat")) {
+ apply = 0;
+ numstat = 1;
+ continue;
+ }
if (!strcmp(arg, "--summary")) {
apply = 0;
summary = 1;
^ permalink raw reply related
* Re: [PATCH gitweb] Visually indicating patch size with horizontal bars
From: Josef Weidendorfer @ 2005-10-28 9:16 UTC (permalink / raw)
To: git
In-Reply-To: <20051027203945.GC1622@pe.Belkin>
On Thursday 27 October 2005 22:39, Chris Shoemaker wrote:
>
> I really like gitweb (thanks Kay!), but I thought it would be nice to
> have a visual indication of patch size. I found this helpful when
> scanning though the shortlogs.
Looks nice.
What about splitting this up into red (removed lines)
and green (added lines) bars?
Josef
^ permalink raw reply
* Re: [PATCH] Link git-name-rev and git-symbolic-ref from the main git page
From: Junio C Hamano @ 2005-10-28 9:14 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git
In-Reply-To: <Pine.LNX.4.63.0510271156520.16500@wbgn013.biozentrum.uni-wuerzburg.de>
Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> I did not do it right away, because I did not expect that it
> was merged into master *that* fast.
Sorry, but I am more inclusive kind than Linus was.
^ permalink raw reply
* Re: gitk shows an empty line between "Comments" and changed files
From: Junio C Hamano @ 2005-10-28 9:13 UTC (permalink / raw)
To: Pavel Roskin; +Cc: git
In-Reply-To: <1130463389.2186.14.camel@dv>
Pavel Roskin <proski@gnu.org> writes:
> git-patch-id is only used by git-cherry. git-cherry writes the second
> SHA1 to some files in a temporary directory, but it never reads those
> files, it only checks that they exist.
I do not oppose dropping the commit-id line from the default
output, but having it optionally available would be useful in
one application. Somebody _could_ write a tool that does
something like:
git-rev-list ^$old_head $new_head |
git-diff-tree -p -m --stdin --with-commit-ids |
git-patch-id
to cache the patch-id --> commit-id mappings. If this were kept
on the upstream repo for public query, it would be useful for
you to find out if your favorite patch as already been merged.
For example, gitweb could have an query page to let you submit a
patch-id and return the commit (or "no such patch merged yet").
^ permalink raw reply
* Re: [PATCH gitweb] Visually indicating patch size with horizontal bars
From: Andreas Ericsson @ 2005-10-28 8:29 UTC (permalink / raw)
To: git
In-Reply-To: <43617B47.3070008@zytor.com>
H. Peter Anvin wrote:
> Chris Shoemaker wrote:
>
>>
>> Ok, but that cache would live inside GIT_DIR an be shared with gitk,
>> right?
>>
>
> That would be bad. Don't assume that the person running gitweb (or
> gitk, for that matter) has write permission.
>
Not necessarily in the archive, but it could support a --cache-dir
option. If no cache-dir directive is used it could try GIT_DIR/cache and
go on as usual if that fails too.
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
^ permalink raw reply
* Re: [PATCH] Avoid using dc in git-count-objects
From: H. Peter Anvin @ 2005-10-28 5:22 UTC (permalink / raw)
To: Herbert Xu; +Cc: Linus Torvalds, smurf, git
In-Reply-To: <20051028045837.GA1167@gondor.apana.org.au>
Herbert Xu wrote:
> On Thu, Oct 27, 2005 at 09:34:30PM -0700, H. Peter Anvin wrote:
>
>>>Perhaps you could use dash for your project as well?
>>
>>Depends on how big it is.
>
>
> I just noticed that you were building it with -Os. So I built
> dash with -Os and this is what I get:
>
> $ size dash
> text data bss dec hex filename
> 64397 884 10240 75521 12701 dash
> $ size klibc-1.1.1/ash/sh.shared
> text data bss dec hex filename
> 66237 424 70908 137569 21961 klibc-1.1.1/ash/sh.shared
>
> So it looks like as long as dash can link with klibc then:
>
> 1) It should be smaller in size.
> 2) It should be more stable due to much wider testing coverage (Debian).
> 3) You get some extra bells & whistles thrown in for free like printf.
>
> I'll let you know when I have a version that links with klibc.
>
> Cheers,
Cool, thanks!
-hpa
^ permalink raw reply
* Re: [PATCH] Avoid using dc in git-count-objects
From: Herbert Xu @ 2005-10-28 4:58 UTC (permalink / raw)
To: H. Peter Anvin; +Cc: Linus Torvalds, smurf, git
In-Reply-To: <4361AA56.2090906@zytor.com>
On Thu, Oct 27, 2005 at 09:34:30PM -0700, H. Peter Anvin wrote:
>
> >Perhaps you could use dash for your project as well?
>
> Depends on how big it is.
I just noticed that you were building it with -Os. So I built
dash with -Os and this is what I get:
$ size dash
text data bss dec hex filename
64397 884 10240 75521 12701 dash
$ size klibc-1.1.1/ash/sh.shared
text data bss dec hex filename
66237 424 70908 137569 21961 klibc-1.1.1/ash/sh.shared
So it looks like as long as dash can link with klibc then:
1) It should be smaller in size.
2) It should be more stable due to much wider testing coverage (Debian).
3) You get some extra bells & whistles thrown in for free like printf.
I'll let you know when I have a version that links with klibc.
Cheers,
--
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
^ permalink raw reply
* Re: [PATCH] Avoid using dc in git-count-objects
From: H. Peter Anvin @ 2005-10-28 4:34 UTC (permalink / raw)
To: Herbert Xu; +Cc: Linus Torvalds, smurf, git
In-Reply-To: <20051028043211.GA781@gondor.apana.org.au>
Herbert Xu wrote:
> On Thu, Oct 27, 2005 at 09:14:51PM -0700, H. Peter Anvin wrote:
>
>>Current ash also has these features, and is about that size compiled
>>static with klibc :)
>
>
> Interesting. I just tried it on my POSIX testsuite and unfortunately
> it failed a number of simple tests including the case statement and
> segfaulted on quite a few occasions too. I've included one of the
> segfault scripts here.
>
> Dash is already used in busybox where it has been linked with ulibc.
> So it can't be that hard to make it work with klibc.
>
> Perhaps you could use dash for your project as well?
>
Depends on how big it is.
-hpa
^ permalink raw reply
* Re: [PATCH] Avoid using dc in git-count-objects
From: Herbert Xu @ 2005-10-28 4:32 UTC (permalink / raw)
To: H. Peter Anvin; +Cc: Linus Torvalds, smurf, git
In-Reply-To: <4361A5BB.5040100@zytor.com>
[-- Attachment #1: Type: text/plain, Size: 787 bytes --]
On Thu, Oct 27, 2005 at 09:14:51PM -0700, H. Peter Anvin wrote:
>
> Current ash also has these features, and is about that size compiled
> static with klibc :)
Interesting. I just tried it on my POSIX testsuite and unfortunately
it failed a number of simple tests including the case statement and
segfaulted on quite a few occasions too. I've included one of the
segfault scripts here.
Dash is already used in busybox where it has been linked with ulibc.
So it can't be that hard to make it work with klibc.
Perhaps you could use dash for your project as well?
Cheers,
--
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
[-- Attachment #2: dotcmd --]
[-- Type: text/plain, Size: 172 bytes --]
trap 'rm -f $TMP' EXIT
TMP=$(tempfile)
cat <<- EOF > $TMP
return
echo not here
EOF
a() {
. $TMP
echo here
}
a
cat <<- EOF > $TMP
exit
EOF
(false; . $TMP)
echo $?
^ permalink raw reply
* Re: [PATCH] Avoid using dc in git-count-objects
From: H. Peter Anvin @ 2005-10-28 4:14 UTC (permalink / raw)
To: Herbert Xu; +Cc: Linus Torvalds, smurf, git
In-Reply-To: <E1EVKmt-0003xn-00@gondolin.me.apana.org.au>
Herbert Xu wrote:
> Linus Torvalds <torvalds@osdl.org> wrote:
>
>>Oh - there's another similarity between $(..) and $((..)). They're both
>>POSIX 1003.2 standard features, so any "modern" shell should support them.
>>Although in practice I don't know if that means anything else than ksh
>>(where both syntaxes came from, actually).
>
>
> There is also dash (http://gondor.apana.org.au/~herbert/dash/).
> It complies with POSIX, is less than half the size of pdksh (83960 bytes
> currently on i386), and is faster than pdksh.
Current ash also has these features, and is about that size compiled
static with klibc :)
-hpa
^ 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