* Re: [PATCH] bash completion: use read -r everywhere
From: Junio C Hamano @ 2011-12-21 19:23 UTC (permalink / raw)
To: Thomas Rast; +Cc: git, Kevin Ballard
In-Reply-To: <87wr9pkahw.fsf@thomas.inf.ethz.ch>
Thomas Rast <trast@student.ethz.ch> writes:
> Perhaps we can then just fold it into the first paragraph after the
> POSIX quote, like
Well, that is what I tried say so we are on the same page ;-).
> We use the 'read' command without -r, so that it treats '\' as an
> escape character, in several places. This breaks the loop reading
> refnames from git-for-each-ref in __git_refs() if there are refnames
> such as "foo'bar", in which case for-each-ref helpfully quotes them as
> in
>
> Or some such. Do you want me to resend?
Nah, The above as-is is perfectly fine.
By the way, this is not a problem with the patch, but the for-each-ref
loop is a poor example. Its --shell option is meant to produce a scriptlet
that can be evaled without the buggy processing loop you are fixing, i.e.
script=$(git for-each-ref --shell --format='
ref=%(refname:short)
ref=${ref#*/}
if [[ "$ref" == "$cur"* ]]
then
...
' refs/remotes/) &&
eval "$script"
is how it was designed to be used avoiding shell loops.
>> Does this regress for zsh users in some ways, by the way?
>
> I'm not one of them, but...
Thanks, that was all I wanted to know before deciding if I should apply
this directly to 'master' or cook in 'next' to give real zsh users a
chance to object or tweak it.
^ permalink raw reply
* Re: [PATCH] builtin/commit: add missing '/' in help message
From: Junio C Hamano @ 2011-12-21 19:16 UTC (permalink / raw)
To: Michael Schubert; +Cc: git
In-Reply-To: <4EF1F380.3090901@elegosoft.com>
Thanks.
^ permalink raw reply
* Re: [PATCH] builtin/log: remove redundant initialization
From: Junio C Hamano @ 2011-12-21 19:16 UTC (permalink / raw)
To: Michael Schubert; +Cc: git
In-Reply-To: <4EF1CB87.8050801@elegosoft.com>
Thanks.
^ permalink raw reply
* Re: git 1.7.7.5
From: Junio C Hamano @ 2011-12-21 19:10 UTC (permalink / raw)
To: Thomas Jarosch; +Cc: Jonathan Nieder, git, schacon
In-Reply-To: <201112211820.45447.thomas.jarosch@intra2net.com>
Thomas Jarosch <thomas.jarosch@intra2net.com> writes:
> May be Scott Chacon can provide you commit access to git-scm.com ;)
> If you are interested in this of course.
>
> For example wikipedia lists git-scm.com as website for git.
> (http://en.wikipedia.org/wiki/Git_%28software%29)
No, thanks.
They volunteered to keep the site up to date and useful to the user
community and they have been doing a good job at it, and that is why we
advertise git-scm.com as the official site. A minor bug like this which I
know they are perfectly capable of fixing at their site is not a
justifiable incident to trigger taking control and credit over from them.
^ permalink raw reply
* Re: [PATCH] bash completion: use read -r everywhere
From: Thomas Rast @ 2011-12-21 19:09 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Kevin Ballard
In-Reply-To: <7vipl9hht4.fsf@alter.siamese.dyndns.org>
Junio C Hamano <gitster@pobox.com> writes:
> Thomas Rast <trast@student.ethz.ch> writes:
>
>> POSIX specifies
>>
>> The read utility shall read a single line from standard input.
>> By default, unless the -r option is specified, backslash ('\')
>> shall act as an escape character...
>>
>> Our omission of -r breaks the loop reading refnames from
>> git-for-each-ref in __git_refs() if there are refnames such as
>> "foo'bar", in which case for-each-ref helpfully quotes them as in
[...]
> Thanks.
>
> As this script is specific to bash, it is secondary importance what POSIX
> says. The "-r" option is important only because "bash" happens to follow
> POSIX in this case. I'd like to see the early part of the message reworded
> perhaps like this:
>
> At various points in the script, we use "read" utility without
> giving it the "-r" option that prevents a backslash ('\')
> character to act as an escape character. This breaks e.g. reading
> refnames from ...
Perhaps we can then just fold it into the first paragraph after the
POSIX quote, like
We use the 'read' command without -r, so that it treats '\' as an
escape character, in several places. This breaks the loop reading
refnames from git-for-each-ref in __git_refs() if there are refnames
such as "foo'bar", in which case for-each-ref helpfully quotes them as
in
Or some such. Do you want me to resend?
> Does this regress for zsh users in some ways, by the way?
I'm not one of them, but a quick googling for "zsh builtin read" turns
up that it has a dozen options, and -r means
-r
Raw mode: a \ at the end of a line does not signify line continuation.
I can't discern whether it treats \ special at all with or without -r.
--
Thomas Rast
trast@{inf,student}.ethz.ch
^ permalink raw reply
* Re: [PATCH 4/4] Suppress "statement not reached" warnings under Sun Studio
From: Ævar Arnfjörð Bjarmason @ 2011-12-21 19:03 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Elijah Newren, Jason Evans, David Barr
In-Reply-To: <7vvcp9hjam.fsf@alter.siamese.dyndns.org>
On Wed, Dec 21, 2011 at 19:27, Junio C Hamano <gitster@pobox.com> wrote:
> Ævar Arnfjörð Bjarmason <avarab@gmail.com> writes:
>
>> diff --git a/read-cache.c b/read-cache.c
>> index a51bba1..0a4e895 100644
>> --- a/read-cache.c
>> +++ b/read-cache.c
>> @@ -758,7 +758,13 @@ int verify_path(const char *path)
>> return 0;
>>
>> goto inside;
>> +#ifdef __sun
>> +# pragma error_messages (off, E_STATEMENT_NOT_REACHED)
>> +#endif
>> for (;;) {
>> +#ifdef __sun
>> +# pragma error_messages (on, E_STATEMENT_NOT_REACHED)
>> +#endif
>> if (!c)
>> return 1;
>
> Patches 1-3 makes sense, but this one is too ugly to live.
>
> Wouldn't something like this be equivalent and have the same effect
> without sacrificing the readablity?
>
> diff --git a/read-cache.c b/read-cache.c
> index a51bba1..73af797 100644
> --- a/read-cache.c
> +++ b/read-cache.c
> @@ -757,12 +757,12 @@ int verify_path(const char *path)
> if (has_dos_drive_prefix(path))
> return 0;
>
> - goto inside;
> + /* we are at the beginning of a path component */
> + c = '/';
> for (;;) {
> if (!c)
> return 1;
> if (is_dir_sep(c)) {
> -inside:
> c = *path++;
> if ((c == '.' && !verify_dotfile(path)) ||
> is_dir_sep(c) || c == '\0')
That would make that warning go away, but I don't know if that changes
the semantics of the code. I was aiming not to change any code, just
to squash spurious warnings under Sun Studio.
We could also just wrap the whole function definition in the pragma,
which would make the code more readable since we wouldn't have 6 lines
of warning suppression in the middle of the function.
Or we could just drop this patch entirely, or rewrite the code. Your
pick.
^ permalink raw reply
* Re: [PATCH] bash completion: use read -r everywhere
From: Junio C Hamano @ 2011-12-21 18:59 UTC (permalink / raw)
To: Thomas Rast; +Cc: git, Kevin Ballard
In-Reply-To: <4502a0248bb843018335e9b5cdf70736c096ebe3.1324482693.git.trast@student.ethz.ch>
Thomas Rast <trast@student.ethz.ch> writes:
> POSIX specifies
>
> The read utility shall read a single line from standard input.
> By default, unless the -r option is specified, backslash ('\')
> shall act as an escape character...
>
> Our omission of -r breaks the loop reading refnames from
> git-for-each-ref in __git_refs() if there are refnames such as
> "foo'bar", in which case for-each-ref helpfully quotes them as in
>
> $ git update-ref "refs/remotes/test/foo'bar" HEAD
> $ git for-each-ref --shell --format="ref=%(refname:short)" "refs/remotes"
> ref='test/foo'\''bar'
>
> Interpolating the \' here will read "ref='test/foo'''bar'" instead,
> and eval then chokes on the unbalanced quotes.
>
> However, since none of the read loops _want_ to have backslashes
> interpolated, it's much safer to use read -r everywhere.
>
> Signed-off-by: Thomas Rast <trast@student.ethz.ch>
Thanks.
As this script is specific to bash, it is secondary importance what POSIX
says. The "-r" option is important only because "bash" happens to follow
POSIX in this case. I'd like to see the early part of the message reworded
perhaps like this:
At various points in the script, we use "read" utility without
giving it the "-r" option that prevents a backslash ('\')
character to act as an escape character. This breaks e.g. reading
refnames from ...
Does this regress for zsh users in some ways, by the way?
> ---
> contrib/completion/git-completion.bash | 12 ++++++------
> 1 files changed, 6 insertions(+), 6 deletions(-)
>
> diff --git a/contrib/completion/git-completion.bash b/contrib/completion/git-completion.bash
> index 78257ae..e7a39ef 100755
> --- a/contrib/completion/git-completion.bash
> +++ b/contrib/completion/git-completion.bash
> @@ -111,7 +111,7 @@ __git_ps1_show_upstream ()
>
> # get some config options from git-config
> local output="$(git config -z --get-regexp '^(svn-remote\..*\.url|bash\.showupstream)$' 2>/dev/null | tr '\0\n' '\n ')"
> - while read key value; do
> + while read -r key value; do
> case "$key" in
> bash.showupstream)
> GIT_PS1_SHOWUPSTREAM="$value"
> @@ -589,7 +589,7 @@ __git_refs ()
> local ref entry
> git --git-dir="$dir" for-each-ref --shell --format="ref=%(refname:short)" \
> "refs/remotes/" | \
> - while read entry; do
> + while read -r entry; do
> eval "$entry"
> ref="${ref#*/}"
> if [[ "$ref" == "$cur"* ]]; then
> @@ -602,7 +602,7 @@ __git_refs ()
> case "$cur" in
> refs|refs/*)
> git ls-remote "$dir" "$cur*" 2>/dev/null | \
> - while read hash i; do
> + while read -r hash i; do
> case "$i" in
> *^{}) ;;
> *) echo "$i" ;;
> @@ -611,7 +611,7 @@ __git_refs ()
> ;;
> *)
> git ls-remote "$dir" HEAD ORIG_HEAD 'refs/tags/*' 'refs/heads/*' 'refs/remotes/*' 2>/dev/null | \
> - while read hash i; do
> + while read -r hash i; do
> case "$i" in
> *^{}) ;;
> refs/*) echo "${i#refs/*/}" ;;
> @@ -636,7 +636,7 @@ __git_refs_remotes ()
> {
> local i hash
> git ls-remote "$1" 'refs/heads/*' 2>/dev/null | \
> - while read hash i; do
> + while read -r hash i; do
> echo "$i:refs/remotes/$1/${i#refs/heads/}"
> done
> }
> @@ -1863,7 +1863,7 @@ __git_config_get_set_variables ()
> done
>
> git --git-dir="$(__gitdir)" config $config_file --list 2>/dev/null |
> - while read line
> + while read -r line
> do
> case "$line" in
> *.*=*)
^ permalink raw reply
* Re: Patches for message-digest support
From: Bill Zaumen @ 2011-12-21 18:44 UTC (permalink / raw)
To: git, peff, pclouds
... sorry for an additional message. The patches I just sent
were based on commit 876a6f4991abdd72ea707b193b4f2b831096ad3c
(Update draft release notes to 1.7.9).
I should have also added that the function verify_commit was
tested via a compile-time option, but it is currently not used.
Its purpose is to verify that the (new) digest header in commit
messages is consistent with the commit's tree, parents, other
headers, and the commit message. For authentication, one
would want to sign the commit SHA-1 hash and the message digest
for the commit (which is stored separate from the commit object).
My patch doesn't do that, but there is a single function that
can be called to look up the digest, if one is present (which may
not be the case due to backwards compatibility issues) - I'd prefer
to have someone familiar with the signature code make any changes.
The version of Makefile in the patch turns off the commit message-digest
header because some of the test scripts won't run with it, due to
those encoding specific SHA-1 values and file lengths, but the test does
run far enough to have created and used a number of commits. I didn't
want to go to the trouble of updating the test scripts unless the patch
is actually going to get used - updating the scripts is a bit tedious
and you'd probably want to decide on the digest hash first.
Bill
^ permalink raw reply
* Re: Re* How to generate pull-request with info of signed tag
From: Junio C Hamano @ 2011-12-21 18:39 UTC (permalink / raw)
To: Aneesh Kumar K.V; +Cc: Git Mailing List
In-Reply-To: <87ipl9yik6.fsf@linux.vnet.ibm.com>
"Aneesh Kumar K.V" <aneesh.kumar@linux.vnet.ibm.com> writes:
> With an entry like below
>
> [remote "github"]
> fetch = +refs/tags/*:refs/tags/origin/*
> url = git://github.com/kvaneesh/QEMU.git
>
> when i do git fetch github for-anthony i get the below error
When you give refspecs from the command line like that, the default
refspec remote.github.fetch will not be used and what you configure there
is immaterial.
> [master@QEMU]$ git fetch github for-anthony
>>From git://github.com/kvaneesh/QEMU
> * tag for-anthony -> FETCH_HEAD
Sounds sane.
Does "git cat-file -t FETCH_HEAD" report "tag" (it should)? After doing
that fetch and inspecting "git log -p ..FETCH_HEAD", you should be able to
do "git merge FETCH_HEAD" and it should be like you did "git pull github
for-anthony".
> Also trying to do
>
> [master@QEMU]$ git fetch git://github.com/kvaneesh/QEMU.git for-anthony:aneesh/for-anthony
> error: Trying to write non-commit object 12916047784615b7d8b879d9d39be6c1559e1b1b to branch refs/heads/aneesh/for-anthony
>>From git://github.com/kvaneesh/QEMU
> ! [new branch] for-anthony -> aneesh/for-anthony (unable to update local ref)
> * [new tag] for-anthony -> for-anthony
Sounds sane, too.
> I understand that replacing the above with below works. But we should
> not be required to specify refs/tags there right ?
>
> [master@QEMU]$ git fetch git://github.com/kvaneesh/QEMU.git refs/tags/for-anthony:refs/tags/aneesh/for-anthony
If the "for-anthony" name is ambiguous between branches and tags, then you
must disambiguate. I am guessing that the unqualified LHS "for-anthony" is
found in the branch namespace of the remote, and that is why RHS is qualified
with the same refs/heads/ prefix to store it to the branch namespace.
On the other hand, if "for-anthony" name is unambiguous, then you may have
found a bug. I cannot tell.
^ permalink raw reply
* Re: [PATCH 4/4] Suppress "statement not reached" warnings under Sun Studio
From: Junio C Hamano @ 2011-12-21 18:27 UTC (permalink / raw)
To: Ævar Arnfjörð Bjarmason
Cc: git, Elijah Newren, Jason Evans, David Barr
In-Reply-To: <1324430302-22441-5-git-send-email-avarab@gmail.com>
Ævar Arnfjörð Bjarmason <avarab@gmail.com> writes:
> diff --git a/read-cache.c b/read-cache.c
> index a51bba1..0a4e895 100644
> --- a/read-cache.c
> +++ b/read-cache.c
> @@ -758,7 +758,13 @@ int verify_path(const char *path)
> return 0;
>
> goto inside;
> +#ifdef __sun
> +# pragma error_messages (off, E_STATEMENT_NOT_REACHED)
> +#endif
> for (;;) {
> +#ifdef __sun
> +# pragma error_messages (on, E_STATEMENT_NOT_REACHED)
> +#endif
> if (!c)
> return 1;
Patches 1-3 makes sense, but this one is too ugly to live.
Wouldn't something like this be equivalent and have the same effect
without sacrificing the readablity?
diff --git a/read-cache.c b/read-cache.c
index a51bba1..73af797 100644
--- a/read-cache.c
+++ b/read-cache.c
@@ -757,12 +757,12 @@ int verify_path(const char *path)
if (has_dos_drive_prefix(path))
return 0;
- goto inside;
+ /* we are at the beginning of a path component */
+ c = '/';
for (;;) {
if (!c)
return 1;
if (is_dir_sep(c)) {
-inside:
c = *path++;
if ((c == '.' && !verify_dotfile(path)) ||
is_dir_sep(c) || c == '\0')
^ permalink raw reply related
* [PATCH] clone: don't say <branch> when we mean <remote>
From: Carlos Martín Nieto @ 2011-12-21 18:14 UTC (permalink / raw)
To: git
Signed-off-by: Carlos Martín Nieto <cmn@elego.de>
---
The manpage says <name> which might actually be a better word to use
everywhere, but having <branch> instead of <remote> can only lead to
confusion.
Looking through blame, the second line survived a typo fix and was
introduced in 2008 when clone was made a builtin. The script used to
say <name>. So it's clearly nothing urgent, but it bugged me, so I'm
sending a patch.
builtin/clone.c | 4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/builtin/clone.c b/builtin/clone.c
index efe8b6c..e85ee69 100644
--- a/builtin/clone.c
+++ b/builtin/clone.c
@@ -84,8 +84,8 @@ static struct option builtin_clone_options[] = {
"directory from which templates will be used"),
OPT_CALLBACK(0 , "reference", &option_reference, "repo",
"reference repository", &opt_parse_reference),
- OPT_STRING('o', "origin", &option_origin, "branch",
- "use <branch> instead of 'origin' to track upstream"),
+ OPT_STRING('o', "origin", &option_origin, "remote",
+ "use <remote> instead of 'origin' to track upstream"),
OPT_STRING('b', "branch", &option_branch, "branch",
"checkout <branch> instead of the remote's HEAD"),
OPT_STRING('u', "upload-pack", &option_upload_pack, "path",
--
1.7.8.352.g876a6f
^ permalink raw reply related
* Re: git 1.7.7.5
From: Thomas Jarosch @ 2011-12-21 17:20 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Jonathan Nieder, git, schacon
In-Reply-To: <7viplckt2m.fsf@alter.siamese.dyndns.org>
On Tuesday, 20. December 2011 01:03:29 Junio C Hamano wrote:
> but anyway I've uploaded both 1.7.7.5 and 1.7.6.5 tarballs.
Thanks!
May be Scott Chacon can provide you commit access to git-scm.com ;)
If you are interested in this of course.
For example wikipedia lists git-scm.com as website for git.
(http://en.wikipedia.org/wiki/Git_%28software%29)
Cheers,
Thomas
^ permalink raw reply
* Re: Re* How to generate pull-request with info of signed tag
From: Aneesh Kumar K.V @ 2011-12-21 16:51 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Git Mailing List
In-Reply-To: <7vzkemh0de.fsf@alter.siamese.dyndns.org>
On Tue, 20 Dec 2011 23:03:57 -0800, Junio C Hamano <gitster@pobox.com> wrote:
> "Aneesh Kumar K.V" <aneesh.kumar@linux.vnet.ibm.com> writes:
>
> > Also can we make .git/config remote stanza to have something like below
> >
> >
> > fetch = +refs/tags/*:refs/tags/abc/*
> >
> > so that one can do
> >
> > git fetch t-remote tag-name
> >
> > and that get stored to abc/tag-name
>
> You can do whatever you want to your own config file without asking anybody.
>
> Having said that, the point of the recent change to allow you to pull this
> way (notice the lack of "tag")
>
> $ git pull $url $signed_tag_name
>
> is so that you do not have to contaminate your own ref namespace with tags
> that are used to leave audit trails in the history graph.
>
With an entry like below
[remote "github"]
fetch = +refs/tags/*:refs/tags/origin/*
url = git://github.com/kvaneesh/QEMU.git
when i do git fetch github for-anthony i get the below error
[master@QEMU]$ git fetch github for-anthony
From git://github.com/kvaneesh/QEMU
* tag for-anthony -> FETCH_HEAD
[master@QEMU]$ less .git/config
Also trying to do
[master@QEMU]$ git fetch git://github.com/kvaneesh/QEMU.git for-anthony:aneesh/for-anthony
error: Trying to write non-commit object 12916047784615b7d8b879d9d39be6c1559e1b1b to branch refs/heads/aneesh/for-anthony
From git://github.com/kvaneesh/QEMU
! [new branch] for-anthony -> aneesh/for-anthony (unable to update local ref)
* [new tag] for-anthony -> for-anthony
I understand that replacing the above with below works. But we should
not be required to specify refs/tags there right ?
[master@QEMU]$ git fetch git://github.com/kvaneesh/QEMU.git refs/tags/for-anthony:refs/tags/aneesh/for-anthony
-aneesh
^ permalink raw reply
* Re: [PATCH] git-commit: add option --date-now
From: Matthieu Moy @ 2011-12-21 16:24 UTC (permalink / raw)
To: Carlos Martín Nieto; +Cc: Michael Schubert, git
In-Reply-To: <20111221153837.GC2160@beez.lab.cmartin.tk>
Carlos Martín Nieto <cmn@elego.de> writes:
> I was surpised when I tried 'git commit --amend --date=now' that git
> didn't understand 'now' as a date, which seems like a more obvious
> place to fix it.
+1
I really don't think Git wants yet-another-option for each use-case we
find, and accepting "now" as a date (either by hardcoding "now" as an
accepted value, or by running approxidate on the argument of --date).
--
Matthieu Moy
http://www-verimag.imag.fr/~moy/
^ permalink raw reply
* Re: [PATCH] Use Python's "print" as a function, not as a keyword
From: Sverre Rabbelier @ 2011-12-21 16:12 UTC (permalink / raw)
To: Ævar Arnfjörð Bjarmason; +Cc: Sebastian Morr, git
In-Reply-To: <CACBZZX7PVyCFfHTJN_QZfyt5wAcr4UAiJSmo54PSi=8pgv3sYA@mail.gmail.com>
On Tue, Dec 20, 2011 at 20:48, Ævar Arnfjörð Bjarmason <avarab@gmail.com> wrote:
> I'm running Debian unstable and it has Python 2.7. Most people are
> still using Python 2.x as their default system Python since 3.x breaks
> backwards compatibility for common constructs like print.
>
> Does this only break Python 2.6, or all 2.x versions of Python?
>
> What's our currently supported Python version for the Python code in
> Git? It's 5.8.0 for Perl, do we have any particular aim for a
> supported Python version?
Python 2.4.
--
Cheers,
Sverre Rabbelier
^ permalink raw reply
* [PATCH] bash completion: use read -r everywhere
From: Thomas Rast @ 2011-12-21 15:54 UTC (permalink / raw)
To: git; +Cc: Junio C Hamano, Kevin Ballard
POSIX specifies
The read utility shall read a single line from standard input.
By default, unless the -r option is specified, backslash ('\')
shall act as an escape character...
Our omission of -r breaks the loop reading refnames from
git-for-each-ref in __git_refs() if there are refnames such as
"foo'bar", in which case for-each-ref helpfully quotes them as in
$ git update-ref "refs/remotes/test/foo'bar" HEAD
$ git for-each-ref --shell --format="ref=%(refname:short)" "refs/remotes"
ref='test/foo'\''bar'
Interpolating the \' here will read "ref='test/foo'''bar'" instead,
and eval then chokes on the unbalanced quotes.
However, since none of the read loops _want_ to have backslashes
interpolated, it's much safer to use read -r everywhere.
Signed-off-by: Thomas Rast <trast@student.ethz.ch>
---
contrib/completion/git-completion.bash | 12 ++++++------
1 files changed, 6 insertions(+), 6 deletions(-)
diff --git a/contrib/completion/git-completion.bash b/contrib/completion/git-completion.bash
index 78257ae..e7a39ef 100755
--- a/contrib/completion/git-completion.bash
+++ b/contrib/completion/git-completion.bash
@@ -111,7 +111,7 @@ __git_ps1_show_upstream ()
# get some config options from git-config
local output="$(git config -z --get-regexp '^(svn-remote\..*\.url|bash\.showupstream)$' 2>/dev/null | tr '\0\n' '\n ')"
- while read key value; do
+ while read -r key value; do
case "$key" in
bash.showupstream)
GIT_PS1_SHOWUPSTREAM="$value"
@@ -589,7 +589,7 @@ __git_refs ()
local ref entry
git --git-dir="$dir" for-each-ref --shell --format="ref=%(refname:short)" \
"refs/remotes/" | \
- while read entry; do
+ while read -r entry; do
eval "$entry"
ref="${ref#*/}"
if [[ "$ref" == "$cur"* ]]; then
@@ -602,7 +602,7 @@ __git_refs ()
case "$cur" in
refs|refs/*)
git ls-remote "$dir" "$cur*" 2>/dev/null | \
- while read hash i; do
+ while read -r hash i; do
case "$i" in
*^{}) ;;
*) echo "$i" ;;
@@ -611,7 +611,7 @@ __git_refs ()
;;
*)
git ls-remote "$dir" HEAD ORIG_HEAD 'refs/tags/*' 'refs/heads/*' 'refs/remotes/*' 2>/dev/null | \
- while read hash i; do
+ while read -r hash i; do
case "$i" in
*^{}) ;;
refs/*) echo "${i#refs/*/}" ;;
@@ -636,7 +636,7 @@ __git_refs_remotes ()
{
local i hash
git ls-remote "$1" 'refs/heads/*' 2>/dev/null | \
- while read hash i; do
+ while read -r hash i; do
echo "$i:refs/remotes/$1/${i#refs/heads/}"
done
}
@@ -1863,7 +1863,7 @@ __git_config_get_set_variables ()
done
git --git-dir="$(__gitdir)" config $config_file --list 2>/dev/null |
- while read line
+ while read -r line
do
case "$line" in
*.*=*)
--
1.7.8.484.gdad4270
^ permalink raw reply related
* Re: [PATCH] git-commit: add option --date-now
From: Carlos Martín Nieto @ 2011-12-21 15:38 UTC (permalink / raw)
To: Michael Schubert; +Cc: git
In-Reply-To: <4EF1F3AB.5080607@elegosoft.com>
[-- Attachment #1: Type: text/plain, Size: 4129 bytes --]
On Wed, Dec 21, 2011 at 03:56:43PM +0100, Michael Schubert wrote:
> Currently, Git doesn't provide an easy way to use the current date when
> amending a commit or reusing an existing commmit with -C/-c. Therefore,
> add --date-now.
The option --reset-author also resets the date. So 'git commit
--ammend --reset-author' does what 'git commit --amend --date-now'
would do in most cases. I was surpised when I tried 'git commit
--amend --date=now' that git didn't understand 'now' as a date, which
seems like a more obvious place to fix it.
>
> Signed-off-by: Michael Schubert <mschub@elegosoft.com>
> ---
> Documentation/git-commit.txt | 7 +++++--
> builtin/commit.c | 9 ++++++++-
> 2 files changed, 13 insertions(+), 3 deletions(-)
>
> diff --git a/Documentation/git-commit.txt b/Documentation/git-commit.txt
> index 5cc84a1..b7c6f0d 100644
> --- a/Documentation/git-commit.txt
> +++ b/Documentation/git-commit.txt
> @@ -12,8 +12,8 @@ SYNOPSIS
> [--dry-run] [(-c | -C | --fixup | --squash) <commit>]
> [-F <file> | -m <msg>] [--reset-author] [--allow-empty]
> [--allow-empty-message] [--no-verify] [-e] [--author=<author>]
> - [--date=<date>] [--cleanup=<mode>] [--status | --no-status]
> - [-i | -o] [--] [<file>...]
> + [--date=<date> | --date-now] [--cleanup=<mode>]
> + [--status | --no-status] [-i | -o] [--] [<file>...]
>
> DESCRIPTION
> -----------
> @@ -126,6 +126,9 @@ OPTIONS
> --date=<date>::
> Override the author date used in the commit.
>
> +--date-now
> + Override the author date used in the commit with the current local time.
> +
> -m <msg>::
> --message=<msg>::
> Use the given <msg> as the commit message.
> diff --git a/builtin/commit.c b/builtin/commit.c
> index be1ab2e..28fdf1a 100644
> --- a/builtin/commit.c
> +++ b/builtin/commit.c
> @@ -82,6 +82,7 @@ static const char *author_message, *author_message_buffer;
> static char *edit_message, *use_message;
> static char *fixup_message, *squash_message;
> static int all, also, interactive, patch_interactive, only, amend, signoff;
> +static int date_now;
> static int edit_flag = -1; /* unspecified */
> static int quiet, verbose, no_verify, allow_empty, dry_run, renew_authorship;
> static int no_post_rewrite, allow_empty_message;
> @@ -134,6 +135,7 @@ static struct option builtin_commit_options[] = {
> OPT_FILENAME('F', "file", &logfile, "read message from file"),
> OPT_STRING(0, "author", &force_author, "author", "override author for commit"),
> OPT_STRING(0, "date", &force_date, "date", "override date for commit"),
> + OPT_BOOLEAN(0, "date-now", &date_now, "override date for commit with current local time"),
> OPT_CALLBACK('m', "message", &message, "message", "commit message", opt_parse_m),
> OPT_STRING('c', "reedit-message", &edit_message, "commit", "reuse and edit message from specified commit"),
> OPT_STRING('C', "reuse-message", &use_message, "commit", "reuse message from specified commit"),
> @@ -557,7 +559,9 @@ static void determine_author_info(struct strbuf *author_ident)
> (lb - strlen(" ") -
> (a + strlen("\nauthor "))));
> email = xmemdupz(lb + strlen("<"), rb - (lb + strlen("<")));
> - date = xmemdupz(rb + strlen("> "), eol - (rb + strlen("> ")));
> + if (!date_now)
> + date = xmemdupz(rb + strlen("> "),
> + eol - (rb + strlen("> ")));
> }
>
> if (force_author) {
> @@ -1018,6 +1022,9 @@ static int parse_and_validate_options(int argc, const char *argv[],
> if (force_author && renew_authorship)
> die(_("Using both --reset-author and --author does not make sense"));
>
> + if (force_date && date_now)
> + die(_("Using both --date and --date-now does not make sense"));
> +
> if (logfile || message.len || use_message || fixup_message)
> use_editor = 0;
> if (0 <= edit_flag)
> --
> 1.7.8.521.g64725
> --
> To unsubscribe from this list: send the line "unsubscribe git" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 490 bytes --]
^ permalink raw reply
* [PATCH] git-commit: add option --date-now
From: Michael Schubert @ 2011-12-21 14:56 UTC (permalink / raw)
To: git
Currently, Git doesn't provide an easy way to use the current date when
amending a commit or reusing an existing commmit with -C/-c. Therefore,
add --date-now.
Signed-off-by: Michael Schubert <mschub@elegosoft.com>
---
Documentation/git-commit.txt | 7 +++++--
builtin/commit.c | 9 ++++++++-
2 files changed, 13 insertions(+), 3 deletions(-)
diff --git a/Documentation/git-commit.txt b/Documentation/git-commit.txt
index 5cc84a1..b7c6f0d 100644
--- a/Documentation/git-commit.txt
+++ b/Documentation/git-commit.txt
@@ -12,8 +12,8 @@ SYNOPSIS
[--dry-run] [(-c | -C | --fixup | --squash) <commit>]
[-F <file> | -m <msg>] [--reset-author] [--allow-empty]
[--allow-empty-message] [--no-verify] [-e] [--author=<author>]
- [--date=<date>] [--cleanup=<mode>] [--status | --no-status]
- [-i | -o] [--] [<file>...]
+ [--date=<date> | --date-now] [--cleanup=<mode>]
+ [--status | --no-status] [-i | -o] [--] [<file>...]
DESCRIPTION
-----------
@@ -126,6 +126,9 @@ OPTIONS
--date=<date>::
Override the author date used in the commit.
+--date-now
+ Override the author date used in the commit with the current local time.
+
-m <msg>::
--message=<msg>::
Use the given <msg> as the commit message.
diff --git a/builtin/commit.c b/builtin/commit.c
index be1ab2e..28fdf1a 100644
--- a/builtin/commit.c
+++ b/builtin/commit.c
@@ -82,6 +82,7 @@ static const char *author_message, *author_message_buffer;
static char *edit_message, *use_message;
static char *fixup_message, *squash_message;
static int all, also, interactive, patch_interactive, only, amend, signoff;
+static int date_now;
static int edit_flag = -1; /* unspecified */
static int quiet, verbose, no_verify, allow_empty, dry_run, renew_authorship;
static int no_post_rewrite, allow_empty_message;
@@ -134,6 +135,7 @@ static struct option builtin_commit_options[] = {
OPT_FILENAME('F', "file", &logfile, "read message from file"),
OPT_STRING(0, "author", &force_author, "author", "override author for commit"),
OPT_STRING(0, "date", &force_date, "date", "override date for commit"),
+ OPT_BOOLEAN(0, "date-now", &date_now, "override date for commit with current local time"),
OPT_CALLBACK('m', "message", &message, "message", "commit message", opt_parse_m),
OPT_STRING('c', "reedit-message", &edit_message, "commit", "reuse and edit message from specified commit"),
OPT_STRING('C', "reuse-message", &use_message, "commit", "reuse message from specified commit"),
@@ -557,7 +559,9 @@ static void determine_author_info(struct strbuf *author_ident)
(lb - strlen(" ") -
(a + strlen("\nauthor "))));
email = xmemdupz(lb + strlen("<"), rb - (lb + strlen("<")));
- date = xmemdupz(rb + strlen("> "), eol - (rb + strlen("> ")));
+ if (!date_now)
+ date = xmemdupz(rb + strlen("> "),
+ eol - (rb + strlen("> ")));
}
if (force_author) {
@@ -1018,6 +1022,9 @@ static int parse_and_validate_options(int argc, const char *argv[],
if (force_author && renew_authorship)
die(_("Using both --reset-author and --author does not make sense"));
+ if (force_date && date_now)
+ die(_("Using both --date and --date-now does not make sense"));
+
if (logfile || message.len || use_message || fixup_message)
use_editor = 0;
if (0 <= edit_flag)
--
1.7.8.521.g64725
^ permalink raw reply related
* [PATCH] builtin/commit: add missing '/' in help message
From: Michael Schubert @ 2011-12-21 14:56 UTC (permalink / raw)
To: git; +Cc: Junio C Hamano
Signed-off-by: Michael Schubert <mschub@elegosoft.com>
---
builtin/commit.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/builtin/commit.c b/builtin/commit.c
index 626036a..be1ab2e 100644
--- a/builtin/commit.c
+++ b/builtin/commit.c
@@ -139,7 +139,7 @@ static struct option builtin_commit_options[] = {
OPT_STRING('C', "reuse-message", &use_message, "commit", "reuse message from specified commit"),
OPT_STRING(0, "fixup", &fixup_message, "commit", "use autosquash formatted message to fixup specified commit"),
OPT_STRING(0, "squash", &squash_message, "commit", "use autosquash formatted message to squash specified commit"),
- OPT_BOOLEAN(0, "reset-author", &renew_authorship, "the commit is authored by me now (used with -C-c/--amend)"),
+ OPT_BOOLEAN(0, "reset-author", &renew_authorship, "the commit is authored by me now (used with -C/-c/--amend)"),
OPT_BOOLEAN('s', "signoff", &signoff, "add Signed-off-by:"),
OPT_FILENAME('t', "template", &template_file, "use specified template file"),
OPT_BOOL('e', "edit", &edit_flag, "force edit of commit"),
--
1.7.8.521.g64725
^ permalink raw reply related
* Re: [PATCH] Specify a precision for the length of a subject string
From: Nathan Panike @ 2011-12-21 14:53 UTC (permalink / raw)
To: Andreas Schwab; +Cc: Nathan W. Panike, git
In-Reply-To: <m2liq6go7y.fsf@igel.home>
On Wed, Dec 21, 2011 at 12:26:25PM +0100, Andreas Schwab wrote:
> "Nathan W. Panike" <nathan.panike@gmail.com> writes:
>
> > $ git log --pretty='%h %30s' d165204 -1
>
> In C's formatted output this syntax denotes a minimum field width, not a
> precision, so it will probably be surprising to many people.
C semantics are already broken because (from git-log(1))
"If you add a - (minus sign) after % of a placeholder, line-feeds that
immediately precede the expansion are deleted if and only if the placeholder
expands to an empty string."
rather than indicating justification of the field.
>
> Andreas.
>
> --
> Andreas Schwab, schwab@linux-m68k.org
> GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5
> "And now for something completely different."
^ permalink raw reply
* Re: [PATCH] Specify a precision for the length of a subject string
From: Nathan Panike @ 2011-12-21 14:51 UTC (permalink / raw)
To: Jeff King; +Cc: Nathan W. Panike, git
In-Reply-To: <20111221043843.GA20714@sigill.intra.peff.net>
On Tue, Dec 20, 2011 at 11:38:43PM -0500, Jeff King wrote:
> On Tue, Dec 20, 2011 at 04:07:54PM -0600, Nathan W. Panike wrote:
>
> > We can specify the precision of a subject string, so that length the subjects
> > viewed by the user do not grow beyond a bound set by the user, in a pretty
> > formatted string
> >
> > This makes it possible to do, e.g.,
> >
> > $ git log --pretty='%h %s' d165204 -1
> > d165204 git-p4: fix skipSubmitEdit regression
> >
> > With this patch, the user can do
> >
> > $ git log --pretty='%h %30s' d165204 -1
> > d165204 git-p4: fix skipSubmitEdit reg
>
> Hmm. I think the idea of limiting is OK (though personally, I would just
> pipe through a filter that truncates long lines). But I'm a bit negative
> on adding a tweak like this that only affects the subject. Is there a
> reason I couldn't do %30gs, or %30f, or even some other placeholder?
The ones that make sense to limit are all those that depend on the subject, as the
above; it does not make sense to limit other fields that don't depend on the
subject, as they are fixed width, or have small variance. And it does not make
sense to me to limit the length of the body.
>
> Also, we already have %w to handle wrapping. Could this be handled in a
> similar way (perhaps it could even be considered a special form of
> wrapping)?
I'll look at the wrapping code and see. Thanks for the idea.
>
> -Peff
^ permalink raw reply
* Re: Escape character for .gitconfig
From: demerphq @ 2011-12-21 13:59 UTC (permalink / raw)
To: Peter Krefting; +Cc: Erik Blake, Git Mailing List
In-Reply-To: <alpine.DEB.2.00.1112211352580.17957@ds9.cixit.se>
On 21 December 2011 13:54, Peter Krefting <peter@softwolves.pp.se> wrote:
> Erik Blake:
>
>
>> As you can see, I'm running git on a Win7 64 machine. Is there any way to
>> escape the brackets? Or do I need to reinstall notepad++ on a different
>> path?
>
>
> Just use the 8.3 path instead, using either "C:/Progra~1" or "C:/Progra~2"
> (depending on how the system got installed). You can mix 8.3 and long paths
> in the same command (so keeping the "Notepad++" component is fine).
Or use a junction to make an alias of the name without strange chars....
Yves
--
perl -Mre=debug -e "/just|another|perl|hacker/"
^ permalink raw reply
* Re: Rewriting history and public-private-ish branches
From: Peter Krefting @ 2011-12-21 12:58 UTC (permalink / raw)
To: Jay Levitt; +Cc: git@vger.kernel.org
In-Reply-To: <4EF08086.6080606@gmail.com>
Jay Levitt:
> As long as I'm the only one who's seen this "published" history, am I doing
> anything bad?
I do things like that too, and as long as you know what you are doing, it
usually works fine.
> Do I leave any residue behind in the repo?
As long as you run "git gc" on the repos regularly, it shouldn't really
matter much. Your abandoned changes will be available through the reflog
until that expires, and when that has happened "git gc" should remove them
from the repositories altogether.
--
\\// Peter - http://www.softwolves.pp.se/
^ permalink raw reply
* Re: Escape character for .gitconfig
From: Peter Krefting @ 2011-12-21 12:54 UTC (permalink / raw)
To: Erik Blake; +Cc: Git Mailing List
In-Reply-To: <4EEC6A9D.1060005@icefield.yk.ca>
Erik Blake:
> As you can see, I'm running git on a Win7 64 machine. Is there any way to
> escape the brackets? Or do I need to reinstall notepad++ on a different path?
Just use the 8.3 path instead, using either "C:/Progra~1" or "C:/Progra~2"
(depending on how the system got installed). You can mix 8.3 and long paths
in the same command (so keeping the "Notepad++" component is fine).
--
\\// Peter - http://www.softwolves.pp.se/
^ permalink raw reply
* [PATCH] builtin/log: remove redundant initialization
From: Michael Schubert @ 2011-12-21 12:05 UTC (permalink / raw)
To: git
"abbrev" and "commit_format" in struct rev_info get initialized in
init_revisions - no need to reinit in cmd_log_init_defaults.
Signed-off-by: Michael Schubert <mschub@elegosoft.com>
---
builtin/log.c | 2 --
1 files changed, 0 insertions(+), 2 deletions(-)
diff --git a/builtin/log.c b/builtin/log.c
index 89d0cc0..7d1f6f8 100644
--- a/builtin/log.c
+++ b/builtin/log.c
@@ -73,8 +73,6 @@ static int decorate_callback(const struct option *opt, const char *arg, int unse
static void cmd_log_init_defaults(struct rev_info *rev)
{
- rev->abbrev = DEFAULT_ABBREV;
- rev->commit_format = CMIT_FMT_DEFAULT;
if (fmt_pretty)
get_commit_format(fmt_pretty, rev);
rev->verbose_header = 1;
--
1.7.8.400.g03f4
^ 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