* 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
* 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: [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: [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 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] 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] 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] 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] 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] 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: [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: [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] 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: 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: Unable to remove a file
From: Zbigniew Jędrzejewski-Szmek @ 2011-10-04 14:08 UTC (permalink / raw)
To: robert mena; +Cc: John Szakmeister, Andreas Schwab, git
In-Reply-To: <CAAZ43xZo8cyE_ASz1Hc4yYoUjmH1OnVogOj6mtqFzmAUSBptFw@mail.gmail.com>
On 10/04/2011 01:36 PM, robert mena wrote:
> Hi John,
>
> I understand that. For the other that have cloned the repository in
> the past (no one has committed anything locally) is there any special
> procedure to be performed or a simply git fetch/pull will make their
> local repositories in sync?
git fetch updates the remote references, always. If the remote is rebased,
as in this case, the only difference is that git fetch's message will be
a little bit different.
git pull cannot be used in this case! It would "merge" the old history
with the new rewritten history... One should do 'git fetch' and then
'git reset --hard origin/master' or something like that.
-
Zbyszek
> 2011/10/4 John Szakmeister<john@szakmeister.net>:
>> 2011/10/4 Zbigniew Jędrzejewski-Szmek<zbyszek@in.waw.pl>:
>> [snip]
>>>> git filter-branch --index-filter 'git rm -q --ignore-unmatch --cached
>>>> scripts/\\' HEAD
>>>> Rewrite 5ac83187fa298add60cf81fd1d54b194da7ae783 (57/57)
>>>> Ref 'refs/heads/master' was rewritten
>>>> git push
>>>> ! [rejected] master -> master (non-fast-forward)
>>>> error: failed to push some refs to 'git@myserver:repository'
>>>>
>>>> Should I do anything special?
>>>
>>> git push -f
>>
>> I assume you understand that you're rewriting history Robert, and that
>> has some consequences? You're master branch is now divergent, since
>> the commit ids changed.
>>
>> -John
>>
>
^ permalink raw reply
* [PATCH] log --children
From: Jay Soffian @ 2011-10-04 14:02 UTC (permalink / raw)
To: git; +Cc: Jay Soffian, Junio C Hamano
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);
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,
--
1.7.7.3.gaf8e
^ permalink raw reply related
* Re: pack-object poor performance (with large number of objects?)
From: Piotr Krukowiecki @ 2011-10-04 13:21 UTC (permalink / raw)
To: Jeff King; +Cc: Junio C Hamano, Shawn Pearce, Git Mailing List, Ingo Molnar
In-Reply-To: <20111004124502.GB30162@sigill.intra.peff.net>
On Tue, Oct 4, 2011 at 2:45 PM, Jeff King <peff@peff.net> wrote:
> On Tue, Oct 04, 2011 at 02:22:55PM +0200, Piotr Krukowiecki wrote:
>
>> > So my guess is that it is simply taking an enormous amount of disk
>> > space, and git is mostly waiting on the disk to read in files. What does
>> > "du -sh .git/objects" say?
>>
>> It isn't that big - it's 11G.
>> .git/objects/pack/ is 666MB currently.
>
> But you have 4G of RAM, no? So depending on the access patterns, you are
> thrashing your disk cache and always pulling each object straight from
> disk.
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
$ ps auxwwww | grep git
pkruk 13541 0.0 0.0 15704 716 pts/2 S+ 13:19 0:00 git
repack -a -d -f
pkruk 13542 0.0 0.0 4220 540 pts/2 S+ 13:19 0:00
/bin/sh /usr/local/stow/git-master/libexec/git-core/git-repack -a -d
-f
pkruk 13556 3.9 9.8 1143628 401232 pts/2 DN+ 13:19 4:25 git
pack-objects --keep-true-parents --honor-pack-keep --non-empty --all
--reflog --no-reuse-delta --delta-base-offset
/home/pkruk/dv/devel1_git_repos/.git/objects/pack/.tmp-13542-pack
I have updated to 1.7.7 btw.
--
Piotr Krukowiecki
^ permalink raw reply
* Re: pack-object poor performance (with large number of objects?)
From: Jeff King @ 2011-10-04 12:45 UTC (permalink / raw)
To: Piotr Krukowiecki
Cc: Junio C Hamano, Shawn Pearce, Git Mailing List, Ingo Molnar
In-Reply-To: <CAA01CsodyUQJOnj5vV0LdVEWpkvwSW2TAONzyY9J82o9VwC6Ag@mail.gmail.com>
On Tue, Oct 04, 2011 at 02:22:55PM +0200, Piotr Krukowiecki wrote:
> > So my guess is that it is simply taking an enormous amount of disk
> > space, and git is mostly waiting on the disk to read in files. What does
> > "du -sh .git/objects" say?
>
> It isn't that big - it's 11G.
> .git/objects/pack/ is 666MB currently.
But you have 4G of RAM, no? So depending on the access patterns, you are
thrashing your disk cache and always pulling each object straight from
disk.
-Peff
^ permalink raw reply
* Re: Git ksshaskpass to play nice with https and kwallet
From: Jeff King @ 2011-10-04 12:43 UTC (permalink / raw)
To: Michael J Gruber; +Cc: Git Mailing List
In-Reply-To: <4E8AF812.5090906@drmicha.warpmail.net>
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.
> > $ git push https://example.com/foo.git
> > Password for 'user@example.com':
> >
> > which is a nice reminder. And it would happen to work with your askpass
> > magic (I also wonder if it should mention the protocol and the repo, but
> > most of the time that isn't relevant, and it does make the prompt harder
> > to read).
>
> With the above, I can probably do without any magic: 'example.com' would
> be the wallet key for the username (if I let the wallet store it) and
> 'user@example.com' the key for the password, whether the username comes
> from the wallet or from the config. (Again, why not from the URL?)
Yeah, sorry, I should have said "ksshaskpass's magic". :)
And yes, it can come from the URL. Mentioning the user in the password
prompt is not as useful a reminder if it comes from:
$ git push https://user@example.com/foo.git
but, if it's something like:
$ git clone https://user@example.com/foo.git
[months pass]
$ git push
Password for 'user@example.com':
then it's a nice reminder.
-Peff
^ permalink raw reply
* Re: pack-object poor performance (with large number of objects?)
From: Piotr Krukowiecki @ 2011-10-04 12:22 UTC (permalink / raw)
To: Jeff King; +Cc: Junio C Hamano, Shawn Pearce, Git Mailing List, Ingo Molnar
In-Reply-To: <20111004110702.GA18599@sigill.intra.peff.net>
On Tue, Oct 4, 2011 at 1:07 PM, Jeff King <peff@peff.net> wrote:
> On Tue, Oct 04, 2011 at 09:59:08AM +0200, Piotr Krukowiecki wrote:
>
>> I've run the command and it took about 20 minutes in "Counting
>> objects" to count up to 500000 on idle machine and there's still 700MB
>> RAM free.
>> [...]
>> So it looks it's not a problem with git but rather with my disk/file
>> system/linux...
>
> You mentioned that git was in the 'D' state earlier. And it sounds like
> you have 1.7 million objects, _completely_ unpacked.
That's right - since I had auto-gc disabled at first it had not chance
to pack anything.
> So my guess is that it is simply taking an enormous amount of disk
> space, and git is mostly waiting on the disk to read in files. What does
> "du -sh .git/objects" say?
It isn't that big - it's 11G.
.git/objects/pack/ is 666MB currently.
--
Piotr Krukowiecki
^ permalink raw reply
* Re: Git ksshaskpass to play nice with https and kwallet
From: Michael J Gruber @ 2011-10-04 12:12 UTC (permalink / raw)
To: Jeff King; +Cc: Git Mailing List
In-Reply-To: <20111004113713.GA19171@sigill.intra.peff.net>
Jeff King venit, vidit, dixit 04.10.2011 13:37:
> On Tue, Oct 04, 2011 at 01:27:57PM +0200, Michael J Gruber wrote:
>
>> Still, ksshaskpass's trying to guess a unique key from the prompt text
>> seems quite hackish to me. But many people will have a Git without
>> credential-helpers, and a KDE default setup, so hope my post helps
>> someone besides myself.
>
> Hmm. I don't think that pre-credential-helper git actually puts the
> hostname in the prompt, though. It just says "Username:". So your trick
> wouldn't work then, would it?
>
>> Note that git-credentials-askpass would have a fair chance of doing
>> better: credential_askpass() knows the username and could pass it to
>> credential_ask_one(), e.g. by amending the description field, or setting
>> the first field to "Password for user %(user)". Do you think that would
>> be worth deviating from the default behavior (i.e. compared to no helper)?
>
> I think that git should do that by default. v1.7.7 (and earlier) does:
>
> $ git push https://example.com/foo.git
> Username:
> Password:
>
> With my patches in 'next', it does:
>
> $ git push https://example.com/foo.git
> Username for 'example.com':
> Password for 'example.com':
>
Sheesh. I'm too used to using next(+) to even think of that! You're
completely right: My trick only works with next's additions.
> But it would probably be better to say:
>
> $ git push https://example.com/foo.git
> Username for 'example.com':
> Password for 'user@example.com':
Yes, exactly. credential_askpass() knows what it needs for that.
> 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.
>
> $ git push https://example.com/foo.git
> Password for 'user@example.com':
>
> which is a nice reminder. And it would happen to work with your askpass
> magic (I also wonder if it should mention the protocol and the repo, but
> most of the time that isn't relevant, and it does make the prompt harder
> to read).
With the above, I can probably do without any magic: 'example.com' would
be the wallet key for the username (if I let the wallet store it) and
'user@example.com' the key for the password, whether the username comes
from the wallet or from the config. (Again, why not from the URL?)
Michael
^ permalink raw reply
* Re: Git ksshaskpass to play nice with https and kwallet
From: Jeff King @ 2011-10-04 11:37 UTC (permalink / raw)
To: Michael J Gruber; +Cc: Git Mailing List
In-Reply-To: <4E8AEDBD.4070404@drmicha.warpmail.net>
On Tue, Oct 04, 2011 at 01:27:57PM +0200, Michael J Gruber wrote:
> Still, ksshaskpass's trying to guess a unique key from the prompt text
> seems quite hackish to me. But many people will have a Git without
> credential-helpers, and a KDE default setup, so hope my post helps
> someone besides myself.
Hmm. I don't think that pre-credential-helper git actually puts the
hostname in the prompt, though. It just says "Username:". So your trick
wouldn't work then, would it?
> Note that git-credentials-askpass would have a fair chance of doing
> better: credential_askpass() knows the username and could pass it to
> credential_ask_one(), e.g. by amending the description field, or setting
> the first field to "Password for user %(user)". Do you think that would
> be worth deviating from the default behavior (i.e. compared to no helper)?
I think that git should do that by default. v1.7.7 (and earlier) does:
$ git push https://example.com/foo.git
Username:
Password:
With my patches in 'next', it does:
$ git push https://example.com/foo.git
Username for 'example.com':
Password for 'example.com':
But it would probably be better to say:
$ git push https://example.com/foo.git
Username for 'example.com':
Password for 'user@example.com':
The latter is especially useful if you have put a username in your
~/.gitconfig, in which case you get:
$ git push https://example.com/foo.git
Password for 'user@example.com':
which is a nice reminder. And it would happen to work with your askpass
magic (I also wonder if it should mention the protocol and the repo, but
most of the time that isn't relevant, and it does make the prompt harder
to read).
-Peff
^ permalink raw reply
* Re: Unable to remove a file
From: robert mena @ 2011-10-04 11:36 UTC (permalink / raw)
To: John Szakmeister; +Cc: Zbigniew Jędrzejewski-Szmek, Andreas Schwab, git
In-Reply-To: <CAEBDL5U4gU9C0De42Sgqv1ODLwQBuOdYdhfTBCMUziCZrhK9dA@mail.gmail.com>
Hi John,
I understand that. For the other that have cloned the repository in
the past (no one has committed anything locally) is there any special
procedure to be performed or a simply git fetch/pull will make their
local repositories in sync?
2011/10/4 John Szakmeister <john@szakmeister.net>:
> 2011/10/4 Zbigniew Jędrzejewski-Szmek <zbyszek@in.waw.pl>:
> [snip]
>>> git filter-branch --index-filter 'git rm -q --ignore-unmatch --cached
>>> scripts/\\' HEAD
>>> Rewrite 5ac83187fa298add60cf81fd1d54b194da7ae783 (57/57)
>>> Ref 'refs/heads/master' was rewritten
>>> git push
>>> ! [rejected] master -> master (non-fast-forward)
>>> error: failed to push some refs to 'git@myserver:repository'
>>>
>>> Should I do anything special?
>>
>> git push -f
>
> I assume you understand that you're rewriting history Robert, and that
> has some consequences? You're master branch is now divergent, since
> the commit ids changed.
>
> -John
>
^ permalink raw reply
* Re: Git ksshaskpass to play nice with https and kwallet
From: Michael J Gruber @ 2011-10-04 11:27 UTC (permalink / raw)
To: Jeff King; +Cc: Git Mailing List
In-Reply-To: <20111004105008.GA11789@sigill.intra.peff.net>
Jeff King venit, vidit, dixit 04.10.2011 12:50:
> On Tue, Oct 04, 2011 at 12:19:59PM +0200, Michael J Gruber wrote:
>
>> But Git calls the askpass helper with a command line like
>> /usr/bin/ksshaskpass Username for 'bitbucket.org':
>> and once again with
>> /usr/bin/ksshaskpass Password for 'bitbucket.org':
>> So far so good.
>>
>> But when asked to store the credentials in the KDE wallet, ksshaskpass
>> tries (too) hard to guess a good key from that line. And for both
>> invocations, it comes up with the same key (the URL), so that when the
>> password info is needed, the username info from the wallet is returned.
>> Authentication fails.
>> Far from good.
>
> Neat. I didn't know ksshaskpass would do that. I wondered for a minute
> if all of the credential helper stuff could have gone through the
> askpass interface. But I don't think so.
Don't worry ;)
> One problem is that the askpass interface only lets us ask for one thing
> at a time. So even with your clever hack, it will end up storing two
> separate keys: Username@host and Password@host. But it has no idea
> they're connected. So if you store "user1 / pass1", then try to push to
> "user2@host", we would silently use the password for user1.
>
> On top of that, there isn't much contextual information. I guess they
> assumed the guessing would be used for "ssh". But it means that a stored
> ssh password could potentially be used for git, and vice versa. I guess
> you could get around that by making the host field longer and more
> descriptive (i.e., a full url).
I think it's really meant for ssh keys only, where the keyid identifies
the key uniquely.
Still, ksshaskpass's trying to guess a unique key from the prompt text
seems quite hackish to me. But many people will have a Git without
credential-helpers, and a KDE default setup, so hope my post helps
someone besides myself.
Note that git-credentials-askpass would have a fair chance of doing
better: credential_askpass() knows the username and could pass it to
credential_ask_one(), e.g. by amending the description field, or setting
the first field to "Password for user %(user)". Do you think that would
be worth deviating from the default behavior (i.e. compared to no helper)?
Cheers,
Michael
^ permalink raw reply
* [PATCH] git-difftool: allow skipping file by typing 'n' at prompt
From: Sitaram Chamarty @ 2011-10-04 10:53 UTC (permalink / raw)
To: git, gitster
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.
git-difftool--helper.sh | 9 +++++----
1 files changed, 5 insertions(+), 4 deletions(-)
diff --git a/git-difftool--helper.sh b/git-difftool--helper.sh
index 8452890..bc1b098 100755
--- a/git-difftool--helper.sh
+++ b/git-difftool--helper.sh
@@ -38,15 +38,16 @@ launch_merge_tool () {
# $LOCAL and $REMOTE are temporary files so prompt
# the user with the real $MERGED name before launching $merge_tool.
+ ans=y
if should_prompt
then
printf "\nViewing: '$MERGED'\n"
if use_ext_cmd
then
- printf "Hit return to launch '%s': " \
+ printf "Launch '%s' [y]/n: " \
"$GIT_DIFFTOOL_EXTCMD"
else
- printf "Hit return to launch '%s': " "$merge_tool"
+ printf "Launch '%s' [y]/n: " "$merge_tool"
fi
read ans
fi
@@ -54,9 +55,9 @@ launch_merge_tool () {
if use_ext_cmd
then
export BASE
- eval $GIT_DIFFTOOL_EXTCMD '"$LOCAL"' '"$REMOTE"'
+ test "$ans" != "n" && eval $GIT_DIFFTOOL_EXTCMD '"$LOCAL"' '"$REMOTE"'
else
- run_merge_tool "$merge_tool"
+ test "$ans" != "n" && run_merge_tool "$merge_tool"
fi
}
--
1.7.6
^ 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