* Re: The criss-cross merge case
From: Daniel Barkalow @ 2005-04-27 23:32 UTC (permalink / raw)
To: Bram Cohen; +Cc: git
In-Reply-To: <Pine.LNX.4.44.0504271254120.4678-100000@wax.eds.org>
On Wed, 27 Apr 2005, Bram Cohen wrote:
> The way Git handles this currently is very bad, because it forces the
> common ancestor to be from the same snapshot across all files, so this
> problem will happen if the modifications are made even in different files,
> not just different lines within the same file. That could be improved
> greatly by finding an LCA for each file individually, which is what
> Monotone does.
The git core is perfectly sufficient for getting all LCAs or
per-file best LCAs; merge-base doesn't bother, currently, because the
deficiencies of "merge" (a.k.a. diff3) are worse than the issues with
chosing a suboptimal LCA.
My plan is to implement multi-file diff and merge with a suffix tree-based
algorithm, and then revisit the history stuff once we have a merger that
can do sensible things with this information.
Note that the present very bad merger is actually seems to be sufficient
for the Linux kernel, where patches from different sides of a merge are
generally either unrelated or are identical, and, otherwise, they tend to
be true conflicts where people fixed the same bug independantly in
different ways.
> Darcs, Codeville, and all the Arch descendants have better merge
> algorithms which don't have to pick a single common ancestor.
I've been looking at Darcs (which seems to have a good method, although I
think the underlying diff isn't great), and Codeville still doesn't have
any documentation. Arch's method is strictly weaker than 3-way merge, and
generates more rejects (not even conflicts) in my experience than even
CVS.
-Daniel
*This .sig left intentionally blank*
^ permalink raw reply
* Re: PATCH: Allow tree-id to return the ID of a tree object
From: Petr Baudis @ 2005-04-27 23:22 UTC (permalink / raw)
To: Philip Pokorny; +Cc: git
In-Reply-To: <426FBBE7.1090806@mindspring.com>
Dear diary, on Wed, Apr 27, 2005 at 06:20:55PM CEST, I got a letter
where Philip Pokorny <ppokorny@mindspring.com> told me that...
> While playing with cg-ls, I tried:
>
> % cg-ls
> ... snip ...
> 100644 blob bc607fd55f6ce4e56ce87766369b5d4d55ec79af object.h
> 100755 blob f35877a6aa5b68d2fb4a388dcfa9b3e64262604e parent-id
> 040000 tree bfb75011c32589b282dd9c86621dadb0f0bb3866 ppc
> 100644 blob d922305ee0f5583bdfcb629f6d4061e11e0fa859 read-cache.c
> 100644 blob 1ad7ffc555b635fe57fa7834b12d71ff576be065 read-tree.c
> ... snip ...
> % cg-ls bfb75011c32589b282dd9c86621dadb0f0bb3866 <-- the ppc tree ID
> Invalid id: bfb75011c32589b282dd9c86621dadb0f0bb3866
> usage: cat-file [-t | tagname] <sha1>
> usage: cat-file [-t | tagname] <sha1>
> Invalid id:
>
>
> Shouldn't cg-ls give a listing of a sub-tree? The cg-help says it takes
> a TREE-ID?
>
> The problem seems to be that tree-id really only accepts a commit-id and
> returns the TREE-ID of that commit.
>
> So I modified commit-id, tree-id and parent-id to make them more similar
> in coding style, force "short-id" names to be at least 4 lower case
> letters, and have tree-id accept short, unambiguous ID's and bare SHA1-ID's.
>
> Patch attached.
Could you please functionally split and sign off your patch?
Also, I'd prefer not to have the sha1 completion logic duplicated; what
about just having commit-id take a parameter not to validate its id?
Actually, that's ugly too. I think the cleanest solution would be to
reintroduce the cg-Xnormid, now to only really do the _common_ stuff -
basically everything up to the typecheck (exclusively) in commit-id.
--
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
C++: an octopus made by nailing extra legs onto a dog. -- Steve Taylor
^ permalink raw reply
* Re: import mbox?
From: Linus Torvalds @ 2005-04-27 23:21 UTC (permalink / raw)
To: Jeff Garzik; +Cc: Git Mailing List
In-Reply-To: <42701B79.8080106@pobox.com>
On Wed, 27 Apr 2005, Jeff Garzik wrote:
>
> Sorry for the FAQ, but I didn't see this in any of the scripts in the
> 'git' archives, nor in the README.
>
> What script should kernel developers use, to import an mbox full of patches?
I've got a "tools" project at
kernel.org:/pub/linux/kernel/people/torvalds/git-tools.git
which has my old "dotest" scripts re-written for git (yeah, yeah, three
years and two generations later, I still call the damn thing "dotest". I'm
not very good at this tool naming thing ;)
Linus
^ permalink raw reply
* [PATCH (take 2)] Use diff-tree -p instead of "git diff" in git-export.
From: Junio C Hamano @ 2005-04-27 23:18 UTC (permalink / raw)
To: Linus Torvalds; +Cc: git
Now diff-tree can produce patch itself, there is no reason to
depend on Cogito to show diff in the git-export output anymore.
Signed-off-by: Junio C Hamano <junkio@cox.net>
---
This is a reworked patch---we just made -p to imply recursive so
we can just say diff-tree -p, not diff-tree -p -r like I said in
the previous patch.
git-export.c | 2 +-
1 files changed, 1 insertion(+), 1 deletion(-)
--- k/git-export.c
+++ l/git-export.c
@@ -18,7 +18,7 @@ void show_commit(struct commit *commit)
char *against = sha1_to_hex(commit->parents->item->object.sha1);
printf("\n\n======== diff against %s ========\n", against);
fflush(NULL);
- sprintf(cmdline, "git diff -r %s:%s", against, hex);
+ sprintf(cmdline, "diff-tree -p %s %s", against, hex);
system(cmdline);
}
printf("======== end ========\n\n");
^ permalink raw reply
* Re: git pull on ia64 linux tree
From: Linus Torvalds @ 2005-04-27 23:19 UTC (permalink / raw)
To: Petr Baudis; +Cc: Luck, Tony, git
In-Reply-To: <20050427225821.GI22956@pasky.ji.cz>
On Thu, 28 Apr 2005, Petr Baudis wrote:
>
> Actually, grep has -z parameter. ;-)
Ahh. It's not even mentioned in the grep man-page (which mentions -Z, but
that's for grep _output_, not input).
Linus
^ permalink raw reply
* Re: import mbox?
From: Petr Baudis @ 2005-04-27 23:14 UTC (permalink / raw)
To: Jeff Garzik; +Cc: Linus Torvalds, Git Mailing List
In-Reply-To: <42701B79.8080106@pobox.com>
Dear diary, on Thu, Apr 28, 2005 at 01:08:41AM CEST, I got a letter
where Jeff Garzik <jgarzik@pobox.com> told me that...
> Sorry for the FAQ, but I didn't see this in any of the scripts in the
> 'git' archives, nor in the README.
>
> What script should kernel developers use, to import an mbox full of patches?
There is git-tools. One of the many ways how to get it is
$ cg-clone rsync://rsync.kernel.org/pub/linux/kernel/people/torvalds/git-tools.git
Note that AFAIK it does not set $AUTHOR_DATE properly; patches were
posted to this mailing list to fix this.
--
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
C++: an octopus made by nailing extra legs onto a dog. -- Steve Taylor
^ permalink raw reply
* Re: [PATCH] Make -s flag to show-diff a no-op.
From: Junio C Hamano @ 2005-04-27 23:11 UTC (permalink / raw)
To: Linus Torvalds; +Cc: git
In-Reply-To: <Pine.LNX.4.58.0504271600280.18901@ppc970.osdl.org>
>>>>> "LT" == Linus Torvalds <torvalds@osdl.org> writes:
LT> Well, if you give pathnames, it's always going to limit recursion to only
LT> those subdirectories that match one of them.
If that is the case then -p should imply -r. Will fix it up.
^ permalink raw reply
* import mbox?
From: Jeff Garzik @ 2005-04-27 23:08 UTC (permalink / raw)
To: Linus Torvalds, Git Mailing List
Sorry for the FAQ, but I didn't see this in any of the scripts in the
'git' archives, nor in the README.
What script should kernel developers use, to import an mbox full of patches?
Thanks,
Jeff
^ permalink raw reply
* Re: [PATCH] Make -s flag to show-diff a no-op.
From: Linus Torvalds @ 2005-04-27 23:05 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7v64y7etko.fsf@assigned-by-dhcp.cox.net>
On Wed, 27 Apr 2005, Junio C Hamano wrote:
>
> When I know which path I am interested in,
>
> $ diff-tree -p <tree-1> <tree-2> ls-tree.c
>
> would still get the benefit of not descending down into ppc and
> mozilla-sha1 subdirectories, if I am not mistaken.
It won't. It will see that those two aren't interesting, because they
don't match the pathname, so it will ignore them regardless of whether
there is a -r or not.
> Think of the kernel sources, and I would say leaving the option
> of not recursing down is a good thing.
Well, if you give pathnames, it's always going to limit recursion to only
those subdirectories that match one of them.
And if you don't give pathnames, then nor recursing will do something
pretty strange, ie give a diff of only the files in the top-level
directory, and totally ignore the subdirectories that did change:
torvalds@ppc970:~/v2.6/linux> diff-tree e8108c98dd6d65613fa0ec9d2300f89c48d554bf $(cat .git/HEAD)
*040000->040000 tree d44b45026cd1c9530a78756b11d6bb9a78718cc3->474afcccb9cac147aa3b95a9afdd91c2edb139f5 arch
*040000->040000 tree 2394cd732a73c793ba93c32be6e7f058bd7171d8->da5f26fc8b12defe39e58b76e8087281effbf6bf drivers
*040000->040000 tree 8d5010b0ff2b7325131536c63ed04071a563e310->cf51450069a2ab187b611599d1a0e037f176c6c3 fs
*040000->040000 tree a06b4fb363dcfd3225cfe3ac3a0aa02e8d628975->c27a22db91b056499a5c1198ace432768475b5bd include
and then
torvalds@ppc970:~/v2.6/linux> diff-tree -p e8108c98dd6d65613fa0ec9d2300f89c48d554bf $(cat .git/HEAD)
<no output what-so-ever>
where showing things as if nothing changed seems to be actively _wrong_,
I'd say..
Linus
^ permalink raw reply
* Re: git pull on ia64 linux tree
From: Petr Baudis @ 2005-04-27 22:58 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Luck, Tony, git
In-Reply-To: <Pine.LNX.4.58.0504271525520.18901@ppc970.osdl.org>
Dear diary, on Thu, Apr 28, 2005 at 12:35:07AM CEST, I got a letter
where Linus Torvalds <torvalds@osdl.org> told me that...
> One problem with this is that "grep" always thinks lines end in '\n', and
> what we'd really want (from a scriptability angle) is
>
> diff-tree -z -r $orig $final | grep -0 '^-'
>
> but I don't think you can tell grep to think that lines are
> zero-terminated instead of terminated with \n'. But I don't see how to do
> that with grep.
Actually, grep has -z parameter. ;-)
Fixed and pushed out.
--
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
C++: an octopus made by nailing extra legs onto a dog. -- Steve Taylor
^ permalink raw reply
* Re: A shortcoming of the git repo format
From: Jon Seymour @ 2005-04-27 22:51 UTC (permalink / raw)
To: H. Peter Anvin; +Cc: Dave Jones, Linus Torvalds, Git Mailing List
In-Reply-To: <426FDE48.1050700@zytor.com>
On 4/28/05, H. Peter Anvin <hpa@zytor.com> wrote:
> Dave Jones wrote:
> >
> > That actually broke one of my first git scripts when one of the
> > changelog texts started a line with 'tree '. I hacked around it
> > by making my script only grep in the 'head -n4' lines, but this
> > seems somewhat fragile having to make assumptions that the field
> > I want to see is in the first 4 lines.
> >
>
> You have the delimiter for that; there is an empty line between the
> header and the free-form body, similar as for RFC822.
>
...and a relatively simple way to use that rule to extract just the
header lines:
sed -n "1,/^\$/p" # with the separator line
or, either one of these to remove the separator line as well:
sed -n "1,/^\$/s/^\(..*\)/\1/p"
sed -n "1,/^\$/p" | tr -s \\012
jon
--
homepage: http://www.zeta.org.au/~jon/
blog: http://orwelliantremors.blogspot.com/
^ permalink raw reply
* Re: Finding file revisions
From: Linus Torvalds @ 2005-04-27 22:19 UTC (permalink / raw)
To: Chris Mason; +Cc: git
In-Reply-To: <200504271423.37433.mason@suse.com>
On Wed, 27 Apr 2005, Chris Mason wrote:
>
> So, new prog attached. New usage:
>
> file-changes [-c commit_id] [-s commit_id] file ...
>
> -c is the commit where you want to start searching
> -s is the commit where you want to stop searching
Your script will do some funky stuff, because you incorrectly think that
the rev-list is sorted linearly. It's not. It's sorted in a rough
chronological order, but you really can't do the "last" vs "cur" thing
that you do, because two commits after each other in the rev-list listing
may well be from two totally different branches, so when you compare one
tree against the other, you're really doing something pretty nonsensical.
diff-tree will happily compare trees that aren't related, so it will
"work" in a sense, but it doesn't actually do what you think it does ;)
So what you should do is basically something like
open(RL, "rev-list $commit|") || die "rev-list failed";
while(<RL>) {
chomp;
my $cur = $_;
(so far so good) but then you should look at the _parents_ of that
commit, ie do (NOTE NOTE NOTE! I'm a total perl idiot, so I'm not going to
do this right):
open(PARENT, "cat-file commit $cur") || die "cat-file failed");
while(<PARENT>) {
chomp;
my @words = split;
if ($words[1] == "tree")
continue;
if ($words[1] != "parent")
break;
test_diff($cur, $words[2]);
}
close(PARENT);
}
close(RL);
and now your "test_diff()" thing can do the tree diff.
That way you actually do "tree-diff" on the thing you should do, and it
will show you _which_ way it changed in a merge (ie if you hit a
merge-point, it will do a tree-diff against both parents, and show you
which one had the difference - then you'll obviously usually see that same
difference later on when you dig down to the actual changeset that did it
too).
Remember: time is not a nice linear stream.
Linus
^ permalink raw reply
* Re: [PATCH] Make -s flag to show-diff a no-op.
From: Linus Torvalds @ 2005-04-27 22:20 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vfyxbeuwt.fsf@assigned-by-dhcp.cox.net>
On Wed, 27 Apr 2005, Junio C Hamano wrote:
>
> With the recent "no-patch-by-default" change, the -s flag to
> the show-diff command (and silent variable in the show-diff.c)
> became meaningless. This patch deprecates it.
I also wonder whether "-p" should turn on recursion by default (for all
the tools). "-p" without "-r" doesn't really seem to make much sense, does
it?
Linus
^ permalink raw reply
* Re: [PATCH] Make -s flag to show-diff a no-op.
From: Junio C Hamano @ 2005-04-27 22:35 UTC (permalink / raw)
To: Linus Torvalds; +Cc: git
In-Reply-To: <Pine.LNX.4.58.0504271520150.18901@ppc970.osdl.org>
>>>>> "LT" == Linus Torvalds <torvalds@osdl.org> writes:
LT> I also wonder whether "-p" should turn on recursion by default (for all
LT> the tools). "-p" without "-r" doesn't really seem to make much sense, does
LT> it?
When I know which path I am interested in,
$ diff-tree -p <tree-1> <tree-2> ls-tree.c
would still get the benefit of not descending down into ppc and
mozilla-sha1 subdirectories, if I am not mistaken.
Think of the kernel sources, and I would say leaving the option
of not recursing down is a good thing.
^ permalink raw reply
* Re: Finding file revisions
From: Chris Mason @ 2005-04-27 22:31 UTC (permalink / raw)
To: Linus Torvalds; +Cc: git
In-Reply-To: <Pine.LNX.4.58.0504271506290.18901@ppc970.osdl.org>
On Wednesday 27 April 2005 18:19, Linus Torvalds wrote:
> On Wed, 27 Apr 2005, Chris Mason wrote:
> > So, new prog attached. New usage:
> >
> > file-changes [-c commit_id] [-s commit_id] file ...
> >
> > -c is the commit where you want to start searching
> > -s is the commit where you want to stop searching
>
> Your script will do some funky stuff, because you incorrectly think that
> the rev-list is sorted linearly. It's not. It's sorted in a rough
> chronological order, but you really can't do the "last" vs "cur" thing
> that you do, because two commits after each other in the rev-list listing
> may well be from two totally different branches, so when you compare one
> tree against the other, you're really doing something pretty nonsensical.
Aha, didn't realize that one. Thanks, I'll rework things here.
-chris
^ permalink raw reply
* RE: git pull on ia64 linux tree
From: Linus Torvalds @ 2005-04-27 22:35 UTC (permalink / raw)
To: Luck, Tony; +Cc: git
In-Reply-To: <B8E391BBE9FE384DAA4C5C003888BE6F035B31D9@scsmsx401.amr.corp.intel.com>
On Wed, 27 Apr 2005, Luck, Tony wrote:
>
> The merge is right ... but "cg-update" leaves files that have been
> deleted lying around in the checked out tree.
Yes. I _think_ the right thing to do ends up being something like the
update script doing
diff-tree -r $orig $final | grep '^-'
at the end to get the list of deleted files, and just doing 'rm' on the
result.
One problem with this is that "grep" always thinks lines end in '\n', and
what we'd really want (from a scriptability angle) is
diff-tree -z -r $orig $final | grep -0 '^-'
but I don't think you can tell grep to think that lines are
zero-terminated instead of terminated with \n'. But I don't see how to do
that with grep.
Another similar alternative is to use "show-files --others" before and
after the merge and seeing what files got added to the list of "files we
don't track", but that just sounds horribly hacky.
Anyway, there are clearly at least two ways of doing this, and we'll just
have to have people work on the scripts to do it right..
Linus
^ permalink raw reply
* [PATCH] Use diff-tree -p -r instead of "git diff" in git-export.
From: Junio C Hamano @ 2005-04-27 22:26 UTC (permalink / raw)
To: Linus Torvalds; +Cc: git
Now diff-tree can produce patch itself, there is no reason to
depend on Cogito to show diff in the git-export output anymore.
Signed-off-by: Junio C Hamano <junkio@cox.net>
---
git-export.c | 2 +-
1 files changed, 1 insertion(+), 1 deletion(-)
# - diff.c: don't add extra '/' to pathname
# + 04/27 15:23 Use diff-tree -p in git-export.
--- k/git-export.c
+++ l/git-export.c
@@ -18,7 +18,7 @@ void show_commit(struct commit *commit)
char *against = sha1_to_hex(commit->parents->item->object.sha1);
printf("\n\n======== diff against %s ========\n", against);
fflush(NULL);
- sprintf(cmdline, "git diff -r %s:%s", against, hex);
+ sprintf(cmdline, "diff-tree -p -r %s %s", against, hex);
system(cmdline);
}
printf("======== end ========\n\n");
^ permalink raw reply
* Re: Cogito Tutorial If It Helps
From: Alan Chandler @ 2005-04-27 22:15 UTC (permalink / raw)
To: git
In-Reply-To: <20050427193227.GF22956@pasky.ji.cz>
On Wednesday 27 April 2005 20:32, Petr Baudis wrote:
> Those commands affect your working tree:
>
> cg-cancel
> Cancels out any modifications in the working tree w.r.t.
> the last commit
> cg-merge
> Merges changes done in another branch to your current
> branch
> cg-patch
> Applies a patch, with regard to special git-specific
> info generated by cg-diff
> cg-rm
> Removed the file from your working tree if it's still
> around
> cg-seek
> Changes your working tree to match some other commit in
> the database
> cg-update
> Potentially brings in changes from a remote branch, and
> updates your working tree to the latest commit + those
> changes
>
> Those commands affect the objects database:
>
> cg-commit
> cg-pull
> cg-pull just gets the data from remote objects database
> to the local objects database; it is the "first part"
> of what cg-update does
> cg-update
>
> This affects both:
>
> cg-merge
> Not directly, but it can call cg-commit automatically.
> cg-update
Thanks - that makes things a lot clearer
>
> > The reason I raise all this, is when I follow through on your tutorial
> > and get to the cg-diff stage I get this
> >
> > xargs: cg-Xdiffdo: No such file or directory
> >
> > And I have absolutely no idea whats wrong or where to start looking.
>
> You didn't do make install and you don't have the cogito tree in your
> $PATH.
I DID do a make install - which put everything in ~/bin (including cg-Xdiffdo)
and ~/bin is the first item in my $PATH.
--
Alan Chandler
http://www.chandlerfamily.org.uk
^ permalink raw reply
* RE: git pull on ia64 linux tree
From: Luck, Tony @ 2005-04-27 22:11 UTC (permalink / raw)
To: Linus Torvalds; +Cc: git
>On Wed, 27 Apr 2005 tony.luck@intel.com wrote:
>>
>> please pull from:
>>
>>
>rsync://rsync.kernel.org/pub/scm/linux/kernel/git/aegl/linux-2.6.git
>
>Merged and pushed out. You should probably check the end
>result, but it all looks good from here.
The merge is right ... but "cg-update" leaves files that have been
deleted lying around in the checked out tree.
-Tony
^ permalink raw reply
* [PATCH] Make -s flag to show-diff a no-op.
From: Junio C Hamano @ 2005-04-27 22:06 UTC (permalink / raw)
To: Linus Torvalds; +Cc: git
With the recent "no-patch-by-default" change, the -s flag to
the show-diff command (and silent variable in the show-diff.c)
became meaningless. This patch deprecates it.
Cogito uses "show-diff -s" for the purpose of "I do not want the
patch text. I just want to know if something has potentially
changed, in which case I know you will have some output. I'll
run update-cache --refresh if you say something", so we cannot
barf on seeing -s on our command line yet.
Signed-off-by: Junio C Hamano <junkio@cox.net>
---
show-diff.c | 18 +++++++++---------
1 files changed, 9 insertions(+), 9 deletions(-)
--- k/show-diff.c
+++ l/show-diff.c
@@ -6,12 +6,12 @@
#include "cache.h"
#include "diff.h"
-static const char *show_diff_usage = "show-diff [-q] [-s] [-z] [-p] [paths...]";
+static const char *show_diff_usage =
+"show-diff [-p] [-q] [-r] [-z] [paths...]";
static int generate_patch = 0;
static int line_termination = '\n';
static int silent = 0;
-static int silent_on_nonexisting_files = 0;
static int matches_pathspec(struct cache_entry *ce, char **spec, int cnt)
{
@@ -69,16 +69,16 @@ int main(int argc, char **argv)
int i;
while (1 < argc && argv[1][0] == '-') {
- if (!strcmp(argv[1], "-s"))
- silent_on_nonexisting_files = silent = 1;
- else if (!strcmp(argv[1], "-p"))
+ if (!strcmp(argv[1], "-p"))
generate_patch = 1;
else if (!strcmp(argv[1], "-q"))
- silent_on_nonexisting_files = 1;
- else if (!strcmp(argv[1], "-z"))
- line_termination = 0;
+ silent = 1;
else if (!strcmp(argv[1], "-r"))
; /* no-op */
+ else if (!strcmp(argv[1], "-s"))
+ ; /* no-op */
+ else if (!strcmp(argv[1], "-z"))
+ line_termination = 0;
else
usage(show_diff_usage);
argv++; argc--;
@@ -116,7 +116,7 @@ int main(int argc, char **argv)
perror(ce->name);
continue;
}
- if (silent_on_nonexisting_files)
+ if (silent)
continue;
show_file('-', ce);
continue;
^ permalink raw reply
* Re: [PATCH] add a diff-files command
From: Junio C Hamano @ 2005-04-27 21:49 UTC (permalink / raw)
To: Nicolas Pitre; +Cc: Linus Torvalds, git
In-Reply-To: <Pine.LNX.4.62.0504271701080.14033@localhost.localdomain>
>>>>> "NP" == Nicolas Pitre <nico@cam.org> writes:
NP> It also has the ability to accept exclude file patterns with -x and even
NP> a file containing a list of patterns to exclude with -X. This is
NP> especially useful to use the famous dontdiff file when looking for
NP> uncommitted files in a compiled kernel tree.
I think show-diff with path restriction (if restriction is
simple), or piping its output to grep or filterdiff (otherwise),
would be enough to do what you do here, so personally I doubt
this new command is even useful that much.
That said, I have a couple of comments. Other than these I do
not see anything majorly wrong (although I haven't even compiled
it yet ;-).
NP> +static const char *diff_files_usage = "diff-files [-a] [-c] [-d] [-o] [-p | -z]"
NP> + " [-x <pattern>] [-X <file>] [paths...]";
NP> +
If you are trying to do something similar to show-files by these
-[acdo] flags, matching these flags in both commands would be
less confusing to the users and script writers. Either make
diff-files take fully spelled --others etc. that show-files
takes, or submit a patch for show-files to match these shorter
ones as well. I personally prefer the latter.
NP> +/*
NP> + * Read a directory tree. We currently ignore anything but
NP> + * directories and regular files. That's because git doesn't
NP> + * handle them at all yet. Maybe that will change some day.
NP> + *
NP> + * Also, we currently ignore all names starting with a dot.
NP> + * That likely will not change.
NP> + */
For that logic, instead of doing de->d_name[0] == '.' and things
yourself, I'd rather see you lift verify_path() function from
update-cache.c into common library and call it. Then if the
"likely will not change" part needs to be updated, you do not
have to worry about it; updates to verify_path() would take care
of it for you.
^ permalink raw reply
* Re: Mercurial 0.3 vs git benchmarks
From: Linus Torvalds @ 2005-04-27 21:39 UTC (permalink / raw)
To: Bill Davidsen
Cc: Ingo Molnar, Andrew Morton, Magnus Damm, mason, mike.taht, mpm,
linux-kernel, git
In-Reply-To: <426FFFAB.1030005@tmr.com>
On Wed, 27 Apr 2005, Bill Davidsen wrote:
>
> I said much the same in another post, but noatime is not always what I
> really want.
"atime" is really nasty for a filesystem. I don't know if anybody noticed,
but git already uses O_NOATIME to open all the object files, because if
you don't do that, then just looking at a full kernel tree (which has more
than a thousand subdirectories) will cause nasty IO patterns from just
writing back "atime" information for the "tree" objects we looked up.
So you can do (and git does) selective atime updates. It just requires a
small amount of extra care.
> How about a "nojournalatime" option, so the atime would be
> updated at open and close, but not journaled at any other time.
Probably a good idea.
Linus
^ permalink raw reply
* [PATCH] cg-init shouldn't create master branch when pulling
From: Pavel Roskin @ 2005-04-27 21:33 UTC (permalink / raw)
To: git
Hello!
>From what I see in the current cogito sources, ".git/refs/heads/master"
is never used once it's created by cg-init. I believe the "master"
branch is only useful when creating a new repository. Then it's the
only branch in the repository.
When pulling from a remote repository, the "origin" branch is created,
and it should be default. There is no need in having a separate
"master" branch unless the user decides to create it for local
development.
This patch changes cg-init so that the "master" branch is only created
when the remote URI is not specified.
Signed-off-by: Pavel Roskin <proski@gnu.org>
Index: cg-init
===================================================================
--- 8dc4ace046ad3545d48088e604012f95e34e24d3/cg-init (mode:100755 sha1:d249140002888742c46ecba5925cae7c8025ea93)
+++ uncommitted/cg-init (mode:100755)
@@ -14,17 +14,18 @@
init-db
mkdir .git/branches .git/refs .git/refs/heads .git/refs/tags
-touch .git/refs/heads/master
-ln -s refs/heads/master .git/HEAD
if [ "$uri" ]; then
echo "$uri" >.git/branches/origin
+ ln -s refs/heads/origin .git/HEAD
cg-pull origin || die "pull failed"
- cp .git/refs/heads/origin .git/refs/heads/master
read-tree $(tree-id)
checkout-cache -a
update-cache --refresh
echo "Cloned (origin $uri available as branch \"origin\")"
+else
+ touch .git/refs/heads/master
+ ln -s refs/heads/master .git/HEAD
fi
--
Regards,
Pavel Roskin
^ permalink raw reply
* Re: Mercurial 0.3 vs git benchmarks
From: Theodore Ts'o @ 2005-04-27 21:32 UTC (permalink / raw)
To: Florian Weimer
Cc: H. Peter Anvin, Andrew Morton, Linus Torvalds, magnus.damm, mason,
mike.taht, mpm, linux-kernel, git
In-Reply-To: <87r7gw3p6p.fsf@deneb.enyo.de>
On Wed, Apr 27, 2005 at 11:06:06PM +0200, Florian Weimer wrote:
> * H. Peter Anvin:
>
> > Florian Weimer wrote:
> >> Benchmarks are actually a bit tricky because as far as I can tell,
> >> once you hash the directories, they are tainted even if you mount your
> >> file system with ext2.
> >
> > That's what fsck -D is for.
>
> Ah, cool, I didn't know that it works the other way, too. Thanks.
If htree support is disabled, e2fsck -D sorts by name, which was a
silly thing to do. I should change it to sort by inode number instead
(trivial patch). This might not be a problem for the maildir format,
given its naming convention.
- Ted
^ permalink raw reply
* [PATCH] add a diff-files command
From: Nicolas Pitre @ 2005-04-27 21:13 UTC (permalink / raw)
To: Linus Torvalds; +Cc: git
In the same spirit as diff-tree and diff-cache, here is a diff-files
command that processes differences between the index cache and the
working directory content. It produces lists of files that are either
changed (-c), deleted (-d) or outside (-o) from the current cache, or a
combination of those, or all of them (-a).
The -p option can also be used to generate a patch describing the
changes directly.
It also has the ability to accept exclude file patterns with -x and even
a file containing a list of patterns to exclude with -X. This is
especially useful to use the famous dontdiff file when looking for
uncommitted files in a compiled kernel tree.
Signed-off-by: Nicolas Pitre <nico@cam.org>
--- k/Makefile
+++ l/Makefile
@@ -18,7 +18,7 @@ PROG= update-cache show-diff init-db w
cat-file fsck-cache checkout-cache diff-tree rev-tree show-files \
check-files ls-tree merge-base merge-cache unpack-file git-export \
diff-cache convert-cache http-pull rpush rpull rev-list git-mktag \
- diff-tree-helper
+ diff-tree-helper diff-files
all: $(PROG)
--- k/diff-files.c
+++ l/diff-files.c
@@ -0,0 +1,362 @@
+/*
+ * GIT - The information manager from hell
+ *
+ * Copyright (C) Linus Torvalds, 2005
+ */
+
+#include <dirent.h>
+#include <fnmatch.h>
+#include "cache.h"
+#include "diff.h"
+
+static const char *diff_files_usage = "diff-files [-a] [-c] [-d] [-o] [-p | -z]"
+ " [-x <pattern>] [-X <file>] [paths...]";
+
+/* What paths are we interested in? */
+static int nr_paths = 0;
+static char **paths = NULL;
+static int *pathlens = NULL;
+
+static int nr_excludes;
+static const char **excludes;
+static int excludes_alloc;
+
+static void add_exclude(const char *string)
+{
+ if (nr_excludes == excludes_alloc) {
+ excludes_alloc = alloc_nr(excludes_alloc);
+ excludes = realloc(excludes, excludes_alloc*sizeof(char *));
+ }
+ excludes[nr_excludes++] = string;
+}
+
+static void add_excludes_from_file(const char *fname)
+{
+ int fd, i;
+ long size;
+ char *buf, *entry;
+
+ fd = open(fname, O_RDONLY);
+ if (fd < 0)
+ goto err;
+ size = lseek(fd, 0, SEEK_END);
+ if (size < 0)
+ goto err;
+ lseek(fd, 0, SEEK_SET);
+ if (size == 0) {
+ close(fd);
+ return;
+ }
+ buf = malloc(size);
+ if (!buf) {
+ errno = ENOMEM;
+ goto err;
+ }
+ if (read(fd, buf, size) != size)
+ goto err;
+ close(fd);
+
+ entry = buf;
+ for (i = 0; i < size; i++) {
+ if (buf[i] == '\n') {
+ if (entry != buf + i) {
+ buf[i] = 0;
+ add_exclude(entry);
+ }
+ entry = buf + i + 1;
+ }
+ }
+ return;
+
+err: perror(fname);
+ exit(1);
+}
+
+/*
+ * See if name matches our specified paths and is not excluded.
+ * return value:
+ * -1 if no match
+ * 0 if partial match (name is a directory component)
+ * 1 = exact match
+ * 2 = name is under a specified directory path with no excludes
+ */
+static int path_match(const char *name, int namelen)
+{
+ int i, ret;
+
+ /* fast case: no path list and no exclude list */
+ if (!nr_paths && !nr_excludes)
+ return 2;
+
+ ret = (nr_paths) ? -1 : 1;
+ for (i = 0; i < nr_paths; i++) {
+ int pathlen = pathlens[i];
+ if (pathlen == namelen &&
+ strncmp(paths[i], name, pathlen) == 0) {
+ ret = 1;
+ break;
+ } else if (pathlen > namelen &&
+ strncmp(paths[i], name, namelen) == 0 &&
+ paths[i][namelen] == '/') {
+ ret = 0;
+ break;
+ } else if (pathlen < namelen &&
+ strncmp(paths[i], name, pathlen) == 0 &&
+ name[pathlen] == '/') {
+ ret = (nr_excludes) ? 1 : 2;
+ break;
+ }
+ }
+
+ if (ret >= 0 && nr_excludes) {
+ const char *basename = strrchr(name, '/');
+ basename = (basename) ? basename+1 : name;
+ for (i = 0; i < nr_excludes; i++) {
+ if (fnmatch(excludes[i], basename, 0) == 0) {
+ ret = -1;
+ break;
+ }
+ }
+ }
+
+ return ret;
+}
+
+static const char **others;
+static int nr_others;
+static int others_alloc;
+
+static void add_name(const char *pathname, int len)
+{
+ char *name;
+
+ if (cache_name_pos(pathname, len) >= 0)
+ return;
+
+ if (nr_others == others_alloc) {
+ others_alloc = alloc_nr(others_alloc);
+ others = realloc(others, others_alloc*sizeof(char *));
+ }
+ name = malloc(len + 1);
+ memcpy(name, pathname, len + 1);
+ others[nr_others++] = name;
+}
+
+/*
+ * Read a directory tree. We currently ignore anything but
+ * directories and regular files. That's because git doesn't
+ * handle them at all yet. Maybe that will change some day.
+ *
+ * Also, we currently ignore all names starting with a dot.
+ * That likely will not change.
+ */
+static void read_directory(const char *path, const char *base, int baselen, int match)
+{
+ DIR *dir = opendir(path);
+
+ if (dir) {
+ struct dirent *de;
+ char fullname[MAXPATHLEN + 1];
+ memcpy(fullname, base, baselen);
+
+ while ((de = readdir(dir)) != NULL) {
+ int len;
+
+ if (de->d_name[0] == '.')
+ continue;
+ len = strlen(de->d_name);
+ memcpy(fullname + baselen, de->d_name, len+1);
+ if (match < 2)
+ match = path_match(fullname, baselen+len);
+ if (match < 0)
+ continue;
+
+ switch (de->d_type) {
+ struct stat st;
+ default:
+ continue;
+ case DT_UNKNOWN:
+ if (lstat(fullname, &st))
+ continue;
+ if (S_ISREG(st.st_mode))
+ break;
+ if (!S_ISDIR(st.st_mode))
+ continue;
+ /* fallthrough */
+ case DT_DIR:
+ memcpy(fullname + baselen + len, "/", 2);
+ read_directory(fullname, fullname,
+ baselen + len + 1, match);
+ continue;
+ case DT_REG:
+ break;
+ }
+ if (match > 0)
+ add_name(fullname, baselen + len);
+ }
+ closedir(dir);
+ }
+}
+
+static int cmp_name(const void *p1, const void *p2)
+{
+ const char *n1 = *(const char **)p1;
+ const char *n2 = *(const char **)p2;
+ int l1 = strlen(n1), l2 = strlen(n2);
+
+ return cache_name_compare(n1, l1, n2, l2);
+}
+
+static int show_changed = 0;
+static int show_deleted = 0;
+static int show_others = 0;
+static int generate_patch = 0;
+static int line_terminator = '\n';
+
+static const char null_sha1[20];
+static const char null_sha1_hex[] = "0000000000000000000000000000000000000000";
+
+static void show_file(int prefix, unsigned int mode,
+ const char *sha1, const char *name)
+{
+ if (generate_patch)
+ diff_addremove(prefix, mode, sha1, name, NULL);
+ else
+ printf("%c%o\t%s\t%s\t%s%c", prefix, mode, "blob",
+ sha1_to_hex(sha1), name, line_terminator);
+}
+
+int main(int argc, char **argv)
+{
+ int i, entries;
+
+ for (i = 1; i < argc; i++) {
+ char *arg = argv[i];
+
+ if (*arg != '-')
+ break;
+
+ if (!strcmp(arg, "-z")) {
+ line_terminator = 0;
+ continue;
+ }
+ if (!strcmp(arg, "-a")) {
+ show_changed = show_deleted = show_others = 1;
+ continue;
+ }
+ if (!strcmp(arg, "-c")) {
+ show_changed = 1;
+ continue;
+ }
+ if (!strcmp(arg, "-d")) {
+ show_deleted = 1;
+ continue;
+ }
+ if (!strcmp(arg, "-o")) {
+ show_others = 1;
+ continue;
+ }
+ if (!strcmp(arg, "-p")) {
+ generate_patch = 1;
+ continue;
+ }
+ if (!strcmp(arg, "-x") && i+1 < argc) {
+ arg = argv[++i];
+ add_exclude(arg);
+ continue;
+ }
+ if (!strcmp(arg, "-X") && i+1 < argc) {
+ arg = argv[++i];
+ add_excludes_from_file(arg);
+ continue;
+ }
+ if (!strcmp(arg, "--")) {
+ i++;
+ break;
+ }
+
+ usage(diff_files_usage);
+ }
+
+ /* default to -c if none of -c, -d nor -o have been specified */
+ if (!show_changed && !show_deleted && !show_others)
+ show_changed = 1;
+
+ if (i < argc) {
+ paths = &argv[i];
+ nr_paths = argc - i;
+ pathlens = malloc(nr_paths * sizeof(int));
+ for (i=0; i<nr_paths; i++) {
+ pathlens[i] = strlen(paths[i]);
+ if (paths[i][pathlens[i] - 1] == '/')
+ pathlens[i]--;
+ }
+ }
+
+ entries = read_cache();
+ if (entries < 0) {
+ perror("read_cache");
+ exit(1);
+ }
+
+ if (show_others) {
+ read_directory(".", "", 0, 0);
+ qsort(others, nr_others, sizeof(char *), cmp_name);
+ for (i = 0; i < nr_others; i++) {
+ struct stat st;
+ unsigned int mode;
+ if (stat(others[i], &st) < 0) {
+ perror(others[i]);
+ } else {
+ mode = S_IFREG | ce_permissions(st.st_mode);
+ show_file('+', mode, null_sha1, others[i]);
+ }
+ }
+ }
+
+ for (i = 0; i < entries; i++) {
+ struct stat st;
+ unsigned int ce_mode, mode;
+ struct cache_entry *ce = active_cache[i];
+
+ if (path_match(ce->name, ce_namelen(ce)) < 1)
+ continue;
+
+ if (show_changed && ce_stage(ce)) {
+ if (generate_patch)
+ diff_unmerge(ce->name);
+ else
+ printf("U %s%c", ce->name, line_terminator);
+ do {
+ i++;
+ } while (i < entries &&
+ !strcmp(ce->name, active_cache[i]->name));
+ continue;
+ }
+
+ ce_mode = ntohl(ce->ce_mode);
+ if (stat(ce->name, &st) < 0) {
+ if (errno != ENOENT) {
+ perror(ce->name);
+ } else if (show_deleted) {
+ show_file('-', ce_mode, ce->sha1, ce->name);
+ }
+ continue;
+ }
+
+ if (!show_changed || !cache_match_stat(ce, &st))
+ continue;
+
+ mode = S_IFREG | ce_permissions(st.st_mode);
+ if (generate_patch)
+ diff_change(ce_mode, mode, ce->sha1,
+ null_sha1, ce->name, NULL);
+ else
+ printf("*%o->%o\t%s\t%s->%s\t%s%c",
+ ce_mode, mode, "blob",
+ sha1_to_hex(ce->sha1), null_sha1_hex,
+ ce->name, line_terminator);
+ }
+
+ return 0;
+}
^ 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