* Re: Is cogito really this inefficient
From: Linus Torvalds @ 2005-07-14 15:51 UTC (permalink / raw)
To: Russell King; +Cc: Catalin Marinas, git
In-Reply-To: <20050714105938.A31383@flint.arm.linux.org.uk>
On Thu, 14 Jul 2005, Russell King wrote:
>
> Actually, I should've left the sh -x /usr/bin/cg-diff drivers/serial/8250.c
> running a little longer. It's not the git-update-cache command which
> is taking the time, it's git-diff-cache.
Ok. git-diff-cache actually ends up reading your HEAD tree, and that, in
turn, is 1000+ tree objects. So it can take a while for the whole tree,
especially in the nonpacked and uncached case.
git-diff-tree (comparing two trees) is smart enough to limit itself to
just the sub-trees that have been named, and would have compared the two
trees by looking up just eight objects (three subdirectories from each
tree, and then the file itself from both trees).
But git-diff-cache isn't - because it's comparing the tree against the
index file, and the index is inevitably the whole tree.
And I now think I know what makes it slow. Not only are you basically
opening 1100 files (the tree objects - there's really that many
subdirectories in the kernel. Scary), but because you have alternate
object directories, and almost all of the objects are in the alternate
(not your primary), you'll basically always end up _first_ looking in the
primary, failing, and then looking in the alternate.
Together with the hashing, you'll be looking all over the place, in other
words ;)
Which means that you'll be needing a fair amount of memory to keep all of
those negative dentries etc cached (and the directory tree too).
This is something the pack-files will just help enormously with, but it
was only recently that we turned git around to check the pack-files
_first_, and the object directories second, so you probably won't see it
(not to mention that you probably don't have big pack-files at all ;)
I'll look into making diff-cache be more efficient. I normally don't use
it myself, so I didn't bother (I use git-diff-files, which is way more
efficient, but doesn't show the difference against the _tree_, it shows
the difference against the index. Since cogito tries to hide the index
from you, cogito can't very well use that).
Linus
^ permalink raw reply
* Re: Patch to make README more newbie-friendly
From: Matthias Urlichs @ 2005-07-14 16:01 UTC (permalink / raw)
To: git
In-Reply-To: <42D5F10B.5050708@pason.com>
Hi, Jerry Seutter wrote:
> I'd also like to include stuff about branches, but I haven't gotten my
> head wrapped around how they work yet. cg-branch-add expects a location
> after the branch name and I'm not sure what to give it.
Cogito branch creation is based on the idea that you have a different
archive _somewhere_else_ that you pull from, so it wants to store the
source URL in .git/branches/<name>.
Git doesn't have that assumption; "git checkout -b <name>" simply
creates a new branch and switches to it. However, the git branch idea came
somewhat later, so there's a bit of a mismatch at the moment.
Simply switching branches isn't supposed to have any effect unless you
actually have changes in different branches. I tend to work along these
lines:
#!/bin/sh
cd /tmp
rm -rf test.$$
mkdir test.$$
cd test.$$
git-init-db
echo not-quite-empty >testfile
cg-add testfile
echo Created test | cg-commit
git checkout -b one
echo foo >>testfile
echo added foo to testfile | cg-commit
git checkout -b two master
echo bar >> testfile
echo added bar to testfile | cg-commit
cg-diff -r one:two | cat
git checkout master
cg-merge one
cg-merge two
The first merge fast-forwards your master tree to "one"; the second
creates a conflict (lines were added at the same location) which you'll
have to resolve (edit the file).
vi testfile
echo Merged one and two | cg-commit
gitk
--
Matthias Urlichs | {M:U} IT Design @ m-u-it.de | smurf@smurf.noris.de
Disclaimer: The quote was selected randomly. Really. | http://smurf.noris.de
- -
Apollo, the God of light, of reason, of proportion, harmony, number --
Apollo blinds those who press too close in worship. Don't look straight
at the sun. Go into a dark bar and have a beer with Dionysos, every now
and then. -- Ursula K. LeGuin
^ permalink raw reply
* Re: Why O_EXCL would make this difference? I am puzzled..
From: Linus Torvalds @ 2005-07-14 16:08 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7v8y09g5sq.fsf@assigned-by-dhcp.cox.net>
On Thu, 14 Jul 2005, Junio C Hamano wrote:
>
> The bisect search found that the commit
>
> Make "git-checkout" create files with O_EXCL
>
> makes the test t1005 fail. But it is getting late so I give up
> to figuire this out tonight.
Ahh, thanks for noticing.
It says
* expecting success: rm -f .git/index &&
rm -fr DF &&
mkdir DF &&
echo DF/DF >DF/DF &&
git-update-cache --add DF/DF &&
read_tree_twoway $treeDFDF $treeDF &&
git-ls-files --stage >DFDFcheck.out &&
diff -u DF.out DFDFcheck.out &&
check_cache_at DF clean && # different from pure 2-way
:
100644 052efc3abbc31348f7abd34535b1953d38273257 3 DF
100644 b90ea14b2dd74b6f377c10870b3757344bbe077c 1 DF/DF
100644 b90ea14b2dd74b6f377c10870b3757344bbe077c 2 DF/DF
Adding DF
error: git-checkout-cache: unable to create file DF (File exists)
Removing DF/DF
100644 052efc3abbc31348f7abd34535b1953d38273257 0 DF
DF: dirty
* FAIL 24: DF vs DF/DF case test (#2) rm -f .git/index &&
Which is strange. If the path already exists, the "lstat(path, &st)"
should have returned 0 in checkout_entry (which is the only caller of
"write_entry()"), and that code does an "unlink(path)" before it calls
write-entry. So I was sure O_EXCL wouldn't make any difference, but I'm
obviously wrong, wrong, wrong.
I'll strace the dang thing.
Linus
^ permalink raw reply
* Re: Why O_EXCL would make this difference? I am puzzled..
From: Linus Torvalds @ 2005-07-14 16:52 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <Pine.LNX.4.58.0507140904440.19183@g5.osdl.org>
On Thu, 14 Jul 2005, Linus Torvalds wrote:
>
> I'll strace the dang thing.
It's the "Adding" case in git-merge-one-file-script, which does
git-checkout-cache -u -f -- "$4"
and it's because of this:
lstat64("DF", {st_mode=S_IFDIR|0775, st_size=4096, ...}) = 0
unlink("DF") = -1 EISDIR (Is a directory)
.. unpack the object ..
open("DF", O_WRONLY|O_CREAT|O_TRUNC|O_EXCL, 0666) = -1 EEXIST (File exists)
ie the problem is that we actually _have_ a test for this, but it's:
if (errno == EISDIR && force) {
but if the directory already exists, we do that wrong.
Btw, this also shows a different problem: the symlink handling doesn't do
any of this, so you cannot even force a directory to become a symlink.
I think both problems can be fixed by just moving the (EISDIR && force)
test down to the "unlink()".
Will try.
Linus
^ permalink raw reply
* Getting list of changed objects...
From: James Ketrenos @ 2005-07-14 18:20 UTC (permalink / raw)
To: git
I have the following tree path:
A C B
| |
| 3.|<--.
| | |
2.|-->' |
| |
1.|------>'
|
Where A is the root repository for my overlays. B was created by
cloning A (1)
B is where development has been progressing. Finding the set of
objects to move from A to B is easily obtained via:
git-rev-list --objects B ^A
The problem is now when I want to re-sync B with the latest version
of A. What I currently do is:
Create a new C tree based on latest A (2) and then merge B back into
it (3):
git-merge-tree -m $(git-merge-base C B) C B
That works great. I now have a tree with all of the latest A code
and the B changes applied. The problem is now in getting the list
of objects to create the overlay repository.
cg-log -f -r C:B
Will correctly show only those files that have actually changed
between C and B in the first log entry. However, cg-log does
not show me the list of tree objects that have changed between
C and B.
The problem is that if I run:
git-rev-list --objects B ^C
It shows me all of the tree and commit objects but also gives a
list of all of the files that changed between A and C as if they
are needed to move C to B.
Am I overlooking something, misusing things, or ?
Thanks,
James
^ permalink raw reply
* Re: Getting list of changed objects...
From: Linus Torvalds @ 2005-07-14 17:58 UTC (permalink / raw)
To: James Ketrenos; +Cc: git
In-Reply-To: <42D6ACF0.30303@linux.intel.com>
On Thu, 14 Jul 2005, James Ketrenos wrote:
>
> The problem is that if I run:
>
> git-rev-list --objects B ^C
>
> It shows me all of the tree and commit objects but also gives a
> list of all of the files that changed between A and C as if they
> are needed to move C to B.
Since you haven't merged A and B in the above, they _are_ needed, aren't
they?
Maybe what you want is
git-rev-list --objects B ^A ^C
ie "objects that are in B, but not in A or in C", since you seem to
consider A uninteresting too?
I don't actually understand what you want to do, and also, "git-rev-list
--objects" is actually not 100% careful - it can include objects that are
in the "not" group, just because it doesn't actually bother to do a full
negative list (it only creates a negative list for the "boundary" objects,
but it won't even do "mark_tree_uninteresting()" for commits that it has
decided cannot be meaningful, so it's not in any way guaranteed to be a
_minimal_ set of objects).
Linus
^ permalink raw reply
* cg update failing
From: James Cloos @ 2005-07-14 18:04 UTC (permalink / raw)
To: git
I'm getting this on my clone of linus' tree:
,----
| cg-merge: merge blocked: seeked from master
`----
I've not found a way past it.
Is there an easy way, or do I have still yet another borked lk clone?
(Borked clones would be much less of an issue if I had more bandwidth
than disk space, but at the moment I'm stuck behind a straw. Cloning
something like lk takes hours.)
-JimC
--
James H. Cloos, Jr. <cloos@jhcloos.com>
^ permalink raw reply
* Re: [PATCH] stgit: allow spaces in filenames
From: Junio C Hamano @ 2005-07-13 22:26 UTC (permalink / raw)
To: Catalin Marinas; +Cc: git
In-Reply-To: <1121290004.6876.11.camel@localhost.localdomain>
Catalin Marinas <catalin.marinas@gmail.com> writes:
>> I'd very much like to stay on the same list. By the same logic, cogito
>> should have it's own list as well...
>
> I'd like this too and it's probably OK with a low traffic (we'll see if
> we receive complaints :-) ).
I'd like to keep Porcelain discussions on this list for two
reasons:
(1) Porcelain implementations need their own bookkeeping
information somewhere, and possibly in .git/ directory.
I'd want to see them agree on what's stored where for what
purpose and stay compatible when that makes sense. The
place to brew that concensus is here.
(2) The core GIT people want to learn what Porcelain needs
from the core. I am personally interested in StGIT so
subscribing to that list is fine for me, but it is
convenient to have everything in one place, especially with
this relatively low traffic.
^ permalink raw reply
* Re: cg update failing
From: Darrin Thompson @ 2005-07-14 18:24 UTC (permalink / raw)
To: James Cloos; +Cc: git
In-Reply-To: <m3oe95qn64.fsf@lugabout.cloos.reno.nv.us>
On Thu, 2005-07-14 at 14:04 -0400, James Cloos wrote:
> I'm getting this on my clone of linus' tree:
>
> ,----
> | cg-merge: merge blocked: seeked from master
> `----
>
> I've not found a way past it.
cg-seek master ?
--
Darrin
^ permalink raw reply
* Re: Getting list of changed objects...
From: James Ketrenos @ 2005-07-14 20:20 UTC (permalink / raw)
To: Linus Torvalds; +Cc: git
In-Reply-To: <Pine.LNX.4.58.0507141053540.19183@g5.osdl.org>
Linus Torvalds wrote:
>Since you haven't merged A and B in the above, they _are_ needed, aren't
>they?
>
>
My original email wasn't worded quite right. I think you are tracking
what I'm trying to do... but here is a different view anyway:
time
|
1 A -------> B clone A to B
2 | | make changes on B and A
3 | --> C | clone A to C
4 | | <---' merge B into C
5 | |
A C
I am merging B (as it was at time 3, or B3) into C (as it was at time 3,
or C3) via:
git-read-tree -m $(git-merge-base B3 C3) C3 B3
where $(git-merge-base B3 C3) resolves to A1. After I run git-read-tree,
I resolve any conflicts via git-merge-cache, etc. and write the
tree via git-write-tree.
>Maybe what you want is
>
> git-rev-list --objects B ^A ^C
>
>ie "objects that are in B, but not in A or in C", since you seem to
>consider A uninteresting too?
>
>
That does seem to work here by doing:
git-rev-list --objects C5 ^C3 ^$(git-merge-base C3 B3)
>, and also, "git-rev-list
>--objects" is actually not 100% careful - it can include objects that are
>in the "not" group, just because it doesn't actually bother to do a full
>negative list (it only creates a negative list for the "boundary" objects,
>but it won't even do "mark_tree_uninteresting()" for commits that it has
>decided cannot be meaningful, so it's not in any way guaranteed to be a
>_minimal_ set of objects).
>
>
Good to know. If git-rev-list is just checking the boundary, and the merge
commit is between C5 and C3 (at C4) then that explains why I see what I
see. It would grab all the objects listed in C4 and not exhuaustively be
removing them via one of its ancestors.
The goal is to create the list of objects (tree, commit, and blob)
required such
that if someone already has all the objects for repo A, they just need to
download the 'in C, not in A' objects and the HEAD from C and then they can
create a full copy of C.
I'll look to modify my scripts that merge the parent repository to cache
the parent
repository's SHA. I can then pass that list of merge points to
get-rev-list as a
set of boundaries.
Thanks,
James
^ permalink raw reply
* Re: cg update failing
From: James Cloos @ 2005-07-14 20:06 UTC (permalink / raw)
To: Darrin Thompson; +Cc: git
In-Reply-To: <1121365461.4729.0.camel@localhost.localdomain>
>>>>> "Darrin" == Darrin Thompson <darrint@progeny.com> writes:
JimC> cg-merge: merge blocked: seeked from master `----
Darrin> cg-seek master ?
:; cg seek master
On commit 514fd7fd01d378a7b5584c657d9807fc28f22079
-JimC
^ permalink raw reply
* Re: cg update failing
From: Darrin Thompson @ 2005-07-14 21:21 UTC (permalink / raw)
To: James Cloos; +Cc: git
In-Reply-To: <m3k6jtnod8.fsf@lugabout.cloos.reno.nv.us>
On Thu, 2005-07-14 at 16:06 -0400, James Cloos wrote:
> >>>>> "Darrin" == Darrin Thompson <darrint@progeny.com> writes:
>
> JimC> cg-merge: merge blocked: seeked from master `----
>
> Darrin> cg-seek master ?
>
> :; cg seek master
> On commit 514fd7fd01d378a7b5584c657d9807fc28f22079
Now your merge should not be blocked. No?
--
Darrin
^ permalink raw reply
* [PATCH] git-diff-*: Allow "--name-only -z" as alias for "--name-only-z"
From: Matthias Urlichs @ 2005-07-14 21:51 UTC (permalink / raw)
To: Linus Torvalds, git, junkio
[-- Attachment #1: Type: text/plain, Size: 4052 bytes --]
Junio C Hamano wrote:
> + else if (!strcmp(arg, "--name-only-z"))
> + diff_output_format = DIFF_FORMAT_NAME_Z;
Speaking as a user, I would get rather frustrated when I try to do that
and it doesn't work... so the attached patch allows that usage.
Please apply.
---
diff --git a/diff-cache.c b/diff-cache.c
--- a/diff-cache.c
+++ b/diff-cache.c
@@ -222,11 +222,17 @@ int main(int argc, const char **argv)
continue;
}
if (!strcmp(arg, "-z")) {
- diff_output_format = DIFF_FORMAT_MACHINE;
+ if (diff_output_format == DIFF_FORMAT_NAME)
+ diff_output_format = DIFF_FORMAT_NAME_Z;
+ else
+ diff_output_format = DIFF_FORMAT_MACHINE;
continue;
}
if (!strcmp(arg, "--name-only")) {
- diff_output_format = DIFF_FORMAT_NAME;
+ if (diff_output_format == DIFF_FORMAT_MACHINE)
+ diff_output_format = DIFF_FORMAT_NAME_Z;
+ else
+ diff_output_format = DIFF_FORMAT_NAME;
continue;
}
if (!strcmp(arg, "--name-only-z")) {
diff --git a/diff-files.c b/diff-files.c
--- a/diff-files.c
+++ b/diff-files.c
@@ -55,11 +55,17 @@ int main(int argc, const char **argv)
; /* no-op */
else if (!strcmp(argv[1], "-s"))
; /* no-op */
- else if (!strcmp(argv[1], "-z"))
- diff_output_format = DIFF_FORMAT_MACHINE;
- else if (!strcmp(argv[1], "--name-only"))
- diff_output_format = DIFF_FORMAT_NAME;
- else if (!strcmp(argv[1], "--name-only-z"))
+ else if (!strcmp(argv[1], "-z")) {
+ if (diff_output_format == DIFF_FORMAT_NAME)
+ diff_output_format = DIFF_FORMAT_NAME_Z;
+ else
+ diff_output_format = DIFF_FORMAT_MACHINE;
+ } else if (!strcmp(argv[1], "--name-only")) {
+ if (diff_output_format == DIFF_FORMAT_MACHINE)
+ diff_output_format = DIFF_FORMAT_NAME_Z;
+ else
+ diff_output_format = DIFF_FORMAT_NAME;
+ } else if (!strcmp(argv[1], "--name-only-z"))
diff_output_format = DIFF_FORMAT_NAME_Z;
else if (!strcmp(argv[1], "-R"))
diff_setup_opt |= DIFF_SETUP_REVERSE;
diff --git a/diff-stages.c b/diff-stages.c
--- a/diff-stages.c
+++ b/diff-stages.c
@@ -86,11 +86,17 @@ int main(int ac, const char **av)
}
else if (!strcmp(arg, "--find-copies-harder"))
find_copies_harder = 1;
- else if (!strcmp(arg, "-z"))
- diff_output_format = DIFF_FORMAT_MACHINE;
- else if (!strcmp(arg, "--name-only"))
- diff_output_format = DIFF_FORMAT_NAME;
- else if (!strcmp(arg, "--name-only-z"))
+ else if (!strcmp(arg, "-z")) {
+ if (diff_output_format == DIFF_FORMAT_NAME)
+ diff_output_format = DIFF_FORMAT_NAME_Z;
+ else
+ diff_output_format = DIFF_FORMAT_MACHINE;
+ } else if (!strcmp(arg, "--name-only")) {
+ if (diff_output_format == DIFF_FORMAT_MACHINE)
+ diff_output_format = DIFF_FORMAT_NAME_Z;
+ else
+ diff_output_format = DIFF_FORMAT_NAME;
+ } else if (!strcmp(arg, "--name-only-z"))
diff_output_format = DIFF_FORMAT_NAME_Z;
else if (!strcmp(arg, "-R"))
diff_setup_opt |= DIFF_SETUP_REVERSE;
diff --git a/diff-tree.c b/diff-tree.c
--- a/diff-tree.c
+++ b/diff-tree.c
@@ -483,7 +483,10 @@ int main(int argc, const char **argv)
continue;
}
if (!strcmp(arg, "--name-only")) {
- diff_output_format = DIFF_FORMAT_NAME;
+ if (diff_output_format == DIFF_FORMAT_MACHINE)
+ diff_output_format = DIFF_FORMAT_NAME_Z;
+ else
+ diff_output_format = DIFF_FORMAT_NAME;
continue;
}
if (!strcmp(arg, "--name-only-z")) {
@@ -491,7 +494,10 @@ int main(int argc, const char **argv)
continue;
}
if (!strcmp(arg, "-z")) {
- diff_output_format = DIFF_FORMAT_MACHINE;
+ if (diff_output_format == DIFF_FORMAT_NAME)
+ diff_output_format = DIFF_FORMAT_NAME_Z;
+ else
+ diff_output_format = DIFF_FORMAT_MACHINE;
continue;
}
if (!strcmp(arg, "-m")) {
--
Matthias Urlichs | {M:U} IT Design @ m-u-it.de | smurf@smurf.noris.de
Disclaimer: The quote was selected randomly. Really. | http://smurf.noris.de
- -
When The Religious Right Takes Over, We'll All Live In Iran
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: cg update failing
From: James Cloos @ 2005-07-14 21:50 UTC (permalink / raw)
To: Darrin Thompson; +Cc: git
In-Reply-To: <1121376069.4729.2.camel@localhost.localdomain>
>>>>> "Darrin" == Darrin Thompson <darrint@progeny.com> writes:
Darrin> Now your merge should not be blocked. No?
I figured out what you meant after I sent that first reply, but waited
for update to finish to be sure it worked before replying again.
It took about thirty minutes, and claimed that I had local changes (it
was a pristine clone) that it needed to bring forward, but it seems OK.
Now I just need to remember how to get the checked-out copy
updated from the 2.6.12 tag to current. ;)
(I'd been using hg, but www.kernel.org/hg is fubar, so I had to go
back to my cg clone.)
-JimC
^ permalink raw reply
* Re: [PATCH] git-diff-*: Allow "--name-only -z" as alias for "--name-only-z"
From: Junio C Hamano @ 2005-07-14 22:17 UTC (permalink / raw)
To: Matthias Urlichs; +Cc: Linus Torvalds, git, junkio
In-Reply-To: <20050714215126.GY9915@kiste.smurf.noris.de>
I've considered it, but what happens if you give -z first and
then name-only?
^ permalink raw reply
* Re: [PATCH] git-diff-*: Allow "--name-only -z" as alias for "--name-only-z"
From: Matthias Urlichs @ 2005-07-14 22:36 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Linus Torvalds, git
In-Reply-To: <7vvf3d6nis.fsf@assigned-by-dhcp.cox.net>
[-- Attachment #1: Type: text/plain, Size: 444 bytes --]
Hi,
Junio C Hamano:
> I've considered it, but what happens if you give -z first and
> then name-only?
>
Exactly the same thing as vice versa.
Or, even more exactly, my patch *makes* that happen. ;-)
--
Matthias Urlichs | {M:U} IT Design @ m-u-it.de | smurf@smurf.noris.de
Disclaimer: The quote was selected randomly. Really. | http://smurf.noris.de
- -
Isn't this a beautiful day! Just watch some bastard louse it up.
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: [PATCH] git-diff-*: Allow "--name-only -z" as alias for "--name-only-z"
From: Junio C Hamano @ 2005-07-14 23:11 UTC (permalink / raw)
To: Matthias Urlichs; +Cc: Linus Torvalds, git
In-Reply-To: <20050714223622.GZ9915@kiste.smurf.noris.de>
Matthias Urlichs <smurf@smurf.noris.de> writes:
> Exactly the same thing as vice versa.
> Or, even more exactly, my patch *makes* that happen. ;-)
Ah, I was not being careful enough. Sorry.
That said, I have been hating that diff options parsing for
quite a while, and I've been thinking about cleaning it up along
the lines I'll outline here, but have not done anything about
it. Care to help me out?
- In diff.h introduce these new stuff:
struct diff_opts {
int output_format;
int detect_rename;
...
};
void diff_opts_init(struct diff_opts *);
int diff_opts_parse(const char *, struct diff_opts *);
int diff_opts_final(struct diff_opts *);
- In diff-* brothers:
- replace individual diff option variables with a single
"static struct diff_opts diff_opts";
- change the argument parsing code to do the following:
diff_opts_init(&diff_opts);
for each arg {
/* common options to diff brothers are handled by
* diff_opts_parse()
*/
switch (diff_opts_parse(arg, &diff_opts)) {
case 1: /* was a diff option and was parsed successfully */
continue;
case -1: /* error */
usage(diff_*_usage);
}
if (!strcmp())
... parsing of other options
}
if (diff_opts_final(&diff_opts))
/* defaulting to HUMAN format when nothing specified,
* complaining if find-copies-harder is specified but
* -C was not, etc. is done in diff_opts_final().
*
* The complex if() chains that checks if we are in
* name or in raw mode and switch output_format around
* properly is what I missed in your patch, but I think
* you can lose that by recording z-ness of the output
* independently from the output format in diff_opts_parse()
* and combining diff-raw vs diff-name and z vs non-z
* in diff_opts_final(). That would make the code much
* simpler.
*/
usage(diff_*_usage);
- In diff.h and diff.c, replace individual option parameters
for the following functions to a single pointer to struct
diff_opts:
diff_setup(), diffcore_std(), diffcore_std_no_resolve(), diff_flush().
We probably can make diff_scoreopt_parse() function static to
diff.c once this is done.
We may want to rip out the independeant pickaxe, orderfile and
filter support for diff-helper while we are at it, making it
truly just a "diff-raw to diff-patch" converter.
Hmm?
^ permalink raw reply
* Re: [PATCH] git-diff-*: Allow "--name-only -z" as alias for "--name-only-z"
From: Matthias Urlichs @ 2005-07-14 23:29 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Linus Torvalds, git
In-Reply-To: <7vmzop56fo.fsf@assigned-by-dhcp.cox.net>
[-- Attachment #1: Type: text/plain, Size: 638 bytes --]
Hi,
Junio C Hamano:
> That said, I have been hating that diff options parsing for
> quite a while, and I've been thinking about cleaning it up along
> the lines I'll outline here, but have not done anything about
> it. Care to help me out?
>
I saw the problem...
>
> Hmm?
>
Sure -- assuming I find some time to actually do it over the next few days.
The problem is that this has been a problem lately. :-/
--
Matthias Urlichs | {M:U} IT Design @ m-u-it.de | smurf@smurf.noris.de
Disclaimer: The quote was selected randomly. Really. | http://smurf.noris.de
- -
Illiterate? Write today, for free help!
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: Is cogito really this inefficient
From: Linus Torvalds @ 2005-07-15 0:29 UTC (permalink / raw)
To: Russell King; +Cc: Catalin Marinas, git
In-Reply-To: <Pine.LNX.4.58.0507140832490.19183@g5.osdl.org>
On Thu, 14 Jul 2005, Linus Torvalds wrote:
>
> I'll look into making diff-cache be more efficient. I normally don't use
> it myself, so I didn't bother (I use git-diff-files, which is way more
> efficient, but doesn't show the difference against the _tree_, it shows
> the difference against the index. Since cogito tries to hide the index
> from you, cogito can't very well use that).
Ok, done.
I made git-diff-cache _and_ git-diff-files limit the pathnames early, so
that they don't even bother expanding the tree objects that are
irrelevant, and don't bother even validating index objects that don't
match the pathnames given.
Junio - I think this makes gitcore-pathspec pretty pointless, but I didn't
actually remove it. I guess "git-diff-helper" still uses it.
Linus
^ permalink raw reply
* Re: [PATCH] tagger id
From: Eric W. Biederman @ 2005-07-15 0:36 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <loom.20050713T011619-369@post.gmane.org>
Junio C Hamano <junkio@twinsun.com> writes:
> I am afraid I do not follow you.
I was confused. My big problem was that we don't really have
an in tree user, and there wasn't a good explanation anywhere. So it
was hard to track this down.
I'm going to lobby for a script to import patches from email being
in the git tree just so people can see how this is done, and probably
because there are a lot of people who have been reinventing this
script :)
> The intent of "tags" (especially the signed kind) is to express "trust":
> "This commit is called v2.6.12 and *I* vouch for it."
>
> COMMITTER is the only sensible thing to use there, because (as you said)
> what you care is "who I am", not "for whom I am doing this"
Sounds good.
Eric
^ permalink raw reply
* Re: [PATCH] tagger id
From: Eric W. Biederman @ 2005-07-15 0:46 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <loom.20050712T230013-978@post.gmane.org>
Junio C Hamano <junkio@twinsun.com> writes:
> Eric W. Biederman <ebiederm <at> xmission.com> writes:
>
>
>> Part of the request was to put all of this information together
>> in a common place. And note that it is actually:
>> tagger="$GIT_COMMITTER_NAME <$GIT_COMMITTER_EMAIL> $GIT_COMMITTER_DATE"
>> Where the date is a human unreadable string of the number of seconds
>> since the epoch (aka 1 Jan 1970 UTC).
>
> This may sound whacy, but how about having git-env command that
>
> (1) parrots GIT_* environment variables if the user has one; or
> (2) shows the values of environment variables the user _could_ have had
> to cause the program to behave the same way, when it the user does
> not have them?
I like the general idea. But I hate the code implications for
echoing environmental variables that git cares about. Especially
since we really don't care about the environmental variables. Instead
we are doing this because we are doing things that the are best
not done in shell.
So I have made the program git-var [ -l | <variable name ]
Without the implicit tying we can just export those values
that we find interesting. -l will list all of the variables
and their values like env, while specifying an single variable
will just read that variables value.
Eric
^ permalink raw reply
* [ANNOUNCE] Gct-0.1, a GUI enabled Git commit tool
From: Fredrik Kuivinen @ 2005-07-15 0:46 UTC (permalink / raw)
To: git
Hi,
Gct v0.1 has been released and can be downloaded from
http://www.cyd.liu.se/~freku045/gct/gct-0.1.tar.gz
What follows is an excerpt from the README in the tarball:
Introduction
------------
Git Commit Tool or gct is a simple GUI enabled Git commit tool. It
allows the user to select which files should be committed, write
commit messages and perform the commit. It also has some support for
controlling the synchronisation between the Git cache and the working
directory.
Any comments, suggestions and/or bug reports regarding Gct are greatly
appreciated.
Requirements
------------
* Python, http://www.python.org
* Qt version 3.*, http://www.trolltech.com/products/qt/index.html
* PyQt, http://www.riverbankcomputing.co.uk/pyqt/
* Git a fairly recent snapshot,
http://www.kernel.org/pub/software/scm/git/ and
rsync://rsync.kernel.org/pub/scm/git/git.git
Gct has been developed with Python 2.3, Qt 3.3.4 and PyQt 2.13. Other
fairly recent versions may or may not work.
- Fredrik Kuivinen
^ permalink raw reply
* [PATCH 1/6] Move git_author_info and git_commiter_info to ident.c
From: Eric W. Biederman @ 2005-07-15 0:50 UTC (permalink / raw)
To: Linus Torvalds; +Cc: git
Moving these functions allows all of the logic for figuring out what
these values are to be shared between programs.
---
cache.h | 2 ++
commit-tree.c | 10 ----------
ident.c | 10 ++++++++++
3 files changed, 12 insertions(+), 10 deletions(-)
c6f1b65729df142a8968441ca441f6b69926127a
diff --git a/cache.h b/cache.h
--- a/cache.h
+++ b/cache.h
@@ -223,6 +223,8 @@ void datestamp(char *buf, int bufsize);
extern int setup_ident(void);
extern char *get_ident(const char *name, const char *email, const char *date_str);
+extern char *git_author_info(void);
+extern char *git_committer_info(void);
static inline void *xmalloc(size_t size)
{
diff --git a/commit-tree.c b/commit-tree.c
--- a/commit-tree.c
+++ b/commit-tree.c
@@ -79,16 +79,6 @@ static int new_parent(int idx)
return 1;
}
-static char *git_author_info(void)
-{
- return get_ident(gitenv("GIT_AUTHOR_NAME"), gitenv("GIT_AUTHOR_EMAIL"), gitenv("GIT_AUTHOR_DATE"));
-}
-
-static char *git_committer_info(void)
-{
- return get_ident(gitenv("GIT_COMMITTER_NAME"), gitenv("GIT_COMMITTER_EMAIL"), gitenv("GIT_COMMITTER_DATE"));
-}
-
int main(int argc, char **argv)
{
int i;
diff --git a/ident.c b/ident.c
--- a/ident.c
+++ b/ident.c
@@ -136,3 +136,13 @@ char *get_ident(const char *name, const
buffer[i] = 0;
return buffer;
}
+
+char *git_author_info(void)
+{
+ return get_ident(gitenv("GIT_AUTHOR_NAME"), gitenv("GIT_AUTHOR_EMAIL"), gitenv("GIT_AUTHOR_DATE"));
+}
+
+char *git_committer_info(void)
+{
+ return get_ident(gitenv("GIT_COMMITTER_NAME"), gitenv("GIT_COMMITTER_EMAIL"), gitenv("GIT_COMMITTER_DATE"));
+}
^ permalink raw reply
* [PATCH 2/6] ident.c: Disambiguate the error messages in setup_ident
From: Eric W. Biederman @ 2005-07-15 0:52 UTC (permalink / raw)
To: Linus Torvalds; +Cc: git
If your user name is too long it is your sysadmin who
hates you not your parents!
Signed-off-by: Eric W. Biederman <ebiederm@xmission.com>
---
ident.c | 4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
935f88376b79fc19df6dff85ba57ed94f06d79f0
diff --git a/ident.c b/ident.c
--- a/ident.c
+++ b/ident.c
@@ -26,13 +26,13 @@ int setup_ident(void)
/* Get the name ("gecos") */
len = strlen(pw->pw_gecos);
if (len >= sizeof(real_name))
- die("Your parents must have hated you");
+ die("Your parents must have hated you!");
memcpy(real_name, pw->pw_gecos, len+1);
/* Make up a fake email address (name + '@' + hostname [+ '.' + domainname]) */
len = strlen(pw->pw_name);
if (len > sizeof(real_email)/2)
- die("Your parents must have hated you");
+ die("Your sysadmin must have hate you!");
memcpy(real_email, pw->pw_name, len);
real_email[len++] = '@';
gethostname(real_email + len, sizeof(real_email) - len);
^ permalink raw reply
* [PATCH 3/6] Add git-var a tool for reading interesting git variables.
From: Eric W. Biederman @ 2005-07-15 0:55 UTC (permalink / raw)
To: Linus Torvalds; +Cc: git
Sharing code between shell scripts and C is a challenge.
The program git-var allows us to have a set of named values
that a shell script can interrogate and a normal C program
can simply call the functions that compute them. Allowing
sharing when computing plain test values.
---
Documentation/git-var.txt | 60 ++++++++++++++++++++++++++++++++++++++++++
Documentation/git.txt | 3 ++
Makefile | 3 +-
var.c | 65 +++++++++++++++++++++++++++++++++++++++++++++
4 files changed, 130 insertions(+), 1 deletions(-)
create mode 100644 Documentation/git-var.txt
create mode 100644 var.c
2c929de1b5444fadda13becb6df3d852277e6e27
diff --git a/Documentation/git-var.txt b/Documentation/git-var.txt
new file mode 100644
--- /dev/null
+++ b/Documentation/git-var.txt
@@ -0,0 +1,60 @@
+git-var(1)
+==================
+v0.1, July 2005
+
+NAME
+----
+git-var - Print the git users identity
+
+
+SYNOPSIS
+--------
+git-var [ -l | <variable> ]
+
+DESCRIPTION
+-----------
+Prints a git logical variable.
+
+-l causes the logical variables to be listed.
+
+EXAMPLE
+--------
+$git-var GIT_AUTHOR_IDENT
+
+Eric W. Biederman <ebiederm@lnxi.com> 1121223278 -0600
+
+
+VARIABLES
+----------
+GIT_AUTHOR_IDENT
+ The author of a piece of code.
+
+GIT_COMMITTER_IDENT
+ The person who put a piece of code into git.
+
+Diagnostics
+-----------
+You don't exist. Go away!::
+ The passwd(5) gecos field couldn't be read
+Your parents must have hated you!::
+ The password(5) gecos field is longer than a giant static buffer.
+Your sysadmin must have hate you!::
+ The password(5) name field is longer than a giant static buffer.
+
+See Also
+--------
+link:git-commit-tree.html[git-commit-tree]
+link:git-tag-script.html[git-tag-script]
+
+Author
+------
+Written by Eric Biederman <ebiederm@xmission.com>
+
+Documentation
+--------------
+Documentation by Eric Biederman and the git-list <git@vger.kernel.org>.
+
+GIT
+---
+Part of the link:git.html[git] suite
+
diff --git a/Documentation/git.txt b/Documentation/git.txt
--- a/Documentation/git.txt
+++ b/Documentation/git.txt
@@ -111,6 +111,9 @@ link:git-tar-tree.html[git-tar-tree]::
link:git-unpack-file.html[git-unpack-file]::
Creates a temporary file with a blob's contents
+link:git-var.html[git-var]::
+ Displays a git logical variable
+
link:git-verify-pack.html[git-verify-pack]::
Validates packed GIT archive files
diff --git a/Makefile b/Makefile
--- a/Makefile
+++ b/Makefile
@@ -48,7 +48,7 @@ PROG= git-update-cache git-diff-files
git-diff-stages git-rev-parse git-patch-id git-pack-objects \
git-unpack-objects git-verify-pack git-receive-pack git-send-pack \
git-prune-packed git-fetch-pack git-upload-pack git-clone-pack \
- git-show-index git-daemon
+ git-show-index git-daemon git-var
all: $(PROG)
@@ -148,6 +148,7 @@ git-receive-pack: receive-pack.c
git-send-pack: send-pack.c
git-prune-packed: prune-packed.c
git-fetch-pack: fetch-pack.c
+git-var: var.c
git-http-pull: LIBS += -lcurl
git-rev-list: LIBS += -lssl
diff --git a/var.c b/var.c
new file mode 100644
--- /dev/null
+++ b/var.c
@@ -0,0 +1,65 @@
+/*
+ * GIT - The information manager from hell
+ *
+ * Copyright (C) Eric Biederman, 2005
+ */
+#include "cache.h"
+#include <stdio.h>
+#include <errno.h>
+#include <string.h>
+
+static char *var_usage = "git-var [-l | <variable>]";
+
+struct git_var {
+ const char *name;
+ char *(*read)(void);
+};
+static struct git_var git_vars[] = {
+ { "GIT_COMMITTER_IDENT", git_committer_info },
+ { "GIT_AUTHOR_IDENT", git_author_info },
+ { "", NULL },
+};
+
+static void list_vars(void)
+{
+ struct git_var *ptr;
+ for(ptr = git_vars; ptr->read; ptr++) {
+ printf("%s=%s\n", ptr->name, ptr->read());
+ }
+}
+
+static const char *read_var(const char *var)
+{
+ struct git_var *ptr;
+ const char *val;
+ val = NULL;
+ for(ptr = git_vars; ptr->read; ptr++) {
+ if (strcmp(var, ptr->name) == 0) {
+ val = ptr->read();
+ break;
+ }
+ }
+ return val;
+}
+
+int main(int argc, char **argv)
+{
+ const char *val;
+ if (argc != 2) {
+ usage(var_usage);
+ }
+ setup_ident();
+ val = NULL;
+
+ if (strcmp(argv[1], "-l") == 0) {
+ list_vars();
+ return 0;
+ }
+ val = read_var(argv[1]);
+ if (!val)
+ usage(var_usage);
+
+ printf("%s\n", val);
+
+ 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