* Re: [PATCH 2/2] push: --ignore-stale option
From: Junio C Hamano @ 2011-12-19 5:33 UTC (permalink / raw)
To: git; +Cc: Jeff King
In-Reply-To: <7vmxatofvr.fsf@alter.siamese.dyndns.org>
Junio C Hamano <gitster@pobox.com> writes:
> Jeff King <peff@peff.net> writes:
>
>> But I still see this as solving the wrong problem, and encouraging a
>> dangerous workflow.
>
> Yes, that is what I meant, so we are in total agreement that these people
> should be encouraged not to use the matching semantics.
>
> How that encouragement is made we may differ, though.
So here is my idea of how best to implement such an encouragement.
The first patch is a documentation update/clean-up to prepare for the main
one which is the second.
^ permalink raw reply
* Re: post-receive for web deployment
From: Stephen Major @ 2011-12-19 2:42 UTC (permalink / raw)
To: git
In-Reply-To: <CALzTOmJUqzO8H5UxyFaodi98DBJtFvsbQsHsYh1U=Ggq3NRO5A@mail.gmail.com>
Hello,
I am having some difficulty understanding what I am doing wrong when
working with git to deploy a website through the use of a post-receive
hook on the remote.
Here is the script:
#!/bin/sh
staging_path="/home/user/domains/domain.com/public_html/staging"
live_path="/home/user/domains/domain.com/public_html/live"
while read oldrev newrev ref
do
branch=$(echo $ref | cut -d/ -f3)
# ***
# update the live site
#
if [[ "master" == "$branch" ]]; then
export GIT_WORK_TREE=$live_path
git checkout -f $branch
echo "Release has been pushed to production"
# ***
# we update the staging server with the latest push
#
elif [[ "develop" == "$branch" ]]; then
echo "Resetting staging tree"
export GIT_WORK_TREE=$staging_path
git checkout -f $branch
echo "Develop has been pushed to staging"
fi
done
This is what we have done:
git checkout develop
touch 1 2 3 4 5 6
git add .
git commit -am "added some files"
git push origin develop
checking the remote server now all files are found in:
/home/user/domains/domain.com/public_html/staging
git checkout master
git merge develop
git push origin master
checking the remote server now all files are found in:
/home/user/domains/domain.com/public_html/live
git checkout develop
git rm 4 5 6
git commit -am "removed some files"
git push origin develop
checking the remote server now files 4 5 6 have been removed from:
/home/user/domains/domain.com/public_html/staging
git checkout master
git merge develop
git push origin master
checking the remote server files 4 5 6 are still found in:
/home/user/domains/domain.com/public_html/live
Why is this happening? checking the local repo for master shows the
files are removed there... pulling the latest from origin:master shows
the files have been removed... but why were they not removed from the
working tree like they were on the staging working tree?
well I think it has something to do with later commits and therefor
the working tree of the live server could quickly become out of sync
with the development tree
a quick test, lets checkout master again and perform the removes
directly on it then push it back:
git checkout master
git rm 1 2 3
git commit -am "removed 1 2 3"
git push origin master
checking the remote server now files 1 2 3 have been removed from:
/home/user/domains/domain.com/public_html/live
Okay weird so they remove when the commit happens directly on that
branch and is pushed to the remote but they dont get removed if the
removal happened on a different branch and is merged in then pushed to
the remote....
anyone have an explanation or a workaround?
^ permalink raw reply
* Re: [PATCH] Fix capitalization of "renamelimit" in docs to agree with code
From: Pete Harlan @ 2011-12-19 1:13 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vsjkhnzkt.fsf@alter.siamese.dyndns.org>
On 12/18/2011 05:02 PM, Junio C Hamano wrote:
> Pete Harlan <pgit@pcharlan.com> writes:
>
>> Signed-off-by: Pete Harlan <pgit@pcharlan.com>
>> ---
>> The documentation and bash-completion have always capitalized
>> "renamelimit" as "renameLimit". The code has always lowercased the
>> whole name. Repair the docs.
>
> Please don't do this.
Sorry for the spam. There was a circumstance at work where it appeared
clear that case wasn't being ignored and it bit us twice. Obviously our
problem lies elsewhere; please forgive the intrusion.
SubmittingPatches says to send to you directly if (and only if) the
patch is ready for inclusion. Next time I won't presume that a patch is
ready without review however obvious that may seem to me at the time.
--Pete
> Exactly because we treat the variable name part (and the top-level section
> part of three-part names) case insensitively, the code lowercases before
> comparing as an implementation detail.
>
> However, you will be naming the same variable whether you spell it using
> all lowercase, or using camelCase (i.e. it does not really matter what
> case the user uses). The camelCase makes it slightly easier to see where
> the word boundaries are than alllowercase, and that is why we try to use
> it in our documentes, which is after all meant to be read by humans.
>
> I would also appreciate if people tried not to overflow my mailbox with an
> incorrect patch that hasn't been discussed and hasn't seen concensus on
> the list that the particular change is a good thing to do, unless the
> patch is about an area that I am an area expert (you can see who the area
> experts are by asking "git shortlog --no-merges -n" or "git blame").
>
> Thanks.
^ permalink raw reply
* Re: [PATCH] Fix capitalization of "renamelimit" in docs to agree with code
From: Junio C Hamano @ 2011-12-19 1:02 UTC (permalink / raw)
To: Pete Harlan; +Cc: git
In-Reply-To: <4EEE86AC.2030802@pcharlan.com>
Pete Harlan <pgit@pcharlan.com> writes:
> Signed-off-by: Pete Harlan <pgit@pcharlan.com>
> ---
> The documentation and bash-completion have always capitalized
> "renamelimit" as "renameLimit". The code has always lowercased the
> whole name. Repair the docs.
Please don't do this.
Exactly because we treat the variable name part (and the top-level section
part of three-part names) case insensitively, the code lowercases before
comparing as an implementation detail.
However, you will be naming the same variable whether you spell it using
all lowercase, or using camelCase (i.e. it does not really matter what
case the user uses). The camelCase makes it slightly easier to see where
the word boundaries are than alllowercase, and that is why we try to use
it in our documentes, which is after all meant to be read by humans.
I would also appreciate if people tried not to overflow my mailbox with an
incorrect patch that hasn't been discussed and hasn't seen concensus on
the list that the particular change is a good thing to do, unless the
patch is about an area that I am an area expert (you can see who the area
experts are by asking "git shortlog --no-merges -n" or "git blame").
Thanks.
^ permalink raw reply
* [PATCH 4/3] gitweb: Fix fallback mode of to_utf8 subroutine
From: Jakub Narebski @ 2011-12-19 0:54 UTC (permalink / raw)
To: git; +Cc: Juergen Kreileder, John Hawley, admin
In-Reply-To: <1324113743-21498-1-git-send-email-jnareb@gmail.com>
e5d3de5 (gitweb: use Perl built-in utf8 function for UTF-8 decoding.,
2007-12-04) was meant to make gitweb faster by using Perl's internals
(see subsection "Messing with Perl's Internals" in Encode(3pm) manpage)
Simple benchmark confirms that (old = 00f429a, new = this version);
note that it is synthetic benchmark of standalone subroutines, not
of gitweb itself
old new
old -- -65%
new 189% --
Unfortunately it made fallback mode of to_utf8 do not work... except
for default value 'latin1' of $fallback_encoding ('latin1' is Perl
native encoding), which is why it was not noticed for such long time.
utf8::valid(STRING) is an internal function that tests whether STRING
is in a _consistent state_ regarding UTF-8. It returns true is
well-formed UTF-8 and has the UTF-8 flag on _*or*_ if string is held
as bytes (both these states are 'consistent'). For gitweb the second
option was true, as output from git commands is opened without ':utf8'
layer.
What made it work at all for STRING in 'latin1' encoding is the fact
that utf8:decode(STRING) turns on UTF-8 flag only if source string is
valid UTF-8 and contains multi-byte UTF-8 characters... and that if
string doesn't have UTF-8 flag set it is treated as in native Perl
encoding, i.e. 'latin1' / 'iso-8859-1' (unless native encoding it is
EBCDIC ;-)). It was ':utf8' layer that actually converted 'latin1'
(no UTF-8 flag == native == 'latin1) to 'utf8'.
Let's make use of the fact that utf8:decode(STRING) returns false if
STRING is invalid as UTF-8 to check whether to enable fallback mode.
Signed-off-by: Jakub Narebski <jnareb@gmail.com>
---
Excuse me for overly long commit message...
Resent as part of to_utf8 fixes for better visibility
gitweb/gitweb.perl | 3 +--
1 files changed, 1 insertions(+), 2 deletions(-)
diff --git a/gitweb/gitweb.perl b/gitweb/gitweb.perl
index d24763b..75b0970 100755
--- a/gitweb/gitweb.perl
+++ b/gitweb/gitweb.perl
@@ -1443,8 +1443,7 @@ sub validate_refname {
sub to_utf8 {
my $str = shift;
return undef unless defined $str;
- if (utf8::valid($str)) {
- utf8::decode($str);
+ if (utf8::valid($str) && utf8::decode($str)) {
return $str;
} else {
return decode($fallback_encoding, $str, Encode::FB_DEFAULT);
--
1.7.6
^ permalink raw reply related
* Re: [PATCH] Fix capitalization of "renamelimit" in docs to agree with code
From: Jakub Narebski @ 2011-12-19 0:51 UTC (permalink / raw)
To: Pete Harlan; +Cc: git
In-Reply-To: <4EEE86AC.2030802@pcharlan.com>
Pete Harlan <pgit@pcharlan.com> writes:
> Signed-off-by: Pete Harlan <pgit@pcharlan.com>
> ---
> The documentation and bash-completion have always capitalized
> "renamelimit" as "renameLimit". The code has always lowercased the
> whole name. Repair the docs.
Key names are *case insensitive* so we can write it in docs in a way
that is more clear, like 'renameLimit'.
Code compares with lowercased key name, so that is why it uses
'renamelimit'.
> @@ -2122,7 +2122,7 @@ _git_config ()
> diff.ignoreSubmodules
> diff.mnemonicprefix
> diff.noprefix
> - diff.renameLimit
> + diff.renamelimit
> diff.renames
> diff.suppressBlankEmpty
> diff.tool
Consitency - why you change diff.renameLimit but not
diff.ignoreSubmodules?
--
Jakub Narebski
^ permalink raw reply
* [PATCH] Fix capitalization of "renamelimit" in docs to agree with code
From: Pete Harlan @ 2011-12-19 0:34 UTC (permalink / raw)
To: git, Junio C Hamano
Signed-off-by: Pete Harlan <pgit@pcharlan.com>
---
The documentation and bash-completion have always capitalized
"renamelimit" as "renameLimit". The code has always lowercased the
whole name. Repair the docs.
Documentation/diff-config.txt | 2 +-
Documentation/merge-config.txt | 4 ++--
contrib/completion/git-completion.bash | 4 ++--
3 files changed, 5 insertions(+), 5 deletions(-)
diff --git a/Documentation/diff-config.txt b/Documentation/diff-config.txt
index 1aed79e..1b9a314 100644
--- a/Documentation/diff-config.txt
+++ b/Documentation/diff-config.txt
@@ -86,7 +86,7 @@ diff.mnemonicprefix::
diff.noprefix::
If set, 'git diff' does not show any source or destination prefix.
-diff.renameLimit::
+diff.renamelimit::
The number of files to consider when performing the copy/rename
detection; equivalent to the 'git diff' option '-l'.
diff --git a/Documentation/merge-config.txt b/Documentation/merge-config.txt
index 861bd6f..fdb3cb6 100644
--- a/Documentation/merge-config.txt
+++ b/Documentation/merge-config.txt
@@ -32,10 +32,10 @@ merge.log::
actual commits that are being merged. Defaults to false, and
true is a synonym for 20.
-merge.renameLimit::
+merge.renamelimit::
The number of files to consider when performing rename detection
during a merge; if not specified, defaults to the value of
- diff.renameLimit.
+ diff.renamelimit.
merge.renormalize::
Tell git that canonical representation of files in the
diff --git a/contrib/completion/git-completion.bash
b/contrib/completion/git-completion.bash
index cc1bdf9..76f66e1 100755
--- a/contrib/completion/git-completion.bash
+++ b/contrib/completion/git-completion.bash
@@ -2122,7 +2122,7 @@ _git_config ()
diff.ignoreSubmodules
diff.mnemonicprefix
diff.noprefix
- diff.renameLimit
+ diff.renamelimit
diff.renames
diff.suppressBlankEmpty
diff.tool
@@ -2218,7 +2218,7 @@ _git_config ()
merge.
merge.conflictstyle
merge.log
- merge.renameLimit
+ merge.renamelimit
merge.renormalize
merge.stat
merge.tool
--
^ permalink raw reply related
* Re: [RFD] Handling of non-UTF8 data in gitweb
From: Jakub Narebski @ 2011-12-18 22:00 UTC (permalink / raw)
To: Junio C Hamano
Cc: git, Jürgen Kreileder, John Hawley, Ismail Dönmez
In-Reply-To: <7vehwhcj3q.fsf@alter.siamese.dyndns.org>
On Wed, 7 Dec 2011, Junio C Hamano wrote:
> Jakub Narebski <jnareb@gmail.com> writes:
>
> > But doing this would change gitweb behavior. Currently when
> > encountering something (usually line of output) that is not valid
> > UTF-8, we decode it (to UTF-8) using $fallback_encoding, by default
> > 'latin1'. Note however that this value is per gitweb installation,
> > not per repository.
>
> I think we added and you acked 00f429a (gitweb: Handle non UTF-8 text
> better, 2007-06-03) for a good reason, and I think the above argues that
> whatever issue the commit tried to address is a non-issue. Is it really
> true?
Actually... the change in
00f429a (gitweb: Handle non UTF-8 text better, 2007-06-03)
worked correctly, but since
e5d3de5 (gitweb: use Perl built-in utf8 function for UTF-8 decoding., 2007-12-04)
it was changed to a NON-WORKING version - and *nobody* protested.
sub to_utf8 {
my $str = shift;
- my $res;
- eval { $res = decode_utf8($str, Encode::FB_CROAK); };
- if (defined $res) {
- return $res;
+ if (utf8::valid($str)) {
+ utf8::decode($str);
+ return $str;
} else {
return decode($fallback_encoding, $str, Encode::FB_DEFAULT);
}
Well, it works for utf8 and latin1 _only_ (with $fallback_encoding being
set to 'latin1' by default), and for latin1 by historical accident... that
might be why nobody noticed. $fallback_encoding != 'latin1' or 'utf8'
didn't work.
utf8::valid(STRING) is an internal function that tests whether STRING is
in a consistent state regarding UTF-8. It returns true is well-formed
UTF-8 and has the UTF-8 flag on _or_ if string is held as bytes (both
these states are 'consistent'). For gitweb the second option was true.
Note that utf8:decode(STRING) returns false if STRING is invalid as UTF-8.
What makes it all work is the fact that utf8:decode(STRING) turns on UTF-8
flag only if source string is valid UTF-8 and contains multi-byte UTF-8
characters... and that if string doesn't have UTF-8 flag set it is treated
as in native Perl encoding, i.e. 'latin1' / 'iso-8859-1' (unless it is EBCDIC).
It is ':utf8' layer that actually convert 'latin1' to 'utf8'.
-- >8 --
Subject: [PATCH] gitweb: Fix fallback mode of to_utf8 subroutine
e5d3de5 (gitweb: use Perl built-in utf8 function for UTF-8 decoding.,
2007-12-04) was meant to make gitweb faster by using Perl's internals
(see subsection "Messing with Perl's Internals" in Encode(3pm) manpage)
Simple benchmark confirms that (old = 00f429a, new = this version):
old new
old -- -65%
new 189% --
Unfortunately it made fallback mode of to_utf8 do not work... except
for default value 'latin1' of $fallback_encoding ('latin1' is Perl
native encoding), which is why it was not noticed for such long time.
utf8::valid(STRING) is an internal function that tests whether STRING
is in a _consistent state_ regarding UTF-8. It returns true is
well-formed UTF-8 and has the UTF-8 flag on _*or*_ if string is held
as bytes (both these states are 'consistent'). For gitweb the second
option was true, as output from git commands is opened without ':utf8'
layer.
What made it work at all for STRING in 'latin1' encoding is the fact
that utf8:decode(STRING) turns on UTF-8 flag only if source string is
valid UTF-8 and contains multi-byte UTF-8 characters... and that if
string doesn't have UTF-8 flag set it is treated as in native Perl
encoding, i.e. 'latin1' / 'iso-8859-1' (unless native encoding it is
EBCDIC ;-)). It was ':utf8' layer that actually converted 'latin1'
(no UTF-8 flag == native == 'latin1) to 'utf8'.
Let's make use of the fact that utf8:decode(STRING) returns false if
STRING is invalid as UTF-8 to check whether to enable fallback mode.
Signed-off-by: Jakub Narebski <jnareb@gmail.com>
---
I'm sorry for overly wordy commit message...
gitweb/gitweb.perl | 3 +--
1 files changed, 1 insertions(+), 2 deletions(-)
diff --git a/gitweb/gitweb.perl b/gitweb/gitweb.perl
index d24763b..75b0970 100755
--- a/gitweb/gitweb.perl
+++ b/gitweb/gitweb.perl
@@ -1443,8 +1443,7 @@ sub validate_refname {
sub to_utf8 {
my $str = shift;
return undef unless defined $str;
- if (utf8::valid($str)) {
- utf8::decode($str);
+ if (utf8::valid($str) && utf8::decode($str)) {
return $str;
} else {
return decode($fallback_encoding, $str, Encode::FB_DEFAULT);
--
1.7.6
^ permalink raw reply related
* Re: [PATCHv3 02/11] git-p4: test debug macro
From: Junio C Hamano @ 2011-12-18 21:48 UTC (permalink / raw)
To: Pete Wyckoff; +Cc: Jonathan Nieder, Luke Diamand, git
In-Reply-To: <20111218140633.GB16487@padd.com>
Pete Wyckoff <pw@padd.com> writes:
> 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>
> ---
...
> 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
> +...
> +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
> +}
> +
You may have found this handy yourself, but I would rather not to see it
here in the current form for multiple reasons.
- Why "ctrl-c"? You are not even spawning shell from here but are having
the user interact with this state in the middle of a test from another
shell, no?
Why not "When done, type <RET>" and have a "read junk" or something
instead? That would be a lot simpler and you do not have to worry about
portability with many lines of comments.
An alternative is to spawn an interactive shell here, and change the
"Debug me" comment to say "ctrl-d when done".
- This is not linked to the generic "debug" option "txxxx-name.sh -d".
Shouldn't you be extending test_debug so that it can go interactive,
give customized comments&insns (i.e. "cd $here" may be useful for test
scripts outside testing p4, but "P4PORT=..." would not be, so the user
of test_debug in t9800-git-p4.* needs customizability of the message).
Also could we please rename p4 related tests in t/t98* series so that it
is clear that they are about git-p4 from "ls t/" output (i.e. have them
all have "git-p4" in their names)?
^ permalink raw reply
* 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
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