* 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: 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
* 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: 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
* [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: 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
* 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: 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: 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: 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: 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: 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: 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
* [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: 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
* 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
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