* 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
* Re: pack-object poor performance (with large number of objects?)
From: Jeff King @ 2011-10-04 11:07 UTC (permalink / raw)
To: Piotr Krukowiecki
Cc: Junio C Hamano, Shawn Pearce, Git Mailing List, Ingo Molnar
In-Reply-To: <CAA01CsoSTsBLNcbv5o6Jx6YrjG4g8T=yodX811ymBLXg7sjDJQ@mail.gmail.com>
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.
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?
-Peff
^ permalink raw reply
* Re: [BUG?] git fetch -p -t prunes all non-tag refs
From: Carlos Martín Nieto @ 2011-10-04 11:06 UTC (permalink / raw)
To: Jeff King; +Cc: Junio C Hamano, mathstuf, git
In-Reply-To: <20111004103624.GA11863@sigill.intra.peff.net>
[-- Attachment #1: Type: text/plain, Size: 2466 bytes --]
On Tue, 2011-10-04 at 06:36 -0400, Jeff King wrote:
> On Tue, Oct 04, 2011 at 12:33:22PM +0200, Carlos Martín Nieto wrote:
>
> > > The latter. If I say:
> > >
> > > git fetch --prune origin refs/heads/master:refs/remotes/origin/master
> > >
> > > and refs/heads/master doesn't exist on the remote, I would expect
> > > refs/remotes/origin/master to be deleted locally. And that naturally
> > > extends to:
> > >
> > > git fetch --prune origin refs/heads/*:refs/remotes/origin/*
> >
> > I have some code locally that solves this second part. If we are given
> > refspecs on the command-line, it will try to match against that instead
> > of blindly trusting what get_stale_heads tells us. I'm looking into
> > putting the logic into get_stale_heads so that we can trust it.
> >
> > The first part might be more complicated. If the remote head doesn't
> > exist, get_fetch_map dies. It does take a missing_ok flag, so it might
> > be as easy as passing 1 there; but I'm not sure what that would do for a
> > non-prune fetch.
>
> Let's not worry about the first one for now, then. It is a natural
> extension of the other, but in practice, I don't expect people to really
> care that much about auto-pruning one specific ref. Instead, they want
> to prune wildcards. So as long as it works in the wildcard case, that is
> a good start.
I'm going to add the logic to do specific-ref-prunning because it's just
adding a strcmp to an if (I may yet be proven wrong, mind) and if that
works, we can use it later. get_stale_heads is going to gain a couple of
arguments so it can inspect the user-given refspecs. It should now be a
simple matter of adding a check to see if the refspec's dst matches the
refname (it's a simple matter once you've spent five hours trying to
understand what the fetch code does).
>
> > > # backup to a repository where our objects will be shared
> > > # with other related backups. So we must only use our slice of the
> > > # ref namespace.
> > > git push --mirror backup-repo +refs/*:refs/`hostname`/*
> >
> > Is --mirror needed there? I would have thought that
> > refs/*:refs/`hostname`/* would do the same by itself.
>
> I wanted it to auto-prune the remote branches. So if I delete
> "refs/heads/foo" locally, then it will be deleted from the backup on the
> next push. Regular "push" will not do that, but --mirror will.
OK, gotcha.
cmn
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 490 bytes --]
^ permalink raw reply
* Re: Git ksshaskpass to play nice with https and kwallet
From: Jeff King @ 2011-10-04 10:50 UTC (permalink / raw)
To: Michael J Gruber; +Cc: Git Mailing List
In-Reply-To: <4E8ADDCF.6090406@drmicha.warpmail.net>
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.
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).
-Peff
^ permalink raw reply
* Award Number: HL-001655NL
From: Dr.Mary Simon @ 2011-10-04 10:33 UTC (permalink / raw)
You have won the sum of 550,000.00euros from LuckyDay lottery 2011 Year bonanza award.You are to contact him with your details below:
1.Ref Number:67218/501-4242/ES
2.Batch Number:612775428-SN
3.Ticket Number:194463-85
4.Award Number: HL-001655NL
1.Name........Address ....................3.Age...........4.Occupation.........5.Phone/Fax................
Contact Person:Mr David Moolman
Email: chaletspl@aim.com
Tel:+31-647-226-334
Fax:+31-84-731-7577
Congratulations once again.
Regards,
Dr.Mary Simon
^ permalink raw reply
* Re: [BUG?] git fetch -p -t prunes all non-tag refs
From: Jeff King @ 2011-10-04 10:36 UTC (permalink / raw)
To: Carlos Martín Nieto; +Cc: Junio C Hamano, mathstuf, git
In-Reply-To: <1317724404.2577.6.camel@bee.lab.cmartin.tk>
On Tue, Oct 04, 2011 at 12:33:22PM +0200, Carlos Martín Nieto wrote:
> > The latter. If I say:
> >
> > git fetch --prune origin refs/heads/master:refs/remotes/origin/master
> >
> > and refs/heads/master doesn't exist on the remote, I would expect
> > refs/remotes/origin/master to be deleted locally. And that naturally
> > extends to:
> >
> > git fetch --prune origin refs/heads/*:refs/remotes/origin/*
>
> I have some code locally that solves this second part. If we are given
> refspecs on the command-line, it will try to match against that instead
> of blindly trusting what get_stale_heads tells us. I'm looking into
> putting the logic into get_stale_heads so that we can trust it.
>
> The first part might be more complicated. If the remote head doesn't
> exist, get_fetch_map dies. It does take a missing_ok flag, so it might
> be as easy as passing 1 there; but I'm not sure what that would do for a
> non-prune fetch.
Let's not worry about the first one for now, then. It is a natural
extension of the other, but in practice, I don't expect people to really
care that much about auto-pruning one specific ref. Instead, they want
to prune wildcards. So as long as it works in the wildcard case, that is
a good start.
> > # backup to a repository where our objects will be shared
> > # with other related backups. So we must only use our slice of the
> > # ref namespace.
> > git push --mirror backup-repo +refs/*:refs/`hostname`/*
>
> Is --mirror needed there? I would have thought that
> refs/*:refs/`hostname`/* would do the same by itself.
I wanted it to auto-prune the remote branches. So if I delete
"refs/heads/foo" locally, then it will be deleted from the backup on the
next push. Regular "push" will not do that, but --mirror will.
-Peff
^ permalink raw reply
* Re: [BUG?] git fetch -p -t prunes all non-tag refs
From: Carlos Martín Nieto @ 2011-10-04 10:33 UTC (permalink / raw)
To: Jeff King; +Cc: Junio C Hamano, mathstuf, git
In-Reply-To: <20110927033134.GB8534@sigill.intra.peff.net>
[-- Attachment #1: Type: text/plain, Size: 2735 bytes --]
On Mon, 2011-09-26 at 23:31 -0400, Jeff King wrote:
> On Tue, Sep 27, 2011 at 01:28:09AM +0200, Carlos Martín Nieto wrote:
>
> > > term I think we should fix it properly. We are already learning "what are
> > > the refs the remote side currently has" from the transport and the right
> > > fix ought to be to use that original information, not the version filtered
> > > for the use of the primary objective of fetch, which is to only fetch what
> > > the user asked for.
> >
> > Do you mean that we should ignore the refspec? Or do you mean that we
> > should look at the refspec if it exists, and only consider deleting
> > those that meet the refspec, so that `--prune --tags` would only delete
> > tags that don't exist in the remote?
>
> The latter. If I say:
>
> git fetch --prune origin refs/heads/master:refs/remotes/origin/master
>
> and refs/heads/master doesn't exist on the remote, I would expect
> refs/remotes/origin/master to be deleted locally. And that naturally
> extends to:
>
> git fetch --prune origin refs/heads/*:refs/remotes/origin/*
I have some code locally that solves this second part. If we are given
refspecs on the command-line, it will try to match against that instead
of blindly trusting what get_stale_heads tells us. I'm looking into
putting the logic into get_stale_heads so that we can trust it.
The first part might be more complicated. If the remote head doesn't
exist, get_fetch_map dies. It does take a missing_ok flag, so it might
be as easy as passing 1 there; but I'm not sure what that would do for a
non-prune fetch.
>
> We do something similar with "git push --mirror", which does pruning
> like this[1].
>
> -Peff
>
> [1] Actually, I'm not sure how correct "push --mirror" is. It would be
> nice if the prune operation could be split from the mirror, too. In
> the past, I have wanted to do both:
>
> # backup to a repository where our objects will be shared
> # with other related backups. So we must only use our slice of the
> # ref namespace.
> git push --mirror backup-repo +refs/*:refs/`hostname`/*
Is --mirror needed there? I would have thought that
refs/*:refs/`hostname`/* would do the same by itself.
>
> and:
>
> # update topic branches we have already published (using the
> # "matching" refspec), but remove any that we have deleted
> # locally.
> git push --mirror publish-point +:
>
> and I don't think either works.
> --
> To unsubscribe from this list: send the line "unsubscribe git" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 490 bytes --]
^ permalink raw reply
* Re: [RFC/PATCH]: reverse bisect v 2.0
From: Jeff King @ 2011-10-04 10:30 UTC (permalink / raw)
To: Junio C Hamano
Cc: Michal Vyskocil, git, Sverre Rabbelier, Johannes Sixt,
Christian Couder
In-Reply-To: <7vfwjaggd2.fsf@alter.siamese.dyndns.org>
On Mon, Oct 03, 2011 at 10:00:25AM -0700, Junio C Hamano wrote:
> > I like this idea a lot. My "yes/no" thing was a "if I were designing
> > bisect from scratch today..." suggestion, but having something like
> > --used-to makes it a natural addition to the regular good/bad interface.
> > And I really like the prompt to help people remember what it is they're
> > declaring each time.
>
> I forgot to clarify that "tested" was only to help users who wanted
> reminder; if the user is confident with the usual "yes/no", the
> interactivity is not required.
That makes sense to me. I think in either case, it would be nice to
mention the --used-to text when we take each step. We're already
outputting some status information there (like how many commits left).
> > However, --used-to feels a bit backwards to me. I think of it as
> > "--has-property" or something similar.
>
> I do not think --used-to='frotz says xyzzy' is a good phrasing at all; it
> is grammatically incorrect. But --has-property has one large downside. At
> least --used-to makes it clear that the user is supposed to decribe the
> property of the tree in the past.
>
> Let's step back a bit to understand why I think this is not optimal.
What you say makes sense, but isn't it just a problem of the name? IOW,
a much better name than "--has-property" would be "--started-to". That
would imply the exact same cutoff as --used-to, but negate only the
yes/no bit.
So you could say:
# find a bug:
git bisect start --used-to='work with --foo=bar'
# or if you are looking for a specific undesirable behavior, you might
# write:
git bisect start --used-to='not segfault with --foo=bar'
# but now you have a negation in your condition. So it might be more
# natural to write it as:
git bisect start --started-to='segfault with --foo=bar'
# Or we can find a feature
git bisect start --used-to='not respect core.foo'
# but again, we have a negation. Instead:
git bisect start --started-to='respect core.foo'
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".
I know you wanted to emphasize the "older tree has this property" of
--used-to, but I think it is clear with --started-to that the older tree
obviously obviously had the negation of the property.
-Peff
^ permalink raw reply
* Re: Unable to remove a file
From: John Szakmeister @ 2011-10-04 10:24 UTC (permalink / raw)
To: Zbigniew Jędrzejewski-Szmek; +Cc: robert mena, Andreas Schwab, git
In-Reply-To: <4E8ABC85.7090705@in.waw.pl>
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
* Git ksshaskpass to play nice with https and kwallet
From: Michael J Gruber @ 2011-10-04 10:19 UTC (permalink / raw)
To: Git Mailing List
Checking out bitbucket and https, I came across a stupid issue between
the default KDE setup (SSH_ASKPASS=/usr/bin/ksshakspass and KDE wallet)
and the way we call the askpass helper, which makes the combo not work
out of the box.
For those interested in getting it to work (or learning why it does not
work out of the box), you can read the details formatted on my sparse
blog (brain dump)
http://grubix.blogspot.com/2011/10/git-ksshaskpass-to-play-nice-with-https.html
or below if you don't feel like clicking through.
Cheers
Michael
By default (with GIT_ASKPASS not set etc.), Git invokes $SSH_ASKPASS
when it needs to ask you for credential info. In a KDE environment,
SSH_ASKPASS is set to /usr/bin/ksshaskpass. So far so good.
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.
If you still want to use the KDE helpers, you can save the little snippet
#!/bin/bash
set $*
exec ksshaskpass $1\@$3
into ~/bin/git-ksshaskpass (and make it executable) and set
git config --global core.askpass ~/bin/git-ksshaskpass
Gitcha!
NB:
tested and works with https
not tested with other methods (use ssh-agent)
new credential helper interface coming in Git after 1.7.7
^ permalink raw reply
* Re: [PATCH] contrib: add a pair of credential helpers for Mac OS X's keychain
From: Jeff King @ 2011-10-04 10:16 UTC (permalink / raw)
To: Jay Soffian; +Cc: git, Junio C Hamano, John Szakmeister
In-Reply-To: <CAG+J_DxAaw=vVENFUP5Mq9+inuDEpn_3Le_b7sO97wRUW6aFSA@mail.gmail.com>
On Mon, Oct 03, 2011 at 09:13:12AM -0400, Jay Soffian wrote:
> > Yeah. I was thinking the ACL prompt would come up more often, but I
> > guess most people would hit "allow always", since it would get annoying
> > pretty quickly otherwise (I didn't, because I was testing).
>
> In the normal case, the keychain entry would be added via the
> credential helper, so they'd never even see the prompt since the
> binary which adds an entry is automatically on that entry's ACL.
Ah, that makes sense. That wasn't what happened for me; the first time I
ran it, before I had ever given it a password, it asked if it could
access the login keychain. But that was because I _already_ had an entry
there from the GitHub for Mac client.
So I assume it was typical that most users would see it at least that
first time. But it's probably not.
> > Side note: do you know how to edit those ACLs? I couldn't find it in the
> > keychain manager. It would be helpful for testing to be able to tweak it
> > (as a workaround, I just modified the binary, which apparently the
> > keychain code cares about).
>
> Double-click on the entry in Keychain Access, then click the "Access
> Control" tab.
Thanks. For some reason I was thinking the ACL was based on the
keychain, but of course having it per-entry makes much more sense. So I
was just looking in the wrong place.
-Peff
^ permalink raw reply
* Re: [PATCH] git-completion: offer references for 'git reflog'
From: Michael Schubert @ 2011-10-04 8:48 UTC (permalink / raw)
To: git; +Cc: Junio C Hamano
In-Reply-To: <4E7F05A6.30505@elegosoft.com>
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.?
^ permalink raw reply
* Re: [PATCH/RFC] remote: support --all for the prune-subcommand
From: Erik Faye-Lund @ 2011-10-04 8:22 UTC (permalink / raw)
To: Jeff King; +Cc: git
In-Reply-To: <20111004075608.GC7308@sigill.intra.peff.net>
On Tue, Oct 4, 2011 at 9:56 AM, Jeff King <peff@peff.net> wrote:
> On Tue, Oct 04, 2011 at 09:40:22AM +0200, Erik Faye-Lund wrote:
>> In fact, I'm not sure I understand why we simply do not always prune
>> by default.
>
> I think the original rationale was that we didn't want fetch to be
> "lossy". That is, if I were using upstream's "foo" branch as part of my
> work (to diff against, or whatever), then doing a "git fetch" to update
> should not suddenly make it hard to do my work. And not just hard as in
> "I notice that it's gone and I adapt my workflow". But that you no
> longer have _any_ record of where upstream's "foo" branch used to point,
> so even doing something like:
>
> git rebase --onto new-foo foo my-topic
>
> is impossible.
>
Following that logic, a user cannot _ever_ safely prune a remote if he
wants to work on some of the branches. Doing something like "git
remote foo -n" to check if the branch would get pruned before doing a
proper prune is prone to a race-condition; the branch could be deleted
on the remote between the dry-run and the actual pruning.
Besides, the owner of the repo can just as easily have deleted the
branch and created a new one with the same name, causing the contents
of the branch to be lost. This happens all the time with
"for-upstream"-kind of branches, no?
> These days we have reflogs, so you would hope to do something like:
>
> git rebase --onto new-foo foo@{1} my-topic
>
> But ref deletion also deletes the reflog completely, so that doesn't
> work.
>
...and this just makes the problem I pointed out above a lot worse.
So surely, the only sane thing is to make a local branch of what
you're interested in to be safe?
> The right solution, IMHO, is that ref deletion should actually keep the
> reflog around in a graveyard of some sort. Entries would expire
> naturally over time, as they do in regular reflogs. And then it becomes
> a lot safer to prune on every fetch, because you still have 90 days look
> at the reflog.
>
Fixing the reflog to expire for ref deletion rather than completely
deleting it sounds like a good move, indeed.
>> If a user wants to keep another user's branch, surely the most sane
>> thing would be to make a local branch of it?
>
> Unfortunately there are some management problems there. How do I keep my
> local branch up to date with what I fetch? I have to keep checking out
> and merging on every fetch (or use some plumbing), which is a pain. But
> if I don't, then when the upstream branch goes away, I still have no
> clue where its tip was right before it got pruned.
Hmm, good point. I tend to just do the dirty work every now and then
myself. But I only tend to track upstream and stale
development-branches that I intend to pick up, so I'm probably not the
best user-example.
While we're on the subject, an additional argument to change "git
fetch" to always prune is that it's much much easier for user to grok
"last known state of <remote>'s branches" than "the union of all the
branches that were ever pulled from <remote>, unless --prune was
specified". But that's not a technical one, and surely there's issues
to resolve with the proposal before going in that direction.
^ permalink raw reply
* Re: [PATCH] po/pl.po: Eliminate fuzzy translations
From: Zbigniew Jędrzejewski-Szmek @ 2011-10-04 8:23 UTC (permalink / raw)
To: Jakub Narebski
Cc: Ævar Arnfjörð Bjarmason, Git Mailing List,
Marcin Cieślak
In-Reply-To: <201110032337.09975.jnareb@gmail.com>
On 10/03/2011 11:37 PM, Jakub Narebski wrote:
+# Terminologia dla kluczowych terminów z Subversion:
+# path - ścieżka
+# URL - URL
+# file - plik
+# directory - katalog
+# update - aktualizacja
+# commit - zatwierdzenie, zatwierdzenie zmian
This seems kind of awkward. E.g. 'initial commit' would become
'początkowe zatwierdzenie zmian' or 'pierwsze zatwierdzenie', which just
doesn't sound right. What about starting with the mercurial term
'changeset'? Git users also use 'commit' to mean 'change', so maybe
the polish translation of this crucial term should be 'zmiana':
'initial commit' -- 'początkowa zmiana' or 'pierwsza zmiana'
'commit message' -- 'opis zmiany'
+# version control - zarządzanie wersjami
+# repository - repozytorium
+# branch - odgałęzienie
'gałąź'? I think that's the translation which is used in informal
conversations.
+# tag - tag
'metka', 'etykieta' according to the dictionary. I'm aware of 'metka'
being used in CS anywhere, but it is short, and pretty cool, IMO.
+# merge - łączenie zmian
'łączenie gałęzi'?
+# conflict - konflikt
+# property - atrybut
+# revision - wersja
+# log message - opis zmian
+# entry/item - element
+# ancestry - pochodzenie
+# ancestor - przodek
+# working copy - kopia robocza
+# working dir - bieżący katalog
+# usage - wykorzystanie
'użycie', 'wywołanie'?
E.g. 'standardowe wywołanie tego programu to: prog arg'
+# source - źródłowy
+# destination - docelowy
+# hook - skrypt (skrypt repozytorium)
+# exclude - wykluczyć
+# crop - obciąć
+# cache - pamięć podręczna
+# child - obiekt podrzędny
Standard CS term is 'ojciec' and 'syn' for 'parent/child'.
+# obliteration - obliteracja
'wymazanie'?
+# patch - łata
+# notes - adnotacja
Zbyszek
^ 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