* Re: Unable to remove a file
From: Andreas Schwab @ 2011-10-04 14:50 UTC (permalink / raw)
To: Zbigniew Jędrzejewski-Szmek; +Cc: robert mena, John Szakmeister, git
In-Reply-To: <4E8B135D.8090507@in.waw.pl>
Zbigniew Jędrzejewski-Szmek <zbyszek@in.waw.pl> writes:
> git fetch updates the remote references, always.
Only if the refspec starts with '+'.
Andreas.
--
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5
"And now for something completely different."
^ permalink raw reply
* Re: [RFC/PATCH] git checkout $tree path
From: Jay Soffian @ 2011-10-04 15:05 UTC (permalink / raw)
To: Jeff King; +Cc: Junio C Hamano, git
In-Reply-To: <20111003102647.GD16078@sigill.intra.peff.net>
On Mon, Oct 3, 2011 at 6:26 AM, Jeff King <peff@peff.net> wrote:
> On Thu, Sep 29, 2011 at 03:46:31PM -0700, Junio C Hamano wrote:
>> An alternative semantics could be to first remove paths that match the
>> given pathspec from the index, then update the index with paths taken from
>> the named tree, and update the working tree. "git checkout master dir"
>> would then mean "replace anything currently in dir with whatever is in dir
>> in master". It is more dangerous, and it can easily emulated by doing:
>
> being what the user expects. As in, "master deleted this file; shouldn't
> checkout pull the deletion to my new branch when I ask it to?".
>
> But we can't distinguish those two cases without actually having a merge
> base. And this isn't a merge; it's not about picking changes from
> master, it's about saying "make dir look like it does in master". So
> in that sense, the most straightforward thing is your second
> alternative: afterwards, we should have only the files in "dir" that
> master has.
I think I'd expect the first behavior with:
$ git checkout master -- dir/*
And the second with:
$ git checkout master -- dir
$0.02.
j.
^ permalink raw reply
* Re: [RFC/PATCH] git checkout $tree path
From: Junio C Hamano @ 2011-10-04 15:20 UTC (permalink / raw)
To: Jeff King; +Cc: git
In-Reply-To: <20111004074212.GB7308@sigill.intra.peff.net>
Jeff King <peff@peff.net> writes:
> This is sufficiently tricky and subtle that it is probably worth
> future-proofing with some tests (e.g., the example you gave in the
> commit message).
Yes, see t2022 in 'pu'.
^ permalink raw reply
* Re: [RFC/PATCH]: reverse bisect v 2.0
From: Junio C Hamano @ 2011-10-04 15:22 UTC (permalink / raw)
To: Jeff King
Cc: Michal Vyskocil, git, Sverre Rabbelier, Johannes Sixt,
Christian Couder
In-Reply-To: <20111004103056.GB11236@sigill.intra.peff.net>
Jeff King <peff@peff.net> writes:
> On Mon, Oct 03, 2011 at 10:00:25AM -0700, Junio C Hamano wrote:
>
> And the --started-to would literally be implemented as flipping the
> meaning of "git bisect yes" and "git bisect no", and nothing more. IOW,
> it's just another way of spelling "git bisect --reverse".
Yes, if we wanted to also implement the flipping of the mapping between
yes/no and good/bad, I do not have any problem with --used-to/--started-to
pair of options.
Thanks.
^ permalink raw reply
* Re: [PATCH] git-difftool: allow skipping file by typing 'n' at prompt
From: Junio C Hamano @ 2011-10-04 15:25 UTC (permalink / raw)
To: Sitaram Chamarty; +Cc: git
In-Reply-To: <20111004105333.GA24331@atcmail.atc.tcs.com>
Sitaram Chamarty <sitaram@atc.tcs.com> writes:
> Signed-off-by: Sitaram Chamarty <sitaram@atc.tcs.com>
> ---
>
> I'm using what is pretty much a universal convention to
> signify that the default choice is "y"; I hope documentation
> for something so small is not needed but if it is, let me
> know and I'll do that also.
>
> - printf "Hit return to launch '%s': " \
> + printf "Launch '%s' [y]/n: " \
I think I've seen this done as: "do this? [Y/n]" elsewhere.
Not telling you what to do, but trying to feel what others may think.
^ permalink raw reply
* Re: [PATCH] git-completion: offer references for 'git reflog'
From: Junio C Hamano @ 2011-10-04 17:05 UTC (permalink / raw)
To: Michael Schubert; +Cc: git
In-Reply-To: <4E8AC85A.2070009@elegosoft.com>
Michael Schubert <mschub@elegosoft.com> writes:
> On 09/25/2011 12:42 PM, Michael Schubert wrote:
>> 'git reflog <ref>' is a valid command, therefore offer reference
>> completion.
>>
>> Signed-off-by: Michael Schubert <mschub@elegosoft.com>
>> ---
>> contrib/completion/git-completion.bash | 2 +-
>> 1 files changed, 1 insertions(+), 1 deletions(-)
>>
>> diff --git a/contrib/completion/git-completion.bash b/contrib/completion/git-completion.bash
>> index 8648a36..63d0f08 100755
>> --- a/contrib/completion/git-completion.bash
>> +++ b/contrib/completion/git-completion.bash
>> @@ -1774,7 +1774,7 @@ _git_reflog ()
>> local subcommand="$(__git_find_on_cmdline "$subcommands")"
>>
>> if [ -z "$subcommand" ]; then
>> - __gitcomp "$subcommands"
>> + __gitcomp "$subcommands $(__git_refs)"
>> else
>> __gitcomp "$(__git_refs)"
>> fi
>
> Ping.?
Personally I think this change will give much less pleasant user
experience. This is what I currently get:
$ git reflog <TAB>
delete expire show
$ git reflog
and after learning the "show" subcommand exists, this is what I would get:
$ git reflog show <TAB>
Display all 626 possibilities? (y or n)
With your change, I would get:
$ git reflog <TAB>
Display all 629 possibilities? (y or n)
and do not even have a chance to remind myself if the subcommand to drop
a reflog was "delete" or "remove".
At least when I know that I want to be reminded of refs to $verb (use one
of the three subcommands I currently get in place of the "$verb"), I can
say
$ git reflog $verb <TAB>
and at that point, I am willing to wade thru list of 600+ refs.
^ permalink raw reply
* Re: [PATCH] contrib: add a pair of credential helpers for Mac OS X's keychain
From: Junio C Hamano @ 2011-10-04 17:13 UTC (permalink / raw)
To: Jeff King; +Cc: Jay Soffian, git, John Szakmeister
In-Reply-To: <20111004101610.GA11236@sigill.intra.peff.net>
Now, I would like to start moving the core part of the credential helper
series to 'master'. Could people summarize what the current status of
various moving parts are?
Here is an example of write-up, based on my understanding (I said it
should be pretty-much ready, but please correct me if I am mistaken).
- The core part have seen some updates while it was cooking in 'next',
with help from inputs by credential plug-in authors. The API and the
sample implementation should be stable enough that it can be given to
people who follow 'master' perhaps with 'experimental, minor details
still subject to change' label attached.
I'd like to see similar write-ups for plug-ins from people who were
involved in the topic, at least on the following:
- Mac OS X keychain?
- Gnome?
- KDE?
- Windows?
- Others?
Thanks.
^ permalink raw reply
* Re: [PATCH] contrib: add a pair of credential helpers for Mac OS X's keychain
From: Jeff King @ 2011-10-04 17:48 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Jay Soffian, git, John Szakmeister
In-Reply-To: <7v39f8d6iq.fsf@alter.siamese.dyndns.org>
On Tue, Oct 04, 2011 at 10:13:33AM -0700, Junio C Hamano wrote:
> Now, I would like to start moving the core part of the credential helper
> series to 'master'. Could people summarize what the current status of
> various moving parts are?
>
> Here is an example of write-up, based on my understanding (I said it
> should be pretty-much ready, but please correct me if I am mistaken).
>
> - The core part have seen some updates while it was cooking in 'next',
> with help from inputs by credential plug-in authors. The API and the
> sample implementation should be stable enough that it can be given to
> people who follow 'master' perhaps with 'experimental, minor details
> still subject to change' label attached.
No, sadly I don't think we're there yet. The two big open questions are:
1. Should we be giving more context details to the helpers, and/or
should we be breaking down the information into pieces?
I think the answer is probably yes. Certainly OS X would benefit
from the broken-down pieces. My feeling is that we could hand
helpers both broken-down pieces as well as an inclusive URL. So
something like:
git credential-foo \
--type=network --protocol=https --host=example.com \
--username=user1 --path=repo.git \
--url=https://user1@example.com/repo.git
and then the helper can pick what it likes from there.
One thing I haven't figured out is how the user would tell git "no,
the repo path is not relevant for determining the auth domain".
That feature can come later, but I want to make sure that helpers
know they might or might not get the "--path" option. I guess that
is just a matter of documentation; I'm just a little nervous
committing to it without having figured out the details.
2. There has been some talk that the helper interface should perhaps
be vastly simplified from "get the credentials and give them to
git" to merely being a store/retrieve system, where the invocations
would be something like (pretend git is the shell):
# git asks if we have a stored credential
git credential-foo --get --url=...,etc | read password
# we had a successful authentication; ask the helper to store it;
echo password | git credential-foo --put --url=...,etc
That makes the helpers much simpler, and makes interacting with the
user more uniform across helpers.
It disallows helpers doing specialized interactions or dialogs. I'm
not sure how much we want that. I thought some systems might find
that more natural, but that's debatable. Jay implemented a git-like
pure-terminal prompt in his helper. Lukas used the kde
password-dialog for the KDE helper. I'm not sure what people really want.
I can produce patches for both if we want to see what they would look
like. But I kind of think it's not a matter of "what will the code look
like" (both of them are pretty straightforward to implement), but "what
do we want the interface to look like". And that is really as much up to
me as to people who are going to write and use the helpers.
-Peff
^ permalink raw reply
* Re: [PATCH] git-difftool: allow skipping file by typing 'n' at prompt
From: Jeff King @ 2011-10-04 17:49 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Sitaram Chamarty, git
In-Reply-To: <7vbotwdbjg.fsf@alter.siamese.dyndns.org>
On Tue, Oct 04, 2011 at 08:25:07AM -0700, Junio C Hamano wrote:
> Sitaram Chamarty <sitaram@atc.tcs.com> writes:
>
> > Signed-off-by: Sitaram Chamarty <sitaram@atc.tcs.com>
> > ---
> >
> > I'm using what is pretty much a universal convention to
> > signify that the default choice is "y"; I hope documentation
> > for something so small is not needed but if it is, let me
> > know and I'll do that also.
> >
> > - printf "Hit return to launch '%s': " \
> > + printf "Launch '%s' [y]/n: " \
>
> I think I've seen this done as: "do this? [Y/n]" elsewhere.
>
> Not telling you what to do, but trying to feel what others may think.
Yes, that was my immediate thought, too (or even [Yn]).
-Peff
^ permalink raw reply
* Re: [PATCH v3 3/4] enter_repo: do not modify input
From: Phil Hord @ 2011-10-04 17:55 UTC (permalink / raw)
To: Erik Faye-Lund; +Cc: git, peff, j6t, gitster, rene.scharfe
In-Reply-To: <1317329963-6656-4-git-send-email-kusmabite@gmail.com>
On Thu, Sep 29, 2011 at 4:59 PM, Erik Faye-Lund <kusmabite@gmail.com> wrote:
> entr_repo(..., 0) currently modifies the input to strip away
> trailing slashes. This means that we some times need to copy the
> input to keep the original.
I'm also modifying enter_repo() so I'm looking a bit closer at this patch now.
> Change it to unconditionally copy it into the used_path buffer so
> we can safely use the input without having to copy it.
>
> Signed-off-by: Erik Faye-Lund <kusmabite@gmail.com>
> ---
[...]
> */
> -char *enter_repo(char *path, int strict)
> +const char *enter_repo(const char *path, int strict)
> {
> static char used_path[PATH_MAX];
> static char validated_path[PATH_MAX];
> @@ -297,14 +297,15 @@ char *enter_repo(char *path, int strict)
> };
> int len = strlen(path);
> int i;
> - while ((1 < len) && (path[len-1] == '/')) {
> - path[len-1] = 0;
> + while ((1 < len) && (path[len-1] == '/'))
> len--;
> - }
> +
> if (PATH_MAX <= len)
> return NULL;
> - if (path[0] == '~') {
> - char *newpath = expand_user_path(path);
> + strncpy(used_path, path, len);
When len < strlen(path), this will will leave used_path unterminated.
> +
> + if (used_path[0] == '~') {
> + char *newpath = expand_user_path(used_path);
> if (!newpath || (PATH_MAX - 10 < strlen(newpath))) {
> free(newpath);
> return NULL;
> @@ -316,24 +317,21 @@ char *enter_repo(char *path, int strict)
> * anyway.
> */
> strcpy(used_path, newpath); free(newpath);
> - strcpy(validated_path, path);
> - path = used_path;
> + strcpy(validated_path, used_path);
The point of 'validated_path' is to keep the original unmolested,
unexpanded path string (plus DWIM suffix), but here you've just
replaced validated_path with a copy of the expanded_user_path. On the
other hand, we seem always to strcpy(validated_path , path), so we
might as well get that done up-front.
I'll re-roll these changes in in a minute. Stand by.
Phil
^ permalink raw reply
* Re: [PATCH v3 3/4] enter_repo: do not modify input
From: Phil Hord @ 2011-10-04 18:00 UTC (permalink / raw)
To: Erik Faye-Lund; +Cc: git, peff, j6t, gitster, rene.scharfe
In-Reply-To: <CABURp0qDsxHwsuyvB6-KvKPrKuUT0-Fpr730TD_TxxFY7fotpA@mail.gmail.com>
From: Erik Faye-Lund <kusmabite@gmail.com>
entr_repo(..., 0) currently modifies the input to strip away
trailing slashes. This means that we some times need to copy the
input to keep the original.
Change it to unconditionally copy it into the used_path buffer so
we can safely use the input without having to copy it. Also store
a working copy in validated_path up-front before we start
resolving anything.
Signed-off-by: Erik Faye-Lund <kusmabite@gmail.com>
Signed-off-by: Phil Hord <hordp@cisco.com>
---
cache.h | 2 +-
daemon.c | 4 ++--
path.c | 28 ++++++++++++----------------
3 files changed, 15 insertions(+), 19 deletions(-)
diff --git a/cache.h b/cache.h
index 607c2ea..a7e4de1 100644
--- a/cache.h
+++ b/cache.h
@@ -734,7 +734,7 @@ int safe_create_leading_directories(char *path);
int safe_create_leading_directories_const(const char *path);
int mkdir_in_gitdir(const char *path);
extern char *expand_user_path(const char *path);
-char *enter_repo(char *path, int strict);
+const char *enter_repo(const char *path, int strict);
static inline int is_absolute_path(const char *path)
{
return is_dir_sep(path[0]) || has_dos_drive_prefix(path);
diff --git a/daemon.c b/daemon.c
index 4c8346d..9253192 100644
--- a/daemon.c
+++ b/daemon.c
@@ -108,11 +108,11 @@ static void NORETURN daemon_die(const char *err,
va_list params)
exit(1);
}
-static char *path_ok(char *directory)
+static const char *path_ok(char *directory)
{
static char rpath[PATH_MAX];
static char interp_path[PATH_MAX];
- char *path;
+ const char *path;
char *dir;
dir = directory;
diff --git a/path.c b/path.c
index 6f3f5d5..01028f2 100644
--- a/path.c
+++ b/path.c
@@ -283,7 +283,7 @@ return_null:
* links. User relative paths are also returned as they are given,
* except DWIM suffixing.
*/
-char *enter_repo(char *path, int strict)
+const char *enter_repo(const char *path, int strict)
{
static char used_path[PATH_MAX];
static char validated_path[PATH_MAX];
@@ -297,14 +297,16 @@ char *enter_repo(char *path, int strict)
};
int len = strlen(path);
int i;
- while ((1 < len) && (path[len-1] == '/')) {
- path[len-1] = 0;
+ while ((1 < len) && (path[len-1] == '/'))
len--;
- }
+
if (PATH_MAX <= len)
return NULL;
- if (path[0] == '~') {
- char *newpath = expand_user_path(path);
+ strncpy(used_path, path, len); used_path[len] = 0 ;
+ strcpy(validated_path, used_path);
+
+ if (used_path[0] == '~') {
+ char *newpath = expand_user_path(used_path);
if (!newpath || (PATH_MAX - 10 < strlen(newpath))) {
free(newpath);
return NULL;
@@ -316,24 +318,18 @@ char *enter_repo(char *path, int strict)
* anyway.
*/
strcpy(used_path, newpath); free(newpath);
- strcpy(validated_path, path);
- path = used_path;
}
else if (PATH_MAX - 10 < len)
return NULL;
- else {
- path = strcpy(used_path, path);
- strcpy(validated_path, path);
- }
- len = strlen(path);
+ len = strlen(used_path);
for (i = 0; suffix[i]; i++) {
- strcpy(path + len, suffix[i]);
- if (!access(path, F_OK)) {
+ strcpy(used_path + len, suffix[i]);
+ if (!access(used_path, F_OK)) {
strcat(validated_path, suffix[i]);
break;
}
}
- if (!suffix[i] || chdir(path))
+ if (!suffix[i] || chdir(used_path))
return NULL;
path = validated_path;
}
--
1.7.7.503.g26392.dirty
^ permalink raw reply related
* Re: [PATCH] git-difftool: allow skipping file by typing 'n' at prompt
From: Phil Hord @ 2011-10-04 18:02 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Sitaram Chamarty, git
In-Reply-To: <7vbotwdbjg.fsf@alter.siamese.dyndns.org>
On Tue, Oct 4, 2011 at 11:25 AM, Junio C Hamano <gitster@pobox.com> wrote:
> Sitaram Chamarty <sitaram@atc.tcs.com> writes:
>
>> Signed-off-by: Sitaram Chamarty <sitaram@atc.tcs.com>
>> ---
>>
>> I'm using what is pretty much a universal convention to
>> signify that the default choice is "y"; I hope documentation
>> for something so small is not needed but if it is, let me
>> know and I'll do that also.
>>
>> - printf "Hit return to launch '%s': " \
>> + printf "Launch '%s' [y]/n: " \
>
> I think I've seen this done as: "do this? [Y/n]" elsewhere.
>
> Not telling you what to do, but trying to feel what others may think.
I think so, too. The [y]/n syntax is not clear enough for me to
confidently know what the default value will be.
Phil
^ permalink raw reply
* Re: pack-object poor performance (with large number of objects?)
From: Jeff King @ 2011-10-04 18:08 UTC (permalink / raw)
To: Piotr Krukowiecki
Cc: Junio C Hamano, Shawn Pearce, Git Mailing List, Ingo Molnar
In-Reply-To: <CAA01Csp2rouKk4jvCH0Wu+0gc3+cvyH__d-yw8EHEkeZhRpX1Q@mail.gmail.com>
On Tue, Oct 04, 2011 at 03:21:24PM +0200, Piotr Krukowiecki wrote:
> I have 4GB ram + 4GB swap. Is it possible the RAM is the problem if I
> always have free RAM left and my swap is almost not used?
> For example at the moment repack finished counting objects ("Counting
> objects: 1742200, done."):
>
> $ free -m
> total used free shared buffers cached
> Mem: 3960 3814 146 0 441 215
> -/+ buffers/cache: 3157 803
> Swap: 6143 694 5449
I am not the best person to comment on Linux's disk caching strategies,
but in general, it should prefer dropping disk cache over pushing
program memory into swap. So no, you're not swapping, but you are
working with only 800M or so to do your disk caching.
So depending how big pack-object's working set of objects is, we might
be overflowing that, and constantly evicting and re-reading objects. I
don't recall offhand what kind of locality there is to pack-object's
accesses.
One thing you could try to reduce the working set is to incrementally
pack some smaller chunks, and then combine them all at the end. That
ends up being more work overall, but at any given time, your working set
of objects will be smaller.
You'd have to do something like this (this is very untested):
# find out how many revisions we have. Let's pretend it's about
# 25,000.
git rev-list HEAD | wc -l
# now split them into chunks of whatever size you feel like trying.
# 1000, maybe, or a few thousand. Bearing in mind that this is a gross
# approximation, since the history is not linear.
#
# Start with HEAD~24K (25K total, minus 1K we want to pack)
echo HEAD~24000 | git pack-objects --revs .git/objects/pack/pack
# And then prune the loose objects that we just packed.
git prune-packed
# And repeat for the next chunk
echo HEAD~24000..HEAD~23000 | git pack-objects --revs .git/objects/pack/pack
git prune-packed
# And so forth...
And then at the end, probably do a "git repack -ad" to put it all in
one big pack. Which should hopefully be less disk-intensive, because now
you'll have a much smaller disk footprint, since most of your objects
are at least delta'd against the others in their own pack.
I have no idea if this will actually go faster for you. But it might be
worth trying, instead of just redoing the svn import with auto-gc turned
on.
-Peff
^ permalink raw reply
* Re: Git ksshaskpass to play nice with https and kwallet
From: Michael J Gruber @ 2011-10-04 18:49 UTC (permalink / raw)
To: Jeff King; +Cc: Git Mailing List
In-Reply-To: <20111004124344.GA30162@sigill.intra.peff.net>
Jeff King venit, vidit, dixit 04.10.2011 14:43:
> On Tue, Oct 04, 2011 at 02:12:02PM +0200, Michael J Gruber wrote:
>
>>> The latter is especially useful if you have put a username in your
>>> ~/.gitconfig, in which case you get:
>>
>> I'm actually wondering why git can't infer the user from
>>
>> https://user@host.com
>>
>> with last week's next, at least.
>
> It can, and it has for some time. Part of the configurable-username
> thing was that it would be way nicer to just use a user-agnostic URL,
> because it means it's easier to share with other people.
>
We seem to mean something different:
git config --get remote.bitbucket.pushurl
https://grubix@bitbucket.org/grubix/git.git
SSH_ASKPASS= git push -n bitbucket
Username for 'bitbucket.org':
I mean that git should not need to ask for the username here.
Michael
^ permalink raw reply
* Git attributes ignored for root directory
From: Gioele Barabucci @ 2011-10-04 18:52 UTC (permalink / raw)
To: git
Hello,
I just updated to git v1.7.7 using the Ubuntu Lucid PPA and I found that
`git check-attr` is broken now.
I have this attribute in my `$HOME/.gitattributes` file:
/. show_in_prompt=no
Now, if I go to `$HOME` and run
git check-attr show_in_prompt -- .
With git v1.7.6 this is the answer I got:
.: show_in_prompt: no
With the newer v1.7.7 I get this, instead:
.: show_in_prompt: unspecified
Also, if I use the `--all` option, `check-attr` does not show any
attribute at all.
I see in the release notes of 1.7.7-rc1 that `check-attr` has been
changed to allow relative paths to be specified. Maybe this error is
related to that change.
Best,
--
Gioele Barabucci <gioele@svario.it>
^ permalink raw reply
* Re: [PATCH] contrib: add a pair of credential helpers for Mac OS X's keychain
From: Junio C Hamano @ 2011-10-04 19:10 UTC (permalink / raw)
To: Jeff King; +Cc: Jay Soffian, git, John Szakmeister, Kyle Neath
In-Reply-To: <20111004174840.GA31558@sigill.intra.peff.net>
Jeff King <peff@peff.net> writes:
> No, sadly I don't think we're there yet.
It is much better to proceed with caution than unleashing something whose
semantics will later have to change so drastically that we end up hurting
end users, so nobody has to say "sadly". By spelling out what more needs
to be there for us to get there, we are making progress.
> The two big open questions are:
>
> 1. Should we be giving more context details to the helpers, and/or
> should we be breaking down the information into pieces?
>
> I think the answer is probably yes. Certainly OS X would benefit
> from the broken-down pieces. My feeling is that we could hand
> helpers both broken-down pieces as well as an inclusive URL. So
> something like:
>
> git credential-foo \
> --type=network --protocol=https --host=example.com \
> --username=user1 --path=repo.git \
> --url=https://user1@example.com/repo.git
>
> and then the helper can pick what it likes from there.
Hmm, don't we first want to enumerate contexts where we might want to get
the access information from the user? E.g.
* "transport" aka "git fetch/push"; I think you meant this by --type=network,
but there probably are other kinds of accesses over "network".
* "imap-send".
* "send-email".
* "tag -s" and perhaps upcoming "push --signed" or "commit --gpg-sign"?
Anything else?
I am not sure where the unlocking passphrase for ssl cert fits in this
picture, though.
> One thing I haven't figured out is how the user would tell git "no,
> the repo path is not relevant for determining the auth domain".
> That feature can come later, but I want to make sure that helpers
> know they might or might not get the "--path" option. I guess that
> is just a matter of documentation; I'm just a little nervous
> committing to it without having figured out the details.
Well, shouldn't the caller of credential-foo be passing --authdomain as a
separate piece anyway? In the above example, if example.com operates as a
single auth domain no matter what repository, --authdomain may just say
"". If it uses per repository auth domain, --authdomain may say "repo.git"
(I am assuming <authdomain> is not globally unique but unique within the
context of <type, host> or perhaps <type, proto, host>).
> 2. There has been some talk that the helper interface should perhaps
> be vastly simplified from "get the credentials and give them to
> git" to merely being a store/retrieve system, where the invocations
> would be something like (pretend git is the shell):
>
> # git asks if we have a stored credential
> git credential-foo --get --url=...,etc | read password
>
> # we had a successful authentication; ask the helper to store it;
> echo password | git credential-foo --put --url=...,etc
>
> That makes the helpers much simpler, and makes interacting with the
> user more uniform across helpers.
>
> It disallows helpers doing specialized interactions or dialogs.
Very true.
I have this suspicion that running dialog on various desktop environments
may be orthogonal to what credential store to be used. Once we know the
repertoire of the broken-down pieces, we may want to add "dialog-foo"
family of helpers whose sole purpose is to interact with the user to get
missing information. E.g. we may notice that we need to ask both the
username and password, and invoke
$ dialog-foo --msg=$msg --ask=username --ask-secret=password
where $msg tells the user why we are asking these pieces (e.g. trying to
push into https://example.com/repo.git), and then read from the helper
what the user gave it.
If the URL had user1@ in it, then the $msg would say that we are trying to
push into https://example.com/repo.git as user1, and we invoke the helper
with only --ask-secret=password (without --ask=username).
The same "helper" executable _could_ implement both interfaces, but I
think they are logically separate.
^ permalink raw reply
* Re: [PATCH] git-difftool: allow skipping file by typing 'n' at prompt
From: Junio C Hamano @ 2011-10-04 19:28 UTC (permalink / raw)
To: Phil Hord; +Cc: Sitaram Chamarty, git
In-Reply-To: <CABURp0qmYWRJzHZZwZreKnj0ymFyM_AYXWXqwy=vTZspoPvvvg@mail.gmail.com>
Phil Hord <phil.hord@gmail.com> writes:
> On Tue, Oct 4, 2011 at 11:25 AM, Junio C Hamano <gitster@pobox.com> wrote:
>
>> I think I've seen this done as: "do this? [Y/n]" elsewhere.
>>
>> Not telling you what to do, but trying to feel what others may think.
>
> I think so, too. The [y]/n syntax is not clear enough for me to
> confidently know what the default value will be.
One downside of "do this [Y,n,m,o,p,q]? " is that it limits us to
lowercase responses, which means we cannot assign 'q' for quitting from
the innermost nested context and assign 'Q' for quitting from the whole
interactive loop (e.g. "git add -p").
"do this [y,n,m,o,p,q] (default=y)? "
may have been a better choice in hindsight.
No matter what we end up doing, let's try to be consistent.
Thanks.
^ permalink raw reply
* Re: [PATCH] git-completion: offer references for 'git reflog'
From: Michael Schubert @ 2011-10-04 19:34 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7v7h4kd6vg.fsf@alter.siamese.dyndns.org>
On 10/04/2011 07:05 PM, Junio C Hamano wrote:
> Michael Schubert <mschub@elegosoft.com> writes:
>
>> On 09/25/2011 12:42 PM, Michael Schubert wrote:
>>> 'git reflog <ref>' is a valid command, therefore offer reference
>>> completion.
>>>
>>> Signed-off-by: Michael Schubert <mschub@elegosoft.com>
>>> ---
>>> contrib/completion/git-completion.bash | 2 +-
>>> 1 files changed, 1 insertions(+), 1 deletions(-)
>>>
>>> diff --git a/contrib/completion/git-completion.bash b/contrib/completion/git-completion.bash
>>> index 8648a36..63d0f08 100755
>>> --- a/contrib/completion/git-completion.bash
>>> +++ b/contrib/completion/git-completion.bash
>>> @@ -1774,7 +1774,7 @@ _git_reflog ()
>>> local subcommand="$(__git_find_on_cmdline "$subcommands")"
>>>
>>> if [ -z "$subcommand" ]; then
>>> - __gitcomp "$subcommands"
>>> + __gitcomp "$subcommands $(__git_refs)"
>>> else
>>> __gitcomp "$(__git_refs)"
>>> fi
>>
>> Ping.?
>
> Personally I think this change will give much less pleasant user
> experience. This is what I currently get:
>
> $ git reflog <TAB>
> delete expire show
> $ git reflog
>
> and after learning the "show" subcommand exists, this is what I would get:
>
> $ git reflog show <TAB>
> Display all 626 possibilities? (y or n)
>
> With your change, I would get:
>
> $ git reflog <TAB>
> Display all 629 possibilities? (y or n)
Yeah, that would be a tradeoff. IMHO the current behaviour is pleasant
for newcomers, but (I guess) most users would rather enjoy "the short form".
> and do not even have a chance to remind myself if the subcommand to drop
> a reflog was "delete" or "remove".
>
> At least when I know that I want to be reminded of refs to $verb (use one
> of the three subcommands I currently get in place of the "$verb"), I can
> say
>
> $ git reflog $verb <TAB>
>
> and at that point, I am willing to wade thru list of 600+ refs.
^ permalink raw reply
* [PATCH 1/4] enter_repo: do not modify input
From: Phil Hord @ 2011-10-04 20:02 UTC (permalink / raw)
To: git, Erik Faye-Lund
From: Erik Faye-Lund <kusmabite@gmail.com>
entr_repo(..., 0) currently modifies the input to strip away
trailing slashes. This means that we some times need to copy the
input to keep the original.
Change it to unconditionally copy it into the used_path buffer so
we can safely use the input without having to copy it. Also store
a working copy in validated_path up-front before we start
resolving anything.
Signed-off-by: Erik Faye-Lund <kusmabite@gmail.com>
Signed-off-by: Phil Hord <hordp@cisco.com>
---
This is Erik Faye-Lund's patch with some minor cleanup by me. I sent
this to the list earlier today for Erik, but I'm including it here
again as part of this series. Not sure what the etiquette is on this,
but this way seemed safest.
diff --git a/cache.h b/cache.h
index 9994a3c..7eeb8cf 100644
--- a/cache.h
+++ b/cache.h
@@ -734,7 +734,7 @@ int safe_create_leading_directories(char *path);
int safe_create_leading_directories_const(const char *path);
int mkdir_in_gitdir(const char *path);
extern char *expand_user_path(const char *path);
-char *enter_repo(char *path, int strict);
+const char *enter_repo(const char *path, int strict);
static inline int is_absolute_path(const char *path)
{
return is_dir_sep(path[0]) || has_dos_drive_prefix(path);
diff --git a/daemon.c b/daemon.c
index 4c8346d..9253192 100644
--- a/daemon.c
+++ b/daemon.c
@@ -108,11 +108,11 @@ static void NORETURN daemon_die(const char *err,
va_list params)
exit(1);
}
-static char *path_ok(char *directory)
+static const char *path_ok(char *directory)
{
static char rpath[PATH_MAX];
static char interp_path[PATH_MAX];
- char *path;
+ const char *path;
char *dir;
dir = directory;
diff --git a/path.c b/path.c
index 6f3f5d5..01028f2 100644
--- a/path.c
+++ b/path.c
@@ -283,7 +283,7 @@ return_null:
* links. User relative paths are also returned as they are given,
* except DWIM suffixing.
*/
-char *enter_repo(char *path, int strict)
+const char *enter_repo(const char *path, int strict)
{
static char used_path[PATH_MAX];
static char validated_path[PATH_MAX];
@@ -297,14 +297,16 @@ char *enter_repo(char *path, int strict)
};
int len = strlen(path);
int i;
- while ((1 < len) && (path[len-1] == '/')) {
- path[len-1] = 0;
+ while ((1 < len) && (path[len-1] == '/'))
len--;
- }
+
if (PATH_MAX <= len)
return NULL;
- if (path[0] == '~') {
- char *newpath = expand_user_path(path);
+ strncpy(used_path, path, len); used_path[len] = 0 ;
+ strcpy(validated_path, used_path);
+
+ if (used_path[0] == '~') {
+ char *newpath = expand_user_path(used_path);
if (!newpath || (PATH_MAX - 10 < strlen(newpath))) {
free(newpath);
return NULL;
@@ -316,24 +318,18 @@ char *enter_repo(char *path, int strict)
* anyway.
*/
strcpy(used_path, newpath); free(newpath);
- strcpy(validated_path, path);
- path = used_path;
}
else if (PATH_MAX - 10 < len)
return NULL;
- else {
- path = strcpy(used_path, path);
- strcpy(validated_path, path);
- }
- len = strlen(path);
+ len = strlen(used_path);
for (i = 0; suffix[i]; i++) {
- strcpy(path + len, suffix[i]);
- if (!access(path, F_OK)) {
+ strcpy(used_path + len, suffix[i]);
+ if (!access(used_path, F_OK)) {
strcat(validated_path, suffix[i]);
break;
}
}
- if (!suffix[i] || chdir(path))
+ if (!suffix[i] || chdir(used_path))
return NULL;
path = validated_path;
}
--
1.7.7.503.g26392.dirty
^ permalink raw reply related
* [PATCH 2/4] Learn to handle gitfiles in enter_repo
From: Phil Hord @ 2011-10-04 20:05 UTC (permalink / raw)
To: git, Erik Faye-Lund
The enter_repo() function is used to navigate into a .git
directory. It knows how to find standard alternatives (DWIM) but
it doesn't handle gitfiles created by git init --separate-git-dir.
This means that git-fetch and others do not work with repositories
using the separate-git-dir mechanism.
Teach enter_repo() to deal with the gitfile mechanism by resolving
the path to the redirected path and continuing tests on that path
instead of the found file.
Signed-off-by: Phil Hord <hordp@cisco.com>
---
This change allows enter_repo to work with gitfiles, but another change
is required to teach transport.c to recognize gitfiles as git-dirs.
diff --git a/path.c b/path.c
index 01028f2..b6f71d1 100644
--- a/path.c
+++ b/path.c
@@ -295,6 +295,7 @@ const char *enter_repo(const char *path, int strict)
static const char *suffix[] = {
".git/.git", "/.git", ".git", "", NULL,
};
+ const char *gitfile;
int len = strlen(path);
int i;
while ((1 < len) && (path[len-1] == '/'))
@@ -329,7 +330,12 @@ const char *enter_repo(const char *path, int strict)
break;
}
}
- if (!suffix[i] || chdir(used_path))
+ if (!suffix[i])
+ return NULL;
+ gitfile = read_gitfile(used_path) ;
+ if (gitfile)
+ strcpy(used_path, gitfile);
+ if (chdir(used_path))
return NULL;
path = validated_path;
}
--
1.7.7.503.g26392.dirty
^ permalink raw reply related
* [PATCH v3] gitk: Teach gitk to respect log.showroot
From: Marcus Karlsson @ 2011-10-04 20:08 UTC (permalink / raw)
To: paulus; +Cc: zbyszek, gitster, git
In early days, all projects managed by git (except for git itself) had the
product of a fairly mature development history in their first commit, and
it was deemed unnecessary clutter to show additions of these thousands of
paths as a patch.
"git log" learned to show the patch for the initial commit without requiring
--root command line option at 0f03ca9 (config option log.showroot to show
the diff of root commits, 2006-11-23).
Teach gitk to respect log.showroot.
Signed-off-by: Marcus Karlsson <mk@acc.umu.se>
---
Improved the commit message after suggestion from Zbigniew
Jedrzejewski-Szmek.
gitk-git/gitk | 13 +++++++++++--
1 files changed, 11 insertions(+), 2 deletions(-)
diff --git a/gitk-git/gitk b/gitk-git/gitk
index 4cde0c4..40ea73f 100755
--- a/gitk-git/gitk
+++ b/gitk-git/gitk
@@ -7402,7 +7402,7 @@ proc addtocflist {ids} {
}
proc diffcmd {ids flags} {
- global nullid nullid2
+ global log_showroot nullid nullid2
set i [lsearch -exact $ids $nullid]
set j [lsearch -exact $ids $nullid2]
@@ -7436,7 +7436,11 @@ proc diffcmd {ids flags} {
lappend cmd HEAD
}
} else {
- set cmd [concat | git diff-tree -r $flags $ids]
+ set cmd [concat | git diff-tree -r]
+ if {$log_showroot eq true} {
+ set cmd [concat $cmd --root]
+ }
+ set cmd [concat $cmd $flags $ids]
}
return $cmd
}
@@ -11403,6 +11407,11 @@ catch {
}
}
+set log_showroot true
+catch {
+ set log_showroot [exec git config --get log.showroot]
+}
+
if {[tk windowingsystem] eq "aqua"} {
set mainfont {{Lucida Grande} 9}
set textfont {Monaco 9}
--
1.7.7
^ permalink raw reply related
* [PATCH 3/4] Teach transport about the gitfile mechanism
From: Phil Hord @ 2011-10-04 20:08 UTC (permalink / raw)
To: git, Erik Faye-Lund
The transport_get() function assumes that a regular file is a
bundle rather than a local git directory. Look inside the file
for the telltale "gitlink: " header to see if it is actually a
gitfile. If so, do not try to process it as a bundle, but
treat it as a local repository instead.
Signed-off-by: Phil Hord <hordp@cisco.com>
diff --git a/transport.c b/transport.c
index cd49a25..f7017c1 100644
--- a/transport.c
+++ b/transport.c
@@ -867,6 +867,28 @@ static int is_local(const char *url)
has_dos_drive_prefix(url);
}
+static int is_gitfile(const char *url)
+{
+ struct stat st;
+ char buf[9];
+ int fd, len;
+ if (stat(url, &st))
+ return 0;
+ if (!S_ISREG(st.st_mode))
+ return 0;
+ if (st.st_size < 10 || st.st_size > PATH_MAX)
+ return 1;
+
+ fd = open(url, O_RDONLY);
+ if (fd < 0)
+ die_errno("Error opening '%s'", url);
+ len = read_in_full(fd, buf, sizeof(buf));
+ close(fd);
+ if (len != sizeof(buf))
+ die("Error reading %s", url);
+ return !prefixcmp(buf, "gitdir: ");
+}
+
static int is_file(const char *url)
{
struct stat buf;
@@ -915,7 +937,7 @@ struct transport *transport_get(struct remote
*remote, const char *url)
ret->fetch = fetch_objs_via_rsync;
ret->push = rsync_transport_push;
ret->smart_options = NULL;
- } else if (is_local(url) && is_file(url)) {
+ } else if (is_local(url) && is_file(url) && !is_gitfile(url)) {
struct bundle_transport_data *data = xcalloc(1, sizeof(*data));
ret->data = data;
ret->get_refs_list = get_refs_from_bundle;
--
1.7.7.503.g26392.dirty
^ permalink raw reply related
* Re: [PATCH] contrib: add a pair of credential helpers for Mac OS X's keychain
From: Jay Soffian @ 2011-10-04 20:09 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Jeff King, git, John Szakmeister, Kyle Neath
In-Reply-To: <7vy5x0bmjk.fsf@alter.siamese.dyndns.org>
On Tue, Oct 4, 2011 at 3:10 PM, Junio C Hamano <gitster@pobox.com> wrote:
>
> Hmm, don't we first want to enumerate contexts where we might want to get
> the access information from the user? E.g.
>
> * "transport" aka "git fetch/push"; I think you meant this by --type=network,
> but there probably are other kinds of accesses over "network".
> * "imap-send".
> * "send-email".
> * "tag -s" and perhaps upcoming "push --signed" or "commit --gpg-sign"?
>
> Anything else?
Perhaps it would be illustrative to look at the OS X keychain API call
for adding a password to the store:
OSStatus SecKeychainAddInternetPassword (
SecKeychainRef keychain,
UInt32 serverNameLength,
const char *serverName,
UInt32 securityDomainLength,
const char *securityDomain,
UInt32 accountNameLength,
const char *accountName,
UInt32 pathLength,
const char *path,
UInt16 port,
SecProtocolType protocol,
SecAuthenticationType authenticationType,
UInt32 passwordLength,
const void *passwordData,
SecKeychainItemRef *itemRef
);
SecProtocolType is an enum of 4-char values such as 'ftp ', 'http',
etc. Similarly for SecAuthenticationType which uses values such as
'form' (web form), 'http' (basic auth), etc.
http://developer.apple.com/library/mac/#documentation/Security/Reference/keychainservices/Reference/reference.html#//apple_ref/doc/c_ref/SecKeychainAddInternetPassword
http://developer.apple.com/library/mac/#documentation/Security/Reference/keychainservices/Reference/reference.html#//apple_ref/doc/c_ref/SecProtocolType
http://developer.apple.com/library/mac/#documentation/Security/Reference/keychainservices/Reference/reference.html#//apple_ref/doc/c_ref/SecAuthenticationType
j.
^ permalink raw reply
* [PATCH 4/4] Add test showing git-fetch groks gitfiles
From: Phil Hord @ 2011-10-04 20:09 UTC (permalink / raw)
To: git, Erik Faye-Lund
Add a test for two subtly different cases: 'git fetch path/.git'
and 'git fetch path' to confirm that transport recognizes both
paths as git repositories when using the gitfile mechanism.
Signed-off-by: Phil Hord <hordp@cisco.com>
diff --git a/t/t5601-clone.sh b/t/t5601-clone.sh
index e810314..87ee016 100755
--- a/t/t5601-clone.sh
+++ b/t/t5601-clone.sh
@@ -206,6 +206,20 @@ test_expect_success 'clone from .git file' '
git clone dst/.git dst2
'
+test_expect_success 'fetch from .git gitfile' '
+ (
+ cd dst2 &&
+ git fetch ../dst/.git
+ )
+'
+
+test_expect_success 'fetch from gitfile parent' '
+ (
+ cd dst2 &&
+ git fetch ../dst
+ )
+'
+
test_expect_success 'clone separate gitdir where target already exists' '
rm -rf dst &&
test_must_fail git clone --separate-git-dir realgitdir src dst
--
1.7.7.503.g26392.dirty
^ permalink raw reply related
* Re: [PATCH] log --children
From: Michael J Gruber @ 2011-10-04 20:12 UTC (permalink / raw)
To: Jay Soffian; +Cc: git, Junio C Hamano
In-Reply-To: <1317736923-20539-1-git-send-email-jaysoffian@gmail.com>
Jay Soffian venit, vidit, dixit 04.10.2011 16:02:
> Teach git-log to support --children, which was added by f35f5603f4
> to the revision machinery, and by 72276a3ecb to rev-list, but
> was never added to git-log.
>
> Signed-off-by: Jay Soffian <jaysoffian@gmail.com>
> ---
> log-tree.c | 12 ++++++++++++
> 1 files changed, 12 insertions(+), 0 deletions(-)
>
> diff --git a/log-tree.c b/log-tree.c
> index 24c295ea1d..e7694a3a4c 100644
> --- a/log-tree.c
> +++ b/log-tree.c
> @@ -165,6 +165,14 @@ static void show_parents(struct commit *commit, int abbrev)
> }
> }
>
> +static void show_children(struct rev_info *opt, struct commit *commit, int abbrev)
> +{
> + struct commit_list *p = lookup_decoration(&opt->children, &commit->object);
> + for ( ; p; p = p->next) {
> + printf(" %s", find_unique_abbrev(p->item->object.sha1, abbrev));
> + }
> +}
> +
> void show_decorations(struct rev_info *opt, struct commit *commit)
> {
> const char *prefix;
> @@ -414,6 +422,8 @@ void show_log(struct rev_info *opt)
> fputs(find_unique_abbrev(commit->object.sha1, abbrev_commit), stdout);
> if (opt->print_parents)
> show_parents(commit, abbrev_commit);
> + if (opt->children.name)
> + show_children(opt, commit, abbrev_commit);
That means that "log --children --parents" will print out the parents'
sha1s, then the children's. Is that a good default format, or should we
somehow deal with the case when both are specified?
> show_decorations(opt, commit);
> if (opt->graph && !graph_is_commit_finished(opt->graph)) {
> putchar('\n');
> @@ -473,6 +483,8 @@ void show_log(struct rev_info *opt)
> stdout);
> if (opt->print_parents)
> show_parents(commit, abbrev_commit);
> + if (opt->children.name)
> + show_children(opt, commit, abbrev_commit);
> if (parent)
> printf(" (from %s)",
> find_unique_abbrev(parent->object.sha1,
And I guess we would like to test this...
Michael
^ 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