* 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
* 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
* [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: [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 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: 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
* 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: 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 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
* [PATCH 1/2] advice: Document that they all default to true
From: Junio C Hamano @ 2011-12-19 5:35 UTC (permalink / raw)
To: git; +Cc: Jeff King
In-Reply-To: <7vliq9nn0l.fsf@alter.siamese.dyndns.org>
By definition, the default value of "advice.*" variables must be true and
they all control various additional help messages that are designed to aid
new users. Setting one to false is to tell Git that the user understands
the nature of the error and does not need the additional verbose help
message.
Also fix the asciidoc markup for linkgit:git-checkout[1] in the
description of the detachedHead advice by removing an excess colon.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
---
Documentation/config.txt | 19 ++++++++-----------
1 files changed, 8 insertions(+), 11 deletions(-)
diff --git a/Documentation/config.txt b/Documentation/config.txt
index 8a7d2d4..9be7106 100644
--- a/Documentation/config.txt
+++ b/Documentation/config.txt
@@ -115,35 +115,32 @@ in the appropriate manual page. You will find a description of non-core
porcelain configuration variables in the respective porcelain documentation.
advice.*::
- When set to 'true', display the given optional help message.
- When set to 'false', do not display. The configuration variables
- are:
+ These variables control various optional help messages designed to
+ aid new users. All 'advice.*' variables default to 'true', and you
+ can tell Git that you do not need help by setting these to 'false':
+
--
pushNonFastForward::
Advice shown when linkgit:git-push[1] refuses
- non-fast-forward refs. Default: true.
+ non-fast-forward refs.
statusHints::
Directions on how to stage/unstage/add shown in the
output of linkgit:git-status[1] and the template shown
- when writing commit messages. Default: true.
+ when writing commit messages.
commitBeforeMerge::
Advice shown when linkgit:git-merge[1] refuses to
merge to avoid overwriting local changes.
- Default: true.
resolveConflict::
Advices shown by various commands when conflicts
prevent the operation from being performed.
- Default: true.
implicitIdentity::
Advice on how to set your identity configuration when
your information is guessed from the system username and
- domain name. Default: true.
-
+ domain name.
detachedHead::
- Advice shown when you used linkgit::git-checkout[1] to
+ Advice shown when you used linkgit:git-checkout[1] to
move to the detach HEAD state, to instruct how to create
- a local branch after the fact. Default: true.
+ a local branch after the fact.
--
core.fileMode::
--
1.7.8.370.gb3269
^ permalink raw reply related
* [PATCH 2/2] push: hint to use push.default=upstream when appropriate
From: Junio C Hamano @ 2011-12-19 5:38 UTC (permalink / raw)
To: git; +Cc: Jeff King
In-Reply-To: <7vliq9nn0l.fsf@alter.siamese.dyndns.org>
If you push into a shared repository that others push to, and you have
local branches in your repository that matches the remote side but do not
keep them up-to-date, then 'matching refs' is not an appropriate default
for you.
Detect when push failed due to non-fast-forward _and_ we did matching refs
by default (i.e. if the user explicitly said ':' from the command line, or
had push.default set to 'matching', then we do not want to advise), and
give a hint to tell the user that the user may want to set 'push.default'
configuration variable to 'upstream', if the remote repository receives
pushes from other places.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
---
Documentation/config.txt | 6 ++++++
advice.c | 2 ++
advice.h | 1 +
builtin/push.c | 25 +++++++++++++++++++++++++
cache.h | 3 ++-
environment.c | 2 +-
6 files changed, 37 insertions(+), 2 deletions(-)
diff --git a/Documentation/config.txt b/Documentation/config.txt
index 9be7106..8da7063 100644
--- a/Documentation/config.txt
+++ b/Documentation/config.txt
@@ -141,6 +141,12 @@ advice.*::
Advice shown when you used linkgit:git-checkout[1] to
move to the detach HEAD state, to instruct how to create
a local branch after the fact.
+ pushUseUpstream::
+ Advice to set 'push.default' to 'upstream' when you ran
+ linkgit:git-push[1] and pushed 'matching refs' by default
+ (i.e. you did not have any explicit refspec on the command
+ line, and no 'push.default' configuration was set) and it
+ resulted in a non-fast-forward error.
--
core.fileMode::
diff --git a/advice.c b/advice.c
index e02e632..9b56709 100644
--- a/advice.c
+++ b/advice.c
@@ -6,6 +6,7 @@ int advice_commit_before_merge = 1;
int advice_resolve_conflict = 1;
int advice_implicit_identity = 1;
int advice_detached_head = 1;
+int advice_push_use_upstream = 1;
static struct {
const char *name;
@@ -17,6 +18,7 @@ static struct {
{ "resolveconflict", &advice_resolve_conflict },
{ "implicitidentity", &advice_implicit_identity },
{ "detachedhead", &advice_detached_head },
+ { "pushuseupstream", &advice_push_use_upstream },
};
void advise(const char *advice, ...)
diff --git a/advice.h b/advice.h
index e5d0af7..6bb89cd 100644
--- a/advice.h
+++ b/advice.h
@@ -9,6 +9,7 @@ extern int advice_commit_before_merge;
extern int advice_resolve_conflict;
extern int advice_implicit_identity;
extern int advice_detached_head;
+extern int advice_push_use_upstream;
int git_default_advice_config(const char *var, const char *value);
void advise(const char *advice, ...);
diff --git a/builtin/push.c b/builtin/push.c
index 35cce53..5f8c7f4 100644
--- a/builtin/push.c
+++ b/builtin/push.c
@@ -9,6 +9,7 @@
#include "transport.h"
#include "parse-options.h"
#include "submodule.h"
+#include "advice.h"
static const char * const push_usage[] = {
"git push [<options>] [<repository> [<refspec>...]]",
@@ -24,6 +25,7 @@ static int progress;
static const char **refspec;
static int refspec_nr;
static int refspec_alloc;
+static int default_matching_used;
static void add_refspec(const char *ref)
{
@@ -95,6 +97,9 @@ static void setup_default_push_refspecs(struct remote *remote)
{
switch (push_default) {
default:
+ case PUSH_DEFAULT_UNSPECIFIED:
+ default_matching_used = 1;
+ /* fallthru */
case PUSH_DEFAULT_MATCHING:
add_refspec(":");
break;
@@ -114,6 +119,23 @@ static void setup_default_push_refspecs(struct remote *remote)
}
}
+static const char *message_advice_use_upstream[] = {
+ "If you are pushing into a repository that receives pushes from",
+ "repositories other than the current repository, you may want to",
+ "set 'push.default' configuration variable to 'upstream' to avoid",
+ "pushing branches you haven't worked on that others have updated.",
+};
+
+static void advise_use_upstream(void)
+{
+ int i;
+
+ if (!advice_push_use_upstream)
+ return;
+ for (i = 0; i < ARRAY_SIZE(message_advice_use_upstream); i++)
+ advise(message_advice_use_upstream[i]);
+}
+
static int push_with_options(struct transport *transport, int flags)
{
int err;
@@ -136,6 +158,9 @@ static int push_with_options(struct transport *transport, int flags)
err |= transport_disconnect(transport);
+ if (nonfastforward && default_matching_used)
+ advise_use_upstream();
+
if (!err)
return 0;
diff --git a/cache.h b/cache.h
index 627fb6a..6c86725 100644
--- a/cache.h
+++ b/cache.h
@@ -624,7 +624,8 @@ enum push_default_type {
PUSH_DEFAULT_NOTHING = 0,
PUSH_DEFAULT_MATCHING,
PUSH_DEFAULT_UPSTREAM,
- PUSH_DEFAULT_CURRENT
+ PUSH_DEFAULT_CURRENT,
+ PUSH_DEFAULT_UNSPECIFIED
};
extern enum branch_track git_branch_track;
diff --git a/environment.c b/environment.c
index c93b8f4..d7e6c65 100644
--- a/environment.c
+++ b/environment.c
@@ -52,7 +52,7 @@ enum safe_crlf safe_crlf = SAFE_CRLF_WARN;
unsigned whitespace_rule_cfg = WS_DEFAULT_RULE;
enum branch_track git_branch_track = BRANCH_TRACK_REMOTE;
enum rebase_setup_type autorebase = AUTOREBASE_NEVER;
-enum push_default_type push_default = PUSH_DEFAULT_MATCHING;
+enum push_default_type push_default = PUSH_DEFAULT_UNSPECIFIED;
#ifndef OBJECT_CREATION_MODE
#define OBJECT_CREATION_MODE OBJECT_CREATION_USES_HARDLINKS
#endif
--
1.7.8.370.gb3269
^ permalink raw reply related
* What's cooking in git.git (Dec 2011, #06; Sun, 18)
From: Junio C Hamano @ 2011-12-19 5:57 UTC (permalink / raw)
To: git
Here are the topics that have been cooking. Commits prefixed with '-' are
only in 'pu' (proposed updates) while commits prefixed with '+' are in
'next'.
A handful of topics have graduated to 'master', but they are all minor.
More important features for 1.7.9 will come in the next batch (marked as
'Will merge to "master"' below), which should happen in a couple of days;
Peff's credential series is among them.
Here are the repositories that have my integration branches:
With maint, master, next, pu, todo:
git://git.kernel.org/pub/scm/git/git.git
git://repo.or.cz/alt-git.git
https://code.google.com/p/git-core/
https://github.com/git/git
With only maint and master:
git://git.sourceforge.jp/gitroot/git-core/git.git
git://git-core.git.sourceforge.net/gitroot/git-core/git-core
With all the topics and integration branches:
https://github.com/gitster/git
The preformatted documentation in HTML and man format are found in:
git://git.kernel.org/pub/scm/git/git-{htmldocs,manpages}.git/
git://repo.or.cz/git-{htmldocs,manpages}.git/
https://code.google.com/p/git-{htmldocs,manpages}.git/
https://github.com/gitster/git-{htmldocs,manpages}.git/
--------------------------------------------------
[Graduated to "master"]
* aw/rebase-i-stop-on-failure-to-amend (2011-11-30) 1 commit
(merged to 'next' on 2011-12-09 at a117e83)
+ rebase -i: interrupt rebase when "commit --amend" failed during "reword"
* jc/commit-amend-no-edit (2011-12-08) 5 commits
(merged to 'next' on 2011-12-09 at b9cfa4e)
+ test: commit --amend should honor --no-edit
+ commit: honour --no-edit
+ t7501 (commit): modernize style
+ test: remove a porcelain test that hard-codes commit names
+ test: add missing "&&" after echo command
* jc/stream-to-pack (2011-12-01) 5 commits
(merged to 'next' on 2011-12-09 at d0fd605)
+ bulk-checkin: replace fast-import based implementation
+ csum-file: introduce sha1file_checkpoint
+ finish_tmp_packfile(): a helper function
+ create_tmp_packfile(): a helper function
+ write_pack_header(): a helper function
(this branch is used by jc/split-blob.)
Teaches "git add" to send large-ish blob data straight to a packfile.
This is a continuation to the "large file support" topic. The codepath to
move data from worktree to repository is made aware of streaming, just
like the checkout codepath that goes the other way, which was done in the
previous "large file support" topic in the 1.7.7 cycle.
* jh/fast-import-notes (2011-11-28) 3 commits
(merged to 'next' on 2011-12-09 at 2b01132)
+ fast-import: Fix incorrect fanout level when modifying existing notes refs
+ t9301: Add 2nd testcase exposing bugs in fast-import's notes fanout handling
+ t9301: Fix testcase covering up a bug in fast-import's notes fanout handling
* jk/upload-archive-use-start-command (2011-11-21) 1 commit
(merged to 'next' on 2011-12-09 at 88cb83a)
+ upload-archive: use start_command instead of fork
--------------------------------------------------
[New Topics]
* cn/maint-lf-to-crlf-filter (2011-12-16) 1 commit
- lf_to_crlf_filter(): tell the caller we added "\n" when draining
(this branch is used by jc/maint-lf-to-crlf-keep-crlf.)
A recent fix to the codepath was not quite correct.
Will merge to "next".
* jc/maint-lf-to-crlf-keep-crlf (2011-12-18) 1 commit
- lf_to_crlf_filter(): resurrect CRLF->CRLF hack
(this branch uses cn/maint-lf-to-crlf-filter.)
The lf-to-crlf filter in the streaming checkout codepath forgot that we
try not to convert LF to CRLF if the repository data already has CRLF.
Will merge to "next".
* jc/request-pull-show-head-4 (2011-12-16) 1 commit
(merged to 'next' on 2011-12-16 at bea51ac)
+ request-pull: update the "pull" command generation logic
Will merge to "master".
* jk/doc-fsck (2011-12-16) 1 commit
- docs: brush up obsolete bits of git-fsck manpage
Will merge to "next".
* jk/follow-rename-score (2011-12-16) 1 commit
- use custom rename score during --follow
Will merge to "next".
* jk/pretty-reglog-ent (2011-12-16) 1 commit
- pretty: give placeholders to reflog identity
Will merge to "next".
* jk/http-push-to-empty (2011-12-17) 1 commit
- remote-curl: don't pass back fake refs
Will merge to "next".
* jk/maint-push-v-is-verbose (2011-12-17) 1 commit
- make "git push -v" actually verbose
Will merge to "next".
* jk/maint-strbuf-missing-init (2011-12-18) 2 commits
- Update jk/maint-strbuf-missing-init to builtin/ rename
- commit, merge: initialize static strbuf
Will merge to "next".
* rs/diff-tree-combined-clean-up (2011-12-17) 3 commits
- submodule: use diff_tree_combined_merge() instead of diff_tree_combined()
- pass struct commit to diff_tree_combined_merge()
- use struct sha1_array in diff_tree_combined()
Will merge to "next".
* jn/maint-gitweb-utf8-fix (2011-12-18) 4 commits
- gitweb: Fix fallback mode of to_utf8 subroutine
- gitweb: Output valid utf8 in git_blame_common('data')
- gitweb: esc_html() site name for title in OPML
- gitweb: Call to_utf8() on input string in chop_and_escape_str()
Will merge to "next".
* pw/p4-docs-and-tests (2011-12-18) 11 commits
- git-p4: document and test submit options
- git-p4: test and document --use-client-spec
- git-p4: test --keep-path
- git-p4: test --max-changes
- git-p4: document and test --import-local
- git-p4: honor --changesfile option and test
- git-p4: document and test clone --branch
- git-p4: test cloning with two dirs, clarify doc
- git-p4: clone does not use --git-dir
- git-p4: test debug macro
- git-p4: introduce asciidoc documentation
* jc/advise-push-default (2011-12-18) 2 commits
- push: hint to use push.default=upstream when appropriate
- advice: Document that they all default to true
A counter-proposal to jc/push-ignore-stale that may encourage a bad
workflow.
--------------------------------------------------
[Cooking]
* ef/setenv-putenv (2011-12-14) 2 commits
- compat/setenv.c: error if name contains '='
- compat/setenv.c: update errno when erroring out
(this branch is used by ef/x-setenv-putenv.)
Will merge to "next".
* jk/maint-do-not-feed-stdin-to-tests (2011-12-15) 1 commit
- test-lib: redirect stdin of tests
Will merge to "next".
* jn/test-cleanup-7006 (2011-12-14) 1 commit
- test: errors preparing for a test are not special
Will merge to "next".
* nd/war-on-nul-in-commit (2011-12-15) 3 commits
- commit_tree(): refuse commit messages that contain NULs
- Convert commit_tree() to take strbuf as message
- merge: abort if fails to commit
Will merge to "next".
* jk/git-prompt (2011-12-12) 10 commits
- contrib: add credential helper for OS X Keychain
- Makefile: OS X has /dev/tty
- Makefile: linux has /dev/tty
- credential: use git_prompt instead of git_getpass
- prompt: use git_terminal_prompt
- add generic terminal prompt function
- refactor git_getpass into generic prompt function
- move git_getpass to its own source file
- imap-send: don't check return value of git_getpass
- imap-send: avoid buffer overflow
(this branch uses jk/credentials.)
Will merge to 'next' after taking another look.
* mh/ref-api-rest (2011-12-12) 35 commits
- repack_without_ref(): call clear_packed_ref_cache()
- read_packed_refs(): keep track of the directory being worked in
- is_refname_available(): query only possibly-conflicting references
- refs: read loose references lazily
- read_loose_refs(): take a (ref_entry *) as argument
- struct ref_dir: store a reference to the enclosing ref_cache
- sort_ref_dir(): take (ref_entry *) instead of (ref_dir *)
- do_for_each_ref_in_dir*(): take (ref_entry *) instead of (ref_dir *)
- add_entry(): take (ref_entry *) instead of (ref_dir *)
- search_ref_dir(): take (ref_entry *) instead of (ref_dir *)
- find_containing_direntry(): use (ref_entry *) instead of (ref_dir *)
- add_ref(): take (ref_entry *) instead of (ref_dir *)
- read_packed_refs(): take (ref_entry *) instead of (ref_dir *)
- find_ref(): take (ref_entry *) instead of (ref_dir *)
- is_refname_available(): take (ref_entry *) instead of (ref_dir *)
- get_loose_refs(): return (ref_entry *) instead of (ref_dir *)
- get_packed_refs(): return (ref_entry *) instead of (ref_dir *)
- refs: wrap top-level ref_dirs in ref_entries
- get_ref_dir(): keep track of the current ref_dir
- do_for_each_ref(): only iterate over the subtree that was requested
- refs: sort ref_dirs lazily
- sort_ref_dir(): do not sort if already sorted
- refs: store references hierarchically
- refs.c: rename ref_array -> ref_dir
- struct ref_entry: nest the value part in a union
- check_refname_component(): return 0 for zero-length components
- free_ref_entry(): new function
- refs.c: reorder definitions more logically
- is_refname_available(): reimplement using do_for_each_ref_in_array()
- names_conflict(): simplify implementation
- names_conflict(): new function, extracted from is_refname_available()
- repack_without_ref(): reimplement using do_for_each_ref_in_array()
- do_for_each_ref_in_arrays(): new function
- do_for_each_ref_in_array(): new function
- do_for_each_ref(): correctly terminate while processesing extra_refs
(this branch uses mh/ref-api.)
The API for extra anchoring points may require rethought first; that would
hopefully make the "ref" part a lot simpler.
* ci/stripspace-docs (2011-12-12) 1 commit
(merged to 'next' on 2011-12-13 at 35b2cdf)
+ Update documentation for stripspace
Will merge to "master".
* jk/maint-mv (2011-12-12) 5 commits
(merged to 'next' on 2011-12-13 at 58caedb)
+ mv: be quiet about overwriting
+ mv: improve overwrite warning
+ mv: make non-directory destination error more clear
+ mv: honor --verbose flag
+ docs: mention "-k" for both forms of "git mv"
Will merge to "master".
* jk/maint-snprintf-va-copy (2011-12-12) 1 commit
(merged to 'next' on 2011-12-13 at d37a7e1)
+ compat/snprintf: don't look at va_list twice
Will merge to "master".
* jn/maint-sequencer-fixes (2011-12-12) 7 commits
(merged to 'next' on 2011-12-13 at 5b3950c)
+ revert: stop creating and removing sequencer-old directory
+ Revert "reset: Make reset remove the sequencer state"
+ revert: do not remove state until sequence is finished
+ revert: allow single-pick in the middle of cherry-pick sequence
+ revert: pass around rev-list args in already-parsed form
+ revert: allow cherry-pick --continue to commit before resuming
+ revert: give --continue handling its own function
(this branch is used by rr/revert-cherry-pick.)
Will merge to "master".
* mh/ref-api (2011-12-12) 16 commits
(merged to 'next' on 2011-12-15 at d65a830)
+ add_ref(): take a (struct ref_entry *) parameter
+ create_ref_entry(): extract function from add_ref()
+ repack_without_ref(): remove temporary
+ resolve_gitlink_ref_recursive(): change to work with struct ref_cache
+ Pass a (ref_cache *) to the resolve_gitlink_*() helper functions
+ resolve_gitlink_ref(): improve docstring
+ get_ref_dir(): change signature
+ refs: change signatures of get_packed_refs() and get_loose_refs()
+ is_dup_ref(): extract function from sort_ref_array()
+ add_ref(): add docstring
+ parse_ref_line(): add docstring
+ is_refname_available(): remove the "quiet" argument
+ clear_ref_array(): rename from free_ref_array()
+ refs: rename parameters result -> sha1
+ refs: rename "refname" variables
+ struct ref_entry: document name member
(this branch is used by mh/ref-api-rest.)
Later part split out to expedite moving the earlier good bits forward.
Will merge to "master".
* nd/resolve-ref (2011-12-13) 3 commits
(merged to 'next' on 2011-12-13 at c7002e9)
+ Rename resolve_ref() to resolve_ref_unsafe()
+ Convert resolve_ref+xstrdup to new resolve_refdup function
+ revert: convert resolve_ref() to read_ref_full()
Will merge to "master".
* tr/grep-threading (2011-12-16) 3 commits
- grep: disable threading in non-worktree case
- grep: enable threading with -p and -W using lazy attribute lookup
- grep: load funcname patterns for -W
Will merge to 'next' after taking another look.
* tr/pty-all (2011-12-12) 3 commits
- t/lib-terminal: test test-terminal's sanity
- test-terminal: set output terminals to raw mode
- test-terminal: give the child an empty stdin TTY
The test breakage that originally triggered interest in this topic is
fixed more cleanly with Peff's jk/maint-do-not-feed-stdin-to-tests but
this series may independently be useful.
Jonathan had good review comments, and this would need to be rerolled.
* jc/push-ignore-stale (2011-12-14) 2 commits
- push: --ignore-stale option
- set_ref_status_for_push(): use transport-flags abstraction
Probably solving a wrong problem and encouraging a wrong workflow while at
it. Will drop. jc/advise-push-default might be a better approach.
* jk/fetch-no-tail-match-refs (2011-12-13) 4 commits
(merged to 'next' on 2011-12-13 at 805c018)
+ connect.c: drop path_match function
+ fetch-pack: match refs exactly
+ t5500: give fully-qualified refs to fetch-pack
+ drop "match" parameter from get_remote_heads
Will merge to "master".
* jk/maint-push-over-dav (2011-12-13) 2 commits
(merged to 'next' on 2011-12-13 at 45e376c)
+ http-push: enable "proactive auth"
+ t5540: test DAV push with authentication
Will merge to "master".
* rr/revert-cherry-pick (2011-12-15) 6 commits
- t3502, t3510: clarify cherry-pick -m failure
- t3510 (cherry-pick-sequencer): use exit status
- revert: simplify getting commit subject in format_todo()
- revert: tolerate extra spaces, tabs in insn sheet
- revert: make commit subjects in insn sheet optional
- revert: free msg in format_todo()
(this branch uses jn/maint-sequencer-fixes.)
Picked up only the earlier bits that are reasonably clear for now.
Will merge to "next".
* ew/keepalive (2011-12-05) 1 commit
(merged to 'next' on 2011-12-13 at 1b5d5c4)
+ enable SO_KEEPALIVE for connected TCP sockets
* jc/checkout-m-twoway (2011-12-15) 3 commits
(merged to 'next' on 2011-12-15 at cc64fed)
+ checkout_merged(): squelch false warning from some gcc
(merged to 'next' on 2011-12-11 at b61057f)
+ Test 'checkout -m -- path'
(merged to 'next' on 2011-12-09 at c946009)
+ checkout -m: no need to insist on having all 3 stages
Will merge to "master".
* tr/cache-tree (2011-12-06) 5 commits
(merged to 'next' on 2011-12-13 at e0da64d)
+ reset: update cache-tree data when appropriate
+ commit: write cache-tree data when writing index anyway
+ Refactor cache_tree_update idiom from commit
+ Test the current state of the cache-tree optimization
+ Add test-scrap-cache-tree
Will merge to "master".
* rr/test-chaining (2011-12-11) 7 commits
(merged to 'next' on 2011-12-13 at b08445e)
+ t3401: use test_commit in setup
+ t3401: modernize style
+ t3040 (subprojects-basic): fix '&&' chaining, modernize style
+ t1510 (worktree): fix '&&' chaining
+ t3030 (merge-recursive): use test_expect_code
+ test: fix '&&' chaining
+ t3200 (branch): fix '&&' chaining
Will merge to "master".
* jc/split-blob (2011-12-01) 6 commits
. WIP (streaming chunked)
- chunked-object: fallback checkout codepaths
- bulk-checkin: support chunked-object encoding
- bulk-checkin: allow the same data to be multiply hashed
- new representation types in the packstream
- varint-in-pack: refactor varint encoding/decoding
Not ready. At least pack-objects and fsck need to learn the new encoding
for the series to be usable locally, and then index-pack/unpack-objects
needs to learn it to be used remotely.
* jk/credentials (2011-12-12) 14 commits
(merged to 'next' on 2011-12-12 at 7a6d658)
+ t: add test harness for external credential helpers
+ credentials: add "store" helper
+ strbuf: add strbuf_add*_urlencode
+ Makefile: unix sockets may not available on some platforms
+ credentials: add "cache" helper
+ docs: end-user documentation for the credential subsystem
+ credential: make relevance of http path configurable
+ credential: add credential.*.username
+ credential: apply helper config
+ http: use credential API to get passwords
+ credential: add function for parsing url components
+ introduce credentials API
+ t5550: fix typo
+ test-lib: add test_config_global variant
(this branch is used by jk/git-prompt.)
Later part split out to expedite moving the earlier good bits forward.
Will merge to "master".
* ab/enable-i18n (2011-12-05) 1 commit
(merged to 'next' on 2011-12-13 at 65af8cd)
+ i18n: add infrastructure for translating Git with gettext
* jc/signed-commit (2011-11-29) 5 commits
- gpg-interface: allow use of a custom GPG binary
- pretty: %G[?GS] placeholders
- test "commit -S" and "log --show-signature"
- log: --show-signature
- commit: teach --gpg-sign option
Not exactly urgent.
^ permalink raw reply
* Re: best way to fastforward all tracking branches after a fetch
From: Nazri Ramliy @ 2011-12-19 6:31 UTC (permalink / raw)
To: Sitaram Chamarty; +Cc: Gelonida N, git
In-Reply-To: <20111217101106.GB19248@sita-lt.atc.tcs.com>
On Sat, Dec 17, 2011 at 6:11 PM, Sitaram Chamarty <sitaramc@gmail.com> wrote:
> oops; forgot the program...
This is nice!
Stick it on github, or somewhere, please, so that I can always get the
latest and greatest?
Thanks.
nazri
^ permalink raw reply
* Re: post-receive for web deployment
From: Johannes Sixt @ 2011-12-19 6:55 UTC (permalink / raw)
To: Stephen Major; +Cc: git
In-Reply-To: <CALzTOm+sJHF_7WzjD7bCqAiAbQSV0A3hEX1KdWfFzV7-ePzX2w@mail.gmail.com>
Am 12/19/2011 3:42, schrieb Stephen Major:
> checking the remote server files 4 5 6 are still found in:
> /home/user/domains/domain.com/public_html/live
>
> Why is this happening?
Before you check out the files, you must ensure that the index matches the
content in the GIT_WORK_TREE that you populate by git checkout.
You first push a tree that removes 4 5 6 while the index you happen to
have still has those files recorded, the files are removed. Your second
push does not have these files anymore, but the index does not record the
files anymore, either; therefore, git does not act on the files 4 5 6 that
happen to live in the other worktree.
Perhaps you should maintain separate index files and set GIT_INDEX_FILE
accordingly before git checkout.
-- Hannes
^ permalink raw reply
* [PATCH] git-svn: Fix time zone in --localtime
From: "Wei-Yin Chen (陳威尹)" @ 2011-12-19 8:11 UTC (permalink / raw)
To: git; +Cc: Pete Harlan, Eric Wong, gitster
Use numerical form of time zone to replace alphabetic time zone
abbreviation generated by "%Z". "%Z" is not portable and contain
ambiguity for many areas. For example, CST could be "Central
Standard Time" (GMT-0600) and "China Standard Time" (GMT+0800).
Alphabetic time zone abbreviation is meant for human readability,
not for specifying a time zone for machines.
Failed case can be illustrated like this in linux shell:
> echo $TZ
Asia/Taipei
> date +%Z
CST
> env TZ=`date +%Z` date
Mon Dec 19 06:03:04 CST 2011
> date
Mon Dec 19 14:03:04 CST 2011
Signed-off-by: Wei-Yin Chen (陳威尹) <chen.weiyin@gmail.com>
---
git-svn.perl | 18 +++++++++++-------
1 files changed, 11 insertions(+), 7 deletions(-)
diff --git a/git-svn.perl b/git-svn.perl
index e30df22..f0b6340 100755
--- a/git-svn.perl
+++ b/git-svn.perl
@@ -2029,6 +2029,7 @@ use Carp qw/croak/;
use File::Path qw/mkpath/;
use File::Copy qw/copy/;
use IPC::Open3;
+use Time::Local;
use Memoize; # core since 5.8.0, Jul 2002
use Memoize::Storable;
@@ -3287,6 +3288,14 @@ sub get_untracked {
\@out;
}
+sub get_tz {
+ # some systmes don't handle or mishandle %z, so be creative.
+ my $t = shift || time;
+ my $gm = timelocal(gmtime($t));
+ my $sign = qw( + + - )[ $t <=> $gm ];
+ return sprintf("%s%02d%02d", $sign, (gmtime(abs($t - $gm)))[2,1]);
+}
+
# parse_svn_date(DATE)
# --------------------
# Given a date (in UTC) from Subversion, return a string in the format
@@ -3319,8 +3328,7 @@ sub parse_svn_date {
delete $ENV{TZ};
}
- my $our_TZ =
- POSIX::strftime('%Z', $S, $M, $H, $d, $m - 1, $Y - 1900);
+ my $our_TZ = get_tz();
# This converts $epoch_in_UTC into our local timezone.
my ($sec, $min, $hour, $mday, $mon, $year,
@@ -5994,7 +6002,6 @@ package Git::SVN::Log;
use strict;
use warnings;
use POSIX qw/strftime/;
-use Time::Local;
use constant commit_log_separator => ('-' x 72) . "\n";
use vars qw/$TZ $limit $color $pager $non_recursive $verbose $oneline
%rusers $show_commit $incremental/;
@@ -6104,11 +6111,8 @@ sub run_pager {
}
sub format_svn_date {
- # some systmes don't handle or mishandle %z, so be creative.
my $t = shift || time;
- my $gm = timelocal(gmtime($t));
- my $sign = qw( + + - )[ $t <=> $gm ];
- my $gmoff = sprintf("%s%02d%02d", $sign, (gmtime(abs($t - $gm)))[2,1]);
+ my $gmoff = get_tz($t);
return strftime("%Y-%m-%d %H:%M:%S $gmoff (%a, %d %b %Y)", localtime($t));
}
^ permalink raw reply related
* Re: [PATCH 1/2] advice: Document that they all default to true
From: Jeff King @ 2011-12-19 9:37 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vhb0xnmyi.fsf_-_@alter.siamese.dyndns.org>
On Sun, Dec 18, 2011 at 09:35:01PM -0800, Junio C Hamano wrote:
> By definition, the default value of "advice.*" variables must be true and
> they all control various additional help messages that are designed to aid
> new users. Setting one to false is to tell Git that the user understands
> the nature of the error and does not need the additional verbose help
> message.
>
> Also fix the asciidoc markup for linkgit:git-checkout[1] in the
> description of the detachedHead advice by removing an excess colon.
Makes sense.
Acked-by: Jeff King <peff@peff.net>
-Peff
^ permalink raw reply
* Re: git 1.7.7.5
From: Thomas Jarosch @ 2011-12-19 9:41 UTC (permalink / raw)
To: Jonathan Nieder; +Cc: Junio C Hamano, git
In-Reply-To: <20111216105757.GA11174@elie.hsd1.il.comcast.net>
On Friday, 16. December 2011 11:57:58 Jonathan Nieder wrote:
> I noticed that v1.7.7.5 was tagged a few days ago (b36dcd72), but
> there is no corresponding tarball at
>
> http://code.google.com/p/git-core/downloads/list
>
> Will there be an official tarball?
>
> I don't mind either way, but it would be useful to know whether
> distributors should make their own or just wait.
Looks like a bug, the front page of "git-scm.com" also shows 1.7.7.5
as latest stable release and leads to a dead link.
Cheers,
Thomas
^ permalink raw reply
* Re: [PATCH] lf_to_crlf_filter(): tell the caller we added "\n" when draining
From: Henrik Grubbström @ 2011-12-19 10:19 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Git Mailing list, Carlos Martín Nieto
In-Reply-To: <7vaa6sgmt3.fsf_-_@alter.siamese.dyndns.org>
[-- Attachment #1: Type: TEXT/PLAIN, Size: 532 bytes --]
On Fri, 16 Dec 2011, Junio C Hamano wrote:
> This can only happen when the input size is multiple of the
> buffer size of the cascade filter (16k) and ends with an LF,
> but in such a case, the code forgot to tell the caller that
> it added the "\n" it could not add during the last round.
We probably ought to have a corresponding test in the testsuite.
A blob consisting of a singe 'A' followed by 8192 linefeeds should
be sufficient to trigger the problems.
--
Henrik Grubbström grubba@roxen.com
Roxen Internet Software AB
^ permalink raw reply
* Re: git-p4: labels
From: Vitor Antunes @ 2011-12-19 10:28 UTC (permalink / raw)
To: Luke Diamand; +Cc: Git List, Pete Wyckoff, Michael Horowitz
In-Reply-To: <4EEE3203.10605@diamand.org>
On Sun, Dec 18, 2011 at 6:33 PM, Luke Diamand <luke@diamand.org> wrote:
> 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.
Hi Luke,
Personally, I would prefer to keep the label import working together
with git-p4 rebase/sync so that it doesn't need to go over P4 history
twice. The sanity check currently implemented seems completely bogus. In
my opinion that check should be completely rewritten (maybe move it into
a specific class method?). On a first approach it should at least check
if all files in the label exist in the repository/branch. Ideally, if
not all repository/branch files are labelled, then a special branch
should be created that would not contain those files and the label would
be applied to that. I'm not sure what to do in the case where the label
contains files that are not part of the repository/branch... maybe we
can simply ignore them with a Warning?
If you are really sure that this is not the way to go and that the
import-labels command needs to be created, then I would advise you to
search P4 history backwards until you find a label that was already
imported. This way the script only has to go over P4 history until the
last time import-labels was run. Of course, it still needs to do this
for all branches (hope you are not forgeting them ;).
--
Vitor Antunes
^ permalink raw reply
* Re: post-receive for web deployment
From: Sitaram Chamarty @ 2011-12-19 10:35 UTC (permalink / raw)
To: Stephen Major; +Cc: git
In-Reply-To: <CALzTOm+sJHF_7WzjD7bCqAiAbQSV0A3hEX1KdWfFzV7-ePzX2w@mail.gmail.com>
On Mon, Dec 19, 2011 at 8:12 AM, Stephen Major <smajor@gmail.com> wrote:
> 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.
The most common issue I have seen in cases like this is that you need
to 'unset GIT_DIR'. In fact, anytime you play around with running
stuff from *inside* a hook that works fine when you run it from
outside, you need to check what GIT_ variables are present.
I believe 'unset `git rev-parse --local-env-vars`' is a good idea too;
probably much simpler.
^ permalink raw reply
* Re: [PATCH 2/2] push: hint to use push.default=upstream when appropriate
From: Jeff King @ 2011-12-19 10:37 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vbor5nmsq.fsf_-_@alter.siamese.dyndns.org>
On Sun, Dec 18, 2011 at 09:38:29PM -0800, Junio C Hamano wrote:
> If you push into a shared repository that others push to, and you have
> local branches in your repository that matches the remote side but do not
> keep them up-to-date, then 'matching refs' is not an appropriate default
> for you.
>
> Detect when push failed due to non-fast-forward _and_ we did matching refs
> by default (i.e. if the user explicitly said ':' from the command line, or
> had push.default set to 'matching', then we do not want to advise), and
> give a hint to tell the user that the user may want to set 'push.default'
> configuration variable to 'upstream', if the remote repository receives
> pushes from other places.
I like the general idea. I initially had the thought "wait, don't we
already complain loudly when push.default is not set?". But it seems we
ripped that out long ago (I think I set push.default to "matching" to
shut it up, and then never noticed that doing so is no longer
necessary).
Focusing instead on when an actual (suspected) misconfiguration has
occurred is a much better approach. It won't catch the case of "oops,
I'm on branch 'foo' and just pushed not-ready-to-publish work to 'bar'".
But the point is not necessarily to catch every mistake, but rather
catch some easy ones and hopefully educate the user to update their
settings or modify their workflow as appropriate.
> +static const char *message_advice_use_upstream[] = {
> + "If you are pushing into a repository that receives pushes from",
> + "repositories other than the current repository, you may want to",
> + "set 'push.default' configuration variable to 'upstream' to avoid",
> + "pushing branches you haven't worked on that others have updated.",
> +};
Minor English nit: I would say "...you want to set _the_ 'push.default'
configuration variable...".
The first few lines feel a little overwhelming, as you are setting up a
hypothetical "if you are in situation X" in as few words as possible,
but it involves the word "repository" three different times (to refer to
three different repositories). I don't think there is anything
inaccurate in the text, or even that the same meaning could be conveyed
more succinctly. But I wonder if it would make sense to take a step back
and stop worrying about the potential repository setup, and try to
describe the failure more specifically.
It seems like the real problem is that they are on branch "foo", but the
matching behavior tried to push "bar", which didn't work. And we are
worried that they may be surprised that we even attempted to push "bar"
at all.
And that probably happened because of the situation you describe, but we
(and the user) don't have to think about that. We can just think about
the more immediate mistake of "oops, I didn't want to push 'bar'".
Which leads me to two ideas:
1. This is not good advice to give when pushing the _current_ branch
failed due to non-ff. Setting push.default to "upstream" would
probably yield the same error. We should probably tighten the
condition for showing this message to when a non-HEAD branch failed
to fast-forward.
2. The text should focus on the (possible) local misconfiguration, not
the repo setup.
So maybe something like:
By default, git pushes all branches that have a matching counterpart
on the remote. In this case, some of your local branches were stale
with respect to their remote counterparts. If you did not intend to
push these branches, you may want to set the 'push.default'
configuration variable to 'upstream' to push only the current branch.
I'm not 100% happy with that text, but I think you can see the direction
I am talking about.
> static int push_with_options(struct transport *transport, int flags)
> {
> int err;
> @@ -136,6 +158,9 @@ static int push_with_options(struct transport *transport, int flags)
>
> err |= transport_disconnect(transport);
>
> + if (nonfastforward && default_matching_used)
> + advise_use_upstream();
> +
How does the location of this message interact with the existing
messages? It seems to come before the usual non-fast-forward advice,
but after the status table and "failed to push some refs to..." error
message.
E.g.:
To origin
1065894..c6935ca master -> master
! [rejected] other -> other (non-fast-forward)
error: failed to push some refs to 'origin'
hint: If you are pushing into a repository that receives pushes from
hint: repositories other than the current repository, you may want to
hint: set 'push.default' configuration variable to 'upstream' to avoid
hint: pushing branches you haven't worked on that others have updated.
To prevent you from losing history, non-fast-forward updates were rejected
Merge the remote changes (e.g. 'git pull') before pushing again. See the
'Note about fast-forwards' section of 'git push --help' for details.
which is quite a chunk of text. If we follow my suggestion above and
only print this message for non-HEAD refs, then these two messages
become an either/or situation, I think. If the HEAD failed to
fast-forward, then the right advice is probably "git pull && git push".
If a non-HEAD failed, then the right advice is either "git checkout $X
&& git pull && git push" or "here's how to avoid accidentally pushing
$X".
So the logic would be something like:
if (nonfastforward == NONFASTFORWARD_HEAD)
advise_pull_before_push();
else if (nonfastforward == NONFASTFORWAD_OTHER) {
if (default_matching_used)
advise_use_upstream();
else
advise_checkout_pull_push();
}
I'm not sure that the checkout-pull-push advice is really all that good,
but we don't have much else to offer.
-Peff
^ permalink raw reply
* Re: [PATCH 4/3] gitweb: Fix fallback mode of to_utf8 subroutine
From: Jakub Narebski @ 2011-12-19 12:11 UTC (permalink / raw)
To: git; +Cc: Juergen Kreileder, Junio Hamano
In-Reply-To: <201112190154.19107.jnareb@gmail.com>
Jakub Narebski wrote:
> 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% --
Nb. that was about operations / second (higher is better):
Rate old new
old 2067/s -- -65%
new 5863/s 184% --
Or in slightly different benchmark (more smaller lines):
Rate old new
old 277/s -- -73%
new 1021/s 268% --
old$ time ./t9500-gitweb-standalone-no-errors.sh >/dev/null
real 1m16.788s
user 1m0.908s
sys 0m14.033s
user+sys 1m14.941s
new$ time ./t9500-gitweb-standalone-no-errors.sh >/dev/null
real 1m12.216s
user 0m57.300s
sys 0m13.329s
user+sys 1m10.639s
Though such benchmarks should have been a part of e5d3de5.
P.S. I started to get strange errors
XML Parsing Error: xml processing instruction not at start of external entity
Location: http://localhost/cgi-bin/gitweb/gitweb.cgi
Line Number 37, Column 1:
<?xml version="1.0" encoding="utf-8"?>
^
while "show source" shows that '<?xml version="1.0" encoding="utf-8"?>'
is the first line. WTF?!?
P.P.S. Now I am getting errors when running gitweb, but only in some
cases (via mod_cgi not as standalone script, only when using lynx),
namely it looks like it falls back to 'latin1' when doing content
which is valid UTF-8.
Will investigate.
--
Jakub Narebski
Poland
^ permalink raw reply
* Re: post-receive for web deployment
From: Stephen Major @ 2011-12-19 12:42 UTC (permalink / raw)
To: Sitaram Chamarty; +Cc: git
In-Reply-To: <CAMK1S_hjncBxdh4+UXAJbtJnsPWZUpWASyixG8eNcpFLMRpLgw@mail.gmail.com>
After some playing I found using git clone to export to the staging
path and then doing git checkout -f master for the production path
keeps the files in the production tree clean while leaving any
un-tracked files in tact, seems what
Johannes said was true and this seems like a simple workaround... not
sure about working with indexes like he pointed out.
echo "Resetting staging tree"
rm -rf staging.git $staging_path
git --work-tree=$staging_path clone ./ staging.git
echo "Resetting production tree"
git --work-tree=$live_path checkout -f master
On Mon, Dec 19, 2011 at 2:35 AM, Sitaram Chamarty <sitaramc@gmail.com> wrote:
> On Mon, Dec 19, 2011 at 8:12 AM, Stephen Major <smajor@gmail.com> wrote:
>> 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.
>
> The most common issue I have seen in cases like this is that you need
> to 'unset GIT_DIR'. In fact, anytime you play around with running
> stuff from *inside* a hook that works fine when you run it from
> outside, you need to check what GIT_ variables are present.
>
> I believe 'unset `git rev-parse --local-env-vars`' is a good idea too;
> probably much simpler.
^ permalink raw reply
* git svn can't handle giant commit
From: fREW Schmidt @ 2011-12-19 15:28 UTC (permalink / raw)
To: Git List
Hey guys,
I'm working on an import of some repos and I discovered that I can't
import a certain commit due to it's size. This is the commit:
http://perlcritic.tigris.org/source/browse/perlcritic?view=rev&revision=2676
Clearly it's large :-)
Anyway, here's the error message I get:
Svndiff data contains invalid instruction: Invalid diff stream:
[new] insn 4 overflows the new data section at
/opt/libexec/git-core/git-svn line 5653
This is not a deal breaker as I'm fairly sure I can do the clone in
pieces as opposed to from the root (I just did the root to get a list
of authors anyway) but it seems like there should be a way to handle
something like this...
--
fREW Schmidt
http://blog.afoolishmanifesto.com
^ permalink raw reply
* [PATCHv2 1/2] attr: map builtin userdiff drivers to well-known extensions
From: Jeff King @ 2011-12-19 15:49 UTC (permalink / raw)
To: git
Cc: Johannes Sixt, Junio C Hamano, Brandon Casey, Jonathan Nieder,
Philip Oakley
In-Reply-To: <20111217033808.GA8683@elie.hsd1.il.comcast.net>
We already provide sane hunk-header patterns for specific
languages.
However, the user has to manually map common extensions to
use them. It's not that hard to do, but it's an extra step
that the user might not even know is an option. Let's be
nice and do it automatically.
It could be a problem in the future if the builtin userdiff
drivers started growing more invasive options, like
automatically claiming to be non-binary (i.e., setting
diff.cpp.binary = false by default), but right now we do not
do that, so it should be safe. To help safeguard against
future changes, we add a new test to t4012 making sure that
we don't consider binary files as text by their extension.
We also have to update t4018, which assumed that without a
.gitattributes file, we would receive the default funcname
pattern for a file matching "*.java". This is not covering
up a regression, but rather the feature working as intended.
Signed-off-by: Jeff King <peff@peff.net>
---
This drops the objc mappings from v1. I still have no data on how much
worse the objc funcname performs on Matlab files, but I'd rather be
conservative until an objc person wants to show up and argue about it.
The C mappings are still here, but see the next patch.
attr.c | 22 ++++++++++++++++++++++
t/t4012-diff-binary.sh | 13 +++++++++++++
t/t4018-diff-funcname.sh | 10 +++++++++-
3 files changed, 44 insertions(+), 1 deletions(-)
diff --git a/attr.c b/attr.c
index 76b079f..10713f3 100644
--- a/attr.c
+++ b/attr.c
@@ -306,6 +306,28 @@ static void free_attr_elem(struct attr_stack *e)
static const char *builtin_attr[] = {
"[attr]binary -diff -text",
+ "*.html diff=html",
+ "*.htm diff=html",
+ "*.java diff=java",
+ "*.perl diff=perl",
+ "*.pl diff=perl",
+ "*.php diff=php",
+ "*.py diff=python",
+ "*.rb diff=ruby",
+ "*.bib diff=bibtex",
+ "*.tex diff=tex",
+ "*.c diff=cpp",
+ "*.cc diff=cpp",
+ "*.cxx diff=cpp",
+ "*.cpp diff=cpp",
+ "*.h diff=cpp",
+ "*.hpp diff=cpp",
+ "*.cs diff=csharp",
+ "*.[Ff] diff=fortran",
+ "*.[Ff][0-9][0-9] diff=fortran",
+ "*.pas diff=pascal",
+ "*.pp diff=pascal",
+ "*.lpr diff=pascal",
NULL,
};
diff --git a/t/t4012-diff-binary.sh b/t/t4012-diff-binary.sh
index 2d9f9a0..b2fc807 100755
--- a/t/t4012-diff-binary.sh
+++ b/t/t4012-diff-binary.sh
@@ -90,4 +90,17 @@ test_expect_success 'diff --no-index with binary creation' '
test_cmp expected actual
'
+test_expect_success 'binary files are not considered text by file extension' '
+ echo Q | q_to_nul >binary.c &&
+ git add binary.c &&
+ cat >expect <<-\EOF &&
+ diff --git a/binary.c b/binary.c
+ new file mode 100644
+ index 0000000..1f2a4f5
+ Binary files /dev/null and b/binary.c differ
+ EOF
+ git diff --cached binary.c >actual &&
+ test_cmp expect actual
+'
+
test_done
diff --git a/t/t4018-diff-funcname.sh b/t/t4018-diff-funcname.sh
index 4bd2a1c..a6227ef 100755
--- a/t/t4018-diff-funcname.sh
+++ b/t/t4018-diff-funcname.sh
@@ -124,7 +124,9 @@ do
done
test_expect_success 'default behaviour' '
- rm -f .gitattributes &&
+ cat >.gitattributes <<-\EOF &&
+ *.java diff=default
+ EOF
test_expect_funcname "public class Beer\$"
'
@@ -187,4 +189,10 @@ test_expect_success 'alternation in pattern' '
test_expect_funcname "public static void main("
'
+test_expect_success 'custom diff drivers override built-in extension matches' '
+ test_config diff.foo.funcname "int special" &&
+ echo "*.java diff=foo" >.gitattributes &&
+ test_expect_funcname "int special"
+'
+
test_done
--
1.7.8.rc2.38.gd9625
^ permalink raw reply related
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