* Re: [PATCH] Windows: set gitexecdir = $(bindir)
From: Johannes Sixt @ 2008-07-19 19:31 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Steffen Prohaska, Johannes Schindelin
In-Reply-To: <7vmykd238a.fsf@gitster.siamese.dyndns.org>
On Samstag, 19. Juli 2008, Junio C Hamano wrote:
> Johannes Sixt <johannes.sixt@telecom.at> writes:
> > Take as an example 'git pull'.
> >
> > - The first call to git will derive the exec-path
> > $prefix/bin/../libexec/git-core and prepend it to $PATH.
> >
> > - Calls to builtin git commands from inside 'git pull' will then derive
> > the exec-path $prefix/bin/../libexec/git-core/../libexec/git-core, that
> > is $prefix/libexec/libexec/git-core, and prepend it to $PATH as well.
> > That directory does not exist - usually - and it does not hurt. But it
> > feels dirty and potentially dangerous.
>
> You run "git" with an argument "pull". It needs to figure out where
> "git-pull" is, it checks where it came from and adds ../libexec/git-core/.
> Then it runs "git-pull" script.
>
> Then the script may have a call to "git ls-files -u" or "git-merge".
>
> - The former case, "git" again needs to find out where "git-ls-files"
> is.
>
> If "git" is found as bin/git and not as libexec/git-core/git, this
> should be perfectly fine, isn't it? Perhaps we install a duplicate
> copy there by mistake, which is what we need to fix?
Yes, there's libexec/git-core/git. There reason might be that the install
target is simpler to write (to create the hardlinks) just in case $(bindir)
and $(gitexecdir) are not on the same mount.
> - The latter case (our scripts source git-sh-setup so they have libexec
> one in the PATH when they are started) would find "git-merge" directly
> and runs it.
>
> In either case, the programs "git-ls-files" and "git-merge" do not need to
> do the same discovery -- are we giving them enough clues when we run them
> to let them avoid that?
Probably the only clue is the name itself, like Steffen proposed.
I'll see how I can improve my earlier exec-path patch series.
-- Hannes
^ permalink raw reply
* Re: [PATCH 2/3] add new Git::Repo API
From: Jakub Narebski @ 2008-07-19 19:07 UTC (permalink / raw)
To: Petr Baudis; +Cc: Lea Wiemann, git, John Hawley
In-Reply-To: <20080718165407.GU10151@machine.or.cz>
On Fri, 18 July 2008, Petr Baudis wrote:
> On Tue, Jul 15, 2008 at 01:41:38AM +0200, Jakub Narebski wrote:
> > On Mon, 14 July 2008, Petr Baudis wrote:
> > > Here is an idea: Introduce Git::Command object that will have very
> > > general interface and look like
> > >
> > > my $c = Git::Command->new(['git', '--git-dir=.', 'cat-file', \
> > > '-p', 'bla'], {pipe_out=>1})
> > > ...
> > > $c->close();
> >
> > Errr... how do you read from such a pipe? <$c> I think wouldn't work,
> > unless you would use some trickery...
>
> That's good point; it might either be done using some trickery, or
> $c->pipe. The idea behind having a special object for it though is to
> have *unified* (no matter how simple) error handling. You might not
> detect the command erroring out at the open time.
>
> Is there a better approach for solving this?
I don't know if it is _better_ approach, but the _alternate_ approach
would be to use:
my $c = Git::Command->new(['git', '--git-dir=.', 'cat-file', \
'-p', 'bla'], {out=>my $fh, err=>undef})
...
while (my $line = <$fh>) {
...
$c->close();
And trickery would be to use blessed filehandle, or what? Or perhaps
extending IO::Handle (but not all like using object methods for I/O
handles)?
> > > and a Git::CommandFactory with a nicer interface that would look like
> > >
> > > my $cf = Git::CommandFactory->new('git', '--git-dir=.');
> > > my $c = $cf->output_pipe('cat-file', '-p', 'bla');
> > > $c->close();
> > >
> > > Then, Git::Repo would have a single Git::CommandFactory instance
> > > pre-initialized with the required calling convention, and returned by
> > > e.g. cmd() method. Then, from the user POV, you would just:
> > >
> > > my $repo = Git::Repo->new;
> > > $repo->cmd->output_pipe('cat-file', '-p', 'bla');
> > >
> > > Or am I overdoing it?
> >
> > You are probably overdoing it.
> >
> > I think it would be good to have the following interface
> >
> > Git->output_pipe('ls-remotes', $URL, '--heads');
>
> This is problematic; I think mixing the new and old interface within a
> single class is very bad idea, we should have Git::Standalone or
> something for this. Or, just, default Git::CommandFactory. ;-)
I forgot that we cannot obsolete / replace old interface. Nevertheless
it would be nice to be able to use for example
Git::Cmd->output_pipe('ls-remotes', $URL, '--heads');
but also
output_pipe('myscript.sh', <arg1>, <arg2>);
See also below for alternative interfaces to Git::Cmd->output_pipe();
> > [...]
> > $r = Git::Repo->new(<git_dir>);
> > $r->output_pipe('ls_tree', 'HEAD');
> > [...]
> > $nb = Git::Repo::NonBare->new(<git_dir>[, <working_area>]);
> > $nb->output_pipe('ls-files');
> >
> >
> > How can it be done with minimal effort, unfortunately I don't know...
>
> Well, this interface is almost identical to what I delineated, except
> that I have the extra ->cmd-> step there. But maybe, we could go with
> your API and instead have Git::CommandFactory as a base of Git::Repo?
> The hierarchy would be
>
> Git::CommandFactory - provides the cmd_pipe toolkit
> |
> Git::Repo - provides repository model
> |
> Git::Repo::NonBare - additional working-copy-related methods
>
> I think I will post a sample implementation sometime over the weekend.
Thanks.
I think this is a very good idea. Although... you mix somewhat here
relationships. Relationship between Git::CommandFactory (Git::Cmd?)
is a bit different than relationship between Git::Repo and
Git::Repo::NonBare. Git::Repo::NonBare is a case of Git::Repo which
additionally knows where its working copy (Git::WC?) is, and where
inside working copy we are (if we are inside working copy). Git::Repo
uses Git::CommandFactory to route calls to git commands, and to
provide default '--git-dir=<repo_path>' argument.
What I'd like to have is a way to easily set in _one_ place where git
binary can be found, even if we are using different repositories, call
git commands not related to git repository.
Should we use
Git::Cmd->output_pipe('ls-remotes', $URL, '--heads');
or
output_pipe(GIT, 'ls-remotes', $URL, '--heads');
or
output_pipe($GIT, 'ls-remotes', $URL, '--heads');
or
output_pipe($Git::GIT, 'ls-remotes', $URL, '--heads');
we would want to be able to set where git binary is once (and for all),
for example via
Git::Cmd->set_git('/usr/local/bin/git');
or something like that.
--
Jakub Narebski
Poland
^ permalink raw reply
* Re: [PATCH] Ensure that SSH runs in non-interactive mode
From: Fredrik Tolf @ 2008-07-19 18:18 UTC (permalink / raw)
To: Keith Packard; +Cc: git
In-Reply-To: <1216490252.10694.58.camel@koto.keithp.com>
On Sat, 2008-07-19 at 10:57 -0700, Keith Packard wrote:
> On Sat, 2008-07-19 at 19:06 +0200, Fredrik Tolf wrote:
> > By removing the DISPLAY env variable before forking, SSH
> > can thus be forced into non-interactive mode, without any obvious
> > ill effects.
>
> This will keep ssh-askpass from using any X-based password input
> program.
Ah, right. Would it be OK to add the `-x' flag to ssh instead? I imagine
that that might make git less portable to SSH implementations other than
OpenSSH, but I don't know if that is considered a problem.
Fredrik Tolf
^ permalink raw reply
* Re: [PATCH] Rename ".dotest/" to ".git/rebase" and ".dotest-merge" to "rebase-merge"
From: Olivier Marin @ 2008-07-19 18:40 UTC (permalink / raw)
To: Junio C Hamano
Cc: Theodore Tso, Nanako Shiraishi, Johannes Schindelin,
René Scharfe, Stephan Beyer, Joe Fiorini, git, Jari Aalto
In-Reply-To: <7viqv5r637.fsf@gitster.siamese.dyndns.org>
Junio C Hamano a écrit :
> Theodore Tso <tytso@mit.edu> writes:
>
>> While you have "git am" open, how about adding an "git am --abort"
>> which nukes the .dotest aka .git/rebase directory, and resets HEAD
>> back to the original position?
>
> This does not seem to have reached the list nor its archives. I cannot
> say I have really looked at it deeply but it may be a good starting
> point. It needs docs ;-)
This can be squashed to Nanako's path: it adds missing docs,
'git rerere clear' and move $dotest deletion at the end in case
'git read-tree' failed (because of a dirty index).
Olivier.
-- >8 --
Subject: [PATCH] git am --abort
To squash.
Signed-off-by: Olivier Marin <dkr@freesurf.fr>
---
Documentation/git-am.txt | 5 ++++-
git-am.sh | 8 +++++---
2 files changed, 9 insertions(+), 4 deletions(-)
diff --git a/Documentation/git-am.txt b/Documentation/git-am.txt
index 2d7f162..e010a16 100644
--- a/Documentation/git-am.txt
+++ b/Documentation/git-am.txt
@@ -13,7 +13,7 @@ SYNOPSIS
[--3way] [--interactive] [--binary]
[--whitespace=<option>] [-C<n>] [-p<n>]
[<mbox> | <Maildir>...]
-'git am' (--skip | --resolved)
+'git am' (--skip | --resolved | --abort)
DESCRIPTION
-----------
@@ -99,6 +99,9 @@ default. You could use `--no-utf8` to override this.
or `--skip` to handle the failure. This is solely
for internal use between 'git-rebase' and 'git-am'.
+--abort::
+ Restore the original branch and abort the patching operation.
+
DISCUSSION
----------
diff --git a/git-am.sh b/git-am.sh
index 5e645e4..04b2e96 100755
--- a/git-am.sh
+++ b/git-am.sh
@@ -22,7 +22,7 @@ p= pass it through git-apply
resolvemsg= override error message when patch failure occurs
r,resolved to be used after a patch failure
skip skip the current patch
-abort abandon patch application and clear .dotest directory
+abort restore the original branch and abort the patching operation.
rebasing (internal use for git-rebase)"
. git-sh-setup
@@ -55,6 +55,7 @@ stop_here_user_resolve () {
fi
echo "When you have resolved this problem run \"$cmdline --resolved\"."
echo "If you would prefer to skip this patch, instead run \"$cmdline --skip\"."
+ echo "To restore the original branch and stop patching run \"$cmdline --abort\"."
stop_here $1
}
@@ -203,9 +204,10 @@ then
case "$abort" in
t)
- rm -fr "$dotest" &&
+ git rerere clear &&
git read-tree -m -u ORIG_HEAD &&
- git reset ORIG_HEAD && :
+ git reset ORIG_HEAD &&
+ rm -fr "$dotest"
exit ;;
esac
else
--
1.5.6.3.441.g3087
^ permalink raw reply related
* Re: "error: non-monotonic index" during fresh linux-2.6.git cloning.
From: Petr Baudis @ 2008-07-19 18:20 UTC (permalink / raw)
To: Evgeniy Polyakov; +Cc: git
In-Reply-To: <20080719174742.GA4253@2ka.mipt.ru>
On Sat, Jul 19, 2008 at 09:47:43PM +0400, Evgeniy Polyakov wrote:
> $ git --version
> git version 1.4.4.4
>
> Fresh 32bit Debian testing.
Are you sure? http://packages.debian.org/testing/git-core says
Package: git-core (1:1.5.6.2-1)
Your sounds more like the Debian stable version.
Petr "Pasky" Baudis
^ permalink raw reply
* [PATCH] Documentation/git-merge.txt: Partial rewrite of How Merge Works
From: Petr Baudis @ 2008-07-19 18:17 UTC (permalink / raw)
To: gitster; +Cc: git
In-Reply-To: <7vprpa67e4.fsf@gitster.siamese.dyndns.org>
The git-merge documentation's "HOW MERGE WORKS" section is confusingly
composed and actually omits the most interesting part, the merging of
the arguments into HEAD itself, surprisingly not actually mentioning
the fast-forward merge anywhere.
This patch replaces the "[NOTE]" screenful of highly technical details
by a single sentence summing up the interesting information, and instead
explains how are the arguments compared with HEAD and the three possible
inclusion states that are named "Already up-to-date", "Fast-forward"
and "True merge". It also makes it clear that the rest of the section
talks only about the true merge situation, and slightly expands the
talk on solving conflicts.
Junio initiated the removal of the Note screenful altogether and
offered many stylistical fixes.
Signed-off-by: Petr Baudis <pasky@suse.cz>
---
> But what I was wondering was if we have given the users enough clues to
> tell if the above is the right action. If merge started and conflicted,
> then forgetting about it and keep going is _not_ the right thing, and the
> user needs to be able to tell these two very distinct cases apart.
I think that this is already obvious from both the documentation and
git-merge output; I'm not sure what to improve further on this.
I did make some minor tweaks in the conflict resolution part, though.
I hope this would be the final patch revision. :-)
Documentation/git-merge.txt | 76 ++++++++++++++++---------------------------
1 files changed, 29 insertions(+), 47 deletions(-)
diff --git a/Documentation/git-merge.txt b/Documentation/git-merge.txt
index 019e4ca..a7487d3 100644
--- a/Documentation/git-merge.txt
+++ b/Documentation/git-merge.txt
@@ -57,50 +57,31 @@ HOW MERGE WORKS
A merge is always between the current `HEAD` and one or more
commits (usually, branch head or tag), and the index file must
-exactly match the
-tree of `HEAD` commit (i.e. the contents of the last commit) when
-it happens. In other words, `git diff --cached HEAD` must
-report no changes.
-
-[NOTE]
-This is a bit of a lie. In certain special cases, your index is
-allowed to be different from the tree of the `HEAD` commit. The most
-notable case is when your `HEAD` commit is already ahead of what
-is being merged, in which case your index can have arbitrary
-differences from your `HEAD` commit. Also, your index entries
-may have differences from your `HEAD` commit that match
-the result of a trivial merge (e.g. you received the same patch
-from an external source to produce the same result as what you are
-merging). For example, if a path did not exist in the common
-ancestor and your head commit but exists in the tree you are
-merging into your repository, and if you already happen to have
-that path exactly in your index, the merge does not have to
-fail.
-
-Otherwise, merge will refuse to do any harm to your repository
-(that is, it may fetch the objects from remote, and it may even
-update the local branch used to keep track of the remote branch
-with `git pull remote rbranch:lbranch`, but your working tree,
-`.git/HEAD` pointer and index file are left intact). In addition,
-merge always sets `.git/ORIG_HEAD` to the original state of HEAD so
-a problematic merge can be removed by using `git reset ORIG_HEAD`.
-
-You may have local modifications in the working tree files. In
-other words, 'git-diff' is allowed to report changes.
-However, the merge uses your working tree as the working area,
-and in order to prevent the merge operation from losing such
-changes, it makes sure that they do not interfere with the
-merge. Those complex tables in read-tree documentation define
-what it means for a path to "interfere with the merge". And if
-your local modifications interfere with the merge, again, it
-stops before touching anything.
-
-So in the above two "failed merge" case, you do not have to
-worry about loss of data --- you simply were not ready to do
-a merge, so no merge happened at all. You may want to finish
-whatever you were in the middle of doing, and retry the same
-pull after you are done and ready.
-
+match the tree of `HEAD` commit (i.e. the contents of the last commit)
+when it starts out. In other words, `git diff --cached HEAD` must
+report no changes. (One exception is when the changed index
+entries are already in the same state that would result from
+the merge anyway.)
+
+Three kinds of merge can happen:
+
+* The merged commit is already contained in `HEAD`. This is the
+ simplest case, called "Already up-to-date."
+
+* `HEAD` is already contained in the merged commit. This is the
+ most common case especially when involved through 'git pull':
+ you are tracking an upstream repository, committed no local
+ changes and now you want to update to a newer upstream revision.
+ Your `HEAD` (and the index) is updated to at point the merged
+ commit, without creating an extra merge commit. This is
+ called "Fast-forward".
+
+* Both the merged commit and `HEAD` are independent and must be
+ tied together by a merge commit that has them both as its parents.
+ The rest of this section describes this "True merge" case.
+
+The chosen merge strategy merges the two commits into a single
+new source tree.
When things cleanly merge, these things happen:
1. The results are updated both in the index file and in your
@@ -142,12 +123,13 @@ After seeing a conflict, you can do two things:
* Decide not to merge. The only clean-up you need are to reset
the index file to the `HEAD` commit to reverse 2. and to clean
- up working tree changes made by 2. and 3.; 'git-reset' can
+ up working tree changes made by 2. and 3.; 'git-reset --hard' can
be used for this.
* Resolve the conflicts. `git diff` would report only the
- conflicting paths because of the above 2. and 3. Edit the
- working tree files into a desirable shape, 'git-add' or 'git-rm'
+ conflicting paths because of the above 2. and 3.
+ Edit the working tree files into a desirable shape
+ ('git mergetool' can ease this task), 'git-add' or 'git-rm'
them, to make the index file contain what the merge result
should be, and run 'git-commit' to commit the result.
^ permalink raw reply related
* Re: "error: non-monotonic index" during fresh linux-2.6.git cloning.
From: Junio C Hamano @ 2008-07-19 18:15 UTC (permalink / raw)
To: Evgeniy Polyakov; +Cc: git
In-Reply-To: <7vfxq521ab.fsf@gitster.siamese.dyndns.org>
Junio C Hamano <gitster@pobox.com> writes:
> Evgeniy Polyakov <johnpol@2ka.mipt.ru> writes:
>
>> $ git clone http://kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git
>> Getting alternates list for http://kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git/
>> Getting pack list for http://kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git/
>> Getting index for pack 81cec7c6b26c755e466a79de8dbe1c7b827a48d6
>> error: non-monotonic index
>> /usr/bin/git-clone: line 33: 2025 Segmentation fault git-http-fetch -v -a -w "$tname" "$name" "$1/"
>>
>> $ git --version
>> git version 1.4.4.4
>>
>> Fresh 32bit Debian testing.
>
> The repository you are cloning uses pack idx version #2; 1.4.4.4 predates it
> by a wide margin.
By the way, Debian folks are very aware of the issue and already has a
backported material to cut a 1.4.4.5, but I do not know what the release
schedule for their update is.
Is it an option for you to update to a more modern version from say
backports.org? Everybody using git for anything serious should be using
1.5.3 or newer these days.
^ permalink raw reply
* Re: "error: non-monotonic index" during fresh linux-2.6.git cloning.
From: Junio C Hamano @ 2008-07-19 18:10 UTC (permalink / raw)
To: Evgeniy Polyakov; +Cc: git
In-Reply-To: <20080719174742.GA4253@2ka.mipt.ru>
Evgeniy Polyakov <johnpol@2ka.mipt.ru> writes:
> $ git clone http://kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git
> Getting alternates list for http://kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git/
> Getting pack list for http://kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git/
> Getting index for pack 81cec7c6b26c755e466a79de8dbe1c7b827a48d6
> error: non-monotonic index
> /usr/bin/git-clone: line 33: 2025 Segmentation fault git-http-fetch -v -a -w "$tname" "$name" "$1/"
>
> $ git --version
> git version 1.4.4.4
The repository you are cloning uses pack idx version #2; 1.4.4.4 predates it
by a wide margin.
^ permalink raw reply
* Re: [PATCH] Ensure that SSH runs in non-interactive mode
From: Keith Packard @ 2008-07-19 17:57 UTC (permalink / raw)
To: Fredrik Tolf; +Cc: keithp, git
In-Reply-To: <1216487215-6927-1-git-send-email-fredrik@dolda2000.com>
[-- Attachment #1: Type: text/plain, Size: 312 bytes --]
On Sat, 2008-07-19 at 19:06 +0200, Fredrik Tolf wrote:
> By removing the DISPLAY env variable before forking, SSH
> can thus be forced into non-interactive mode, without any obvious
> ill effects.
This will keep ssh-askpass from using any X-based password input
program.
--
keith.packard@intel.com
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* "error: non-monotonic index" during fresh linux-2.6.git cloning.
From: Evgeniy Polyakov @ 2008-07-19 17:47 UTC (permalink / raw)
To: git
Hi.
I'm getting above error each time I'm tying to clone current 2.6 tree.
Archives tell that it happens when local index is currupted, but I do
not have local tree, it is a fresh clone in an empty dir.
$ git clone http://kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git
Getting alternates list for http://kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git/
Getting pack list for http://kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git/
Getting index for pack 81cec7c6b26c755e466a79de8dbe1c7b827a48d6
error: non-monotonic index
/usr/bin/git-clone: line 33: 2025 Segmentation fault git-http-fetch -v -a -w "$tname" "$name" "$1/"
$ git --version
git version 1.4.4.4
Fresh 32bit Debian testing.
It worked before (at least several months ago) and works with 1.5.2.5.
--
Evgeniy Polyakov
^ permalink raw reply
* Re: [PATCH] Ensure that SSH runs in non-interactive mode
From: Mike Hommey @ 2008-07-19 17:52 UTC (permalink / raw)
To: Fredrik Tolf; +Cc: git
In-Reply-To: <1216487215-6927-1-git-send-email-fredrik@dolda2000.com>
On Sat, Jul 19, 2008 at 07:06:55PM +0200, Fredrik Tolf wrote:
> OpenSSH has the nice feature that it sets the IP TOS value of its
> connection depending on usage. When used in interactive mode, it
> is set to Minimize-Delay, and other wise to Maximize-Throughput. Its
> usage by Git is best served by Maximize-Throughput, for obvious
> reasons.
>
> However, it seems to use a DWIM heuristic for detecting interactive
> mode. The current implementation enters interactive mode if either
> a PTY is allocated or X11 forwarding is enabled, and even though Git
> SSH:ing does not allocate a PTY, X11 forwarding is often turned on
> by default. By removing the DISPLAY env variable before forking, SSH
> can thus be forced into non-interactive mode, without any obvious
> ill effects.
Wouldn't adding the -x option be better ? Also adding -T could be a good
idea.
Mike
^ permalink raw reply
* Re: [PATCH] builtin-clone: Use is_dir_sep() instead of '/'
From: Daniel Barkalow @ 2008-07-19 17:44 UTC (permalink / raw)
To: Johannes Sixt; +Cc: Junio C Hamano, git
In-Reply-To: <200807191549.56402.johannes.sixt@telecom.at>
On Sat, 19 Jul 2008, Johannes Sixt wrote:
> On Samstag, 19. Juli 2008, Johannes Sixt wrote:
> > On Samstag, 19. Juli 2008, Junio C Hamano wrote:
> > > Ok, but the surrounding code in this function look very suspicious.
> >
> > How about this then?
> >
> > -- snip --
> > builtin-clone: Rewrite guess_dir_name()
> >
> > The function has to do three small and independent tasks, but all of them
> > were crammed into a single loop. This rewrites the function entirely by
> > unrolling these tasks.
>
> Sigh. I knew it, I knew it. If it had been that trivial, then Daniel had done
> it this way in the first place. :-(
>
> This needs to be squashed in. It makes sure that we handle 'foo/.git';
> and .git was not stripped if we cloned from 'foo.git/'.
I actually got that from Johannes Schindelin, who added bundle support to
my clone patch. I remember looking at his change, thinking it looked
overly complicated, but finding that anything I tried to do to simplify it
failed tests. If this gets through the test suite (lots of the tests other
than the clone test try to do a wider variety of odd things than I expect
users do in practice most of the time), then it's probably a better
implementation.
-Daniel
*This .sig left intentionally blank*
^ permalink raw reply
* [PATCH] Ensure that SSH runs in non-interactive mode
From: Fredrik Tolf @ 2008-07-19 17:06 UTC (permalink / raw)
To: git; +Cc: Fredrik Tolf
OpenSSH has the nice feature that it sets the IP TOS value of its
connection depending on usage. When used in interactive mode, it
is set to Minimize-Delay, and other wise to Maximize-Throughput. Its
usage by Git is best served by Maximize-Throughput, for obvious
reasons.
However, it seems to use a DWIM heuristic for detecting interactive
mode. The current implementation enters interactive mode if either
a PTY is allocated or X11 forwarding is enabled, and even though Git
SSH:ing does not allocate a PTY, X11 forwarding is often turned on
by default. By removing the DISPLAY env variable before forking, SSH
can thus be forced into non-interactive mode, without any obvious
ill effects.
Signed-off-by: Fredrik Tolf <fredrik@dolda2000.com>
---
connect.c | 7 +++++++
1 files changed, 7 insertions(+), 0 deletions(-)
diff --git a/connect.c b/connect.c
index 574f42f..54888d3 100644
--- a/connect.c
+++ b/connect.c
@@ -607,6 +607,13 @@ struct child_process *git_connect(int fd[2], const char *url_orig,
*arg++ = port;
}
*arg++ = host;
+ /* Remove the X11 DISPLAY from the environment, to
+ * make SSH run non-interactively */
+ const char *env[] = {
+ "DISPLAY",
+ NULL
+ };
+ conn->env = env;
}
else {
/* remove these from the environment */
--
1.5.6.2
^ permalink raw reply related
* Re: [PATCH] Windows: set gitexecdir = $(bindir)
From: Junio C Hamano @ 2008-07-19 17:28 UTC (permalink / raw)
To: Johannes Sixt; +Cc: Steffen Prohaska, git, Johannes Schindelin
In-Reply-To: <200807191052.20057.johannes.sixt@telecom.at>
Johannes Sixt <johannes.sixt@telecom.at> writes:
> On Samstag, 19. Juli 2008, Junio C Hamano wrote:
>> Sorry, I am not sure if I understand what you are trying to solve. If you
>> have ../libexec/git-core/ in GIT_EXEC_PATH (or have builtin_exec_path()
>> use it), then your installation would look like this:
>>
>> [[some random place]]
>> bin/git
>> libexec/git-core/git-add
>> libexec/git-core/git-del
>> libexec/git-core/git-dir
>> ...
>>
>> and if "git" can figure out it is "[[some random place]]/bin/git",
>> it can find its subcommands from neighbouring directory, that is still
>> inside the random place the user told the installer to use, can't it?
>
> Yes, but...
>
> Take as an example 'git pull'.
>
> - The first call to git will derive the exec-path
> $prefix/bin/../libexec/git-core and prepend it to $PATH.
>
> - Calls to builtin git commands from inside 'git pull' will then derive the
> exec-path $prefix/bin/../libexec/git-core/../libexec/git-core, that is
> $prefix/libexec/libexec/git-core, and prepend it to $PATH as well. That
> directory does not exist - usually - and it does not hurt. But it feels dirty
> and potentially dangerous.
You run "git" with an argument "pull". It needs to figure out where
"git-pull" is, it checks where it came from and adds ../libexec/git-core/.
Then it runs "git-pull" script.
Then the script may have a call to "git ls-files -u" or "git-merge".
- The former case, "git" again needs to find out where "git-ls-files"
is.
If "git" is found as bin/git and not as libexec/git-core/git, this
should be perfectly fine, isn't it? Perhaps we install a duplicate
copy there by mistake, which is what we need to fix?
- The latter case (our scripts source git-sh-setup so they have libexec
one in the PATH when they are started) would find "git-merge" directly
and runs it.
In either case, the programs "git-ls-files" and "git-merge" do not need to
do the same discovery -- are we giving them enough clues when we run them
to let them avoid that?
^ permalink raw reply
* Re: [PATCH] Windows: set gitexecdir = $(bindir)
From: Steffen Prohaska @ 2008-07-19 17:10 UTC (permalink / raw)
To: Johannes Sixt; +Cc: Junio C Hamano, git, Johannes Schindelin
In-Reply-To: <200807191052.20057.johannes.sixt@telecom.at>
On Jul 19, 2008, at 10:52 AM, Johannes Sixt wrote:
> On Samstag, 19. Juli 2008, Junio C Hamano wrote:
>> Sorry, I am not sure if I understand what you are trying to solve.
>> If you
>> have ../libexec/git-core/ in GIT_EXEC_PATH (or have
>> builtin_exec_path()
>> use it), then your installation would look like this:
>>
>> [[some random place]]
>> bin/git
>> libexec/git-core/git-add
>> libexec/git-core/git-del
>> libexec/git-core/git-dir
>> ...
>>
>> and if "git" can figure out it is "[[some random place]]/bin/git",
>> it can find its subcommands from neighbouring directory, that is
>> still
>> inside the random place the user told the installer to use, can't it?
>
> Yes, but...
>
> Take as an example 'git pull'.
>
> - The first call to git will derive the exec-path
> $prefix/bin/../libexec/git-core and prepend it to $PATH.
>
> - Calls to builtin git commands from inside 'git pull' will then
> derive the
> exec-path $prefix/bin/../libexec/git-core/../libexec/git-core, that is
> $prefix/libexec/libexec/git-core, and prepend it to $PATH as well.
> That
> directory does not exist - usually - and it does not hurt. But it
> feels dirty
> and potentially dangerous.
Maybe we can avoid this based on the name of the executable?
We would add libexec only if the executable is named "git",
but not if it is one of the dashed forms "git-*".
Steffen
^ permalink raw reply
* Re: What's cooking in git.git (topics)
From: Junio C Hamano @ 2008-07-19 16:55 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Nanako Shiraishi, git
In-Reply-To: <alpine.DEB.1.00.0807191311220.3305@eeepc-johanness>
Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> Yes, I agree, if all strategies fail, it is dubitable that we find a
> metric that will always find the "best" one. But if one fails and the
> next one does not, it is obvious what is correct.
Not at all. Imagine the case where one of them is either ours or theirs.
^ permalink raw reply
* [PATCH V2] builtin-rm: fix index lock file path
From: Olivier Marin @ 2008-07-19 16:24 UTC (permalink / raw)
To: Olivier Marin; +Cc: Nick Andrew, Junio C Hamano, Git Mailing List
In-Reply-To: <48821485.6050507@free.fr>
From: Olivier Marin <dkr@freesurf.fr>
When hold_locked_index() is called with a relative git_dir and you are
outside the work tree, the lock file become relative to the current
directory. So when later setup_work_tree() change the current directory
it breaks lock file path and commit_locked_index() fails.
This patch move index locking code after setup_work_tree() call to make
lock file relative to the working tree as it should be and add a test
case.
Noticed by Nick Andrew.
Signed-off-by: Olivier Marin <dkr@freesurf.fr>
---
The same with the test case!
builtin-rm.c | 10 +++++-----
t/t3600-rm.sh | 12 ++++++++++++
2 files changed, 17 insertions(+), 5 deletions(-)
diff --git a/builtin-rm.c b/builtin-rm.c
index 56454ec..ee8247b 100644
--- a/builtin-rm.c
+++ b/builtin-rm.c
@@ -146,11 +146,6 @@ int cmd_rm(int argc, const char **argv, const char *prefix)
git_config(git_default_config, NULL);
- newfd = hold_locked_index(&lock_file, 1);
-
- if (read_cache() < 0)
- die("index file corrupt");
-
argc = parse_options(argc, argv, builtin_rm_options, builtin_rm_usage, 0);
if (!argc)
usage_with_options(builtin_rm_usage, builtin_rm_options);
@@ -158,6 +153,11 @@ int cmd_rm(int argc, const char **argv, const char *prefix)
if (!index_only)
setup_work_tree();
+ newfd = hold_locked_index(&lock_file, 1);
+
+ if (read_cache() < 0)
+ die("index file corrupt");
+
pathspec = get_pathspec(prefix, argv);
seen = NULL;
for (i = 0; pathspec[i] ; i++)
diff --git a/t/t3600-rm.sh b/t/t3600-rm.sh
index 316775e..79c06ad 100755
--- a/t/t3600-rm.sh
+++ b/t/t3600-rm.sh
@@ -217,4 +217,16 @@ test_expect_success 'Remove nonexistent file returns nonzero exit status' '
test_must_fail git rm nonexistent
'
+test_expect_success 'Call "rm" from outside the work tree' '
+ mkdir repo &&
+ cd repo &&
+ git init &&
+ echo something > somefile &&
+ git add somefile &&
+ git commit -m "add a file" &&
+ (cd .. &&
+ git --git-dir=repo/.git --work-tree=repo rm somefile) &&
+ test_must_fail git ls-files --error-unmatch somefile
+'
+
test_done
--
1.5.6.3.440.g489d7
^ permalink raw reply related
* [PATCH] builtin-rm: fix index lock file path
From: Olivier Marin @ 2008-07-19 16:21 UTC (permalink / raw)
To: Nick Andrew; +Cc: Junio C Hamano, Git Mailing List
In-Reply-To: <20080719082314.GA15419@mail.local.tull.net>
From: Olivier Marin <dkr@freesurf.fr>
When hold_locked_index() is called with a relative git_dir and you are
outside the work tree, the lock file become relative to the current
directory. So when later setup_work_tree() change the current directory
it breaks lock file path and commit_locked_index() fails.
This patch move index locking code after setup_work_tree() call to make
lock file relative to the working tree as it should be and add a test
case.
Noticed by Nick Andrew.
Signed-off-by: Olivier Marin <dkr@freesurf.fr>
---
builtin-rm.c | 10 +++++-----
1 files changed, 5 insertions(+), 5 deletions(-)
diff --git a/builtin-rm.c b/builtin-rm.c
index 56454ec..ee8247b 100644
--- a/builtin-rm.c
+++ b/builtin-rm.c
@@ -146,11 +146,6 @@ int cmd_rm(int argc, const char **argv, const char *prefix)
git_config(git_default_config, NULL);
- newfd = hold_locked_index(&lock_file, 1);
-
- if (read_cache() < 0)
- die("index file corrupt");
-
argc = parse_options(argc, argv, builtin_rm_options, builtin_rm_usage, 0);
if (!argc)
usage_with_options(builtin_rm_usage, builtin_rm_options);
@@ -158,6 +153,11 @@ int cmd_rm(int argc, const char **argv, const char *prefix)
if (!index_only)
setup_work_tree();
+ newfd = hold_locked_index(&lock_file, 1);
+
+ if (read_cache() < 0)
+ die("index file corrupt");
+
pathspec = get_pathspec(prefix, argv);
seen = NULL;
for (i = 0; pathspec[i] ; i++)
--
1.5.6.3.440.g489d7
^ permalink raw reply related
* Re: gitk: Author/Committer name with special characters
From: Torsten Paul @ 2008-07-19 15:16 UTC (permalink / raw)
To: Paul Mackerras; +Cc: git
In-Reply-To: <18558.35423.933860.915622@cargo.ozlabs.ibm.com>
Paul Mackerras wrote:
> Something like that, I think, but to be sure I'd like to see the
> actual author and committer lines that are causing the problem. Could
> you send me the output of "git cat-file commit" on one of the
> problematic commits?
>
I've created a small script that creates a minimal repo that shows
the problem...
ciao,
Torsten.
#!/bin/bash
#
# Script to generate git commit messages that
# contain windows style user names. This kind of
# names are generated when using git-svn with a
# svn-repo that uses NTLM authentification.
#
EXT="@23e39a30-19ad-a625-8bac-5c9ab2323746"
do_commit () {
F=test.txt
echo "test$1" > "$F"
git add "$F"
M="<$2$EXT>"
GIT_AUTHOR_NAME="$2" \
GIT_AUTHOR_EMAIL="$M" \
GIT_COMMITTER_NAME="$2" \
GIT_COMMITTER_EMAIL="$M" \
git commit -m "commit $1"
}
DIR=`mktemp -d /tmp/gitk-test.XXXXXXXXXX` || exit 1
trap "rm -rf \"$DIR\"" EXIT
cd $DIR || exit 2
git init
do_commit 1 "paul"
do_commit 2 "WIN\paul"
do_commit 3 "WIN\test"
do_commit 4 "WIN\nobody"
do_commit 5 "WIN\paul"
do_commit 6 "paul"
gitk
^ permalink raw reply
* Re: [PATCH] builtin-clone: Use is_dir_sep() instead of '/'
From: Johannes Sixt @ 2008-07-19 13:49 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Daniel Barkalow
In-Reply-To: <200807191132.45648.johannes.sixt@telecom.at>
On Samstag, 19. Juli 2008, Johannes Sixt wrote:
> On Samstag, 19. Juli 2008, Junio C Hamano wrote:
> > Ok, but the surrounding code in this function look very suspicious.
>
> How about this then?
>
> -- snip --
> builtin-clone: Rewrite guess_dir_name()
>
> The function has to do three small and independent tasks, but all of them
> were crammed into a single loop. This rewrites the function entirely by
> unrolling these tasks.
Sigh. I knew it, I knew it. If it had been that trivial, then Daniel had done
it this way in the first place. :-(
This needs to be squashed in. It makes sure that we handle 'foo/.git';
and .git was not stripped if we cloned from 'foo.git/'.
diff --git a/builtin-clone.c b/builtin-clone.c
index 91667d5..88616b3 100644
--- a/builtin-clone.c
+++ b/builtin-clone.c
@@ -98,10 +98,16 @@ static char *guess_dir_name(const char *repo, int is_bundle)
const char *end = repo + strlen(repo), *start, *dot;
/*
- * Strip trailing slashes
+ * Strip trailing slashes and /.git
*/
while (repo < end && is_dir_sep(end[-1]))
end--;
+ if (end - repo > 5 && is_dir_sep(end[-5]) &&
+ !strncmp(end - 4, ".git", 4)) {
+ end -= 5;
+ while (repo < end && is_dir_sep(end[-1]))
+ end--;
+ }
/*
* Find last component, but be prepared that repo could have
@@ -116,10 +122,10 @@ static char *guess_dir_name(const char *repo, int is_bundle)
* Strip .{bundle,git}.
*/
if (is_bundle) {
- if (end - start > 7 && !strcmp(end - 7, ".bundle"))
+ if (end - start > 7 && !strncmp(end - 7, ".bundle", 7))
end -= 7;
} else {
- if (end - start > 4 && !strcmp(end - 4, ".git"))
+ if (end - start > 4 && !strncmp(end - 4, ".git", 4))
end -= 4;
}
^ permalink raw reply related
* [RFC PATCH v2] Support gitlinks in fast-import.
From: Alexander Gavrilov @ 2008-07-19 12:21 UTC (permalink / raw)
To: git; +Cc: Shawn O. Pearce, Johannes Schindelin
Currently fast-import/export cannot be used for
repositories with submodules. This patch extends
the relevant programs to make them correctly
process gitlinks.
Links can be represented by two forms of the
Modify command:
M 160000 SHA1 some/path
which sets the link target explicitly, or
M 160000 :mark some/path
where the mark refers to a commit. The latter
form can be used by importing tools to build
all submodules simultaneously in one physical
repository, and then simply fetch them apart.
Signed-off-by: Alexander Gavrilov <angavrilov@gmail.com>
---
Changes:
1) Fixed the typo in the documentation.
2) Gitlinks are always exported as SHA.
3) Added some comments.
4) Added tests.
-- Alexander
Documentation/git-fast-import.txt | 3 +
builtin-fast-export.c | 17 +++-
fast-import.c | 14 +++-
t/t9300-fast-import.sh | 152 +++++++++++++++++++++++++++++++++++++
t/t9301-fast-export.sh | 42 ++++++++++
5 files changed, 223 insertions(+), 5 deletions(-)
diff --git a/Documentation/git-fast-import.txt b/Documentation/git-fast-import.txt
index 395c055..d510ddb 100644
--- a/Documentation/git-fast-import.txt
+++ b/Documentation/git-fast-import.txt
@@ -481,6 +481,9 @@ in octal. Git only supports the following modes:
what you want.
* `100755` or `755`: A normal, but executable, file.
* `120000`: A symlink, the content of the file will be the link target.
+* `160000`: A gitlink, SHA-1 of the object refers to a commit in
+ another repository. Git links can only be specified by SHA or through
+ a commit mark. They are used to implement submodules.
In both formats `<path>` is the complete path of the file to be added
(if not already existing) or modified (if already existing).
diff --git a/builtin-fast-export.c b/builtin-fast-export.c
index d0a462f..30ccbd5 100644
--- a/builtin-fast-export.c
+++ b/builtin-fast-export.c
@@ -122,9 +122,16 @@ static void show_filemodify(struct diff_queue_struct *q,
if (is_null_sha1(spec->sha1))
printf("D %s\n", spec->path);
else {
- struct object *object = lookup_object(spec->sha1);
- printf("M %06o :%d %s\n", spec->mode,
- get_object_mark(object), spec->path);
+ /* Links refer to objects in another repositories, so
+ output the SHA-1 verbatim */
+ if (S_ISGITLINK(spec->mode))
+ printf("M %06o %s %s\n", spec->mode,
+ sha1_to_hex(spec->sha1), spec->path);
+ else {
+ struct object *object = lookup_object(spec->sha1);
+ printf("M %06o :%d %s\n", spec->mode,
+ get_object_mark(object), spec->path);
+ }
}
}
}
@@ -182,8 +189,10 @@ static void handle_commit(struct commit *commit, struct rev_info *rev)
diff_root_tree_sha1(commit->tree->object.sha1,
"", &rev->diffopt);
+ /* Export the referenced blobs, and remember the marks */
for (i = 0; i < diff_queued_diff.nr; i++)
- handle_object(diff_queued_diff.queue[i]->two->sha1);
+ if (!S_ISGITLINK(diff_queued_diff.queue[i]->two->mode))
+ handle_object(diff_queued_diff.queue[i]->two->sha1);
mark_object(&commit->object);
if (!is_encoding_utf8(encoding))
diff --git a/fast-import.c b/fast-import.c
index e72b286..cb6d1ee 100644
--- a/fast-import.c
+++ b/fast-import.c
@@ -1868,6 +1868,7 @@ static void file_change_m(struct branch *b)
case S_IFREG | 0644:
case S_IFREG | 0755:
case S_IFLNK:
+ case S_IFGITLINK:
case 0644:
case 0755:
/* ok */
@@ -1900,7 +1901,18 @@ static void file_change_m(struct branch *b)
p = uq.buf;
}
- if (inline_data) {
+ if (S_ISGITLINK(mode)) {
+ if (inline_data)
+ die("Git links cannot be specified 'inline': %s",
+ command_buf.buf);
+ else if (oe) {
+ if (oe->type != OBJ_COMMIT)
+ die("Not a commit (actually a %s): %s",
+ typename(oe->type), command_buf.buf);
+ }
+ /* else: accept the sha1 without check, as its object
+ is expected to be in another repository */
+ } else if (inline_data) {
static struct strbuf buf = STRBUF_INIT;
if (p != uq.buf) {
diff --git a/t/t9300-fast-import.sh b/t/t9300-fast-import.sh
index 5edf56f..235a8a6 100755
--- a/t/t9300-fast-import.sh
+++ b/t/t9300-fast-import.sh
@@ -918,4 +918,156 @@ test_expect_success \
grep "progress " <input >expect &&
test_cmp expect actual'
+###
+### series P (gitlinks)
+###
+
+cat >input <<INPUT_END
+blob
+mark :1
+data 10
+test file
+
+reset refs/heads/sub
+commit refs/heads/sub
+mark :2
+committer $GIT_COMMITTER_NAME <$GIT_COMMITTER_EMAIL> $GIT_COMMITTER_DATE
+data 12
+sub_initial
+M 100644 :1 file
+
+blob
+mark :3
+data <<DATAEND
+[submodule "sub"]
+ path = sub
+ url = "`pwd`/sub"
+DATAEND
+
+commit refs/heads/subuse1
+mark :4
+committer $GIT_COMMITTER_NAME <$GIT_COMMITTER_EMAIL> $GIT_COMMITTER_DATE
+data 8
+initial
+from refs/heads/master
+M 100644 :3 .gitmodules
+M 160000 :2 sub
+
+blob
+mark :5
+data 20
+test file
+more data
+
+commit refs/heads/sub
+mark :6
+committer $GIT_COMMITTER_NAME <$GIT_COMMITTER_EMAIL> $GIT_COMMITTER_DATE
+data 11
+sub_second
+from :2
+M 100644 :5 file
+
+commit refs/heads/subuse1
+mark :7
+committer $GIT_COMMITTER_NAME <$GIT_COMMITTER_EMAIL> $GIT_COMMITTER_DATE
+data 7
+second
+from :4
+M 160000 :6 sub
+
+INPUT_END
+
+test_expect_success \
+ 'P: supermodule & submodule mix' \
+ 'git-fast-import <input &&
+ git checkout subuse1 &&
+ rm -rf sub && mkdir sub && cd sub &&
+ git init &&
+ git fetch .. refs/heads/sub:refs/heads/master &&
+ git checkout master &&
+ cd .. &&
+ git submodule init &&
+ git submodule update'
+
+SUBLAST=$(git-rev-parse --verify sub)
+SUBPREV=$(git-rev-parse --verify sub^)
+
+cat >input <<INPUT_END
+blob
+mark :1
+data <<DATAEND
+[submodule "sub"]
+ path = sub
+ url = "`pwd`/sub"
+DATAEND
+
+commit refs/heads/subuse2
+mark :2
+committer $GIT_COMMITTER_NAME <$GIT_COMMITTER_EMAIL> $GIT_COMMITTER_DATE
+data 8
+initial
+from refs/heads/master
+M 100644 :1 .gitmodules
+M 160000 $SUBPREV sub
+
+commit refs/heads/subuse2
+mark :3
+committer $GIT_COMMITTER_NAME <$GIT_COMMITTER_EMAIL> $GIT_COMMITTER_DATE
+data 7
+second
+from :2
+M 160000 $SUBLAST sub
+
+INPUT_END
+
+test_expect_success \
+ 'P: verbatim SHA gitlinks' \
+ 'git branch -D sub &&
+ git gc && git prune &&
+ git-fast-import <input &&
+ test $(git-rev-parse --verify subuse2) = $(git-rev-parse --verify subuse1)'
+
+test_tick
+cat >input <<INPUT_END
+commit refs/heads/subuse3
+mark :1
+committer $GIT_COMMITTER_NAME <$GIT_COMMITTER_EMAIL> $GIT_COMMITTER_DATE
+data <<COMMIT
+corrupt
+COMMIT
+
+from refs/heads/subuse2
+M 160000 inline sub
+data <<DATA
+$SUBPREV
+DATA
+
+INPUT_END
+
+test_expect_success 'P: fail on inline gitlink' '
+ ! git-fast-import <input'
+
+test_tick
+cat >input <<INPUT_END
+blob
+mark :1
+data <<DATA
+$SUBPREV
+DATA
+
+commit refs/heads/subuse3
+mark :2
+committer $GIT_COMMITTER_NAME <$GIT_COMMITTER_EMAIL> $GIT_COMMITTER_DATE
+data <<COMMIT
+corrupt
+COMMIT
+
+from refs/heads/subuse2
+M 160000 :1 sub
+
+INPUT_END
+
+test_expect_success 'P: fail on blob mark in gitlink' '
+ ! git-fast-import <input'
+
test_done
diff --git a/t/t9301-fast-export.sh b/t/t9301-fast-export.sh
index f09bfb1..f18eec9 100755
--- a/t/t9301-fast-export.sh
+++ b/t/t9301-fast-export.sh
@@ -120,4 +120,46 @@ test_expect_success 'signed-tags=strip' '
'
+test_expect_success 'setup submodule' '
+
+ git checkout -f master &&
+ mkdir sub &&
+ cd sub &&
+ git init &&
+ echo test file > file &&
+ git add file &&
+ git commit -m sub_initial &&
+ cd .. &&
+ git submodule add "`pwd`/sub" sub &&
+ git commit -m initial &&
+ test_tick &&
+ cd sub &&
+ echo more data >> file &&
+ git add file &&
+ git commit -m sub_second &&
+ cd .. &&
+ git add sub &&
+ git commit -m second
+
+'
+
+test_expect_success 'submodule fast-export | fast-import' '
+
+ SUBENT1=$(git ls-tree master^ sub) &&
+ SUBENT2=$(git ls-tree master sub) &&
+ rm -rf new &&
+ mkdir new &&
+ git --git-dir=new/.git init &&
+ git fast-export --signed-tags=strip --all |
+ (cd new &&
+ git fast-import &&
+ test "$SUBENT1" = "$(git ls-tree refs/heads/master^ sub)" &&
+ test "$SUBENT2" = "$(git ls-tree refs/heads/master sub)" &&
+ git checkout master &&
+ git submodule init &&
+ git submodule update &&
+ cmp sub/file ../sub/file)
+
+'
+
test_done
--
1.5.6.3.18.gfe82
^ permalink raw reply related
* Re: [PATCH] builtin-clone: Use is_dir_sep() instead of '/'
From: Johannes Schindelin @ 2008-07-19 11:35 UTC (permalink / raw)
To: Johannes Sixt; +Cc: Junio C Hamano, git, Daniel Barkalow
In-Reply-To: <200807191132.45648.johannes.sixt@telecom.at>
Hi,
On Sat, 19 Jul 2008, Johannes Sixt wrote:
> On Samstag, 19. Juli 2008, Junio C Hamano wrote:
> > Ok, but the surrounding code in this function look very suspicious.
>
> How about this then?
I like it. Very clear, very nice. Shorter code (if you look at the
diffstat modulo documentation).
Ciao,
Dscho
^ permalink raw reply
* Re: What's cooking in git.git (topics)
From: Johannes Schindelin @ 2008-07-19 11:19 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Nanako Shiraishi, git
In-Reply-To: <7vabge30dh.fsf@gitster.siamese.dyndns.org>
Hi,
On Fri, 18 Jul 2008, Junio C Hamano wrote:
> Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
>
> > On Fri, 18 Jul 2008, Junio C Hamano wrote:
> >
> >> +The 'recursive' strategy can take the following options:
> >> +
> >> +ours;;
> >
> > You still have not addressed the issue that you can specify multiple
> > strategies,...
>
> Even though multiple -s parameters are supported, I know you have been
> here long enough in git scene to remember how it came about. I've seen
> some third-party documents that talk about our ability to "try multiple
> strategies and pick the best one" as one of the unique features, but
> anybody who was there knows that it was just a failed experiment that we
> did not bother removing.
I think that we made it hard for that experiment to succeed, by
disallowing custom merge strategies.
See
http://git.or.cz/gitwiki/SoC2007Ideas#head-cfde15f16950c2579a89cc109762e911546e6fe3
for an idea that would make complete sense as a _fallback_ strategy.
Fallback, because it is definitely too slow to be the default.
Yes, I agree, if all strategies fail, it is dubitable that we find a
metric that will always find the "best" one. But if one fails and the
next one does not, it is obvious what is correct.
So I still feel that "-s subtree=<blabla>,recursive=theirs" would be a
viable way to go. And more intuitive than "-X".
I'll just ask Miklos what he thinks of the idea, and to write the patch if
he likes it, once he's back from the saddle. :-)
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH] builtin-clone: Use is_dir_sep() instead of '/'
From: Johannes Sixt @ 2008-07-19 9:32 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Daniel Barkalow
In-Reply-To: <7vk5fi67dx.fsf@gitster.siamese.dyndns.org>
On Samstag, 19. Juli 2008, Junio C Hamano wrote:
> Ok, but the surrounding code in this function look very suspicious.
How about this then?
-- snip --
builtin-clone: Rewrite guess_dir_name()
The function has to do three small and independent tasks, but all of them
were crammed into a single loop. This rewrites the function entirely by
unrolling these tasks.
We also now use is_dir_sep(c) instead of c == '/' to increase portability,
which actually was the primary reason to touch this code.
Signed-off-by: Johannes Sixt <johannes.sixt@telecom.at>
---
builtin-clone.c | 55 ++++++++++++++++++++++++++-----------------------------
1 files changed, 26 insertions(+), 29 deletions(-)
diff --git a/builtin-clone.c b/builtin-clone.c
index 8112716..91667d5 100644
--- a/builtin-clone.c
+++ b/builtin-clone.c
@@ -95,35 +95,32 @@ static char *get_repo_path(const char *repo, int *is_bundle)
static char *guess_dir_name(const char *repo, int is_bundle)
{
- const char *p, *start, *end, *limit;
- int after_slash_or_colon;
-
- /* Guess dir name from repository: strip trailing '/',
- * strip trailing '[:/]*.{git,bundle}', strip leading '.*[/:]'. */
-
- after_slash_or_colon = 1;
- limit = repo + strlen(repo);
- start = repo;
- end = limit;
- for (p = repo; p < limit; p++) {
- const char *prefix = is_bundle ? ".bundle" : ".git";
- if (!prefixcmp(p, prefix)) {
- if (!after_slash_or_colon)
- end = p;
- p += strlen(prefix) - 1;
- } else if (!prefixcmp(p, ".bundle")) {
- if (!after_slash_or_colon)
- end = p;
- p += 7;
- } else if (*p == '/' || *p == ':') {
- if (end == limit)
- end = p;
- after_slash_or_colon = 1;
- } else if (after_slash_or_colon) {
- start = p;
- end = limit;
- after_slash_or_colon = 0;
- }
+ const char *end = repo + strlen(repo), *start, *dot;
+
+ /*
+ * Strip trailing slashes
+ */
+ while (repo < end && is_dir_sep(end[-1]))
+ end--;
+
+ /*
+ * Find last component, but be prepared that repo could have
+ * the form "remote.example.com:foo.git", i.e. no slash
+ * in the directory part.
+ */
+ start = end;
+ while (repo < start && !is_dir_sep(start[-1]) && start[-1] != ':')
+ start--;
+
+ /*
+ * Strip .{bundle,git}.
+ */
+ if (is_bundle) {
+ if (end - start > 7 && !strcmp(end - 7, ".bundle"))
+ end -= 7;
+ } else {
+ if (end - start > 4 && !strcmp(end - 4, ".git"))
+ end -= 4;
}
return xstrndup(start, end - start);
--
1.5.6.3.443.g5f70e
^ permalink raw reply related
* Re: [PATCH] Windows: set gitexecdir = $(bindir)
From: Johannes Sixt @ 2008-07-19 8:52 UTC (permalink / raw)
To: Junio C Hamano, Steffen Prohaska; +Cc: git, Johannes Schindelin
In-Reply-To: <7vej5q67dq.fsf@gitster.siamese.dyndns.org>
On Samstag, 19. Juli 2008, Junio C Hamano wrote:
> Sorry, I am not sure if I understand what you are trying to solve. If you
> have ../libexec/git-core/ in GIT_EXEC_PATH (or have builtin_exec_path()
> use it), then your installation would look like this:
>
> [[some random place]]
> bin/git
> libexec/git-core/git-add
> libexec/git-core/git-del
> libexec/git-core/git-dir
> ...
>
> and if "git" can figure out it is "[[some random place]]/bin/git",
> it can find its subcommands from neighbouring directory, that is still
> inside the random place the user told the installer to use, can't it?
Yes, but...
Take as an example 'git pull'.
- The first call to git will derive the exec-path
$prefix/bin/../libexec/git-core and prepend it to $PATH.
- Calls to builtin git commands from inside 'git pull' will then derive the
exec-path $prefix/bin/../libexec/git-core/../libexec/git-core, that is
$prefix/libexec/libexec/git-core, and prepend it to $PATH as well. That
directory does not exist - usually - and it does not hurt. But it feels dirty
and potentially dangerous.
> > This counteracts the aims of the "dash-less" change on Windows, but
> > better this way than having no working git at all.
>
> I'd agree to the extent that anything is better than having no working
> git, but this somewhat feels backwards.
It certainly does.
I'm hoping that the msysgit crew has an opinion on this. CMD users like me do
not care how cluttered $PATH is because there is no command completion that
would reveal the 100+ git commands. But msysgit users who are working from a
bash may want to have them hidden outside $PATH. Or maybe they do not care.
-- Hannes
^ 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