* Re: [PATCH] cg-mkpatch: Show diffstat before the patch
From: Petr Baudis @ 2005-04-27 23:55 UTC (permalink / raw)
To: git
In-Reply-To: <20050426225855.GA28560@diku.dk>
Dear diary, on Wed, Apr 27, 2005 at 12:58:55AM CEST, I got a letter
where Jonas Fonseca <fonseca@diku.dk> told me that...
> Show diffstat before the patch.
>
> Signed-off-by: Jonas Fonseca <fonseca@diku.dk>
I think you should first check by which(1) or something whether you have
diffstat. Piling up dependencies like this is pretty annoying.
Thanks,
--
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: I'm missing isofs.h
From: Petr Baudis @ 2005-04-27 23:51 UTC (permalink / raw)
To: Andrew Morton; +Cc: git
In-Reply-To: <20050426214338.32e9ac27.akpm@osdl.org>
Dear diary, on Wed, Apr 27, 2005 at 06:43:38AM CEST, I got a letter
where Andrew Morton <akpm@osdl.org> told me that...
> In a current tree, using git-pasky-0.7:
>
> bix:/usr/src/git26> cat .git/tags/v2.6.12-rc3
> a2755a80f40e5794ddc20e00f781af9d6320fafb
> bix:/usr/src/git26> git diff -r v2.6.12-rc3|grep isofs.h
> +#include "isofs.h"
> #include "zisofs.h"
> +#include "isofs.h"
> +#include "isofs.h"
> +#include "isofs.h"
> #include "zisofs.h"
> +#include "isofs.h"
> +#include "isofs.h"
> +#include "isofs.h"
> +#include "isofs.h"
>
>
> That diff should have included the addition of the new isofs.h, but it
> isn't there.
Ouch.
Well, using -r v2.6.12-rc3: is a workable workaround, but this is a
problem. With the trailing :, you are diffing against your latest
commit, whilst without the trailing :, you are diffing against your
working tree. ;-)
The problem is in how the latter is implemented:
export GIT_INDEX_FILE=$(mktemp -t gitdiff.XXXXXX)
cp .git/index $GIT_INDEX_FILE
read-tree -m $(tree-id "$id1")
update-cache --refresh
tree=$(tree-id "$id1")
diff-cache -r -z $tree | xargs -0 cg-Xdiffdo ...
So, we are recording our adds to the index cache, but here we use a
different one with the adds are not recorded - so diff-cache won't catch
them.
So I fixed this by doing diff-cache --cached and updating the tmp index
by the +- entries. Pushed out, thanks.
--
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: Daniel Barkalow @ 2005-04-27 23:50 UTC (permalink / raw)
To: H. Peter Anvin; +Cc: Linus Torvalds, Git Mailing List
In-Reply-To: <426FF8C4.8080809@zytor.com>
On Wed, 27 Apr 2005, H. Peter Anvin wrote:
> One can simply say "we don't do that"; finding an unknown tag is always
> a fatal error. That means the format is more brittle, but brittle does
> mean it breaks as opposed to getting deformed in some, potentially
> undesirable way.
If you find an object with an unknown tag, you can't do much with it
anyway, even if it has a format that matches generic rules. Sure, you
could trace reachability through it, but that's only helpful for a couple
of generic programs (fsck and pull), and those programs ought to
additionally have some clue about what's going on if they're going to act
appropriately.
On the other hand, it is probably true that programs should be able to
deal abstractly with new tags if built with a libgit that supports them,
but that's something that we can arrange a bit later.
-Daniel
*This .sig left intentionally blank*
^ permalink raw reply
* Re: git pull on ia64 linux tree
From: Linus Torvalds @ 2005-04-27 23:36 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:
>
> Fixed and pushed out.
It looks like you only did the fix for the pure "just update to the
version at the other end" case.
So if you actually end up doing a merge, it still leaves all the old files
(that the merge may have removed from the tree) around. Or did I miss
something?
Linus
^ permalink raw reply
* 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
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