* Re: Failure using webdav basic auth by git client
From: Jeff King @ 2012-11-11 18:28 UTC (permalink / raw)
To: Jason Pyeron; +Cc: 'Pyeron, Jason J CTR (US)', git
In-Reply-To: <121F1C4AA6A845229D3DF5808B4F0F9E@black>
On Sun, Nov 11, 2012 at 01:09:02PM -0500, Jason Pyeron wrote:
> > My google fu has failed me on this issue. I am trying to setup http(s)
> > repositories for git. If I require authenticated users then git asks
> > for a username and password for the first volley of communications, but
> > then does not include the Authorization header on subsequent requests.
> [...]
> > > GET /git/test/info/refs?service=git-receive-pack HTTP/1.1
> > User-Agent: git/1.7.9
Can you try with a more recent git version? There were some bugs with
on-demand http auth when using the dumb protocol (which I see you are
using). They were fixed in v1.7.10.2 and higher.
Also, consider setting up the smart-http protocol, as it is way more
efficient.
-Peff
^ permalink raw reply
* Re: RFD: fast-import is picky with author names (and maybe it should - but how much so?)
From: Felipe Contreras @ 2012-11-11 18:48 UTC (permalink / raw)
To: Jeff King; +Cc: A Large Angry SCM, Michael J Gruber, Git Mailing List
In-Reply-To: <20121111181406.GA21654@sigill.intra.peff.net>
On Sun, Nov 11, 2012 at 7:14 PM, Jeff King <peff@peff.net> wrote:
> On Sun, Nov 11, 2012 at 06:45:32PM +0100, Felipe Contreras wrote:
>
>> > If there is a standard filter, then what is the advantage in doing it as
>> > a pipe? Why not just teach fast-import the same trick (and possibly make
>> > it optional)? That would be simpler, more efficient, and it would make
>> > it easier for remote helpers to turn it on (they use a command-line
>> > switch rather than setting up an extra process).
>>
>> Right, but instead of a command-line switch it probably should be
>> enabled on the stream:
>>
>> feature clean-authors
>>
>> Or something.
>
> Yeah, I was thinking it would need a feature switch to the remote helper
> to turn on the command-line, but I forgot that fast-import can take
> feature lines directly.
>
>> > We can clean up and normalize
>> > things like whitespace (and we probably should if we do not do so
>> > already). But beyond that, we have no context about the name; only the
>> > exporter has that.
>>
>> There is no context.
>
> There may not be a lot, but there is some:
>
>> These are exactly the same questions every exporter must answer. And
>> there's no answer, because the field is not a git author, it's a
>> mercurial user, or a bazaar committer, or who knows what.
>
> The exporter knows that the field is a mercurial user (or whatever).
> Fast-import does not even know that, and cannot apply any rules or
> heuristics about the format of a mercurial user string, what is common
> in the mercurial world, etc. It may not be a lot of context in some
> cases (I do not know anything about mercurial's formats, so I can't say
> what knowledge is available). But at least the exporter has a chance at
> domain-specific interpretation of the string. Fast-import has no chance,
> because it does not know the domain.
>
> I've snipped the rest of your argument, which is basically that
> mercurial does not have any context at all, and knowing that it is a
> mercurial author is useless. I am not sure that is true; even knowing
> that it is a free-form field versus something structured (e.g., we know
> CVS authors are usernames on the server server) is useful.
It is useful in the sense that we know we cannot do anything sensible
about it. All we can do is try.
> But I would agree there are probably multiple systems that are like
> mercurial in that the author field is usually something like "name
> <email>", but may be arbitrary text (I assume bzr is the same way, but
> you would know better than me). So it may make sense to have some stock
> algorithm to try to convert arbitrary almost-name-and-email text into
> name and email to reduce duplication between exporters, but:
Yes, bazaar seems to be the same way.
% bzr log
------------------------------------------------------------
revno: 1
committer: Foo Bar<foo.bar@example.com> <none@none
branch nick: bzr
timestamp: Sun 2012-11-11 19:41:10 +0100
message:
one
> 1. It must be turned on explicitly by the exporter, since we do not
> want to munge more structured input from clueful exporters.
Agreed.
> 2. The exporter should only turn it on after replacing its own munging
> (e.g., it shouldn't be adding junk like <none@none>; fast-import
> would need to receive as pristine an input as possible).
Agreed.
> 3. Exporters should not use it if they have any broken-down
> representation at all. Even knowing that the first half is a human
> name and the second half is something else would give it a better
> shot at cleaning than fast-import would get.
I'm not sure what you mean by this. If they have name and email, then
sure, it's easy.
And for the record, I've have encountered this problem also with
monotone. There's quite a lot of strategies to convert names to git
authors.
Cheers.
--
Felipe Contreras
^ permalink raw reply
* Re: [PATCH 0/5] ignore SIGINT while editor runs
From: Krzysztof Mazur @ 2012-11-11 19:15 UTC (permalink / raw)
To: Jeff King; +Cc: Kalle Olavi Niemitalo, Paul Fox, git
In-Reply-To: <20121111163100.GB13188@sigill.intra.peff.net>
On Sun, Nov 11, 2012 at 11:31:00AM -0500, Jeff King wrote:
>
> Here's a series that I think should resolve the situation for everybody.
>
> [1/5]: launch_editor: refactor to use start/finish_command
>
> The cleanup I sent out a few minutes ago.
>
> [2/5]: launch_editor: ignore SIGINT while the editor has control
>
> Paul's patch rebased on my 1/5.
>
> [3/5]: run-command: drop silent_exec_failure arg from wait_or_whine
> [4/5]: run-command: do not warn about child death by SIGINT
> [5/5]: launch_editor: propagate SIGINT from editor to git
>
> Act more like current git when the editor dies from SIGINT.
>
Looks ok, but what about SIGQUIT? Some editors like GNU ed (0.4 and 1.6)
ignore SIGQUIT, and after SIGQUIT git dies, but editor is still running.
After pressing any key ed receives -EIO and prints "stdin: Input/output
error". GNU ed 1.6 then exits, but ed 0.4 prints this error forever.
Maybe git should kill the editor in such case?
Krzysiek
^ permalink raw reply
* Re: [PATCH 5/5] launch_editor: propagate SIGINT from editor to git
From: Johannes Sixt @ 2012-11-11 19:48 UTC (permalink / raw)
To: Jeff King; +Cc: Kalle Olavi Niemitalo, Paul Fox, git
In-Reply-To: <20121111165706.GE19850@sigill.intra.peff.net>
Am 11.11.2012 17:57, schrieb Jeff King:
> @@ -51,6 +51,8 @@ int launch_editor(const char *path, struct strbuf *buffer, const char *const *en
> sigchain_push(SIGINT, SIG_IGN);
> ret = finish_command(&p);
> sigchain_pop(SIGINT);
> + if (WIFSIGNALED(ret) && WTERMSIG(ret) == SIGINT)
> + raise(SIGINT);
The return value of finish_command() is already a digested version of
waitpid's status value. According to
Documentation/technical/api-run-command.txt:
. If the program terminated due to a signal, then the return value is
the signal number - 128, ...
the correct condition would be
if (ret == SIGINT - 128)
-- Hannes
^ permalink raw reply
* Re: Test failures in contrib/remote-helpers
From: Felipe Contreras @ 2012-11-11 19:50 UTC (permalink / raw)
To: Ramkumar Ramachandra; +Cc: Git List
In-Reply-To: <CALkWK0k9trxx8NC1GWw-yYzBKhFchrvg2JLeBtyoAkokmv9A0w@mail.gmail.com>
On Sun, Nov 11, 2012 at 1:48 PM, Ramkumar Ramachandra
<artagnon@gmail.com> wrote:
> Felipe Contreras wrote:
>> On Sun, Nov 11, 2012 at 11:32 AM, Ramkumar Ramachandra
>> <artagnon@gmail.com> wrote:
>>> I'm experiencing test failures in contrib/remote-helpers.
>>
>> Which are your versions of hg, and bzr?
>
> Mercurial Distributed SCM (version 1.9.1)
I can reproduce the issue, this fixes it for versions up to 1.8:
--- a/contrib/remote-helpers/git-remote-hg
+++ b/contrib/remote-helpers/git-remote-hg
@@ -294,7 +294,7 @@ def export_ref(repo, name, kind, head):
if tip and tip == head.rev():
# nothing to do
return
- revs = repo.revs('%u:%u' % (tip, head))
+ revs = xrange(tip, head.rev() + 1)
count = 0
revs = [rev for rev in revs if not marks.is_marked(rev)]
I don't think it makes sense to aim anything lower.
--
Felipe Contreras
^ permalink raw reply
* Re: [PATCH 0/5] ignore SIGINT while editor runs
From: Paul Fox @ 2012-11-11 20:24 UTC (permalink / raw)
To: Krzysztof Mazur; +Cc: Jeff King, Kalle Olavi Niemitalo, git
In-Reply-To: <20121111191520.GA9474@shrek.podlesie.net>
krzysztof wrote:
> On Sun, Nov 11, 2012 at 11:31:00AM -0500, Jeff King wrote:
> >
> > Here's a series that I think should resolve the situation for everybody.
> >
> > [1/5]: launch_editor: refactor to use start/finish_command
> >
> > The cleanup I sent out a few minutes ago.
> >
> > [2/5]: launch_editor: ignore SIGINT while the editor has control
> >
> > Paul's patch rebased on my 1/5.
> >
> > [3/5]: run-command: drop silent_exec_failure arg from wait_or_whine
> > [4/5]: run-command: do not warn about child death by SIGINT
> > [5/5]: launch_editor: propagate SIGINT from editor to git
> >
> > Act more like current git when the editor dies from SIGINT.
> >
>
> Looks ok, but what about SIGQUIT? Some editors like GNU ed (0.4 and 1.6)
> ignore SIGQUIT, and after SIGQUIT git dies, but editor is still running.
> After pressing any key ed receives -EIO and prints "stdin: Input/output
> error". GNU ed 1.6 then exits, but ed 0.4 prints this error forever.
> Maybe git should kill the editor in such case?
there's certainly lots of precedent for treating SIGINT and SIGQUIT
the same. but there's also some merit to saying that if the user
knows to send SIGQUIT instead of SIGINT, they may well have a reason.
(after all, if we always treat them the same, there's no point in
having both.)
the em editor (linus' microemacs) behaves as you describe ed 0.4 does,
except without the error message -- it just spins silently getting EIO
from reading stdin. i think em needs to be fixed, and it sounds like
GNU ed already has been. (unless i misunderstand the relationship of
0.4 and 1.6.)
paul
>
> Krzysiek
> --
> 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
=---------------------
paul fox, pgf@foxharp.boston.ma.us (arlington, ma, where it's 57.2 degrees)
^ permalink raw reply
* Re: [PATCH 0/5] ignore SIGINT while editor runs
From: Krzysztof Mazur @ 2012-11-11 20:43 UTC (permalink / raw)
To: Paul Fox; +Cc: Jeff King, Kalle Olavi Niemitalo, git
In-Reply-To: <20121111202419.7602E2E8B6A@grass.foxharp.boston.ma.us>
On Sun, Nov 11, 2012 at 03:24:19PM -0500, Paul Fox wrote:
> krzysztof wrote:
> > Looks ok, but what about SIGQUIT? Some editors like GNU ed (0.4 and 1.6)
> > ignore SIGQUIT, and after SIGQUIT git dies, but editor is still running.
> > After pressing any key ed receives -EIO and prints "stdin: Input/output
> > error". GNU ed 1.6 then exits, but ed 0.4 prints this error forever.
> > Maybe git should kill the editor in such case?
>
> there's certainly lots of precedent for treating SIGINT and SIGQUIT
> the same. but there's also some merit to saying that if the user
> knows to send SIGQUIT instead of SIGINT, they may well have a reason.
> (after all, if we always treat them the same, there's no point in
> having both.)
That's why I'm proposing in case of SIGQUIT just killing the editor
(SIGTERM is sufficient for ed).
So git will ignore SIGINT, but die on SIGQUIT (and kill editor
that ignores SIGQUIT).
>
> the em editor (linus' microemacs) behaves as you describe ed 0.4 does,
> except without the error message -- it just spins silently getting EIO
> from reading stdin. i think em needs to be fixed, and it sounds like
> GNU ed already has been. (unless i misunderstand the relationship of
> 0.4 and 1.6.)
Yes, the version 1.6 is fixed, it just prints an error once and exits.
Krzysiek
^ permalink raw reply
* Re: [PATCH v5 11/15] remote-testgit: make clear the 'done' feature
From: Max Horn @ 2012-11-11 20:49 UTC (permalink / raw)
To: Felipe Contreras
Cc: git, Junio C Hamano, Johannes Schindelin, Jeff King,
Sverre Rabbelier, Brandon Casey, Brandon Casey, Jonathan Nieder,
Ilari Liusvaara, Pete Wyckoff, Ben Walton, Matthieu Moy,
Julian Phillips
In-Reply-To: <1352642392-28387-12-git-send-email-felipe.contreras@gmail.com>
On 11.11.2012, at 14:59, Felipe Contreras wrote:
> People seeking for reference would find it useful.
Hm, I don't understand this commit message. Probably means I am just too dumb, but since I am one of those people who would likely be seeking for reference, I would really appreciate if it could clarified. Like, for example, I don't see how the patch below makes anything "clear", it just seems to change the "import" command of git-remote-testgit to make use of the 'done' feature?
Perhaps the idea of the patch is to make use of the "done" feature so that remote-testgit acts as "reference implementation"? If that is the intention, then perhaps this could be used as commit message:
remote-testgit: make use of the 'done' feature
This might be helpful for people who would like to see how to properly
implement the "done" feature.
But again, I am not sure if I understood the purpose of this patch correctly. So please forgive me if this was totally off-base :-(.
Cheers,
Max
>
> Signed-off-by: Felipe Contreras <felipe.contreras@gmail.com>
> ---
> git-remote-testgit | 4 +++-
> 1 file changed, 3 insertions(+), 1 deletion(-)
>
> diff --git a/git-remote-testgit b/git-remote-testgit
> index 698effc..812321e 100755
> --- a/git-remote-testgit
> +++ b/git-remote-testgit
> @@ -55,8 +55,10 @@ while read line; do
>
> echo "feature import-marks=$gitmarks"
> echo "feature export-marks=$gitmarks"
> - git fast-export --use-done-feature --{import,export}-marks="$testgitmarks" $refs | \
> + echo "feature done"
> + git fast-export --{import,export}-marks="$testgitmarks" $refs | \
> sed -e "s#refs/heads/#${prefix}/heads/#g"
> + echo "done"
> ;;
> export)
> before=$(git for-each-ref --format='%(refname) %(objectname)')
> --
> 1.8.0
>
> --
> 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
>
^ permalink raw reply
* Re: [PATCH v5 02/15] remote-testgit: fix direction of marks
From: Max Horn @ 2012-11-11 20:39 UTC (permalink / raw)
To: Felipe Contreras
Cc: git, Junio C Hamano, Johannes Schindelin, Jeff King,
Sverre Rabbelier, Brandon Casey, Brandon Casey, Jonathan Nieder,
Ilari Liusvaara, Pete Wyckoff, Ben Walton, Matthieu Moy,
Julian Phillips
In-Reply-To: <1352642392-28387-3-git-send-email-felipe.contreras@gmail.com>
On 11.11.2012, at 14:59, Felipe Contreras wrote:
> Basically this is what we want:
>
> == pull ==
>
> testgit transport-helper
>
> * export -> import
>
> # testgit.marks git.marks
>
> == push ==
>
> testgit transport-helper
>
> * import <- export
>
> # testgit.marks git.marks
>
> Each side should be agnostic of the other side. Because testgit.marks
> (our helper marks) could be anything, not necesarily a format parsable
Typo: necesarily => necessarily
Cheers,
Max
^ permalink raw reply
* Re: [PATCH v5 05/15] Add new simplified git-remote-testgit
From: Max Horn @ 2012-11-11 20:40 UTC (permalink / raw)
To: Felipe Contreras
Cc: git, Junio C Hamano, Johannes Schindelin, Jeff King,
Sverre Rabbelier, Brandon Casey, Brandon Casey, Jonathan Nieder,
Ilari Liusvaara, Pete Wyckoff, Ben Walton, Matthieu Moy,
Julian Phillips
In-Reply-To: <1352642392-28387-6-git-send-email-felipe.contreras@gmail.com>
On 11.11.2012, at 14:59, Felipe Contreras wrote:
> It's way simpler. It exerceises the same features of remote helpers.
Typo: exerceises => exercises
Cheers,
Max
^ permalink raw reply
* Re: [PATCH v5 14/15] fast-export: make sure updated refs get updated
From: Max Horn @ 2012-11-11 20:43 UTC (permalink / raw)
To: Felipe Contreras
Cc: git, Junio C Hamano, Johannes Schindelin, Jeff King,
Sverre Rabbelier, Brandon Casey, Brandon Casey, Jonathan Nieder,
Ilari Liusvaara, Pete Wyckoff, Ben Walton, Matthieu Moy,
Julian Phillips
In-Reply-To: <1352642392-28387-15-git-send-email-felipe.contreras@gmail.com>
On 11.11.2012, at 14:59, Felipe Contreras wrote:
> When an object has already been exported (and thus is in the marks) it's
> flagged as SHOWN, so it will not be exported again, even if in a later
> time it's exported through a different ref.
>
> We don't need the object to be exported again, but we want the ref
> updated, which doesn't happen.
>
> Since we can't know if a ref was exported or not, let's just assume that
> if the commit was marked (flags & SHOWN), the user still wants the ref
> updated.
>
> IOW: If it's specified in the command line, it will get updated,
> regardless of wihether or not the object was marked.
Typo: wihether => whether
>
> So:
>
> % git branch test master
> % git fast-export $mark_flags master
> % git fast-export $mark_flags test
>
> Would export 'test' properly.
>
> Additionally, this fixes issues with remote helpers; now they can push
> refs wich objects have already been exported, and a few other issues as
Typo: wich => which
Cheers,
Max
^ permalink raw reply
* Re: Reviews on mailing-list
From: David Lang @ 2012-11-11 21:15 UTC (permalink / raw)
To: Krzysztof Mazur
Cc: Thiago Farina, Felipe Contreras, Deniz Türkoglu, git,
Junio C Hamano, Shawn Pearce
In-Reply-To: <20121111171451.GA26695@shrek.podlesie.net>
On Sun, 11 Nov 2012, Krzysztof Mazur wrote:
> On Sun, Nov 11, 2012 at 11:09:36AM -0200, Thiago Farina wrote:
>> On Sun, Nov 11, 2012 at 10:14 AM, Felipe Contreras
>> <felipe.contreras@gmail.com> wrote:
>>> Requiring everyone to use a web browser would limit the amount of ways
>>> people can review patches.
>> I don't see that as a limitation as I think everyone has access to a
>> web browser these days, don't have?
>
> Almost everyone, but not everyone likes using web browser.
Using a web browser requires connectivity at the time you are doing the review.
Mailing list based reviews can be done at times when you don't have
connectivity.
Coincidently, one of the common times when people don't have connectivity is
when they are traveling, and this can be a good time to do things like code
review.
David Lang
^ permalink raw reply
* Re: [PATCH v5 11/15] remote-testgit: make clear the 'done' feature
From: Felipe Contreras @ 2012-11-11 21:22 UTC (permalink / raw)
To: Max Horn
Cc: git, Junio C Hamano, Johannes Schindelin, Jeff King,
Sverre Rabbelier, Brandon Casey, Brandon Casey, Jonathan Nieder,
Ilari Liusvaara, Pete Wyckoff, Ben Walton, Matthieu Moy,
Julian Phillips
In-Reply-To: <29291552-880A-4FEB-88E0-A73A1C7742F7@quendi.de>
On Sun, Nov 11, 2012 at 9:49 PM, Max Horn <max@quendi.de> wrote:
>
> On 11.11.2012, at 14:59, Felipe Contreras wrote:
>
>> People seeking for reference would find it useful.
>
> Hm, I don't understand this commit message. Probably means I am j git fast-export --use-done-featureust too dumb, but since I am one of those people who would likely be seeking for reference, I would really appreciate if it could clarified. Like, for example, I don't see how the patch below makes anything "clear", it just seems to change the "import" command of git-remote-testgit to make use of the 'done' feature?
No, the done feature was there already, but not so visible: git
fast-export --use-done-feature <-there. Which is the problem, it's too
easy to miss, therefore the need to make it clear.
> Perhaps the idea of the patch is to make use of the "done" feature so that remote-testgit acts as "reference implementation"? If that is the intention, then perhaps this could be used as commit message:
It's already there.
> remote-testgit: make use of the 'done' feature
>
> This might be helpful for people who would like to see how to properly
> implement the "done" feature.
Everybody should implement the 'done' feature. Otherwise random error
messages quite easily appear.
--
Felipe Contreras
^ permalink raw reply
* Re: [PATCH 0/5] ignore SIGINT while editor runs
From: Andreas Schwab @ 2012-11-11 22:08 UTC (permalink / raw)
To: Krzysztof Mazur; +Cc: Paul Fox, Jeff King, Kalle Olavi Niemitalo, git
In-Reply-To: <20121111204305.GA20599@shrek.podlesie.net>
Krzysztof Mazur <krzysiek@podlesie.net> writes:
> That's why I'm proposing in case of SIGQUIT just killing the editor
> (SIGTERM is sufficient for ed).
>
> So git will ignore SIGINT, but die on SIGQUIT (and kill editor
> that ignores SIGQUIT).
system(3) also ignores SIGQUIT.
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: [PATCH v5 00/14] New remote-hg helper
From: Chris Webb @ 2012-11-11 22:17 UTC (permalink / raw)
To: Felipe Contreras
Cc: git, Junio C Hamano, Sverre Rabbelier, Johannes Schindelin,
Ilari Liusvaara, Daniel Barkalow, Jeff King, Michael J Gruber
In-Reply-To: <CAMP44s1-VOetN+e49UgJtpbpwYN2EBVYBzw5j_KoqXu6sbbaHA@mail.gmail.com>
Felipe Contreras <felipe.contreras@gmail.com> writes:
> Implemented now. I'm not handling the 'tip' revision, but most likely
> it's also the '.' revision. In this case a fake 'master' bookmark will
> be created to track that revision.
Hi Felipe. Sorry for the slow response, I've been snowed under with work and
have only just got around to testing your latest version.
The new remote-hg.track-branches=false option is great and does exactly what
I was hoping for. For the benefit of the list archives, one natural way to
use it is
git clone -c remote-hg.track-branches=false hg::foo
when cloning the relevant repositories, if you don't want the setting
globally for every hg-remote clone.
During testing, I've seen some strange behaviour which I think is caused by
using the . revision instead of tip:
$ hg init h
$ hg init h2
$ ( cd h && touch foo && hg add foo && hg commit -m foo && hg push ../h2 )
pushing to ../h2
searching for changes
adding changesets
adding manifests
adding file changes
added 1 changesets with 1 changes to 1 files
$ git clone hg::h g
Cloning into 'g'...
$ git clone hg::h2 g2
Cloning into 'g2'...
warning: remote HEAD refers to nonexistent ref, unable to checkout.
$
The reason for this is that by default . == null (not tip) in the repo h2
which we pushed into from h. The hg equivalent of a bare repo typically has a
null checkout like this. (Actually, the checkout of HEAD seems to break
whenever . is different from tip, not just when it's null as in this example.)
Apart from this, everything seems solid and works well. Really useful; thanks!
Best wishes,
Chris.
^ permalink raw reply
* [PATCH] git p4: handle servers without move support
From: Pete Wyckoff @ 2012-11-11 22:52 UTC (permalink / raw)
To: Vitor Antunes; +Cc: ggibbons, Git Mailing List
In-Reply-To: <CAOpHH-VRhOHqeROfjeLBQxqft23VemJZntGNJ-y7CX0A8N3q1A@mail.gmail.com>
Support for the "p4 move" command was added in 8e9497c (git p4:
add support for 'p4 move' in P4Submit, 2012-07-12), which checks
to make sure the client and server support the command.
But older versions of p4d may not handle the "-k" argument, and
newer p4d allow disabling "p4 move" with a configurable. Check
for both these cases by testing a p4 move command on bogus
filenames and looking for strings in the error messages.
Signed-off-by: Pete Wyckoff <pw@padd.com>
---
vitor.hda@gmail.com wrote on Wed, 07 Nov 2012 21:06 +0000:
> On Mon, Nov 5, 2012 at 5:57 PM, Pete Wyckoff <pw@padd.com> wrote:
> > vitor.hda@gmail.com wrote on Mon, 05 Nov 2012 17:37 +0000:
> >> Hi Pete,
> >>
> >> I've just been hit by a situation where this command is available but is
> >> disabled in the server. I don't know what is the best approach to avoid
> >> this issue.
> >
> > Really? The command exists in the server because it returns the
> > text output for "p4 help move". But "p4 move" itself fails
> > because it is somehow disabled in the server?
> >
> > I didn't even know it was possible to administratively disable
> > commands.
> >
> > What's the actual error message? And versions of your client and
> > server (p4 -V, p4d -V, p4 info).
> >
> > Any ideas Gary?
>
> I don't feel comfortable in testing this again because I'm working in a
> production server. Can Gary provide any details on this type of
> configuration on the server side?
Gary explained how to administratively disable "p4 move". This
patch checks for that condition, and "p4 move -k", which is
missing in p4d 2009.1.
I'm not super happy with it, due to the string-searching in the
error messages. But I can't think of a better way: if "p4 move
-k src dest" returns 1, is it because the server doesn't support
it? arguments were wrong? printer on fire?
Vitor, can you test that it works for you? It's probably worth
putting in the code just so no one else finds the same mysterious
failure.
-- Pete
git-p4.py | 21 ++++++++++++++++++++-
t/t9814-git-p4-rename.sh | 35 +++++++++++++++++++++++++++++++++++
2 files changed, 55 insertions(+), 1 deletion(-)
diff --git a/git-p4.py b/git-p4.py
index 882b1bb..417a66a 100755
--- a/git-p4.py
+++ b/git-p4.py
@@ -129,6 +129,25 @@ def p4_has_command(cmd):
p.communicate()
return p.returncode == 0
+def p4_has_move_command():
+ """See if the move command exists, that it supports -k, and that
+ it has not been administratively disabled. The arguments
+ must be correct, but the filenames do not have to exist. Use
+ ones with wildcards so even if they exist, it will fail."""
+
+ if not p4_has_command("move"):
+ return False
+ cmd = p4_build_cmd(["move", "-k", "@from", "@to"])
+ p = subprocess.Popen(cmd, stdout=subprocess.PIPE, stderr=subprocess.PIPE)
+ (out, err) = p.communicate()
+ # return code will be 1 in either case
+ if err.find("Invalid option") >= 0:
+ return False
+ if err.find("disabled") >= 0:
+ return False
+ # assume it failed because @... was invalid changelist
+ return True
+
def system(cmd):
expand = isinstance(cmd,basestring)
if verbose:
@@ -871,7 +890,7 @@ class P4Submit(Command, P4UserMap):
self.conflict_behavior = None
self.isWindows = (platform.system() == "Windows")
self.exportLabels = False
- self.p4HasMoveCommand = p4_has_command("move")
+ self.p4HasMoveCommand = p4_has_move_command()
def check(self):
if len(p4CmdList("opened ...")) > 0:
diff --git a/t/t9814-git-p4-rename.sh b/t/t9814-git-p4-rename.sh
index 3bf1224..be802e0 100755
--- a/t/t9814-git-p4-rename.sh
+++ b/t/t9814-git-p4-rename.sh
@@ -199,6 +199,41 @@ test_expect_success 'detect copies' '
)
'
+# See if configurables can be set, and in particular if the run.move.allow
+# variable exists, which allows admins to disable the "p4 move" command.
+test_expect_success 'p4 configure command and run.move.allow are available' '
+ p4 configure show run.move.allow >out ; retval=$? &&
+ test $retval = 0 &&
+ {
+ egrep ^run.move.allow: out &&
+ test_set_prereq P4D_HAVE_CONFIGURABLE_RUN_MOVE_ALLOW ||
+ true
+ } || true
+'
+
+# If move can be disabled, turn it off and test p4 move handling
+test_expect_success P4D_HAVE_CONFIGURABLE_RUN_MOVE_ALLOW \
+ 'do not use p4 move when administratively disabled' '
+ test_when_finished "p4 configure set run.move.allow=1" &&
+ p4 configure set run.move.allow=0 &&
+ (
+ cd "$cli" &&
+ echo move-disallow-file >move-disallow-file &&
+ p4 add move-disallow-file &&
+ p4 submit -d "add move-disallow-file"
+ ) &&
+ test_when_finished cleanup_git &&
+ git p4 clone --dest="$git" //depot &&
+ (
+ cd "$git" &&
+ git config git-p4.skipSubmitEdit true &&
+ git config git-p4.detectRenames true &&
+ git mv move-disallow-file move-disallow-file-moved &&
+ git commit -m "move move-disallow-file" &&
+ git p4 submit
+ )
+'
+
test_expect_success 'kill p4d' '
kill_p4d
'
--
1.7.12.1.457.g468b3ef
^ permalink raw reply related
* [RFC PATCH 0/1] status: Allow for short-form output by default
From: Thomas Adam @ 2012-11-11 22:53 UTC (permalink / raw)
To: git; +Cc: Thomas Adam
Hi,
It was asked recently whether git status could output the short-form instead
of the long output (via its "-sb" options). To that end, I've created a
rough POC on how this might look. It's deliberately lacking documentation;
I was curious to know whether:
status.shortwithbranch = true
Was going to cut it. Likewise, I was unsure if instead there should be two
separate options, one for just short (i.e. '-s') also?
What do others think?
ISTR reading on this list recently the addition of a "--long" option to git
status? I'm wondering how this would relate to that, if at all?
Kindly,
Thomas Adam (1):
status: Allow for short-form via config option
builtin/commit.c | 12 ++++++++++++
1 file changed, 12 insertions(+)
--
1.7.11.4
^ permalink raw reply
* [RFC PATCH 1/1] status: Allow for short-form via config option
From: Thomas Adam @ 2012-11-11 22:53 UTC (permalink / raw)
To: git; +Cc: Thomas Adam
In-Reply-To: <1352674383-23654-1-git-send-email-thomas@xteddy.org>
It is currently not possible to use the short-form output of git status
without declaring an alias to do so.
This isn't always desirable therfore, define a git config option which can
be set to display the short-form: status.shortwithbranch
Signed-off-by: Thomas Adam <thomas@xteddy.org>
---
builtin/commit.c | 12 ++++++++++++
1 file changed, 12 insertions(+)
diff --git a/builtin/commit.c b/builtin/commit.c
index a17a5df..552a9f1 100644
--- a/builtin/commit.c
+++ b/builtin/commit.c
@@ -1142,6 +1142,18 @@ static int git_status_config(const char *k, const char *v, void *cb)
return error(_("Invalid untracked files mode '%s'"), v);
return 0;
}
+
+ if (!strcmp(k, "status.shortwithbranch")) {
+ if (git_config_bool(k, v)) {
+ if (!v)
+ return config_error_nonbool(k);
+ else if(!strcmp(v, "true")) {
+ status_format = STATUS_FORMAT_SHORT;
+ s->show_branch = 1;
+ }
+ return 0;
+ }
+ }
return git_diff_ui_config(k, v, NULL);
}
--
1.7.11.4
^ permalink raw reply related
* Re: Re: [PATCH] git tag --contains : avoid stack overflow
From: Johannes Schindelin @ 2012-11-11 23:10 UTC (permalink / raw)
To: Jeff King
Cc: René Scharfe, Jean-Jacques Lafay, msysgit, Git List,
Philip Oakley
In-Reply-To: <20121111165431.GA25884@sigill.intra.peff.net>
Hi,
On Sun, 11 Nov 2012, Jeff King wrote:
> On Sun, Nov 11, 2012 at 05:46:32PM +0100, René Scharfe wrote:
>
> > >However, I couldn't reproduce it on Linux : where the windows
> > >implementations crashes at a ~32000 depth (*not* exactly 32768, mind
> > >you), on linux it happily went through 100000 commits. I didn't take
> > >time to look much further, but maybe on my 64 bit Linux VM, the
> > >process can afford to reserve a much bigger address range for the
> > >stack of each thread than the 1Mb given to 32 bit processes on
> > >windows. Jean-Jacques.
> >
> > I can reproduce it on Linux (Debian testing amd64) with ulimit -s 1000
> > to reduce the stack size from its default value of 8MB.
> >
> > After reverting ffc4b8012d9a4f92ef238ff72c0d15e9e1b402ed (tag: speed
> > up --contains calculation) the test passes even with the smaller
> > stack, but it makes "git tag --contains" take thrice the time as
> > before.
>
> Right, I am not too surprised. That function replaced the original
> algorithm with a much faster depth-first recursive one. I haven't looked
> closely yet at Jean-Jacques' iterative adaptation, but that direction
> seems like a good fix for now.
>
> Ultimately, I have some ideas for doing this in a breadth-first way,
> which would make it more naturally iterative. It would involve having N
> bits of storage per commit to check N tags, but it would mean that we
> could get accurate answers in the face of clock skew (like the
> merge-base calculation, it would merely get slower in the face of skew).
>
> But since I haven't worked on that at all, fixing the depth-first
> algorithm to be iterative makes sense to me.
Have you tried the latest tag-contains branch of
git://github.com/msysgit/git/? It contains a couple of brush-ups and a
re-write of the recursion (which I hope is right, I had only time to work
on it during an unwanted layover at O'Hare). The SHA-1 is
fc4f42787a0dd0022d202627681362081a66ef70.
Ciao,
Johannes
--
*** Please reply-to-all at all times ***
*** (do not pretend to know who is subscribed and who is not) ***
*** Please avoid top-posting. ***
The msysGit Wiki is here: https://github.com/msysgit/msysgit/wiki - Github accounts are free.
You received this message because you are subscribed to the Google
Groups "msysGit" group.
To post to this group, send email to msysgit@googlegroups.com
To unsubscribe from this group, send email to
msysgit+unsubscribe@googlegroups.com
For more options, and view previous threads, visit this group at
http://groups.google.com/group/msysgit?hl=en_US?hl=en
^ permalink raw reply
* [BUG] gitweb: XSS vulnerability of RSS feed
From: glpk xypron @ 2012-11-11 23:28 UTC (permalink / raw)
To: git
Gitweb can be used to generate an RSS feed.
Arbitrary tags can be inserted into the XML document describing
the RSS feed by careful construction of the URL.
Example
http://server/?p=project.git&a=rss&f=</title><script>alert(document.cookie)</script><title>
The generated XML contains
<script>alert(document.cookie)</script>
Depending on the system used to render the XML this might lead
to the execution of javascript in the security context of the
gitweb server pages.
Please, escape all URL parameters.
Version tested:
gitweb v.1.8.0.dirty with git 1.7.2.5
Best regards
Heinrich Schuchardt
^ permalink raw reply
* [PATCH] Update cygwin.c for new mingw-64 win32 api headers
From: Mark Levedahl @ 2012-11-12 0:17 UTC (permalink / raw)
To: git; +Cc: Mark Levedahl
The cygwin project recently switched to a new implementation of the
windows api, now using header files from the mingw-64 project. These
new header files are incompatible with the way cygwin.c included the
old headers: cygwin.c can be compiled using the new or the older (mingw)
headers, but different files must be included in different order for each
to work. The new headers are in use only for the current release series
(based upon the v1.7.x dll version). The previous release series using
the v1.5 dll is kept available but unmaintained for use on older versions
of Windows. So, patch cygwin.c to use the new include ordering only if
the dll version is 1.7 or higher.
Signed-off-by: Mark Levedahl <mlevedahl@gmail.com>
---
Makefile | 4 ++++
compat/cygwin.c | 7 +++++++
2 files changed, 11 insertions(+)
diff --git a/Makefile b/Makefile
index f69979e..1cc5d96 100644
--- a/Makefile
+++ b/Makefile
@@ -1082,6 +1082,7 @@ ifeq ($(uname_O),Cygwin)
NO_SYMLINK_HEAD = YesPlease
NO_IPV6 = YesPlease
OLD_ICONV = UnfortunatelyYes
+ V15_MINGW_HEADERS = YesPlease
endif
NO_THREAD_SAFE_PREAD = YesPlease
NEEDS_LIBICONV = YesPlease
@@ -1889,6 +1890,9 @@ ifdef NO_REGEX
COMPAT_CFLAGS += -Icompat/regex
COMPAT_OBJS += compat/regex/regex.o
endif
+ifdef V15_MINGW_HEADERS
+ COMPAT_CFLAGS += -DV15_MINGW_HEADERS
+endif
ifdef USE_NED_ALLOCATOR
COMPAT_CFLAGS += -Icompat/nedmalloc
diff --git a/compat/cygwin.c b/compat/cygwin.c
index dfe9b30..59d86e4 100644
--- a/compat/cygwin.c
+++ b/compat/cygwin.c
@@ -1,6 +1,13 @@
#define WIN32_LEAN_AND_MEAN
+#ifdef V15_MINGW_HEADERS
#include "../git-compat-util.h"
#include "win32.h"
+#else
+#include <sys/stat.h>
+#include <sys/errno.h>
+#include "win32.h"
+#include "../git-compat-util.h"
+#endif
#include "../cache.h" /* to read configuration */
static inline void filetime_to_timespec(const FILETIME *ft, struct timespec *ts)
--
1.8.0.0.0.14
^ permalink raw reply related
* Re: Reviews on mailing-list
From: Deniz Türkoglu @ 2012-11-12 0:35 UTC (permalink / raw)
To: David Lang
Cc: Krzysztof Mazur, Thiago Farina, Felipe Contreras, git,
Junio C Hamano, Shawn Pearce
In-Reply-To: <alpine.DEB.2.02.1211111313140.19687@nftneq.ynat.uz>
I understand from the feedback that gerrit should get better on making
it possible to review code via e-mail, as pointed out in Nguyen's
mail, a flow like Shawn mentioned[1] can be a good solution.
FWIW, I can fetch the change(s) from gerrit I am interested in and
review it any time I want. I currently have many checked out topics I
am working on for instance.
[1] http://thread.gmane.org/gmane.comp.version-control.git/102887/focus=102901
cheers,
-deniz
^ permalink raw reply
* Re: Reviews on mailing-list
From: David Lang @ 2012-11-12 0:43 UTC (permalink / raw)
To: Deniz Türkoglu
Cc: Krzysztof Mazur, Thiago Farina, Felipe Contreras, git,
Junio C Hamano, Shawn Pearce
In-Reply-To: <CA+ZXwZMh=ON4g32nRHD5cMTX1c7ohhqhXHUNdh57BMvSHG0cYA@mail.gmail.com>
[-- Attachment #1: Type: TEXT/PLAIN, Size: 656 bytes --]
On Sun, 11 Nov 2012, Deniz Türkoglu wrote:
> I understand from the feedback that gerrit should get better on making
> it possible to review code via e-mail, as pointed out in Nguyen's
> mail, a flow like Shawn mentioned[1] can be a good solution.
>
> FWIW, I can fetch the change(s) from gerrit I am interested in and
> review it any time I want. I currently have many checked out topics I
> am working on for instance.
That requires that you know before you loose connectivity what changes you want
to review.
With e-mail based reviews, you just pull copies of all your mail and it includes
any pending reviews along with everything else.
David Lang
^ permalink raw reply
* Re: Bizarre problem cloning repo from Codeplex
From: Enrico Weigelt @ 2012-11-12 0:59 UTC (permalink / raw)
To: Andreas Schwab; +Cc: Jeremy Morton, git
In-Reply-To: <m2k3tteb2k.fsf@igel.home>
> > Their webserver seems to be configured quite restrictively
> > (eg. cannot access files like 'packed-refs').
>
> Probably it just doesn't exist.
Aren' these files requied ?
cu
--
Mit freundlichen Grüßen / Kind regards
Enrico Weigelt
VNC - Virtual Network Consult GmbH
Head Of Development
Pariser Platz 4a, D-10117 Berlin
Tel.: +49 (30) 3464615-20
Fax: +49 (30) 3464615-59
enrico.weigelt@vnc.biz; www.vnc.de
^ permalink raw reply
* Thanking the interim maintainer
From: Junio C Hamano @ 2012-11-12 3:12 UTC (permalink / raw)
To: peff; +Cc: git
I am physically back but still am far from catching up with the list
traffic (yet). After skimming my inbox, it appears that you have
done a magnificent job keeping track of topics in flight and merging
low-risk fixes early to the 'master' branch.
I am hoping that I can ask you to do another issue of "What's
cooking" (or two) while I catch up with the traffic, to collect all
worthy patches that are already published on the list ;-). After
that, let us arrange for me to pick up the tips of topic branches
you have and take it over (just telling me to run "log --oneline
master..pu" might be sufficient if there is no "tentatively ejected"
topic).
Thanks.
^ 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