* Re: [PATCH] diffcore-rename: favour identical basenames
From: Johannes Sixt @ 2007-06-22 7:17 UTC (permalink / raw)
To: git
In-Reply-To: <Pine.LNX.4.64.0706220214250.4059@racer.site>
Johannes Schindelin wrote:
> The dangerous thing is that the score can get negative now.
> ...
> + score = (int)(src_copied * MAX_SCORE / max_size)
> + - levenshtein(src->path, dst->path);
Does that also mean that you can't ever have a rename with a score of
100%?
(I haven't studied the algorithms and assume that levenshtein(a,b) == 0
only if a==b, and that without the -levenshtein(...) the score can grow
to 100%.)
-- Hannes
^ permalink raw reply
* Re: [PATCH] diffcore-rename: favour identical basenames
From: Jeff King @ 2007-06-22 5:41 UTC (permalink / raw)
To: Johannes Schindelin
Cc: Linus Torvalds, Shawn O. Pearce, git, govindsalinas, gitster
In-Reply-To: <Pine.LNX.4.64.0706220214250.4059@racer.site>
On Fri, Jun 22, 2007 at 02:14:43AM +0100, Johannes Schindelin wrote:
> @@ -313,20 +297,24 @@ void diffcore_rename(struct diff_options *options)
> if (rename_dst[i].pair)
> continue; /* dealt with an earlier round */
> for (j = 0; j < rename_src_nr; j++) {
> - int k;
> + int k, distance;
> struct diff_filespec *one = rename_src[j].one;
> if (!is_exact_match(one, two, contents_too))
> continue;
>
> + distance = levenshtein(one->path, two->path);
> /* see if there is a basename match, too */
> for (k = j; k < rename_src_nr; k++) {
This loop can start at k = j+1, since otherwise we are just checking
rename_src[j] against itself.
> +int levenshtein(const char *string1, const char *string2)
> +{
> + int len1 = strlen(string1), len2 = strlen(string2);
> + int *row1 = xmalloc(sizeof(int) * (len2 + 1));
> + int *row2 = xmalloc(sizeof(int) * (len2 + 1));
> + int i, j;
> +
> + for (j = 1; j <= len2; j++)
> + row1[j] = j;
This loop must start at j=0, not j=1; otherwise you have an undefined
value in row1[0], which gets read when setting row2[1], and you get
a totally meaningless distance (I got -1209667248 on my test case!).
-Peff
^ permalink raw reply
* Re: [RFC PATCH 2/2] Teach git-blame --gui how to start git-gui blame
From: Shawn O. Pearce @ 2007-06-22 5:37 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Jakub Narebski
In-Reply-To: <7vps3oa7kf.fsf@assigned-by-dhcp.pobox.com>
Junio C Hamano <gitster@pobox.com> wrote:
> "Shawn O. Pearce" <spearce@spearce.org> writes:
> > Junio C Hamano <gitster@pobox.com> wrote:
> >> This is only minor nuisance, but can we do something about this?
> >>
> >> $ git gui --version
> >> Application initialization failed: no display name and no $DISPLAY environment variable
> >>
> >> I know it is from wish, not you, so I wouldn't insist, though.
>
> If this makes life any harder to people on Windows, especially
> minGW, I would suggest against it.
Its already done. I don't think it will make a difference either
way right now.
Currently we still have to have a Bourne shell on both Cygwin
and MINGW platforms to perform key actions, like say git-clone.
The startup cost of git-gui is also rather high there anyway, so
this extra if test in Bourne shell before we exec into Tcl isn't
going to kill us.
Besides, you can side-step the entire Bourne shell thing by just
starting git-gui in wish yourself. E.g.
CALL /path/to/wish.exe /path/to/git-gui -- ...
I'd like to come back and make git-gui easier to install, perhaps by
making "starpacks" of git-gui and Git plumbing available for some
popular systems (e.g. MINGW/Windows, Mac OS X). Such starpacks
would give users an easy way to get git-gui (and thus basic Git)
up and running quickly. At that point I will need to revisit this
bootstrap code anyway.
--
Shawn.
^ permalink raw reply
* Re: [RFC PATCH 2/2] Teach git-blame --gui how to start git-gui blame
From: Junio C Hamano @ 2007-06-22 5:20 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: git, Jakub Narebski
In-Reply-To: <20070622044716.GG17393@spearce.org>
"Shawn O. Pearce" <spearce@spearce.org> writes:
> Junio C Hamano <gitster@pobox.com> wrote:
>> This is only minor nuisance, but can we do something about this?
>>
>> $ git gui --version
>> Application initialization failed: no display name and no $DISPLAY environment variable
>>
>> I know it is from wish, not you, so I wouldn't insist, though.
>
> Actually that should be fixable.
>
> Should be as simple as using a Bourne shell script up front to
> check for "z$1" = zversion || "z$1" = z--version, and if so dump
> back the version, otherwise exec wish. This is actually quite easy
> and won't change things for existing users. I'll put a patch into
> maint tonight for it.
If this makes life any harder to people on Windows, especially
minGW, I would suggest against it.
^ permalink raw reply
* Re: [PATCH] Make list of features auto-managed.
From: Nicolas Pitre @ 2007-06-22 5:15 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: Junio C Hamano, git
In-Reply-To: <20070622043329.GE17393@spearce.org>
On Fri, 22 Jun 2007, Shawn O. Pearce wrote:
> Yes, however my point here is that I think we have historically
> been bad about making our software reasonably future-proof.
>
> The .pack file has a version field, with value 2. REF_DELTA is not
> supported by those binaries that predated its introduction. They are
> unable to properly unpack, index or read a packfile using REF_DELTA.
> Why did the .pack version stay at 2 if REF_DELTA is used in the file?
Because:
1) you wouldn't be able to properly unpack, index or read a pack file
using those deltas even with a different pack version _anyway_, and
2) the pack encoding itself has not changed at all.
And #2 is real. The introduction of an additional object type didn't
turn the pack content into something that old git versions could
(mis)interpret and be fooled by.
On the other hand, changes leading to pack version 3 really required a
pack version bump as those changes could really be misinterpreted by
older git versions.
The fact that old git versions call the pack corrupt when it contains
unknown objects is a problem with the error message not the pack
version. We even had a bad error message for unknown pack versions too
before you improved it.
Nicolas
^ permalink raw reply
* Re: [RFC PATCH 2/2] Teach git-blame --gui how to start git-gui blame
From: Shawn O. Pearce @ 2007-06-22 4:47 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Jakub Narebski
In-Reply-To: <7vzm2sab63.fsf@assigned-by-dhcp.pobox.com>
Junio C Hamano <gitster@pobox.com> wrote:
> This is only minor nuisance, but can we do something about this?
>
> $ git gui --version
> Application initialization failed: no display name and no $DISPLAY environment variable
>
> I know it is from wish, not you, so I wouldn't insist, though.
Actually that should be fixable.
Should be as simple as using a Bourne shell script up front to
check for "z$1" = zversion || "z$1" = z--version, and if so dump
back the version, otherwise exec wish. This is actually quite easy
and won't change things for existing users. I'll put a patch into
maint tonight for it.
--
Shawn.
^ permalink raw reply
* Re: [PATCH] Make list of features auto-managed.
From: Shawn O. Pearce @ 2007-06-22 4:33 UTC (permalink / raw)
To: Nicolas Pitre; +Cc: Junio C Hamano, git
In-Reply-To: <alpine.LFD.0.99.0706212337030.20596@xanadu.home>
Nicolas Pitre <nico@cam.org> wrote:
> First of all, I mentioned at the time that using a . for separator
> between the tagged version and the number of commits since then in the
> git-describe output was a bad idea. You just made the perfect
> demonstration of that. If it was just me I'd change that . for a + or a
> : like the original patch did.
I preferred + as well, but we wound up with - in the final patch,
and GIT-VERSION-GEN replaces the - with a . because that makes RPM
happier or something:
VN=$(echo "$VN" | sed -e 's/-/./g');
> Now you say that you don't want to wait for the release to happen before
> using this cool new feature. Well, I'd reply that life is tough.
In comparsion to other things we all must deal with in life, this
is a cakewalk. ;-) But yes, your point is well made.
> Either you
> trick Junio into making a release sooner because the feature is just too
> valuable to wait. Or you try the feature (git-blame -w) and hope for
> the best. Certainly in that case you can predict the behavior of
> older git-blame versions if you pass it -w which they don't understand?
I think that's where we are. I can develop the feature, trick
git-gui into enabling it, but most end-users won't be able to use
it until Junio makes a 1.5.3-rc* or 1.5.3 final. Tough for them.
Tricking Junio is very hard, he isn't easily tricked. A good
quality for a mantainer to have.
> > I'd like to at least gracefully fail by
> > disabling an option, or suggesting the user upgrade their plumbing,
> > if an option isn't supported.
>
> Well you should be able to just try the option and detect it when it
> isn't supported.
Sure.
Except sometimes we have been lax about option checking and don't
always fail (though we usually do, but haven't always). And on
Windows doing a fork+exec to poll an option is expensive. Worse,
some options are destructive. For example `update-ref -d`.
Should I run `update-ref -d refs/heads/master` to see if the
-d option is supported by update-ref, so that I know if I should
create a particular UI widget or not? No, of course not. I should
use a special temporary name, like GITGUI_TEST_FEATURE. But now
I have to create and delete a temporary item just to decide if a
UI feature should be enabled. And if the feature doesn't exist,
then I have to cleanup the temporary item "by hand".
Annoying. Like this email thread I'm sure has become.
> > Unlike how we gracefully fail with a useful error message say
> > when an early 1.4 release that doesn't support offset deltas is
> > given a packfile with an OFS_DELTA in it (corrupt pack, recently
> > rediscussed on list). Or when a 1.5.1 client tries to checkout
> > a tree that uses the new subproject mode in 1.5.2 (missing blob,
> > recently discussed on #git).
>
> Those are different as you have an older version that couldn't
> anticipate the future. In your case you can "anticipate the past".
Yes, however my point here is that I think we have historically
been bad about making our software reasonably future-proof.
The .pack file has a version field, with value 2. REF_DELTA is not
supported by those binaries that predated its introduction. They are
unable to properly unpack, index or read a packfile using REF_DELTA.
Why did the .pack version stay at 2 if REF_DELTA is used in the file?
The packed-refs file was introduced without a version header
(whoops). Later Junio had to wedge things into there in order to
get a version header of sorts so we could have the tag deref values
cached in the packed-refs.
We weren't strict enough in checking file modes in the tree parser
(yes, that was actually a real bug) but basically we didn't think
ahead to what an older binary should do when a future binary used a
file mode we didn't understand. For example, the user setuid bit.
Or the new dirlink thing, which isn't even a valid mode in UNIX.
I think we are getting a little better at it, but in general we
have a really poor track record in this area.
--
Shawn.
^ permalink raw reply
* Re: [PATCH] Make list of features auto-managed.
From: Nicolas Pitre @ 2007-06-22 4:07 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: Junio C Hamano, git
In-Reply-To: <20070622032502.GA17393@spearce.org>
On Thu, 21 Jun 2007, Shawn O. Pearce wrote:
> > Nicolas Pitre <nico@cam.org> writes:
> > > When you need git behavior X and you know that it appeared in version Y
> > > then you only need to test for git_version >= Y. Determining that
> > > particular Y is much easier after the facts using the commit log than
> > > trying to anticipate what item should be added to a feature list for
> > > future usage. In fact the same argument as for not explicitly recording
> > > renames in commit objects should apply here.
>
> Here's the problem though: `git-blame -w` will be supported
> in Git 1.5.3 and later, we all know this. But Git doesn't.
> Ask git-describe what version `master` and `next` are; its
> v1.5.2.2-249 and v1.5.2.2-1050.
>
> So tell me, how can git-gui know that Git 1.5.2.2.249 is OK, and
> 1.5.3 is OK, but 1.5.2.3 isn't? Actually its 1.5.2.1.160 that is
> OK (b82871b introduced the -w option). Sure Junio won't release
> a 1.5.2.1.160 as an actual tagged release (160 patch releases to
> 1.5.2.1 is nuts). But what about in the future if a cool feature
> 3 commits past 1.5.3 appears? Wouldn't that look like 1.5.3.3,
> and isn't that a possibly valid version number?
>
> Besides, I can't say 1.5.2.3 is >= 1.5.2.2.249, because in git.git
> it isn't. Only 1.5.3 will be >= 1.5.2.2.249.
First of all, I mentioned at the time that using a . for separator
between the tagged version and the number of commits since then in the
git-describe output was a bad idea. You just made the perfect
demonstration of that. If it was just me I'd change that . for a + or a
: like the original patch did.
Now to your issue. I think that if you must rely upon a particular
version then it's best if it is a released version. Intermediate
versions as provided by git-describe aren't reliable enough to provide
a proper number to test against, especially in the presence of
concurrent branches. The 1.6.0+38 (let me use a saner output) from the
master branch is totally different from 1.6.0+38 from the 'next' branch.
So only released versions should be used to compare against.
Now you say that you don't want to wait for the release to happen before
using this cool new feature. Well, I'd reply that life is tough.
Either you
trick Junio into making a release sooner because the feature is just too
valuable to wait. Or you try the feature (git-blame -w) and hope for
the best. Certainly in that case you can predict the behavior of
older git-blame versions if you pass it -w which they don't understand?
> Nico mentioned that git-gui ships with git.git, and therefore should
> just rely on exactly whatever that git.git supports at the time of
> the merge. I think that is only partially valid. git-gui is also
> an independent project with a repository and history that exists
> outside of git.git. Users can (and should be able to) mix and
> match the version of git-gui with the version of plumbing, to the
> maximum extent possible.
Fair enough.
> I'd like to at least gracefully fail by
> disabling an option, or suggesting the user upgrade their plumbing,
> if an option isn't supported.
Well you should be able to just try the option and detect it when it
isn't supported.
> Unlike how we gracefully fail with a useful error message say
> when an early 1.4 release that doesn't support offset deltas is
> given a packfile with an OFS_DELTA in it (corrupt pack, recently
> rediscussed on list). Or when a 1.5.1 client tries to checkout
> a tree that uses the new subproject mode in 1.5.2 (missing blob,
> recently discussed on #git).
Those are different as you have an older version that couldn't
anticipate the future. In your case you can "anticipate the past".
Nicolas
^ permalink raw reply
* Re: [RFC PATCH 2/2] Teach git-blame --gui how to start git-gui blame
From: Junio C Hamano @ 2007-06-22 4:03 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: git, Jakub Narebski
In-Reply-To: <20070622035652.GD17393@spearce.org>
"Shawn O. Pearce" <spearce@spearce.org> writes:
> Junio C Hamano <gitster@pobox.com> wrote:
>> Hmm. Now, how does "git-blame" tell if there is usable git-gui
>> installed with it? Will we have "git-gui --list-features"?
>
> It can run `git gui version` and check to see that it is >= 0.7.3.
This is only minor nuisance, but can we do something about this?
$ git gui --version
Application initialization failed: no display name and no $DISPLAY environment variable
I know it is from wish, not you, so I wouldn't insist, though.
^ permalink raw reply
* Re: [PATCH] Make list of features auto-managed.
From: Junio C Hamano @ 2007-06-22 3:58 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: Nicolas Pitre, git
In-Reply-To: <20070622032502.GA17393@spearce.org>
"Shawn O. Pearce" <spearce@spearce.org> writes:
> Here's the problem though: `git-blame -w` will be supported
> in Git 1.5.3 and later, we all know this. But Git doesn't.
> Ask git-describe what version `master` and `next` are; its
> v1.5.2.2-249 and v1.5.2.2-1050.
>
> So tell me, how can git-gui know that Git 1.5.2.2.249 is OK, and
> 1.5.3 is OK, but 1.5.2.3 isn't?
You don't. Although 1.5.2.2.249 may have it, you do not enable
it for that version.
That is what "1.5.3 or later" implies. And in 6 weeks that
little distinction does not matter.
Pretty simple.
^ permalink raw reply
* Re: [RFC PATCH 2/2] Teach git-blame --gui how to start git-gui blame
From: Shawn O. Pearce @ 2007-06-22 3:56 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Jakub Narebski
In-Reply-To: <7vtzt13k4o.fsf@assigned-by-dhcp.pobox.com>
Junio C Hamano <gitster@pobox.com> wrote:
> Hmm. Now, how does "git-blame" tell if there is usable git-gui
> installed with it? Will we have "git-gui --list-features"?
It can run `git gui version` and check to see that it is >= 0.7.3.
;-)
I'm actually not sure we want to apply this patch, hence the RFC
prefix I put on it. Jakub suggested it, this crude implementation
was easy enough to hack together, so I posted a patch for someone
to play with if they were so inclined.
Maybe we should just put a link in the git-blame manual page to
the git-gui manual page:
diff --git a/Documentation/git-blame.txt b/Documentation/git-blame.txt
index 66f1203..599e10b 100644
--- a/Documentation/git-blame.txt
+++ b/Documentation/git-blame.txt
@@ -36,6 +36,9 @@ $ git log --pretty=oneline -S'blame_usage'
ea4c7f9bf69e781dd0cd88d2bccb2bf5cc15c9a7 git-blame: Make the output
-----------------------------------------------------------------------------
+A powerful graphical viewer for the output of git-blame can be
+accessed through the blame subcommand of gitlink:git-gui[1].
+
OPTIONS
-------
include::blame-options.txt[]
@@ -184,7 +187,8 @@ commit commentary), a blame viewer won't ever care.
SEE ALSO
--------
-gitlink:git-annotate[1]
+gitlink:git-annotate[1],
+gitlink:git-gui[1]
AUTHOR
------
--
Shawn.
^ permalink raw reply related
* Re: [PATCH] git-gui: use "blame -w -C -C" for "where did it come from, originally?"
From: Shawn O. Pearce @ 2007-06-22 3:34 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Junio C Hamano, git
In-Reply-To: <alpine.LFD.0.98.0706211243400.3593@woody.linux-foundation.org>
Linus Torvalds <torvalds@linux-foundation.org> wrote:
>
> On Thu, 21 Jun 2007, Linus Torvalds wrote:
> >
> > I'd personally rather *not* have git-gui make the -w/-M/-C choice for me.
> > Why don't you just allow the user to say? Sometimes I might want to see
> > who introduced broken whitespace. Let me say
> >
> > git gui blame -w filename.c
> >
> > please? Instead of making that choice for me, and then blaming git for
> > something that wasn't git's problem.
>
> Side note - this ended up being one reason why "gitk" is so good. It just
> passed down the arguments to "git-rev-list", and it allowed me to improve
> on the original gitk without gitk ever even _realizing_ it was improved
> upon. All the pathname filtering etc was done without gitk ever learning
> about it - it "just worked".
Hmm. Good point about gitk. We all know you would rather not hack
Tcl to enhance tools, because you would prefer to work directly in C.
A lot of the stuff rev-list does in pure C does translate
directly into gitk, and its one of the features that I also love
most about gitk. Except --reverse; gitk doesn't really like to do
`gitk --reverse --all`. But it can be extremely amusing to run if
you are bored and have time to waste.
However. The new blame viewer supports two columns, and runs two
blame passes to obtain the information for them. I like that,
because it offers up a lot of information in a single compact view.
Which column do I send the option(s) to? Do I let the user specify
which column to apply the options onto?
git gui blame --left='-C -C' --right= filename.c ;# default
git gui blame --left=-w --right=-M filename.c ;# not default
? Or do I only show one column if the user supplies command line
options? Doesn't that limit the tool?
--
Shawn.
^ permalink raw reply
* Re: [PATCH] Make list of features auto-managed.
From: Shawn O. Pearce @ 2007-06-22 3:25 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Nicolas Pitre, git
In-Reply-To: <7v7ipxw1bq.fsf@assigned-by-dhcp.pobox.com>
Junio C Hamano <gitster@pobox.com> wrote:
> Nicolas Pitre <nico@cam.org> writes:
> > I don't like this feature list idea at all.
>
> ... and thanks for bringing a bit of sanity to this thread.
Indeed. I've read Junio's counter proposal (the grep'ed FEATURE<?>
macro) and I'm now convinced you are both right, this feature list
thing is just going to grow out of control or nobody is going to
mark new features. Either way its useless for its intended purpose.
> > When you need git behavior X and you know that it appeared in version Y
> > then you only need to test for git_version >= Y. Determining that
> > particular Y is much easier after the facts using the commit log than
> > trying to anticipate what item should be added to a feature list for
> > future usage. In fact the same argument as for not explicitly recording
> > renames in commit objects should apply here.
Here's the problem though: `git-blame -w` will be supported
in Git 1.5.3 and later, we all know this. But Git doesn't.
Ask git-describe what version `master` and `next` are; its
v1.5.2.2-249 and v1.5.2.2-1050.
So tell me, how can git-gui know that Git 1.5.2.2.249 is OK, and
1.5.3 is OK, but 1.5.2.3 isn't? Actually its 1.5.2.1.160 that is
OK (b82871b introduced the -w option). Sure Junio won't release
a 1.5.2.1.160 as an actual tagged release (160 patch releases to
1.5.2.1 is nuts). But what about in the future if a cool feature
3 commits past 1.5.3 appears? Wouldn't that look like 1.5.3.3,
and isn't that a possibly valid version number?
Besides, I can't say 1.5.2.3 is >= 1.5.2.2.249, because in git.git
it isn't. Only 1.5.3 will be >= 1.5.2.2.249.
Nico mentioned that git-gui ships with git.git, and therefore should
just rely on exactly whatever that git.git supports at the time of
the merge. I think that is only partially valid. git-gui is also
an independent project with a repository and history that exists
outside of git.git. Users can (and should be able to) mix and
match the version of git-gui with the version of plumbing, to the
maximum extent possible. I'd like to at least gracefully fail by
disabling an option, or suggesting the user upgrade their plumbing,
if an option isn't supported.
Unlike how we gracefully fail with a useful error message say
when an early 1.4 release that doesn't support offset deltas is
given a packfile with an OFS_DELTA in it (corrupt pack, recently
rediscussed on list). Or when a 1.5.1 client tries to checkout
a tree that uses the new subproject mode in 1.5.2 (missing blob,
recently discussed on #git).
Maybe I should ask the StGIT folks how they deal with this, or if
they just don't worry about it. I'm suspecting its the latter...
Hmm.
--
Shawn.
^ permalink raw reply
* Re: Little fix and suggestion for the git tutorial
From: J. Bruce Fields @ 2007-06-22 3:18 UTC (permalink / raw)
To: Carlos Rica; +Cc: git
In-Reply-To: <1b46aba20706210945h49139cc2y69d2de972f014189@mail.gmail.com>
On Thu, Jun 21, 2007 at 06:45:01PM +0200, Carlos Rica wrote:
> Sorry for not sending a patch, I was following the tutorial and found
> this, in the section "Using git for collaboration":
>
> 307 With this, you can perform the first operation alone using the
> 308 "git fetch" command without merging them with her own branch,
> 309 using:
>
> I think that "you" should be replaced with "she".
Yep, thanks. Actually, I think we should make it "Alice".
> I have a suggestion also that I don't know how to fix. The text in
> that section seems to say something like you need to add a "remote"
> alias to be able to run fetch for retrieving without merging:
Yes, I agree, it's confusing. We're trying to introduce both fetch and
remotes at the same time.
It might be the simplest thing to do would just be to use remotes from
the start. I don't know. I haven't looked at this section in a
while--I'll try to find time this weekend and see if I can come up with
a better approach.
--b.
^ permalink raw reply
* Re: problem pushing repository
From: Andrew Ruder @ 2007-06-22 2:24 UTC (permalink / raw)
To: git
In-Reply-To: <7v8xacbvf1.fsf@assigned-by-dhcp.pobox.com>
On Thu, Jun 21, 2007 at 07:00:18PM -0700, Junio C Hamano wrote:
> $ ssh newberry.ihepa.ufl.edu sh -c 'echo $PATH'
>
> may be a good starting point to test this, and the first step
> to fix it would be
>
> $ man ssh
> $ man sshd
While I wholeheartedly agree with Junio here, you may also find
remote.<name>.receivepack
useful, see git-push(1) and git-config(1) for more information.
- Andy
--
Andrew Ruder <andy@aeruder.net>
http://www.aeruder.net
^ permalink raw reply
* Re: problem pushing repository
From: Junio C Hamano @ 2007-06-22 2:00 UTC (permalink / raw)
To: Adam Mercer; +Cc: git
In-Reply-To: <799406d60706211849h6e4fd1dbn487beab03fe1d79c@mail.gmail.com>
"Adam Mercer" <ramercer@gmail.com> writes:
> [ram@skymoo glue]$ git push
> ssh://ram@newberry.ihepa.ufl.edu/~ram/public_html/git/glue.git
> bash: line 1: git-receive-pack: command not found
> fatal: The remote end hung up unexpectedly
> error: failed to push to
> 'ssh://ram@newberry.ihepa.ufl.edu/~ram/public_html/git/glue.git'
> [ram@skymoo glue]$ which git-receive-pack
> /Users/ram/opt/git/bin/git-receive-pack
> [ram@skymoo glue]$
>
> git-receive-pack is in my $PATH so why can't it be found when trying to push?
Check your ssh and ssh server settings. Often the process
invoked from non-interactive ssh connection (such as the attempt
to invoke receive-pack) would not get the PATH you set up in ~/.login
or ~/.bash_profile.
$ ssh newberry.ihepa.ufl.edu sh -c 'echo $PATH'
may be a good starting point to test this, and the first step
to fix it would be
$ man ssh
$ man sshd
^ permalink raw reply
* problem pushing repository
From: Adam Mercer @ 2007-06-22 1:49 UTC (permalink / raw)
To: git
Hi
I've just started using git to track a project I'm working on and I'm
having a problem pushing my repository.
[ram@skymoo glue]$ git push
ssh://ram@newberry.ihepa.ufl.edu/~ram/public_html/git/glue.git
bash: line 1: git-receive-pack: command not found
fatal: The remote end hung up unexpectedly
error: failed to push to
'ssh://ram@newberry.ihepa.ufl.edu/~ram/public_html/git/glue.git'
[ram@skymoo glue]$ which git-receive-pack
/Users/ram/opt/git/bin/git-receive-pack
[ram@skymoo glue]$
git-receive-pack is in my $PATH so why can't it be found when trying to push?
Cheers
Adam
^ permalink raw reply
* Re: [RFC][PATCH] Fix assumption that git is installed in a standard place on the remote end ssh
From: Kevin Green @ 2007-06-22 1:30 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git
In-Reply-To: <Pine.LNX.4.64.0706190114110.4059@racer.site>
On 06/18/07 20:16:47, Johannes Schindelin wrote:
> Hi,
>
> On Fri, 15 Jun 2007, Kevin Green wrote:
>
> > I'm thinking I like the env var idea much more though. I can just
> > export it in my shell and it works in both cases.
>
> And it completely breaks down when you have more than one remotes. Or when
> you cd to another project with another remote. Or etc. IOW it is fragile.
>
> Clearly, the config approach is the only one which makes sense. This
> information is so closely coupled to a specific remote that you should
> store it right where you store all the other remote information, too.
>
You're absolutely right. I agree, except that in _my_ environment git will
be in a non-standard path but *always* consistently in the same place. I'm being
greedy here. :)
The config approach is clearly the most versatile. The question I have is, is
there a good reason not to provide the third option of setting env var? I suppose that in the
more likely case this could cause more harm than good, i.e. maybe
this is too specific for my use case.
Thanks
--Kevin
^ permalink raw reply
* Re: [PATCH] diffcore-rename: favour identical basenames
From: Johannes Schindelin @ 2007-06-22 1:14 UTC (permalink / raw)
To: Jeff King; +Cc: Linus Torvalds, Shawn O. Pearce, git, govindsalinas, gitster
In-Reply-To: <20070621131915.GD4487@coredump.intra.peff.net>
Hi,
On Thu, 21 Jun 2007, Jeff King wrote:
> I think something like a Levenshtein distance between the full pathnames
> would give good results, and would cover almost every situation that the
> basename heuristic would (there are a few exceptions, like getting
> "file.c" from either "file2.c" or "foo/file.c", but that seems kind of
> pathological).
Well, now you only have to test if it makes sense:
-- snipsnap --
[PATCH] diffcore-rename: replace basename_same() heuristics by Levenshtein
Instead of insisting on identical basenames, try the levenshtein
distance.
Basically, if there are multiple rename source candidates, take the
one with the smallest Levenshtein distance.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
---
The dangerous thing is that the score can get negative now.
Makefile | 4 ++--
diffcore-rename.c | 42 +++++++++++++++---------------------------
levenshtein.c | 39 +++++++++++++++++++++++++++++++++++++++
levenshtein.h | 6 ++++++
4 files changed, 62 insertions(+), 29 deletions(-)
create mode 100644 levenshtein.c
create mode 100644 levenshtein.h
diff --git a/Makefile b/Makefile
index 74b69fb..e015833 100644
--- a/Makefile
+++ b/Makefile
@@ -303,12 +303,12 @@ LIB_H = \
run-command.h strbuf.h tag.h tree.h git-compat-util.h revision.h \
tree-walk.h log-tree.h dir.h path-list.h unpack-trees.h builtin.h \
utf8.h reflog-walk.h patch-ids.h attr.h decorate.h progress.h \
- mailmap.h remote.h
+ mailmap.h remote.h levenshtein.h
DIFF_OBJS = \
diff.o diff-lib.o diffcore-break.o diffcore-order.o \
diffcore-pickaxe.o diffcore-rename.o tree-diff.o combine-diff.o \
- diffcore-delta.o log-tree.o
+ diffcore-delta.o log-tree.o levenshtein.o
LIB_OBJS = \
blob.o commit.o connect.o csum-file.o cache-tree.o base85.o \
diff --git a/diffcore-rename.c b/diffcore-rename.c
index 79c984c..41448c9 100644
--- a/diffcore-rename.c
+++ b/diffcore-rename.c
@@ -4,6 +4,7 @@
#include "cache.h"
#include "diff.h"
#include "diffcore.h"
+#include "levenshtein.h"
/* Table of rename/copy destinations */
@@ -119,21 +120,6 @@ static int is_exact_match(struct diff_filespec *src,
return 0;
}
-static int basename_same(struct diff_filespec *src, struct diff_filespec *dst)
-{
- int src_len = strlen(src->path), dst_len = strlen(dst->path);
- while (src_len && dst_len) {
- char c1 = src->path[--src_len];
- char c2 = dst->path[--dst_len];
- if (c1 != c2)
- return 0;
- if (c1 == '/')
- return 1;
- }
- return (!src_len || src->path[src_len - 1] == '/') &&
- (!dst_len || dst->path[dst_len - 1] == '/');
-}
-
struct diff_score {
int src; /* index in rename_src */
int dst; /* index in rename_dst */
@@ -201,11 +187,9 @@ static int estimate_similarity(struct diff_filespec *src,
*/
if (!dst->size)
score = 0; /* should not happen */
- else {
- score = (int)(src_copied * MAX_SCORE / max_size);
- if (basename_same(src, dst))
- score++;
- }
+ else
+ score = (int)(src_copied * MAX_SCORE / max_size)
+ - levenshtein(src->path, dst->path);
return score;
}
@@ -313,20 +297,24 @@ void diffcore_rename(struct diff_options *options)
if (rename_dst[i].pair)
continue; /* dealt with an earlier round */
for (j = 0; j < rename_src_nr; j++) {
- int k;
+ int k, distance;
struct diff_filespec *one = rename_src[j].one;
if (!is_exact_match(one, two, contents_too))
continue;
+ distance = levenshtein(one->path, two->path);
/* see if there is a basename match, too */
for (k = j; k < rename_src_nr; k++) {
+ int d2;
one = rename_src[k].one;
- if (basename_same(one, two) &&
- is_exact_match(one, two,
- contents_too)) {
- j = k;
- break;
- }
+ if (!is_exact_match(one, two,
+ contents_too))
+ continue;
+ d2 = levenshtein(one->path, two->path);
+ if (d2 > distance)
+ continue;
+ distance = d2;
+ j = k;
}
record_rename_pair(i, j, (int)MAX_SCORE);
diff --git a/levenshtein.c b/levenshtein.c
new file mode 100644
index 0000000..80ef860
--- /dev/null
+++ b/levenshtein.c
@@ -0,0 +1,39 @@
+#include "cache.h"
+#include "levenshtein.h"
+
+int levenshtein(const char *string1, const char *string2)
+{
+ int len1 = strlen(string1), len2 = strlen(string2);
+ int *row1 = xmalloc(sizeof(int) * (len2 + 1));
+ int *row2 = xmalloc(sizeof(int) * (len2 + 1));
+ int i, j;
+
+ for (j = 1; j <= len2; j++)
+ row1[j] = j;
+ for (i = 0; i < len1; i++) {
+ int *dummy;
+
+ row2[0] = i + 1;
+ for (j = 0; j < len2; j++) {
+ /* substitution */
+ row2[j + 1] = row1[j] + (string1[i] != string2[j]);
+ /* insertion */
+ if (row2[j + 1] > row1[j + 1] + 1)
+ row2[j + 1] = row1[j + 1] + 1;
+ /* deletion */
+ if (row2[j + 1] > row2[j] + 1)
+ row2[j + 1] = row2[j] + 1;
+ }
+
+ dummy = row1;
+ row1 = row2;
+ row2 = dummy;
+ }
+
+ i = row1[len2];
+ free(row1);
+ free(row2);
+
+ return i;
+}
+
diff --git a/levenshtein.h b/levenshtein.h
new file mode 100644
index 0000000..74a6626
--- /dev/null
+++ b/levenshtein.h
@@ -0,0 +1,6 @@
+#ifndef LEVENSHTEIN_H
+#define LEVENSHTEIN_H
+
+int levenshtein(const char *string1, const char *string2);
+
+#endif
--
1.5.2.2.2822.g027a6-dirty
^ permalink raw reply related
* Re: [PATCH] git-svn: favor ~/.subversion/ ssl client cert settings
From: Junio C Hamano @ 2007-06-22 0:25 UTC (permalink / raw)
To: Michael Krelin; +Cc: git
In-Reply-To: <11824677432401-git-send-email-hacker@klever.net>
Sorry, but I am not familiar with SVN API.
In plain English, what does this change mean and what does it
buy us? An expected answer is something like:
Without this change, there is no way to authenticate
with client SSL certificates, as certificates registered
in ~/.subvsersion are ignored.
BTW, if that is what you meant, it contradicts the word "favor"
in the proposed commit title. "Favor" would mean "We do support
it already but in lower precedence than something else, which is
inconvenient, so let's move it up so that it is used if found
without bothering other possibilities".
If that is what you really meant, then the answer would be in
the form of:
Curently, even when the client wants to use SSL
certificate to authenticate with the server, X
authenticator is tried first which causes Y that is
irritating. This patch makes the client certificate
authenticator be tried first.
But if that is what is going on, we need to judge if the
"irritation" factor is universally true, or just affects people
who want to use client SSL cert; if the change makes it more
convenient for client cert people by making it less convenient
for others, the relative merit needs to be debated to justify
the change.
I am guessing that you meant the former (we currently totally
ignore it, and the patch adds the missing support), but what
would I know...
And if that is the case, then I think the word you wanted to use
is not "favor" but "honor".
In any case, the patch needs a handful lines of proposed commit
log message to explain and justify the change, like the above
two examples I showed here.
^ permalink raw reply
* Re: [PATCH/RFC] config: Add --null/-z option for null-delimted output
From: Jakub Narebski @ 2007-06-21 23:56 UTC (permalink / raw)
To: Frank Lichtenheld; +Cc: Git Mailing List, Junio C Hamano
In-Reply-To: <11821227322913-git-send-email-frank@lichtenheld.de>
On Mon, 18 Jun 2007, Frank Lichtenheld wrote:
> Use \n as delimiter between key and value and \0 as
> delimiter after each key/value pair. This should be
> easily parsable output.
>
> Signed-off-by: Frank Lichtenheld <frank@lichtenheld.de>
> ---
> builtin-config.c | 15 +++++++++++----
> 1 files changed, 11 insertions(+), 4 deletions(-)
No documentation. But this is an RFC.
> Note the FIXME. Does anyone remember the reason why --get-regexp
> and --list use different output format?
I don't know, but at least two scripts use --get-regexp, namely
git-remote and git-submodule. So we would have to be careful about
changing that.
I would be enough to add the following to your patch:
> @@ -12,14 +12,16 @@ static int use_key_regexp;
> static int do_all;
> static int do_not_match;
> static int seen;
> +static char delim = '=';
> +static char term = '\n';
+static char key_delim = ' ';
> static enum { T_RAW, T_INT, T_BOOL } type = T_RAW;
[...]
> @@ -39,6 +41,7 @@ static int show_config(const char* key_, const char* value_)
> return 0;
>
> if (show_keys)
> + /* FIXME: not useful with --null */
- printf("%s ", key_);
+ printf("%s%c", key_, key_delim);
> if (seen && !do_all)
> dup_error = 1;
[...]
> @@ -155,6 +158,10 @@ int cmd_config(int argc, const char **argv, const char *prefix)
> }
> else if (!strcmp(argv[1], "--system"))
> setenv("GIT_CONFIG", ETC_GITCONFIG, 1);
> + else if (!strcmp(argv[1], "--null") || !strcmp(argv[1], "-z")) {
> + term = '\0';
> + delim = '\n';
+ key_delim = '\n';
> + }
> else if (!strcmp(argv[1], "--rename-section")) {
> int ret;
> if (argc != 4)
By the way, I have tried to use git-config --null to redo config
file parsing in gitweb, so one git-config call would be needed for
all the config. I have noticed that --bool option description does
not describe the observed behavior fully. For example it returns
'true' not only for '1', but for any integer != 0, including 0xdeadbeef.
By the way, the error message when key value _cannot_ be converted to
the boolean is somewhat misleading:
$ GIT_CONFIG=conftest git config --bool bool.key7
fatal: bad config value for 'bool.key7' in conftest
--
Jakub Narebski
Poland
^ permalink raw reply
* [PATCH] git-svn: favor ~/.subversion/ ssl client cert settings
From: Michael Krelin @ 2007-06-21 23:15 UTC (permalink / raw)
To: git; +Cc: Michael Krelin
---
git-svn.perl | 1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/git-svn.perl b/git-svn.perl
index 50128d7..9dfea97 100755
--- a/git-svn.perl
+++ b/git-svn.perl
@@ -2925,6 +2925,7 @@ sub new {
SVN::Client::get_ssl_server_trust_file_provider(),
SVN::Client::get_simple_prompt_provider(
\&Git::SVN::Prompt::simple, 2),
+ SVN::Client::get_ssl_client_cert_file_provider(),
SVN::Client::get_ssl_client_cert_prompt_provider(
\&Git::SVN::Prompt::ssl_client_cert, 2),
SVN::Client::get_ssl_client_cert_pw_prompt_provider(
--
1.5.2.2
^ permalink raw reply related
* Re: [StGIT RFC] Changing patch@branch syntax
From: Yann Dirson @ 2007-06-21 23:02 UTC (permalink / raw)
To: Catalin Marinas; +Cc: GIT list
In-Reply-To: <20070522210020.GV19253@nan92-1-81-57-214-146.fbx.proxad.net>
Working in the implementation of hydras/pools, as well as discussing
of their future, led me to the following thoughts, quite related to
how we should select a new syntax for patches.
First, as a foreword, a bit if refactoring: I think we should use some
sort of Stackable (maybe pick a better name) class as a parent for
Patch and PatchSet. Instances of a Stackable would be candidates to
be members of a PatchSet. That means we can have stacks within a
stack, as well as stacks members of a pool. But we also need a syntax
to name stacks-(in-a-stack)*, and patches within them.
Second, but not least, we currently have an ambiguity in syntax: "foo"
can mean "patch foo in current branch" or "branch foo", depending on
the context, and that is *really* bad. What's more, my former
proposal (quoted below) does not improve this issue. And my previous
proposal, which suggested using a prefix like "/stack/patch" for a
fully qualified patch and "patch" for a relative one does not solve
that problem either, and brings the additional annoyance of
introducing a syntax that is incompatible with git-core.
So here is a new proposal, which I believe would address all current
issues, at the expense of changing stgit syntax. The idea is to use a
single separator for all levels of Stackable objects, with an optional
"patch id" (eg. //top) at the end when meaningful. Only names would
be possible to omit, separators would be mandatory to specify the
nesting level. That gives a syntax of:
[patchset]([:stackable]+(//id)?)*
Examples:
<stack> the named branch (git-compatible)
<stack>:<patch> named patch in named stack
:<patch> named patch in current patchset (currently just "<patch>")
<stack>: current (top) patch in named patchset
<pool>:<stack>:<patch> fully-qualified patch in a named hydra
:: top patch of the current stack of an hydra
:<stack>://bottom.old previous bottom of the top patch in the named stack of current pool
How does that feel ?
On Tue, May 22, 2007 at 11:00:20PM +0200, Yann Dirson wrote:
> Following the "stg pick" example above, would we also want to allow
> picking from a remote repo ? Then the URL fragment notation could be
> suited, and we could have something like:
>
> http://full/path/to/repo#my/branch:my/patch//top
>
> That is, a formal syntax of:
>
> [[[repo#]branch:]patch][//modifier]
>
> Going further, since specifying a repo without a branch probably has
> no meaning (unless we want to default to the HEAD branch), we could
> simplify to the following:
>
> [[[repo#]branch#]patch][//modifier]
>
> I don't think we really want to allow "repo#patch", meaning that patch
> on the current branch, as this gets easily confused by branch switching.
^ permalink raw reply
* Re: [PATCH] Let git-svnimport clean up SVK commit messages.
From: Dave O'Neill @ 2007-06-21 21:58 UTC (permalink / raw)
To: git
In-Reply-To: <1182438000.4031.11.camel@lt21223.campus.dmacc.edu>
On Thu, Jun 21, 2007 at 10:00:00AM -0500, Jeffrey C. Ollie wrote:
> This quickie Python script should convert the "tag branches" to regular
> Git tags:
>
> import os
> refs = os.popen('git-for-each-ref --format="%(objectname)%00%(refname)%00" refs/remotes/tags')
> for line in refs:
> [sha, ref] = line.split('\0')[:2]
> os.system('git tag %s %s' % (ref[18:], sha))
Thanks! I'll give that a try. It would be nice if this sort of cleanup
were part of git-svn in some way, though. I doubt I'll be the last
person wanting an easy conversion from SVN.
Cheers,
Dave
^ permalink raw reply
* [PATCH] Generate tags with correct timestamp (git-svnimport)
From: Dave O'Neill @ 2007-06-21 21:48 UTC (permalink / raw)
To: git; +Cc: Dave O'Neill
In-Reply-To: <7vzm2u3tov.fsf@assigned-by-dhcp.pobox.com>
Now uses git-tag instead of manually constructing the tag. This gives us a
correct timestamp, removes some crufty code, and makes it work the same as
git-cvsimport.
The generated tags are now lightweight tags instead of tag objects, which may
or may not be the behaviour we want.
Also, remove two unused variables from git-cvsimport.
---
git-cvsimport.perl | 1 -
git-svnimport.perl | 24 ++----------------------
2 files changed, 2 insertions(+), 23 deletions(-)
diff --git a/git-cvsimport.perl b/git-cvsimport.perl
index 433b7fd..69ccb88 100755
--- a/git-cvsimport.perl
+++ b/git-cvsimport.perl
@@ -774,7 +774,6 @@ sub commit {
or die "Cannot write branch $branch for update: $!\n";
if ($tag) {
- my ($in, $out) = ('','');
my ($xtag) = $tag;
$xtag =~ s/\s+\*\*.*$//; # Remove stuff like ** INVALID ** and ** FUNKY **
$xtag =~ tr/_/\./ if ( $opt_u );
diff --git a/git-svnimport.perl b/git-svnimport.perl
index f459762..32832ad 100755
--- a/git-svnimport.perl
+++ b/git-svnimport.perl
@@ -868,33 +868,13 @@ sub commit {
}
if($tag) {
- my($in, $out) = ('','');
$last_rev = "-" if %$changed_paths;
# the tag was 'complex', i.e. did not refer to a "real" revision
$dest =~ tr/_/\./ if $opt_u;
- $branch = $dest;
-
- my $pid = open2($in, $out, 'git-mktag');
- print $out ("object $cid\n".
- "type commit\n".
- "tag $dest\n".
- "tagger $committer_name <$committer_email> 0 +0000\n") and
- close($out)
- or die "Cannot create tag object $dest: $!\n";
-
- my $tagobj = <$in>;
- chomp $tagobj;
-
- if ( !close($in) or waitpid($pid, 0) != $pid or
- $? != 0 or $tagobj !~ /^[0123456789abcdef]{40}$/ ) {
- die "Cannot create tag object $dest: $!\n";
- }
- open(C,">$git_dir/refs/tags/$dest") and
- print C ("$tagobj\n") and
- close(C)
- or die "Cannot create tag $branch: $!\n";
+ system('git-tag', $dest, $cid) == 0
+ or die "Cannot create tag $dest: $!\n";
print "Created tag '$dest' on '$branch'\n" if $opt_v;
}
--
1.5.2.2.239.g89630
^ permalink raw reply related
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