* Re: gitk-1.0 released
From: walt @ 2005-05-20 1:10 UTC (permalink / raw)
To: git
In-Reply-To: <17036.36624.911071.810357@cargo.ozlabs.ibm.com>
Paul Mackerras wrote:
> I have released a new version of gitk. I got brave and called it 1.0
> and it is at:
>
> http://ozlabs.org/~paulus/gitk-1.0
.
.
.
Today, gitk works beautifully for me. Yesterday, though, I had a weird
first experience when it opened a very attractive tcl/tk interface which
displayed no text of any kind. I tried fiddling with the two menus you
provide, bit still no success.
I finally just gave up. When I tried gitk again today -- it was magic!
All the kernel tree appeared just as (I suppose) you intended.
As far as I know, I did nothing to change anything since yesterday.
Can you venture a guess why I had sucess today and failure yesterday?
Does gitk perhaps depend on a generated database of some kind before
it will work properly?
^ permalink raw reply
* Re: [PATCH] Detect renames in diff family.
From: Junio C Hamano @ 2005-05-20 0:48 UTC (permalink / raw)
To: Linus Torvalds; +Cc: git
In-Reply-To: <Pine.LNX.4.58.0505191656310.2322@ppc970.osdl.org>
>>>>> "LT" == Linus Torvalds <torvalds@osdl.org> writes:
LT> Hmm.. You're right, but it feels kind of wrong. Clearly we
LT> support removals in diff-files, but you're right, we can
LT> never have something show up as an addition, since we only
LT> ever compare against files that are already mentioned in the
LT> cache.
LT> Or am I just being confused and/or stupid?
No, you are not confused nor stupid. We discussed something
related to this about three weeks ago. We ended up not doing
what we discussed, but if we had adopted the convention of the
delayed addition to the cache I described as "magic SHA1" in the
quoted message below, that would have been the "intent to add"
that diff-files would report as an addition.
To: Linus Torvalds <torvalds@osdl.org>
Cc: git@vger.kernel.org
Subject: Re: [PATCH] Really fix git-merge-one-file-script this time.
From: Junio C Hamano <junkio@cox.net>
Date: Sun, 01 May 2005 11:38:15 -0700
Message-ID: <7vzmveu6zs.fsf@assigned-by-dhcp.cox.net>
(... some discussion omitted ...)
I am wondering if the following changes would make sense and
make things easier for you:
* git-merge-one-file-script is changed to register the path
with --cacheinfo using magic SHA1 0{40} instead of using the
resulting file on the filesystem. Do keep the current
behaviour of leaving the merge results of trivial merges
(both kind) in the work tree.
* git-write-tree is changed to refuse to write from a cache
that records the magic SHA1.
* git-ls-files acquires a new option --merged to notice the
magic SHA1 and shows the paths that have such SHA1.
* git-update-cache acquires a new option --resolve to notice
the magic SHA1 and:
- if the named path is not in the work tree anymore, delete
the entry.
- if the named path exists in the work tree, compute the
latest SHA1 for that file and update the entry.
Changes other than the first two listed above are purely
optional, since the Porcelain layer can implement them without
the Plumbing support. Not doing them would keep the Plumbing
somewhat cleaner by not having to know about this magic SHA1
convention. On the other hand, we already use that convention
in git-diff-cache, so it may even be a consistent change to make
these optional changes. Essentially, the magic SHA1 in the
cache means "I know the user wants me to keep an eye on this
path when it matters" [*2*].
[Footnotes]
(... footnote *1* omitted ...)
*2* This convention would also make an implementation of "SCM
add" in the Porcelain layer a bit more efficient. A typical
workflow without such a convention would consist of:
* Create a file and start editing.
* "SCM add" file, causing "git-update-cache --add -- file".
* Do more changes, and review.
* "SCM commit" which does"git-update-cache" changed files,
"git-write-tree" and "git-commit-tree" to commit.
which wastes one extra blob object per "SCM add". My gut
feeling is that more than 80% of the time "SCM add" is followed
by some edit to the added file before "SCM commit", unless it is
the initial import. If we adopt that convention, "SCM add"
would register with --cacheinfo with the magic SHA1 without
creating the useless blob, and "SCM commit" will be written to
lazily pick things up from the work tree.
^ permalink raw reply
* Re: [PATCH] Detect renames in diff family.
From: Linus Torvalds @ 2005-05-20 0:10 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Nicolas Pitre, git
In-Reply-To: <7vhdgyyeom.fsf@assigned-by-dhcp.cox.net>
On Thu, 19 May 2005, Junio C Hamano wrote:
>
> Not quite a related topic, but unless we start to support the
> copy detection you recommended against, my understanding is that
> -M does not do anything useful for git-diff-files. Is there a
> good use case for it? I am not advocating for its removal so
> please leave the command line option there.
Hmm.. You're right, but it feels kind of wrong. Clearly we support
removals in diff-files, but you're right, we can never have something show
up as an addition, since we only ever compare against files that are
already mentioned in the cache.
On the other hand, a unmerged entry really _could_ be a new file, could it
not? Even if we right now always report it as "Unmerged path"? If it's a
case of existing in stage 2/3 only, it really should show up as a new file
diff for git-diff-files, no?
Or am I just being confused and/or stupid?
Linus
^ permalink raw reply
* Re: gitk-1.0 released
From: Benjamin Herrenschmidt @ 2005-05-19 23:13 UTC (permalink / raw)
To: Paul Mackerras; +Cc: git
In-Reply-To: <17036.36624.911071.810357@cargo.ozlabs.ibm.com>
On Thu, 2005-05-19 at 23:05 +1000, Paul Mackerras wrote:
> I have released a new version of gitk. I got brave and called it 1.0
> and it is at:
>
> http://ozlabs.org/~paulus/gitk-1.0
>
> (that's the actual script itself).
>
> Gitk is a git commit viewer with the following features:
>
> * Clear and compact representation of the commit graph
> * Displays headline, author and date of each commit in the
> summary window
> * Displays the full details of one commit - the comments,
> list of files and colorized diff - in the details window
> * Find function for searching through commits
> * Displays the SHA1 ID of the selected commit and makes it
> the X selection so it can be pasted into other windows
> * Convenient key bindings for scanning through each commit
> in turn
Cool !
Here's a feature request though: beeing able to type/paste a SHA1 in the
SHA1 ID field to "jump" to that commit :)
Ben.
^ permalink raw reply
* Re: [PATCH] Detect renames in diff family.
From: Junio C Hamano @ 2005-05-19 23:32 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Nicolas Pitre, git
In-Reply-To: <Pine.LNX.4.58.0505191516350.2322@ppc970.osdl.org>
Not quite a related topic, but unless we start to support the
copy detection you recommended against, my understanding is that
-M does not do anything useful for git-diff-files. Is there a
good use case for it? I am not advocating for its removal so
please leave the command line option there.
^ permalink raw reply
* Re: [PATCH] Remove gitenv macro hack
From: Junio C Hamano @ 2005-05-19 23:41 UTC (permalink / raw)
To: Dan Weber; +Cc: Git Mailing List
In-Reply-To: <Pine.LNX.4.62.0505191800280.16809@mirrorlynx.com>
Please do not do this.
I believe we have that in quite a few places. IIRC, it is one
of the Linus-approved GCC extensions and also used extensively
in the kernel source.
./cache.h:39:#define gitenv(e) (getenv(e) ? : gitenv_bc(e))
./commit-tree.c:149: commitgecos = gitenv("GIT_COMMITTER_NAME") ? : realgecos;
./commit-tree.c:150: commitemail = gitenv("GIT_COMMITTER_EMAIL") ? : realemail;
./commit-tree.c:151: gecos = gitenv("GIT_AUTHOR_NAME") ? : realgecos;
./commit-tree.c:152: email = gitenv("GIT_AUTHOR_EMAIL") ? : realemail;
./fsck-cache.c:359: char *git_dir = gitenv(GIT_DIR_ENVIRONMENT) ? : DEFAULT_GIT_DIR_ENVIRONMENT;
./diff.c:35: diff_opts = gitenv("GIT_DIFF_OPTS") ? : diff_opts;
./diff.c:358: prepare_temp_file(other ? : name, &temp[1], two);
./diff.c:398: builtin_diff(name, other ? : name, temp);
./diff.c:717: diff_rename_minimum_score = minimum_score_ ? : MINIMUM_SCORE;
./sha1_file.c:203: const char *alt = gitenv(ALTERNATE_DB_ENVIRONMENT) ? : "";
./sha1_file.c:215: cp = strchr(last, ':') ? : last + strlen(last);
^ permalink raw reply
* Re: gitk-1.0 released
From: Paul Mackerras @ 2005-05-19 22:32 UTC (permalink / raw)
To: Ingo Molnar; +Cc: git
In-Reply-To: <20050519132411.GA29111@elte.hu>
Ingo Molnar writes:
> very nice! Works well and it's pretty fast on a 2GHz P4.
I'm glad you like it. :)
> The "Octopus merge ..." text is incorrectly overlayed with a graph line.
The patch below fixes that.
> - i guess this one is on your todo list: the history graph of a single
> object (file).
Yes. I was hoping that git-rev-tree would grow an option to do the
necessary selection of commits and produce a simplified graph. I
could do it in Tcl but it's probably better done in C.
> - first window appearance on an uncached repository can be pretty slow
> due to disk seeks - so it might make sense to display something (an
> hourglass?) sooner - when i first started it i thought it hung. On
> already cached repositories the window comes up immediately, and the
> list of commits is updated dynamically.
The problem is that git-rev-tree HEAD doesn't output anything until it
has read all the relevant commits, which can involve a lot of disk
seeks. I put the "Reading commits..." message in to indicate that
something was happening, but your hourglass cursor suggestion is a
good one. It looks like git-rev-list might be better suited to what I
want, actually.
> (and the biggest missing feature of GIT right now is author +
> last-commit annotated file viewing which could be integrated into gitk
> a'ka BK's revtool: selecting a given line of the file would bring one to
> that commit, etc.)
Yes, indeed. I'll have to think about how to do it in a responsive
fashion, since getting the necessary information involves reading all
the commits and all the tree objects back to the beginning of time,
AFAICS. Gitk currently only reads the tree objects when you select a
commit, and it does that asynchronously; when you select a commit, it
immediately displays the commit message and starts a git-diff-tree
process. When the output from git-diff-tree arrives, it updates the
listbox and then (if you haven't selected another commit in the
meantime) starts a git-diff-tree -p to get the diff. As the output
from git-diff-tree arrives, it is colorized and placed in the details
window. That's why you can let the up or down key autorepeat and gitk
doesn't get hopelessly behind.
Another thing I want to do is find a way to display the deleted lines
in the annotated file listing. One thing I found quite frustrating
with bk revtool was trying to find which changeset deleted some
particular lines of code. I was basically reduced to binary searching
through the changesets - and with a large source file, just finding
the place to check in the annotated listing for each changeset was
time-consuming and error-prone in itself.
Paul.
diff -urN gitk-1.0/gitk gitk
--- gitk-1.0/gitk 2005-05-20 08:17:18.000000000 +1000
+++ gitk 2005-05-20 08:09:38.000000000 +1000
@@ -563,6 +563,9 @@
-fill $ofill -outline black -width 1]
$canv raise $t
set xt [expr $canvx0 + $nlines * $linespc]
+ if {$nparents($id) > 2} {
+ set xt [expr {$xt + ($nparents($id) - 2) * $linespc}]
+ }
set headline [lindex $commitinfo($id) 0]
set name [lindex $commitinfo($id) 1]
set date [lindex $commitinfo($id) 2]
^ permalink raw reply
* Re: [PATCH] Detect renames in diff family.
From: Linus Torvalds @ 2005-05-19 22:26 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Nicolas Pitre, git
In-Reply-To: <7vll6ayjok.fsf@assigned-by-dhcp.cox.net>
On Thu, 19 May 2005, Junio C Hamano wrote:
>
> We are talking about the Plumbing. Thank you for reminding me,
> but sometimes people end up using the bare Plumbing.
There's a pretty simple and nice way to make it both useful and easy to do
to arbitrary precision.
Think of the number following the -M as the mantissa.
So -M9 means 0.9 aka "90% match" (or "difference", depending on which way
you want to go), and in general -Mx would have the "10% increments" thing.
But since it's a fraction, you just give more precision by adding more
numbers, and -M99 would be "99% match", while "-M02" would be "2% match"
Then it would be logical for a plain -M to be 100% match / 0% difference
(ie only show renames that are exact), since a "0% match" / 100%
difference is nonsensical.
Alternatively, we'd have -M (without any number) just default to
something, and you'd give a separate number of how closely you want to
mach things, ie
# These all mean the same thing: (default) 20% difference
git-diff-tree -M
git-diff-tree -M --match=80
git-diff-tree -M --differ=20
# show only renames that are perfect matches.
git-diff-tree -M --match=100
# show _everything_ as a rename, except the
# matching matrix means that we prefer better
# matches over worse
git-diff-tree -M --match=0
Hmm?
Linus
^ permalink raw reply
* [PATCH] Remove gitenv macro hack
From: Dan Weber @ 2005-05-19 22:01 UTC (permalink / raw)
To: Git Mailing List
Removed hacky macro for gitenv. Often produced warnings by the compiler
for the use of ?: without anything after the ?
Signed-off-by: Dan Weber <dan@mirrorlynx.com>
---
commit 1b48b369a152a6315a9b4e6eebf50f56176cdd82
tree 53c238f3aa788df47325c456ab16b0eb25004074
parent 5cd4c7b7686d334e341b21d92449349feda3ef65
author Dan Weber <dan@mirrorlynx.com> Thu, 19 May 2005 17:57:44 -0400
committer Dan Weber <dan@mirrorlynx.com> Thu, 19 May 2005 17:57:44 -0400
cache.h | 8 +++++++-
1 files changed, 7 insertions(+), 1 deletion(-)
Index: cache.h
===================================================================
--- ca5fef50fb68a3afbb35e1a48ac622f7a964f021/cache.h (mode:100644)
+++ 53c238f3aa788df47325c456ab16b0eb25004074/cache.h (mode:100644)
@@ -37,7 +37,13 @@
* We accept older names for now but warn.
*/
extern char *gitenv_bc(const char *);
-#define gitenv(e) (getenv(e) ? : gitenv_bc(e))
+static inline char* gitenv(const char* name) {
+ char* result = getenv(name);
+ if (result)
+ return result;
+ else
+ return gitenv_bc(name);
+}
/*
* Basic data structures for the directory cache
^ permalink raw reply
* Re: [PATCH] Detect renames in diff family.
From: Junio C Hamano @ 2005-05-19 21:44 UTC (permalink / raw)
To: Nicolas Pitre; +Cc: Linus Torvalds, git
In-Reply-To: <Pine.LNX.4.62.0505191643030.20274@localhost.localdomain>
>>>>> "NP" == Nicolas Pitre <nico@cam.org> writes:
NP> Are we talking about git plumbing or porcelain here?
We are talking about the Plumbing. Thank you for reminding me,
but sometimes people end up using the bare Plumbing.
As I stated before, I do not do Porcelain [*1*]; my main
interest lies in helping Linus and Linux Kernel development
process, by helping him in the Plumbing area and making the use
of bare Plumbing layer a confortable enough experience.
My ultimate goal is to make the Plumbing useful enough to make
what Porcelain layers do more or less irrelevant ;-).
[Footnote]
*1* Yes I do have my own Porcelain layer, and personally I feel
some of the things it does and some of the approaches it takes
are quite good, but I do not advocate it more than necessary on
this list.
^ permalink raw reply
* Re: [PATCH] Detect renames in diff family.
From: Nicolas Pitre @ 2005-05-19 20:48 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Linus Torvalds, git
In-Reply-To: <7vy8abx8ay.fsf@assigned-by-dhcp.cox.net>
On Thu, 19 May 2005, Junio C Hamano wrote:
> >>>>> "NP" == Nicolas Pitre <nico@cam.org> writes:
>
> NP> Yes, but 0-9 is putting a bound on the accuracy. What if someone wants
> NP> not more than 2% difference?
>
> That statement is correct, but I think you are looking at it
> from a developer perspective.
>
> I suspect people would not want to pay the price of having
> always to type many digits for the benefit of being able to
> specify differences of 2% and 5%. Would you also complain gzip
> only lets you say -1 .. -9 and not -1.63 ;-)?
Are we talking about git plumbing or porcelain here?
Nicolas
^ permalink raw reply
* Re: git-diff-tree for the first commit
From: Linus Torvalds @ 2005-05-19 20:46 UTC (permalink / raw)
To: Thomas Glanzmann; +Cc: GIT
In-Reply-To: <Pine.LNX.4.58.0505191323060.2322@ppc970.osdl.org>
On Thu, 19 May 2005, Linus Torvalds wrote:
>
> That said, a new flag that says "diff the root against the NUL tree"
> wouldn't be wrong either, for when that is what you want.
Done. Use "git-diff-tree --root" if you want to see the root commit as a
big diff against nothing.
Linus
^ permalink raw reply
* Re: git-diff-tree for the first commit
From: Thomas Glanzmann @ 2005-05-19 20:38 UTC (permalink / raw)
To: GIT
In-Reply-To: <Pine.LNX.4.58.0505191323060.2322@ppc970.osdl.org>
Hello,
I see. Thanks for the elaboration. I got the idea now. ;-)
> That said, a new flag that says "diff the root against the NUL tree"
> wouldn't be wrong either, for when that is what you want.
I want it for the following scenario:
My git frontend sets the time stamps of the checked-out files to the
time of the last modification. That way I can do a 'ls -lart' in a sub
directory and have the most recently touched files on bottom. I also
want to use this for keyword expansion.
I currently do it by calling more or less 'git-rev-tool HEAD' and
'git-diff-tree -r REVISION' and cache the output. However for the inital
import are no 'timestamps' available. Now I can do two things. Implement
a git-diff-tree flag or assume that any files which don't have a delta
are imported by the initial tree.
Ideas?
Thomas
^ permalink raw reply
* Re: [PATCH] Detect renames in diff family.
From: Junio C Hamano @ 2005-05-19 20:36 UTC (permalink / raw)
To: Nicolas Pitre; +Cc: Linus Torvalds, git
In-Reply-To: <Pine.LNX.4.62.0505191456040.20274@localhost.localdomain>
>>>>> "NP" == Nicolas Pitre <nico@cam.org> writes:
NP> Yes, but 0-9 is putting a bound on the accuracy. What if someone wants
NP> not more than 2% difference?
That statement is correct, but I think you are looking at it
from a developer perspective.
I suspect people would not want to pay the price of having
always to type many digits for the benefit of being able to
specify differences of 2% and 5%. Would you also complain gzip
only lets you say -1 .. -9 and not -1.63 ;-)?
^ permalink raw reply
* Re: [PATCH 1/2] Introduce git-run-with-user-path helper program.
From: Junio C Hamano @ 2005-05-19 20:35 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Petr Baudis, git
In-Reply-To: <Pine.LNX.4.58.0505181731450.18337@ppc970.osdl.org>
>>>>> "LT" == Linus Torvalds <torvalds@osdl.org> writes:
LT> ... I do believe that git-run-with-user-path _could_ be a
LT> good way to abstract out the "where the heck in the tree am
LT> I?" issues.
Yes, I am still in search of a good way to abstract that issue
out and I myself is not yet convinced that the command in its
current form _is_ a good enough way yet.
What I am most unhappy about with it lies elsewhere, though.
There needs to be a better way to tell it how the underlying
command handles non-paths arguments, so that I can just say
git-run-with-user-path <some option spec for the command> \
command arg1 arg2 arg3 ...
and if arg1 through argO is non-path options then have it
canonicalize and filter only starting from argO+1. That would
alleviate one issue I have with the current implementation.
^ permalink raw reply
* Re: git-diff-tree for the first commit
From: Linus Torvalds @ 2005-05-19 20:31 UTC (permalink / raw)
To: Thomas Glanzmann; +Cc: GIT
In-Reply-To: <20050519195110.GG8105@cip.informatik.uni-erlangen.de>
On Thu, 19 May 2005, Thomas Glanzmann wrote:
>
> I would like to see output for the first commit (initial import) in:
>
> git-rev-list HEAD | git-diff-tree -r --stdin
>
> is it supposed to just be empty or is that a bug?
Hmm.. That's a bug and/or a feature, entirely depending on how you feel.
The first commit doesn't have a parent, so in the world where this is a
feature, this is 100% consistent with the notion that since there is
nothing to diff against, diff-tree has nothing to do.
In an alternate world, you can decide that not having a parent is
equivalent to being parented with an empty tree.
In yet a third world, you'd decide that all git projects should start off
from the empty tree root parent, and that the kernel project (and the git
archive itself) is invalid.
I don't think there is a right answer, except that I think the third
version is likely wrong, since by definition the kernel archive is
perfect.
There's actually some reason to consider the current behaviour correct, in
that the initial tree really _is_ special: it was imported from somewhere
else, and as such anybody who wants to know "what changed" really doesn't
want to see the explosion that happened at the beginning of time: that
wasn't a "change" at all, that was something else.
So the current behaviour actually is (in my opinion) the right one, at
least when considering something like git-whatchanged. Similarly, if you
use a variation of git-whatchanged to implement the equivalent of "cvs
annotate", leaving the lines that don't have a diff _non-annotated_ is
actually the right thing to do, since it would be wrong to say "they came
from the person who did the initial import".
That said, a new flag that says "diff the root against the NUL tree"
wouldn't be wrong either, for when that is what you want.
Linus
^ permalink raw reply
* Re: [PATCH] Detect renames in diff family.
From: H. Peter Anvin @ 2005-05-19 20:12 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Junio C Hamano, git
In-Reply-To: <Pine.LNX.4.58.0505191148470.2322@ppc970.osdl.org>
Linus Torvalds wrote:
>
> IOW, you're screwed. "execvp()" really should take an argument of type
> "const char * const *", but it doesn't for historical reasons.
>
The real problem, IMNSHO, is that C doesn't allow a pointer to a pointer
to a non-const object to be implicitly treated as a pointer to a pointer
to a const object. C should have required those two pointer classes to
have the same representation (which they would in any sane, and pretty
much any insane, system) and therefore a lot of functions could have the
additional consts added to their prototypes.
At least one can do casts on sane architectures... :-/
-hpa
^ permalink raw reply
* Re: [PATCH] Detect renames in diff family.
From: Junio C Hamano @ 2005-05-19 19:53 UTC (permalink / raw)
To: Linus Torvalds; +Cc: git
In-Reply-To: <Pine.LNX.4.58.0505191148470.2322@ppc970.osdl.org>
>>>>> "LT" == Linus Torvalds <torvalds@osdl.org> writes:
LT> IOW, you're screwed. "execvp()" really should take an argument of type
LT> "const char * const *", but it doesn't for historical reasons.
That's what I suspected.
^ permalink raw reply
* git-diff-tree for the first commit
From: Thomas Glanzmann @ 2005-05-19 19:51 UTC (permalink / raw)
To: GIT
Hello,
I would like to see output for the first commit (initial import) in:
git-rev-list HEAD | git-diff-tree -r --stdin
is it supposed to just be empty or is that a bug?
Thomas
^ permalink raw reply
* Re: [PATCH] packed delta git
From: Nicolas Pitre @ 2005-05-19 19:30 UTC (permalink / raw)
To: Thomas Glanzmann; +Cc: git
In-Reply-To: <20050519183810.GF8105@cip.informatik.uni-erlangen.de>
On Thu, 19 May 2005, Thomas Glanzmann wrote:
> Hello Chris,
>
> > size (du -sh .git) 2.5G 227M
>
> wow that beats bitkeeper in size. What is missing to actual use such a
> approach in a distributed environment?
Me completing fsck-cache support for delta objects.
Nicolas
^ permalink raw reply
* Re: [PATCH] Detect renames in diff family.
From: Nicolas Pitre @ 2005-05-19 18:58 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Linus Torvalds, git
In-Reply-To: <7vsm0jyryf.fsf@assigned-by-dhcp.cox.net>
On Thu, 19 May 2005, Junio C Hamano wrote:
> >>>>> "NP" == Nicolas Pitre <nico@cam.org> writes:
>
> NP> On Thu, 19 May 2005, Junio C Hamano wrote:
> >> - the command line interface "-M" to read "-M" or "-M[0-9]"
> >> (one digit); -M defaults to -M5 and give the cut-off point at
> >> similarity score 5000, -M9 at 9000, etc.
>
> NP> Why not a fractional value instead? -M1 is 100% the same while -M.95
> NP> allows for some 5% changes.
>
> We are essentially saying the same thing. Internally diff core
> uses score between 0 and 10000 but single digit proposed above
> or fractional both hides that from the user by normalizing the
> scale to something less arbitrary (in my case 0-9 in your case
> 0-1.0).
Yes, but 0-9 is putting a bound on the accuracy. What if someone wants
not more than 2% difference?
Nicolas
^ permalink raw reply
* Re: [PATCH] Detect renames in diff family.
From: Linus Torvalds @ 2005-05-19 18:55 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vy8abys5a.fsf@assigned-by-dhcp.cox.net>
On Thu, 19 May 2005, Junio C Hamano wrote:
>
> Here is another "doubt" point. I am almost embarrassed to ask
> this, but what's the right way to express the following? I
> could not figure out how to silence const warnings from gcc
> without using the cast there, which defeats the whole point of
> const warnings:
You're not doing this right.
Like it or not, "execvp()" does not take a pointer to "const char *".
It takes a pointer to a constant array of _non-const_ "char *".
Which is not what you have. You have a non-const array of "const char *",
and as a result, you need the cast.
In other words, you really need
char *exec_arg[9];
or, if you can indeed set the array to be const, you can make it be
char *const exec_arg[9] = {
pgm, name,
temp[0].name, temp[0].hex, temp[0].mode,
temp[1].name, temp[1].hex, temp[1].mode,
}
which would work, except to avoid warnings it obviously requires that none
of the strings themselves are "const" (which isn't true).
IOW, you're screwed. "execvp()" really should take an argument of type
"const char * const *", but it doesn't for historical reasons.
Linus
^ permalink raw reply
* Re: [PATCH] packed delta git
From: Chris Mason @ 2005-05-19 18:53 UTC (permalink / raw)
To: Thomas Glanzmann; +Cc: git
In-Reply-To: <20050519183810.GF8105@cip.informatik.uni-erlangen.de>
On Thursday 19 May 2005 14:38, Thomas Glanzmann wrote:
> Hello Chris,
>
> > size (du -sh .git) 2.5G 227M
>
> wow that beats bitkeeper in size. What is missing to actual use such a
> approach in a distributed environment?
It's not quite fair to compare with bitkeeper, since my changeset comments are
only the name of the bk->cvs patch, and I've only got 28k changesets vs bk's
60k or so.
In terms of actually making use of this, we need to deal with the hard linked
files during push/pull. This means using -H on rsync and teaching the
push/pull code about packed files.
git-pack needs to be able to unpack/undelta files so that people can clean a
tree.
git-fsck-cache needs to understand packed files and deltas.
-chris
^ permalink raw reply
* Re: [PATCH] Detect renames in diff family.
From: Junio C Hamano @ 2005-05-19 18:47 UTC (permalink / raw)
To: Nicolas Pitre; +Cc: Linus Torvalds, git
In-Reply-To: <Pine.LNX.4.62.0505191426000.20274@localhost.localdomain>
>>>>> "NP" == Nicolas Pitre <nico@cam.org> writes:
>> - I have been assuming that diff_delta uses its two input
>> read-only but have not verified that myself yet.
NP> It does.
Thanks (also thanks to Linus for pointing out the PROT_READ in
the test program).
^ permalink raw reply
* Re: [PATCH] Detect renames in diff family.
From: Junio C Hamano @ 2005-05-19 18:46 UTC (permalink / raw)
To: Nicolas Pitre; +Cc: Linus Torvalds, git
In-Reply-To: <Pine.LNX.4.62.0505191426000.20274@localhost.localdomain>
>>>>> "NP" == Nicolas Pitre <nico@cam.org> writes:
NP> On Thu, 19 May 2005, Junio C Hamano wrote:
>> - the command line interface "-M" to read "-M" or "-M[0-9]"
>> (one digit); -M defaults to -M5 and give the cut-off point at
>> similarity score 5000, -M9 at 9000, etc.
NP> Why not a fractional value instead? -M1 is 100% the same while -M.95
NP> allows for some 5% changes.
We are essentially saying the same thing. Internally diff core
uses score between 0 and 10000 but single digit proposed above
or fractional both hides that from the user by normalizing the
scale to something less arbitrary (in my case 0-9 in your case
0-1.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