* Re: Suggestion: drop 'g' in git-describe suffix
From: Johannes Schindelin @ 2006-11-02 10:59 UTC (permalink / raw)
To: Han-Wen Nienhuys; +Cc: git
In-Reply-To: <4549CE2A.3010808@xs4all.nl>
Hi,
On Thu, 2 Nov 2006, Han-Wen Nienhuys wrote:
> [lilydev@haring git]$ git describe
> v1.4.3.3-g1e1f76e
> [lilydev@haring git]$ git show g1e1f76e
You'd want to do
git show v1.4.3.3-g1e1f76e
Hth,
^ permalink raw reply
* Re: git and "dumb protocols"
From: Johannes Schindelin @ 2006-11-02 10:57 UTC (permalink / raw)
To: Petr Baudis; +Cc: git
In-Reply-To: <20061102104848.GH20017@pasky.or.cz>
Hi,
On Thu, 2 Nov 2006, Petr Baudis wrote:
> If you already have SSH access to the server, why not compile Git
> there and install it to your $HOME, though?
Could be a number of reasons:
- no compiler
- quota issues
- missing support for that particular platform
- time constraints
- etc
Happened to me.
Ciao,
Dscho
^ permalink raw reply
* Re: Suggestion: drop 'g' in git-describe suffix
From: Han-Wen Nienhuys @ 2006-11-02 10:53 UTC (permalink / raw)
To: git
In-Reply-To: <4549CA6B.4090909@shadowen.org>
Andy Whitcroft escreveu:
> Han-Wen Nienhuys wrote:
>> Andy Whitcroft escreveu:
>>>> or some other non-hex character.
>>> g is not a hex digit, hex is 0-f ??
>>>
>> Yes of course; silly me. Still I think it would be clearer if it used a
>> non-alphabet char, eg.
>>
>> tag+sha1
>>
>> to separate the tag and the committish.
>
> Well there is a non-alphabet character in there, a minus (-). The g
> prefix on the sha1 _fragment_ it to indicate that it is in fact a
> truncated sha1, not a complete one.
is this policy documented somewhere? None of the tools understand it.
[lilydev@haring git]$ git describe
v1.4.3.3-g1e1f76e
[lilydev@haring git]$ git show g1e1f76e
fatal: ambiguous argument 'g1e1f76e': unknown revision or path not in
the working tree.
Use '--' to separate paths from revisions
My suggestion is to use
v1.4.3.3+1e1f76e
here.
> If you want the complete clean sha1
> this is not the way to get it?
--
Han-Wen Nienhuys - hanwen@xs4all.nl - http://www.xs4all.nl/~hanwen
^ permalink raw reply
* Re: git and "dumb protocols"
From: Johannes Schindelin @ 2006-11-02 10:51 UTC (permalink / raw)
To: Matthieu Moy; +Cc: git
In-Reply-To: <vpqu01i16g8.fsf@ecrins.imag.fr>
Hi,
On Thu, 2 Nov 2006, Matthieu Moy wrote:
> Is it possible with git to push to a server on which git is not
> installed, and if so, how?
See
http://www.kernel.org/git/gitweb.cgi?p=git/git.git;a=blob;h=ba191569af9501117322e1881160226a74867007;hb=html;f=howto/setup-git-server-over-http.txt
Hth,
Dscho
^ permalink raw reply
* Re: git and "dumb protocols"
From: Petr Baudis @ 2006-11-02 10:48 UTC (permalink / raw)
To: git
In-Reply-To: <vpqu01i16g8.fsf@ecrins.imag.fr>
Hi,
Dear diary, on Thu, Nov 02, 2006 at 11:36:07AM CET, I got a letter
where Matthieu Moy <Matthieu.Moy@imag.fr> said that...
> Is it possible with git to push to a server on which git is not
> installed, and if so, how?
yes, you can push using HTTP DAV - just push to an HTTP URL; make sure
you have git-http-push compiled, it is sometimes not compiled because it
unfortunately adds dependencies on couple of more libraries.
Beware that this is inherently not safe for anonymous push access,
since malicious client with write access can destroy the repository. You
will want to protect write access to the repository by .htaccess file.
I think a patch that would add support for pushing over sftp or some
other dumb protocol would be welcome. One problem is with proper locking
of ref updates (not sure how well would sftp cope with that), another is
that you will need to do git-update-server-info's job on the server
side.
If you already have SSH access to the server, why not compile Git
there and install it to your $HOME, though?
--
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
#!/bin/perl -sp0777i<X+d*lMLa^*lN%0]dsXx++lMlN/dsM0<j]dsj
$/=unpack('H*',$_);$_=`echo 16dio\U$k"SK$/SM$n\EsN0p[lN*1
^ permalink raw reply
* Rebasing part of a branch
From: Andy Parkins @ 2006-11-02 10:45 UTC (permalink / raw)
To: git
Hello,
Is there a way to rebase part of a branch? For example
H---I---J topicB
/
E---F---G topicA
/
A---B---C---D master
And I want:
H---I---J topicB
/
| E---F---G topicA
|/
A---B---C---D master
Of course,
git-checkout topicB
git-rebase master
Doesn't work, because the common ancestor is D, which is master, and there is
nothing to do.
Of course I can cherry-pick, but is there something like
git-rebase --limit topicA master
Or some git-magic I can work?
Andy
--
Dr Andy Parkins, M Eng (hons), MIEE
^ permalink raw reply
* Re: git and "dumb protocols"
From: Andy Whitcroft @ 2006-11-02 10:42 UTC (permalink / raw)
To: git
In-Reply-To: <vpqu01i16g8.fsf@ecrins.imag.fr>
Matthieu Moy wrote:
> Hi,
>
> Is it possible with git to push to a server on which git is not
> installed, and if so, how?
>
>>From the man page of git, sftp doesn't seem supported, and ssh://
> complains about git-receive-pack not being installed on the server.
>
> The man page documents a rsync:// protocol, but
>
> $ git push rsync://some.location.com/
> fatal: I don't handle protocol 'rsync'
> $
>
> What am I missing?
To push only makes sense when you have git installed at the receiving
end. It is the interaction between the source and destination git
instances which renders the push an effective optimisation.
If you are using rsync, then you can just rsync the whole repository out
and what is out there is as valid as your own copy. Of course a repack
will make the whole thing changed and you'll pay on the next rsync.
git is designed with this use model involved, you 'git
update-server-info' then rsync the repo in-toto out to your http server
and it can be fetch'ed from (all be it less efficiently) by another
client. All without any requirement for anything other than passive
data delivery at the server end. Great if you don't have shell access etc.
-apw
^ permalink raw reply
* Minor documentation problems
From: Matthieu Moy @ 2006-11-02 10:40 UTC (permalink / raw)
To: git
Hi,
I'm giving a try to git/cogito after using other systems (particularly
GNU Arch and Bazaar).
I'm looking for a VCS which can suite me (willing to spend some time
learning it) and some collegues (NOT willing to spend more than a few
minutes learning a new tool. "patch" was already too complex, and
someone already requested me to send a full version instead of this
"weird thing that I don't have time to learn"). I'm also looking for a
system for my students, ranging from the somewhat experienced hacker
to the mathematician not caring about computers at all.
The git/cogito duo might do it, let's see.
I found minor problems with the doc, which deserve to be fixed:
* http://www.kernel.org/pub/software/scm/cogito/docs/cg-commit.1.html
Mentions .git/config, but not ~/.gitconfig (which is indeed _the_
place where I think most people want to set their name and email).
Side note: it can be interesting to have a command to do this.
For example, bzr has "bzr whoami 'me <myself@myisp.com>'", which
avoids having to learn the config file syntax.
* RSS link on the wiki:
The URL
http://git.or.cz/gitwiki/RecentChanges?action=rss_rc&ddiffs=1&unique=1
seems to be working as an RSS feed for changes, but it's not linked
to by http://git.or.cz/gitwiki/RecentChanges. Usually, there's an
RSS icon, and an HTML <link rel="alternate" ...> to help finding it.
Thanks,
--
^ permalink raw reply
* Re: Suggestion: drop 'g' in git-describe suffix
From: Andy Whitcroft @ 2006-11-02 10:37 UTC (permalink / raw)
To: hanwen; +Cc: git
In-Reply-To: <4549C083.9060805@xs4all.nl>
Han-Wen Nienhuys wrote:
> Andy Whitcroft escreveu:
>>> or some other non-hex character.
>>
>> g is not a hex digit, hex is 0-f ??
>>
>
> Yes of course; silly me. Still I think it would be clearer if it used a
> non-alphabet char, eg.
>
> tag+sha1
>
> to separate the tag and the committish.
Well there is a non-alphabet character in there, a minus (-). The g
prefix on the sha1 _fragment_ it to indicate that it is in fact a
truncated sha1, not a complete one. If you want the complete clean sha1
this is not the way to get it?
^ permalink raw reply
* git and "dumb protocols"
From: Matthieu Moy @ 2006-11-02 10:36 UTC (permalink / raw)
To: git
Hi,
Is it possible with git to push to a server on which git is not
installed, and if so, how?
From the man page of git, sftp doesn't seem supported, and ssh://
complains about git-receive-pack not being installed on the server.
The man page documents a rsync:// protocol, but
$ git push rsync://some.location.com/
fatal: I don't handle protocol 'rsync'
$
What am I missing?
Thanks,
--
^ permalink raw reply
* Re: [PATCH] Allow deletion of several patches at once
From: Catalin Marinas @ 2006-11-02 10:36 UTC (permalink / raw)
To: Karl Hasselström; +Cc: git
In-Reply-To: <20061101090714.2066.93948.stgit@localhost>
On 01/11/06, Karl Hasselström <kha@treskal.com> wrote:
> This is an updated patch, which uses parse_patches() to support patch
> ranges. It replaces patch 2/2 in the series; patch 1/2 (original
> delete regression test) is unaffected.
I applied it but added another commit to change the algorithm
slightly. It now first checks whether the applied patches can be
deleted before deleting any patch (I find this safer). It also checks
for local changes, conflicts and HEAD == top only if you delete
applied patches on the current branch. Actually, the HEAD == top test
failed when deleting on a different branch, which is normal since the
top is that of the other branch.
I'll make the changes public tonight.
Thanks.
--
^ permalink raw reply
* Re: [PATCH] Allow hand-editing of patches before sending
From: Catalin Marinas @ 2006-11-02 10:32 UTC (permalink / raw)
To: Karl Hasselström; +Cc: git
In-Reply-To: <20061101090046.1107.81105.stgit@localhost>
On 01/11/06, Karl Hasselström <kha@treskal.com> wrote:
> This adds a new flag to 'stg mail', allowing the user to hand-edit
> each patch e-mail before it is sent, just like it is currently
> possible to edit the cover message.
Applied it but with some conflicts since you have some other patches
which I haven't merged yet (like QP encoding). I'll try to have a look
at this QP encoding this week. The main problem is that Gnus shows
plenty of "=20" instead of new lines and 'stg import' cannot cope with
them.
Thanks.
--
^ permalink raw reply
* Re: What's in git.git
From: Johannes Schindelin @ 2006-11-02 10:02 UTC (permalink / raw)
To: Junio C Hamano, Jon Smirl; +Cc: git
In-Reply-To: <7vk62ewtxd.fsf@assigned-by-dhcp.cox.net>
Hi,
On Wed, 1 Nov 2006, Junio C Hamano wrote:
> * The 'pu' branch, in addition, has these.
>
> Johannes's "shallow" was marked as "pu" material so I've based
> the series on the tip of "next" (which means we cannot
> directly merge that into "next" or "master" without rebasing
> it to "master" first) and parked it in "pu". I have given
> only a cursory look to it but it looks promising.
Note that I have no use for shallow clones myself, since I really like to
have the complete history around. It also makes for a nice distributed
backup solution.
The reasons I did it:
- 'cause I could
- I think it is important for other people (this means you, Jon)
- I suggested lazy clones as an easy way out, but I am now convinced that
they introduce more problems than they solve. Therefore I wanted to make
good for the confusion I helped develop.
Since I do not have any use for shallow clones myself, I am waiting for
people to jump on it, test it, and shout "Hooray" or "Nacknacknack".
Ciao,
Dscho
^ permalink raw reply
* Re: weird strncmp usage?
From: Han-Wen Nienhuys @ 2006-11-02 9:59 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Andy Whitcroft, git
In-Reply-To: <Pine.LNX.4.63.0611021008180.1670@wbgn013.biozentrum.uni-wuerzburg.de>
Johannes Schindelin escreveu:
> However, in this case, you would need another macro, which automatically
> extracts the argument, and soon you will end up with yet another getopt
> package.
It puzzles me that git doesn't use getopt. Git is rare in not accepting
--option arg
but only
--option=arg
Also, -abc doesn't seem to work for combining options.
--
^ permalink raw reply
* Re: Suggestion: drop 'g' in git-describe suffix
From: Han-Wen Nienhuys @ 2006-11-02 9:55 UTC (permalink / raw)
To: git; +Cc: git
In-Reply-To: <45494E20.1000503@shadowen.org>
Andy Whitcroft escreveu:
>> or some other non-hex character.
>
> g is not a hex digit, hex is 0-f ??
>
Yes of course; silly me. Still I think it would be clearer if it used a
non-alphabet char, eg.
tag+sha1
to separate the tag and the committish.
--
Han-Wen Nienhuys - hanwen@xs4all.nl - http://www.xs4all.nl/~hanwen
^ permalink raw reply
* Re: Problem with git-push
From: Johannes Schindelin @ 2006-11-02 9:42 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Florent Thoumie
In-Reply-To: <7v8xiu3ksl.fsf@assigned-by-dhcp.cox.net>
Hi,
On Wed, 1 Nov 2006, Junio C Hamano wrote:
> - if (chmod(path, mode) < 0)
> + if (mode != st.st_mode && chmod(path, mode) < 0)
Oops. Somehow I missed this mail before replying. I'd like to point out
that it's safer to check for (mode & st.st_mode != mode), since we should
leave broader permissions as are.
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH] Add git-count-packs, like git-count-objects.
From: Nguyen Thai Ngoc Duy @ 2006-11-02 9:30 UTC (permalink / raw)
To: git
In-Reply-To: <ehvpcs$20j$2@sea.gmane.org>
On 10/28/06, Jakub Narebski <jnareb@gmail.com> wrote:
> Perhaps to nod add yet another command to already large set, rename
> git-count-objects to git-count end enhance it to count both loose objects
> and packs (or not, and use git-count-objects name).
Oh if so, I'd suggest git-stats over git-count :-)
--
^ permalink raw reply
* Re: how to pass ssh options to git?
From: Michael S. Tsirkin @ 2006-11-02 9:31 UTC (permalink / raw)
To: Matthieu Moy; +Cc: git
In-Reply-To: <vpqejsm433c.fsf@ecrins.imag.fr>
Quoting r. Matthieu Moy <Matthieu.Moy@imag.fr>:
> Subject: Re: how to pass ssh options to git?
>
> "Michael S. Tsirkin" <mst@mellanox.co.il> writes:
>
> > How is it possible to pass ssh options to git?
> > for example, I use these options to log into some machine:
> > ssh -i <private> -o HostKeyAlias=<alias> -p <port> -l <user> <address>
>
> Not answering the question, but this can go to ~/.ssh/config :
>
> Host *.domain.net
> User some_user
> IdentityFile ~/.ssh/foobar
>
I know, problem is I want to use different options at different times.
I could use -F configfile ssh option, but how to pass *that* to git?
--
^ permalink raw reply
* Re: Problem with git-push
From: Johannes Schindelin @ 2006-11-02 9:29 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Florent Thoumie, git
In-Reply-To: <7vk62f2l46.fsf@assigned-by-dhcp.cox.net>
Hi,
On Wed, 1 Nov 2006, Junio C Hamano wrote:
> Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
>
> > How about this instead:
> >
> > - mkdir(filename, 0777);
> > - if (adjust_shared_perm(filename))
> > + if (!mkdir(filename, 0777) && adjust_shared_perm(filename)) {
> > + *dir = '/';
> > return -2;
> > + }
>
> Not really. See the comment above the code you just touched.
/*
* Try to mkdir the last path component if that failed.
*
* Re-try the "link()" regardless of whether the mkdir
* succeeds, since a race might mean that somebody
* else succeeded.
*/
What I proposed does not break that. It only means that you only try to
adjust the permissions if the mkdir succeeded. If somebody else created
the directory in the mean time, it is not our job to adjust the
permissions. Worse, if the other mkdir was run by a different user, the
permission adjusting _cannot_ succeed, like you pointed out.
So I think that my patch is correct, but does not matter very much.
The other thing you asked for: adjust_shared_permissions should only try
to adjust the permissions only if they are not already correct. Here is my
attempt to implement that:
Totally untested.
Ciao,
Dscho
-- snip --
adjust_shared_perm(): Avoid unnecessary chmod()s
Sighed-off-by: Johannes E. Schindelin <johannes.schindelin@gmx.de>
---
diff --git a/path.c b/path.c
index bb89fb0..0a2bc51 100644
--- a/path.c
+++ b/path.c
@@ -279,7 +279,7 @@ int adjust_shared_perm(const char *path)
: 0));
if (S_ISDIR(mode))
mode |= S_ISGID;
- if (chmod(path, mode) < 0)
+ if ((mode & st.st_mode != mode) && chmod(path, mode) < 0)
return -2;
return 0;
}
^ permalink raw reply related
* Re: how to pass ssh options to git?
From: Matthieu Moy @ 2006-11-02 9:20 UTC (permalink / raw)
To: Michael S. Tsirkin; +Cc: git
In-Reply-To: <20061102090717.GE7468@mellanox.co.il>
"Michael S. Tsirkin" <mst@mellanox.co.il> writes:
> How is it possible to pass ssh options to git?
> for example, I use these options to log into some machine:
> ssh -i <private> -o HostKeyAlias=<alias> -p <port> -l <user> <address>
Not answering the question, but this can go to ~/.ssh/config :
Host *.domain.net
User some_user
IdentityFile ~/.ssh/foobar
Host another.host
...
--
^ permalink raw reply
* Re: weird strncmp usage?
From: Johannes Schindelin @ 2006-11-02 9:15 UTC (permalink / raw)
To: Jeff King; +Cc: Andy Whitcroft, hanwen, git
In-Reply-To: <20061102065127.GA23105@coredump.intra.peff.net>
Hi,
On Thu, 2 Nov 2006, Jeff King wrote:
> On Thu, Nov 02, 2006 at 01:44:36AM +0000, Andy Whitcroft wrote:
>
> > That said if you know its constant you can also use sizeof("foo") and
> > that is done at compile time. Something like:
> >
> > #define strxcmp(x, y) strncmp((x), (y), sizeof((y))
>
> You would, of course, need to use sizeof(y)-1 to avoid comparing the NUL
> termination. :)
>
> This is a slightly dangerous macro, because it _only_ works for string
> literals, but not pointers (which is fine in this case, but its
> limitations need to be documented).
It would be even better to avoid these errors by doing something like
#define starts_with(x, y) !strncmp((x), #y, sizeof(#y) - 1)
which would be used like this:
if (starts_with(arg, --abbrev=))
However, in this case, you would need another macro, which automatically
extracts the argument, and soon you will end up with yet another getopt
package.
Ciao,
Dscho
^ permalink raw reply
* how to pass ssh options to git?
From: Michael S. Tsirkin @ 2006-11-02 9:07 UTC (permalink / raw)
Cc: git
How is it possible to pass ssh options to git?
for example, I use these options to log into some machine:
ssh -i <private> -o HostKeyAlias=<alias> -p <port> -l <user> <address>
However, git will only let me specify the user name on command line as part of
the URL. I am guessing something can be done using core.gitProxy?
--
^ permalink raw reply
* Re: [PATCH 4/n] gitweb: Secure against commit-ish/tree-ish with the same name as path
From: Jakub Narebski @ 2006-11-02 8:49 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vac3awtj4.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano wrote:
> I'll be pushing out a "master" update
> sometime today, and do not expect to be able to get to your "n
> turned out to be ten" series, so it might be worthwhile to
> reroll the remaining bits that you still care about on top of
> what I push out tonight to make sure we are on the same page.
I'll wait a while if there are any comments (for example on formatting
used), and resend cleaned-up series.
> Preferably:
>
> - you should avoid making a series out of more-or-less
> unrelated things;
Well, truly unrelated were adding "--" to secure against ref with
the same name as path in the repository (but it was discovered
during testing the series) and replacing ' ' with ' ' in blob
and diff body for non-CSS aware browsers.
Better quoting and unquoting was needed for better commitdiff view.
Ah, well, perhaps it is unrelated.
Securing against filenames with LF for example has sense only if
there can be filenames with LF, and earlier gitweb unquoted it halfway
leaving '\n' instead of LF.
> - if you are doing related things in one series, do not send
> half-baked early parts out until you are finished and are
> confident with it.
I've send series early to get some comments, but I see while I got
some comments on "take 1" and "take 2" on _single_ "new commitdiff"
RFC patch, I got comments only about half-baked '&iquot;' idea.
--
Jakub Narebski
^ permalink raw reply
* Re: Restore a single file in the index back to HEAD
From: Andy Parkins @ 2006-11-02 8:44 UTC (permalink / raw)
To: git
In-Reply-To: <7vejsmzqh6.fsf@assigned-by-dhcp.cox.net>
On Wednesday 2006 November 01 23:39, Junio C Hamano wrote:
> That is not something other git commands with pathspec does.
> Path limiters tell command to "do your thing only for paths that
> match these patterns, while you usually handle all paths; your
> behaviour shall otherwise not be any different in other aspects
> between the case you got no limiter and the case you got _all_
> paths as limiters." So I do not think making path-only mode and
> pathless mode behave differently is a good idea from the UI
> point of view.
Surely if you move HEAD you have implicitly affected every path? In which
case what effect did the path limiter have?
Given
x --- y --- (z--Z)
With z being the index and Z being the working directory - both uncommitted.
The file foo will be different in x, y, z, and Z. We decide that z-foo is
incorrect and that it was right in x; however, there are changes in Z-foo
that we want to keep.
git-reset --mixed HEAD^ foo
This would reset z-foo (because --mixed) to its state in HEAD^; i.e. x-foo.
If HEAD changes as well then all the rest of y will be lost - not just y-foo.
Remember the original problem was a way of selectively manipulating the index
without altering the working directory.
I'm perfectly happy if git-reset is not the place to do this, because
git-reset is only allowed to fiddle with HEAD/index; I moved to git-reset
only because you mentioned that "reset historically is _not_ HEAD
manipulator".
I think we're back to square one: there is no appropriate command to take on
this functionality:
git-ls-tree HEAD^ foo | git-update-index --index-info
* git-reset can't have it because it makes no sense to alter HEAD /and/
revert a file. It also occurs to me that "git-reset --hard HEAD^ foo"
(using my suggested git-reset implementation) would be redundant anyway
because it's the same as "git-checkout -f HEAD^ foo".
* git-checkout can't have it because it doesn't target the index.
* git-update-index can't have it because it is plumbing and doesn't know
about commits, only about objects.
I'm stumped now.
Andy
--
Dr Andy Parkins, M Eng (hons), MIEE
^ permalink raw reply
* [PATCH] git-pickaxe: look for files relative to current path
From: Jeff King @ 2006-11-02 7:22 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Andy Whitcroft
In-Reply-To: <45496432.80503@shadowen.org>
Signed-off-by: Jeff King <peff@peff.net>
---
Andy Whitcroft writes:
> We seem to have a difference in the handling of relative filenames
> within a repository between git blame and git pickaxe. Specifically git
> pickaxe seems to always require names as if it were run in the top of
> the project:
This simple patch seems to fix it (but is not extensively tested).
builtin-pickaxe.c | 15 +++++++++++----
1 files changed, 11 insertions(+), 4 deletions(-)
diff --git a/builtin-pickaxe.c b/builtin-pickaxe.c
index c9405e9..3e76258 100644
--- a/builtin-pickaxe.c
+++ b/builtin-pickaxe.c
@@ -1413,6 +1413,13 @@ static void sanity_check_refcnt(struct s
}
}
+static const char *add_prefix(const char *prefix, const char *path)
+{
+ if (!prefix || !prefix[0])
+ return path;
+ return prefix_path(prefix, strlen(prefix), path);
+}
+
static int has_path_in_work_tree(const char *path)
{
struct stat st;
@@ -1548,7 +1555,7 @@ int cmd_pickaxe(int argc, const char **a
/* (1) */
if (argc <= i)
usage(pickaxe_usage);
- path = argv[i];
+ path = add_prefix(prefix, argv[i]);
if (i + 1 == argc - 1) {
if (unk != 1)
usage(pickaxe_usage);
@@ -1566,13 +1573,13 @@ int cmd_pickaxe(int argc, const char **a
if (seen_dashdash) {
if (seen_dashdash + 1 != argc - 1)
usage(pickaxe_usage);
- path = argv[seen_dashdash + 1];
+ path = add_prefix(prefix, argv[seen_dashdash + 1]);
for (j = i; j < seen_dashdash; j++)
argv[unk++] = argv[j];
}
else {
/* (3) */
- path = argv[i];
+ path = add_prefix(prefix, argv[i]);
if (i + 1 == argc - 1) {
final_commit_name = argv[i + 1];
@@ -1580,7 +1587,7 @@ int cmd_pickaxe(int argc, const char **a
* old-style
*/
if (unk == 1 && !has_path_in_work_tree(path)) {
- path = argv[i + 1];
+ path = add_prefix(prefix, argv[i + 1]);
final_commit_name = argv[i];
}
}
--
^ 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