* git-p4: labels
From: Luke Diamand @ 2011-12-18 18:33 UTC (permalink / raw)
To: Git List; +Cc: Pete Wyckoff, Michael Horowitz, Vitor Antunes
I've been looking at fixing the --detect-labels flag in git-p4. I'm now
thinking that the current way it's done is just all wrong.
The current code has a few annoying bugs which I mostly have fixes for:
- it only works when there is no more than one label per changelist;
- if the count of files in the p4 label doesn't match the count of files
in the p4 changelist then the label gets dropped (by design);
- git-p4 rebase ignores --detect-labels
- it imports all the label/file mappings each time (I haven't fixed this
yet)
However, the thing that's more annoying is that it only imports labels
when importing the changelist they are pointing at.
So, for example, if you do something like this:
p4 edit; p4 submit
p4 tag TAG1
git-p4 rebase
p4 tag TAG2
git-p4 rebase
then TAG1 will be detected, but TAG2 won't.
This is a particular nuisance for me, as I just have git-p4 running all
the time eating commits, so there's no scope for a human to delay the
git-p4 and pickup the label.
I think what's needed is to do something completely different.
This is speculation at the moment, and I'd welcome comments before I
start hacking.
There will be a new _command_, import-labels. This command will find all
the labels that git knows about, and the labels that p4 knows about, and
then do the obvious diff. It will then create tags as needed directly
(i.e. not using fast-import).
It will unfortunately need to hunt through the revision history looking
for the git hash <h> that matches p4 changelist <c>. This could get
quite slow, although no worse than O(n).
Something like:
p4 edit; p4 submit
p4 tag TAG1
git-p4 rebase
git-p4 import-labels
p4 tag TAG2
git-p4 import-labels
I'm going to try to work up a patch with some test cases but in the
meantime if anyone thinks I've missed something, please let me know.
Thanks
Luke
^ permalink raw reply
* Re: [PATCHv3 02/11] git-p4: test debug macro
From: Luke Diamand @ 2011-12-18 17:10 UTC (permalink / raw)
To: Pete Wyckoff; +Cc: Jonathan Nieder, git
In-Reply-To: <20111218140633.GB16487@padd.com>
On 18/12/11 14:06, Pete Wyckoff wrote:
> Call this from a test to have it pause and wait for you to
> investigate. It prints out its current directory and the
> P4 environment variables. It waits for ctrl-c before continuing
> the test.
Looks good, ack.
>
> Signed-off-by: Pete Wyckoff<pw@padd.com>
> ---
> jrnieder@gmail.com wrote on Sat, 17 Dec 2011 21:26 -0600:
>> Pete Wyckoff wrote:
>>
>>> + # 2 is SIGINT, ash/dash does not know symbolic names
>>> + trap echo 2
>>
>> 'trap "$cmd" INT' works, and it's even in POSIX. ;)
>> http://pubs.opengroup.org/onlinepubs/9699919799/utilities/V3_chap02.html#trap
>
> Nicer to use the constant. It works on both. Unfortunately
> ash has other issues regarding handling ctrl-c from subprocesses.
> Point this out in the comments.
>
> t/lib-git-p4.sh | 31 +++++++++++++++++++++++++++++++
> 1 files changed, 31 insertions(+), 0 deletions(-)
>
> diff --git a/t/lib-git-p4.sh b/t/lib-git-p4.sh
> index a870f9a..4c30960 100644
> --- a/t/lib-git-p4.sh
> +++ b/t/lib-git-p4.sh
> @@ -72,3 +72,34 @@ kill_p4d() {
> cleanup_git() {
> rm -rf "$git"
> }
> +
> +#
> +# This is a handy tool when developing or debugging tests. Use
> +# it inline to pause the script, perhaps like this:
> +#
> +# "$GITP4" clone ...&&
> +# (
> +# cd "$git"&&
> +# debug&&
> +# git log --oneline>lines&&
> +# ...
> +#
> +# Go investigate when it pauses, then hit ctrl-c to continue the
> +# test. The other tests will run, and p4d will be cleaned up nicely.
> +#
> +# Note that the directory is deleted and created for every test run,
> +# so you have to do the "cd" again.
> +#
> +# The continuation feature only works in shells that do not propagate
> +# a child-caught ctrl-c, namely bash. With ash, the entire test run
> +# will exit on the ctrl-c.
> +#
> +debug() {
> + echo "*** Debug me, hit ctrl-c when done. Useful shell commands:"
> + echo cd \"$(pwd)\"
> + echo export P4PORT=$P4PORT P4CLIENT=$P4CLIENT
> + trap "echo" INT
> + sleep $((3600 * 24 * 30))
> + trap - INT
> +}
> +
^ permalink raw reply
* Re: How can I do an automatic stash when doing a checkout?
From: Bruce Stephens brs @ 2011-12-18 15:37 UTC (permalink / raw)
To: DeMarcus; +Cc: git
In-Reply-To: <jckvpk$i8v$1@dough.gmane.org>
DeMarcus <demarcus@hotmail.com> writes:
[...]
> It feels strange doing a commit of partial work. Some of the files may
> not even be supposed to be checked in.
Well, maybe forget about files that you don't expect to keep, but
committing partial work is fine. It's only in your local checkout,
after all; once you've got something worth sharing you can rearrange the
commits so they make sense.
[...]
^ permalink raw reply
* Re: How can I do an automatic stash when doing a checkout?
From: DeMarcus @ 2011-12-18 15:10 UTC (permalink / raw)
To: git
In-Reply-To: <84ty4ycdcc.fsf@cenderis.demon.co.uk>
>> This is not how it works with git, where when I want to change branch
>> I have to do a git checkout. However, that leaves all the modified and
>> untracked files in the directory of the branch I switched to. This is
>> seldom the behavior I want.
>>
>> With the git stash command I can clean the directory the way I want
>> but the stash command is not connected to a particular branch.
>>
>> Is there a way to have git checkout do an automatic stash when doing a
>> checkout to another branch, and then do an automatic git stash apply
>> with the correct stash when changing back to the previous branch
>> again?
>
> You probably don't want to use stash. Just commit whatever partial work
> you've done.
>
It feels strange doing a commit of partial work. Some of the files may
not even be supposed to be checked in.
> You could also just checkout different branches in different
> directories. Nothing wrong with doing that in git.
>
Ok thanks, that would give me the same behavior as I have today.
However, I can see some benefits with have everything in the same
directory as git allows compared to other VCSs. And since the stashing
feature is already there in git, it would be nice if the git checkout
with some flag could use stashing automatically.
^ permalink raw reply
* [PATCHv3 02/11] git-p4: test debug macro
From: Pete Wyckoff @ 2011-12-18 14:06 UTC (permalink / raw)
To: Jonathan Nieder; +Cc: Luke Diamand, git
In-Reply-To: <20111218032238.GA6368@elie.hsd1.il.comcast.net>
Call this from a test to have it pause and wait for you to
investigate. It prints out its current directory and the
P4 environment variables. It waits for ctrl-c before continuing
the test.
Signed-off-by: Pete Wyckoff <pw@padd.com>
---
jrnieder@gmail.com wrote on Sat, 17 Dec 2011 21:26 -0600:
> Pete Wyckoff wrote:
>
> > + # 2 is SIGINT, ash/dash does not know symbolic names
> > + trap echo 2
>
> 'trap "$cmd" INT' works, and it's even in POSIX. ;)
> http://pubs.opengroup.org/onlinepubs/9699919799/utilities/V3_chap02.html#trap
Nicer to use the constant. It works on both. Unfortunately
ash has other issues regarding handling ctrl-c from subprocesses.
Point this out in the comments.
t/lib-git-p4.sh | 31 +++++++++++++++++++++++++++++++
1 files changed, 31 insertions(+), 0 deletions(-)
diff --git a/t/lib-git-p4.sh b/t/lib-git-p4.sh
index a870f9a..4c30960 100644
--- a/t/lib-git-p4.sh
+++ b/t/lib-git-p4.sh
@@ -72,3 +72,34 @@ kill_p4d() {
cleanup_git() {
rm -rf "$git"
}
+
+#
+# This is a handy tool when developing or debugging tests. Use
+# it inline to pause the script, perhaps like this:
+#
+# "$GITP4" clone ... &&
+# (
+# cd "$git" &&
+# debug &&
+# git log --oneline >lines &&
+# ...
+#
+# Go investigate when it pauses, then hit ctrl-c to continue the
+# test. The other tests will run, and p4d will be cleaned up nicely.
+#
+# Note that the directory is deleted and created for every test run,
+# so you have to do the "cd" again.
+#
+# The continuation feature only works in shells that do not propagate
+# a child-caught ctrl-c, namely bash. With ash, the entire test run
+# will exit on the ctrl-c.
+#
+debug() {
+ echo "*** Debug me, hit ctrl-c when done. Useful shell commands:"
+ echo cd \"$(pwd)\"
+ echo export P4PORT=$P4PORT P4CLIENT=$P4CLIENT
+ trap "echo" INT
+ sleep $((3600 * 24 * 30))
+ trap - INT
+}
+
--
1.7.8.285.gb668d
^ permalink raw reply related
* Re: [PATCHv2 02/11] git-p4: test debug macro
From: Pete Wyckoff @ 2011-12-18 13:50 UTC (permalink / raw)
To: Jonathan Nieder; +Cc: Luke Diamand, git
In-Reply-To: <20111218032238.GA6368@elie.hsd1.il.comcast.net>
jrnieder@gmail.com wrote on Sat, 17 Dec 2011 21:26 -0600:
> Pete Wyckoff wrote:
>
> > + # 2 is SIGINT, ash/dash does not know symbolic names
> > + trap echo 2
>
> 'trap "$cmd" INT' works, and it's even in POSIX. ;)
> http://pubs.opengroup.org/onlinepubs/9699919799/utilities/V3_chap02.html#trap
Nice! But ash/dash handle subshell INT differently. With ash,
the entire test exits after the ctrl-C, even if caught by a trap in a
subshell. Not so nice. Here's a demonstration.
-----------8<-------------
# shell top.sh
echo top.sh
$SHELL trap.sh
echo top.sh: exit status from trap.sh: $?
echo top.sh: exiting
exit 0
-----------8<-------------
-----------8<-------------
# shell trap.sh
echo trap.sh
trap "echo trap.sh caught INT" INT
sleep 3600
trap - INT
echo trap.sh: exiting
exit 0
-----------8<-------------
Run "bash top.sh". Hit ctrl-c, you'll see:
$ bash top.sh
top.sh
trap.sh
^Ctrap.sh caught INT
trap.sh: exiting
top.sh: exit status from trap.sh: 0
top.sh: exiting
Similarly with "ash top.sh":
$ ash top.sh
top.sh
trap.sh
^Ctrap.sh caught INT
trap.sh: exiting
The top-level script also gets the ctrl-c, but exits on the INT
anyway, after reaping its child. I can't find where POSIX says
if this is correct or not. It isn't how I want it to work here.
I'll add a comment above debug() to explain that it works in bash
but not ash. At least it prints out the P4 environment
information needed to debug.
-- Pete
^ permalink raw reply
* i18n.commitencoding=gbk or --encoding=gbk not work with --pretty=format
From: Yuchen Deng @ 2011-12-18 13:26 UTC (permalink / raw)
To: git
Hi, all!
When set the option i18n.commitencoding value to gbk. I found the 'git log'
ouput encoding always is the default : utf8
git log -n10 --pretty=format:"%h %d %an %s %ci" --topo-order --graph
or
git log -n10 --encoding=utf8 --pretty=format:"%h %d %an %s %ci"
--topo-order --graph
But:
git log --oneline
works well.
I am from China, and the GFW thing, I can't visit git-scm.com.
So, Somebody can help me to report this bug?
I am sure it's don't work for Windows (msys-git) or Linux (Chakra).
Thanks!
--
View this message in context: http://git.661346.n2.nabble.com/i18n-commitencoding-gbk-or-encoding-gbk-not-work-with-pretty-format-tp7105845p7105845.html
Sent from the git mailing list archive at Nabble.com.
^ permalink raw reply
* Re: How can I do an automatic stash when doing a checkout?
From: Bruce Stephens brs @ 2011-12-18 11:45 UTC (permalink / raw)
To: DeMarcus; +Cc: git
In-Reply-To: <jcki8u$oip$1@dough.gmane.org>
DeMarcus <demarcus@hotmail.com> writes:
[...]
> This is not how it works with git, where when I want to change branch
> I have to do a git checkout. However, that leaves all the modified and
> untracked files in the directory of the branch I switched to. This is
> seldom the behavior I want.
>
> With the git stash command I can clean the directory the way I want
> but the stash command is not connected to a particular branch.
>
> Is there a way to have git checkout do an automatic stash when doing a
> checkout to another branch, and then do an automatic git stash apply
> with the correct stash when changing back to the previous branch
> again?
You probably don't want to use stash. Just commit whatever partial work
you've done.
You could also just checkout different branches in different
directories. Nothing wrong with doing that in git.
[...]
^ permalink raw reply
* How can I do an automatic stash when doing a checkout?
From: DeMarcus @ 2011-12-18 11:19 UTC (permalink / raw)
To: git
Hi,
I'm new to git and currently I'm working with SVN and there it's a bit
messier doing branching but once I've branched then all my development
there is completely separated from any other branch. When I want to work
on another branch I just change directory.
This is not how it works with git, where when I want to change branch I
have to do a git checkout. However, that leaves all the modified and
untracked files in the directory of the branch I switched to. This is
seldom the behavior I want.
With the git stash command I can clean the directory the way I want but
the stash command is not connected to a particular branch.
Is there a way to have git checkout do an automatic stash when doing a
checkout to another branch, and then do an automatic git stash apply
with the correct stash when changing back to the previous branch again?
Thanks,
Daniel
^ permalink raw reply
* Re: Escape character for .gitconfig
From: Jeff King @ 2011-12-18 9:51 UTC (permalink / raw)
To: Erik Blake; +Cc: git
In-Reply-To: <4EED9BE5.8060600@icefield.yk.ca>
On Sun, Dec 18, 2011 at 08:53:09AM +0100, Erik Blake wrote:
> That did the trick for this git newb. For the record, I had tried \(,
> /(, double- and single-quoting the entire path (note that git config
> --global had removed the quotes that were originally around the
> string). Did not think of "nested" quotes.
Yeah, if you are using "git config" to enter it on the command line,
you'll have to put an extra layer of quoting around it to pass it
through the shell you're currently running. That's why I showed the
example as the actual config file text. :)
> Now, however, I have a different problem in that notepad++ is somehow
> signalling git that editing is complete before I even get a chance to
> edit the file. I am trying the command
> >git commit --amend
Yep. This is a general problem with editors that open files in an
existing session. The only signal git has of the user being done editing
is when when the editor process exits. For many editors, there is an
option or other trick for sticking around until the file is closed.
I know nothing about notepad++, but a quick google turned up the
"-multiInst" option, which would avoid attaching to the existing
instance. That might work for you.
-Peff
^ permalink raw reply
* Re: Escape character for .gitconfig
From: Erik Blake @ 2011-12-18 7:53 UTC (permalink / raw)
To: Jeff King; +Cc: git
In-Reply-To: <20111217105806.GB23935@sigill.intra.peff.net>
Thanks Jeff,
That did the trick for this git newb. For the record, I had tried \(,
/(, double- and single-quoting the entire path (note that git config
--global had removed the quotes that were originally around the string).
Did not think of "nested" quotes.
Now, however, I have a different problem in that notepad++ is somehow
signalling git that editing is complete before I even get a chance to
edit the file. I am trying the command
>git commit --amend
Notepad++ opens with the message, but git completes the commit before I
get a chance to make any changes. I suspect the issue is that git fires
up a new instance of notepad++ (which in my case is already running with
some other files open). notepad++ sees the new instance starting and
subsumes it under the pre-existing instance and then closes the new
instance. git sees the task close and assumes I am done editing.
Oh well. Cannot use notepad.exe because it does not handle <lf> line
endings. I guess I'll stick to the git gui.
e.
On 2011-12-17 11:58, Jeff King wrote:
> On Sat, Dec 17, 2011 at 11:10:37AM +0100, Erik Blake wrote:
>
>> I have an editor path that includes "(" and ")". No matter how I try
>> to escape this character, I get either variations on:
>>
>> C:/Program Files (x86)/Notepad++/notepad++.exe: -c: line 0: syntax
>> error near unexpected token `('
>> C:/Program Files (x86)/Notepad++/notepad++.exe: -c: line 0:
>> `C:/Program Files (x86)/Notepad++/notepad++.exe \$@\'
>> error: There was a problem with the editor 'C:/Program Files
>> (x86)/Notepad++/notepad++.exe'.
>> Please supply the message using either -m or -F option.
>>
>> or:
>>
>> fatal: bad config file line 5 in C:\Users\xxx/.gitconfig
>
> You didn't tell us what you actually tried, so I don't know where you
> went wrong.
>
> But you will need to quote the whole value for git to read from your
> gitconfig, and then quote any metacharacters in the value so that the
> shell doesn't interpret them. I think you want:
>
> [core]
> editor = "'C:/Program Files (x86)/Notepad++/notepad++.exe'"
>
> -Peff
^ permalink raw reply
* Re: header file at a top
From: Jeff King @ 2011-12-18 5:43 UTC (permalink / raw)
To: Thiago Farina; +Cc: Git Mailing List
In-Reply-To: <CACnwZYdSPPhLyu6Oi3k2aNzYqvmD=xDYWvCEd2ofyJSntqKdJg@mail.gmail.com>
On Sat, Dec 17, 2011 at 07:57:42PM -0200, Thiago Farina wrote:
> I don't understand why in git the .h file is not included as the first
> substantive line of the .c file.
>
> i.e:
>
> foo.c
> --------------------------------------------------------------------
> #include "foo.h"
>
> /* in alphabetical order */
> #include "bar.h"
> #include "tiz.h"
>
> Any particular reason we include the corresponding header file at some
> random position in the source file?
The first include in any git source file should be either
"git-compat-util.h", or something that includes it (usually "cache.h").
This introduces compatibility wrappers and definitions which may be used
by other headers.
After that, the next one could be "foo.h", and I do tend to like that
style (since it gives a check that foo.h has no surprising header
dependencies). But I think we simply don't bother caring about header
dependencies in git (i.e., we do have recursive includes in some places,
but we don't require them, and in practice the compiler will tell us if
a source file fails to include a depended-upon header).
-Peff
^ permalink raw reply
* Re: BUG: Git command causes crash
From: Jeff King @ 2011-12-18 5:38 UTC (permalink / raw)
To: Ryan O'Hara; +Cc: git, Junio C Hamano
In-Reply-To: <20111218050728.GB1787@sigill.intra.peff.net>
On Sun, Dec 18, 2011 at 12:07:28AM -0500, Jeff King wrote:
> -static struct strbuf merge_msg;
> +static struct strbuf merge_msg = STRBUF_INIT;
> [...]
>
> I'm not sure if you can actually trigger a segfault, but it clearly
> violates the strbuf API.
One note on this: that line by itself doesn't violate the strbuf API.
You can always initialize it by hand later. But it's easy to look
through the code in this case and see that we don't.
A grep of "static struct strbuf" doesn't show any other similar cases. I
also did a grep of "struct strbuf [a-z]*;" to find stack and struct
member variables. Most of the stack ones get initialized right away
(which is not too surprising, as they would contain random garbage and
not work at all). A few of the ones in structs are hard to track down,
and could be problematic (I expected to maybe find a memset-to-zero
initialization), but I followed all of them to an actual strbuf_init.
Which isn't to say my looking was exhaustive, as there might be other
code paths I missed. But at least these two are the low-hanging fruit.
Here's a commit which does them both together (they are really the same
bug).
-- >8 --
Subject: [PATCH] initialize static strbufs
Strbufs cannot rely on static all-zero initialization;
instead, they must use STRBUF_INIT to point to the
"slopbuf". This failure can go undetected in most code
paths, as only some of the strbuf functions assume the
slopbuf is in place (e.g., "strbuf_add" works). In
particular, calling "strbuf_setlen" will cause a segfault.
Without this patch, "git commit --no-message" and "git merge
--no-message" segfault reliably.
Signed-off-by: Jeff King <peff@peff.net>
---
builtin/commit.c | 2 +-
builtin/merge.c | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/builtin/commit.c b/builtin/commit.c
index d0f27f9..336faff 100644
--- a/builtin/commit.c
+++ b/builtin/commit.c
@@ -104,7 +104,7 @@
static int use_editor = 1, include_status = 1;
static int show_ignored_in_status;
static const char *only_include_assumed;
-static struct strbuf message;
+static struct strbuf message = STRBUF_INIT;
static int null_termination;
static enum {
diff --git a/builtin/merge.c b/builtin/merge.c
index 2457940..28a3a7e 100644
--- a/builtin/merge.c
+++ b/builtin/merge.c
@@ -50,7 +50,7 @@ struct strategy {
static int fast_forward_only, option_edit;
static int allow_trivial = 1, have_message;
static int overwrite_ignore = 1;
-static struct strbuf merge_msg;
+static struct strbuf merge_msg = STRBUF_INIT;
static struct commit_list *remoteheads;
static struct strategy **use_strategies;
static size_t use_strategies_nr, use_strategies_alloc;
--
1.7.8.rc3.14.gd2470
^ permalink raw reply related
* Re: BUG: Git command causes crash
From: Jeff King @ 2011-12-18 5:07 UTC (permalink / raw)
To: Ryan O'Hara; +Cc: git, Junio C Hamano
In-Reply-To: <20111218050322.GA1787@sigill.intra.peff.net>
On Sun, Dec 18, 2011 at 12:03:22AM -0500, Jeff King wrote:
> Subject: [PATCH] commit: initialize static strbuf
>
> Strbufs cannot rely on static all-zero initialization;
> instead, they must use STRBUF_INIT to point to the
> "slopbuf".
>
> Without this patch, "git commit --no-message" segfaults
> reliably.
This one, too:
diff --git a/builtin/merge.c b/builtin/merge.c
index 2457940..28a3a7e 100644
--- a/builtin/merge.c
+++ b/builtin/merge.c
@@ -50,7 +50,7 @@ struct strategy {
static int fast_forward_only, option_edit;
static int allow_trivial = 1, have_message;
static int overwrite_ignore = 1;
-static struct strbuf merge_msg;
+static struct strbuf merge_msg = STRBUF_INIT;
static struct commit_list *remoteheads;
static struct strategy **use_strategies;
static size_t use_strategies_nr, use_strategies_alloc;
I'm not sure if you can actually trigger a segfault, but it clearly
violates the strbuf API.
-Peff
^ permalink raw reply related
* Re: BUG: Git command causes crash
From: Jeff King @ 2011-12-18 5:03 UTC (permalink / raw)
To: Ryan O'Hara; +Cc: git, Junio C Hamano
In-Reply-To: <CAOgd6zFr5LorTK6X5o6NQE3L61KhaUZG9tX4LEB4_Na_YKPPpA@mail.gmail.com>
On Sat, Dec 17, 2011 at 07:13:53PM -0800, Ryan O'Hara wrote:
> On Git for Windows (MinGW), at least, this command causes git to crash:
>
> git commit -a --no-message --dry-run
On Linux, too, using just "git commit --no-message" (whether there is
something to commit or not). This fixes it for me.
-- >8 --
Subject: [PATCH] commit: initialize static strbuf
Strbufs cannot rely on static all-zero initialization;
instead, they must use STRBUF_INIT to point to the
"slopbuf".
Without this patch, "git commit --no-message" segfaults
reliably.
Signed-off-by: Jeff King <peff@peff.net>
---
builtin/commit.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/builtin/commit.c b/builtin/commit.c
index d0f27f9..336faff 100644
--- a/builtin/commit.c
+++ b/builtin/commit.c
@@ -104,7 +104,7 @@
static int use_editor = 1, include_status = 1;
static int show_ignored_in_status;
static const char *only_include_assumed;
-static struct strbuf message;
+static struct strbuf message = STRBUF_INIT;
static int null_termination;
static enum {
--
1.7.8.rc3.14.gd2470
^ permalink raw reply related
* Re: [PATCHv2 02/11] git-p4: test debug macro
From: Jonathan Nieder @ 2011-12-18 3:26 UTC (permalink / raw)
To: Pete Wyckoff; +Cc: Luke Diamand, git
In-Reply-To: <20111218013651.GA18735@padd.com>
Pete Wyckoff wrote:
> + # 2 is SIGINT, ash/dash does not know symbolic names
> + trap echo 2
'trap "$cmd" INT' works, and it's even in POSIX. ;)
http://pubs.opengroup.org/onlinepubs/9699919799/utilities/V3_chap02.html#trap
^ permalink raw reply
* BUG: Git command causes crash
From: Ryan O'Hara @ 2011-12-18 3:13 UTC (permalink / raw)
To: git
On Git for Windows (MinGW), at least, this command causes git to crash:
git commit -a --no-message --dry-run
^ permalink raw reply
* [PATCHv2 02/11] git-p4: test debug macro
From: Pete Wyckoff @ 2011-12-18 1:36 UTC (permalink / raw)
To: Luke Diamand; +Cc: git
In-Reply-To: <4EED1B06.80007@diamand.org>
Call this from a test to have it pause and wait for you to
investigate. It prints out its current directory and the
P4 environment variables. It waits for ctrl-c before continuing
the test.
Signed-off-by: Pete Wyckoff <pw@padd.com>
---
luke@diamand.org wrote on Sat, 17 Dec 2011 22:43 +0000:
> >+# Go investigate when it pauses, then hit ctrl-c to continue the
> >+# test. The other tests will run, and p4d will be cleaned up nicely.
> >+#
> >+# Note that the directory is deleted and created for every test run,
> >+# so you have to do the "cd" again.
> >+#
> >+debug() {
> >+ echo "*** Debug me, hit ctrl-c when done. Useful shell commands:"
> >+ echo cd \"$(pwd)\"
> >+ echo export P4PORT=$P4PORT P4CLIENT=$P4CLIENT
> >+ trap echo SIGINT
>
> Does that work with non-bash shells like ash? It didn't for me.
>
> >+ sleep $((3600 * 24 * 30))
> >+ trap - SIGINT
> >+}
> >+
Indeed. At least debian's ash is just dash, and version 0.5.7-2
doesn't know the symbolic signal names.
Thanks for noticing.
t/lib-git-p4.sh | 28 ++++++++++++++++++++++++++++
1 files changed, 28 insertions(+), 0 deletions(-)
diff --git a/t/lib-git-p4.sh b/t/lib-git-p4.sh
index a870f9a..b7b2c95 100644
--- a/t/lib-git-p4.sh
+++ b/t/lib-git-p4.sh
@@ -72,3 +72,31 @@ kill_p4d() {
cleanup_git() {
rm -rf "$git"
}
+
+#
+# This is a handy tool when developing or debugging tests. Use
+# it inline to pause the script, perhaps like this:
+#
+# "$GITP4" clone ... &&
+# (
+# cd "$git" &&
+# debug &&
+# git log --oneline >lines &&
+# ...
+#
+# Go investigate when it pauses, then hit ctrl-c to continue the
+# test. The other tests will run, and p4d will be cleaned up nicely.
+#
+# Note that the directory is deleted and created for every test run,
+# so you have to do the "cd" again.
+#
+debug() {
+ echo "*** Debug me, hit ctrl-c when done. Useful shell commands:"
+ echo cd \"$(pwd)\"
+ echo export P4PORT=$P4PORT P4CLIENT=$P4CLIENT
+ # 2 is SIGINT, ash/dash does not know symbolic names
+ trap echo 2
+ sleep $((3600 * 24 * 30))
+ trap - 2
+}
+
--
1.7.8.285.gb668d
^ permalink raw reply related
* Re: [PATCH] Escape file:// URL's to meet subversion SVN::Ra requirements
From: Ben Walton @ 2011-12-17 23:48 UTC (permalink / raw)
To: Jonathan Nieder; +Cc: GIT List, normalperson
In-Reply-To: <20111217095019.GC8845@elie.hsd1.il.comcast.net>
Excerpts from Jonathan Nieder's message of Sat Dec 17 04:50:19 -0500 2011:
Hi Jonathan,
Thanks for following up on this. I've intermittently spent time
digging away at it but other than a few poorly placed fixes that
allowed me to get further into the test suite before failure, I
haven't found a workable fix yet. I've included my wip patch below as
it may help others that are more familiar with the workings of git-svn
isolate a nice clean place to solve the problem.
> The bad effect is that it converts percent signs to %25. So
> commands like "git svn clone file:///path/to/test%20repository" that
> previously worked might not work any more, if v1.6.5-rc0~61 (svn:
> assume URLs from the command-line are URI-encoded, 2009-08-16) did
> not do its job completely.
I wonder if simply doing a uri decode followed by a uri encode might
work? That would decode things that already had some encoding and
then re-encode everything to handle a mixed encodings...I really think
that the svn code should take 'raw' strings and encode internally but
that ship has sailed.
> Another possible approach: to imitate the svn command line tools, we
> could use SVN::Client::url_from_path in some appropriate place.
I've been looking at these functions too.
Thanks
-Ben
>From 98a6b6b4f26a644db5089fce68be6cf7261e4fe1 Mon Sep 17 00:00:00 2001
From: Ben Walton <bwalton@opencsw.org>
Date: Wed, 9 Nov 2011 02:39:05 +0100
Subject: [PATCH] selectively use svn functions to sanitize urls
Signed-off-by: Ben Walton <bwalton@opencsw.org>
---
git-svn.perl | 22 +++++++++++++++-------
1 files changed, 15 insertions(+), 7 deletions(-)
diff --git a/git-svn.perl b/git-svn.perl
index 351e743..fb1ce65 100755
--- a/git-svn.perl
+++ b/git-svn.perl
@@ -1342,9 +1342,13 @@ sub escape_uri_only {
sub escape_url {
my ($url) = @_;
- if ($url =~ m#^([^:]+)://([^/]*)(.*)$#) {
- my ($scheme, $domain, $uri) = ($1, $2, escape_uri_only($3));
- $url = "$scheme://$domain$uri";
+ if ($SVN::Core::VERSION =~ /^1\.[0-6]/) {
+ if ($url =~ m#^([^:]+)://([^/]*)(.*)$#) {
+ my ($scheme, $domain, $uri) = ($1, $2, escape_uri_only($3));
+ $url = "$scheme://$domain$uri";
+ }
+ } else {
+ $url = SVN::_Core::svn_uri_canonicalize($url);
}
$url;
}
@@ -2222,7 +2226,7 @@ sub init_remote_config {
"$url => $min_url\n";
}
my $old_path = $self->{path};
- $self->{path} = $url;
+ $self->{path} = SVN::_Core::svn_uri_canonicalize($url);
$self->{path} =~ s!^\Q$min_url\E(/|$)!!;
if (length $old_path) {
$self->{path} .= "/$old_path";
@@ -5363,9 +5367,13 @@ sub escape_uri_only {
sub escape_url {
my ($url) = @_;
- if ($url =~ m#^(https?)://([^/]+)(.*)$#) {
- my ($scheme, $domain, $uri) = ($1, $2, escape_uri_only($3));
- $url = "$scheme://$domain$uri";
+ if ($SVN::Core::VERSION =~ /^1\.[0-6]/) {
+ if ($url =~ m#^(https?)://([^/]+)(.*)$#) {
+ my ($scheme, $domain, $uri) = ($1, $2, escape_uri_only($3));
+ $url = "$scheme://$domain$uri";
+ }
+ } else {
+ $url = SVN::_Core::svn_uri_canonicalize($url);
}
$url;
}
--
1.7.6.1
--
Ben Walton
Systems Programmer - CHASS
University of Toronto
C:416.407.5610 | W:416.978.4302
^ permalink raw reply related
* Re: [PATCH 02/11] git-p4: test debug macro
From: Luke Diamand @ 2011-12-17 22:43 UTC (permalink / raw)
To: Pete Wyckoff; +Cc: git
In-Reply-To: <1324147942-21558-3-git-send-email-pw@padd.com>
On 17/12/11 18:52, Pete Wyckoff wrote:
> Call this from a test to have it pause and wait for you to
> investigate. It prints out its current directory and the
> P4 environment variables. It waits for ctrl-c before continuing
> the test.
>
Very useful, thanks!
> +# Go investigate when it pauses, then hit ctrl-c to continue the
> +# test. The other tests will run, and p4d will be cleaned up nicely.
> +#
> +# Note that the directory is deleted and created for every test run,
> +# so you have to do the "cd" again.
> +#
> +debug() {
> + echo "*** Debug me, hit ctrl-c when done. Useful shell commands:"
> + echo cd \"$(pwd)\"
> + echo export P4PORT=$P4PORT P4CLIENT=$P4CLIENT
> + trap echo SIGINT
Does that work with non-bash shells like ash? It didn't for me.
> + sleep $((3600 * 24 * 30))
> + trap - SIGINT
> +}
> +
^ permalink raw reply
* header file at a top
From: Thiago Farina @ 2011-12-17 21:57 UTC (permalink / raw)
To: Git Mailing List
Hi folks,
I don't understand why in git the .h file is not included as the first
substantive line of the .c file.
i.e:
foo.c
--------------------------------------------------------------------
#include "foo.h"
/* in alphabetical order */
#include "bar.h"
#include "tiz.h"
Any particular reason we include the corresponding header file at some
random position in the source file?
^ permalink raw reply
* Re: [PATCH] make "git push -v" actually verbose
From: Jeff King @ 2011-12-17 19:50 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Tay Ray Chuan
In-Reply-To: <7vobv7dmak.fsf@alter.siamese.dyndns.org>
On Sat, Dec 17, 2011 at 11:34:59AM -0800, Junio C Hamano wrote:
> > One minor clarification: it is not technically true that "git push -v"
> > does nothing. It just does not do the interesting "show a verbose status
> > table" operation, which is almost certainly what the user wants (and
> > what happened before the commits I mentioned). It does print "Pushing to
> > $url", since that happens above the transport layer. But I'm pretty sure
> > that is not what users of "-v" are interested in. :)
>
> Thanks, but don't be so sure about that.
>
> When you are so used to say "git push ko", from time to time you want to
> check which one of your kernel.org machine you are pushing into; that
> "pushing to this exact url" is actually quite useful.
But we will also print that as part of the status table, so it really is
redundant. The only difference is that it comes before the object
transfer phase, so if the whole thing barfs before you even make it to
the status table, you get a little more debugging output (although
typically the URL is mentioned in the die() message, anyway).
E.g.:
$ git push github
Counting objects: 214, done.
Compressing objects: 100% (131/131), done.
Writing objects: 100% (135/135), 33.73 KiB, done.
Total 135 (delta 102), reused 9 (delta 4)
To https://github.com/peff/git.git
+ 710a44a...0fa8107 private -> private (forced update)
Before my patch, adding "-v" would just put the "Pushing to https://..."
before the object phase.
Anyway, regardless of the utility of that message, I think the fix makes
sense. It really looks like an unintended regression in 8afd8dc, and
certainly the original intent of the code was to match fetch's use of
"-v" to show up-to-date entries in the status table (which I know
because I wrote it).
-Peff
^ permalink raw reply
* Re: [BUG] attribute "eol" with "crlf"
From: Junio C Hamano @ 2011-12-17 19:48 UTC (permalink / raw)
To: Ralf Thielow; +Cc: Matthieu Moy, Carlos Martín Nieto, git
In-Reply-To: <CAN0XMOK0=uxRHcsUmbOE_UrkUcqmRFk-OYnY7kOZkZcWxWOycQ@mail.gmail.com>
Ralf Thielow <ralf.thielow@googlemail.com> writes:
>> Perhaps something like this, but I do not use CRLF myself, so it probably
>> needs to be checked by extra sets of eyes.
>>
>> Thanks.
>>
>
> Works fine for me. Thanks
Ok; thanks. Will queue.
^ permalink raw reply
* Re: Re* How to generate pull-request with info of signed tag
From: Junio C Hamano @ 2011-12-17 19:47 UTC (permalink / raw)
To: Aneesh Kumar K.V; +Cc: Git Mailing List
In-Reply-To: <871us3l45o.fsf@linux.vnet.ibm.com>
"Aneesh Kumar K.V" <aneesh.kumar@linux.vnet.ibm.com> writes:
> Tested-by: Aneesh Kumar K.V <aneesh.kumar@linux.vnet.ibm.com>
>
> -aneesh
Thanks.
^ permalink raw reply
* Re: [PATCH] make "git push -v" actually verbose
From: Junio C Hamano @ 2011-12-17 19:34 UTC (permalink / raw)
To: Jeff King; +Cc: git, Tay Ray Chuan, Junio C Hamano
In-Reply-To: <20111217094142.GA10451@sigill.intra.peff.net>
Jeff King <peff@peff.net> writes:
> On Sat, Dec 17, 2011 at 04:37:15AM -0500, Jeff King wrote:
>
>> Providing a single "-v" to "git push" currently does
>> nothing. Giving two flags ("git push -v -v") turns on the
>> first level of verbosity.
>
> One minor clarification: it is not technically true that "git push -v"
> does nothing. It just does not do the interesting "show a verbose status
> table" operation, which is almost certainly what the user wants (and
> what happened before the commits I mentioned). It does print "Pushing to
> $url", since that happens above the transport layer. But I'm pretty sure
> that is not what users of "-v" are interested in. :)
Thanks, but don't be so sure about that.
When you are so used to say "git push ko", from time to time you want to
check which one of your kernel.org machine you are pushing into; that
"pushing to this exact url" is actually quite useful.
^ 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