* Re: [RFC PATCH] bash completion: complete refs for git-grep
From: Thomas Rast @ 2009-10-07 15:27 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: git
In-Reply-To: <20091006154555.GN9261@spearce.org>
Shawn O. Pearce wrote:
>
> Thomas Rast <trast@student.ethz.ch> wrote:
> > + local i c=1 have_regex=""
> > + while [ $c -lt $COMP_CWORD ]; do
> > + i="${COMP_WORDS[c]}"
> > + case "$i" in
> > + -e) ;;
> > + -e*) have_regex="$c" ; break ;;
> > + -*) ;;
> > + *) have_regex="$c"; break ;;
> > + esac
> > + c=$((++c))
> > + done
>
> What happens with `git grep -e a -e b`? Do we trigger into ref
> completion too early when we should still be doing the regex
> completion?
Hmm, true, I would also have to check for the last argument (before
completion) being -e.
However, that is kind of moot because we currently complete filenames
anyway, and you said I can't stop that:
> > This is still RFC because, as you can see in the code below, I tried
> > to avoid completing at all while the user still needs to supply a
> > regex. Sadly, bash turns the COMPREPLY=() into filename completion
> > anyway. Is there a way to prevent this?
>
> Not that I know of. You can turn off default filename completion
> when you register the completion function, but that then breaks
> like every other git command for completion support because a lot
> of them do want to complete filenames.
So I'll roll a simpler patch that just always (before --) completes
refs instead, if that's ok.
--
Thomas Rast
trast@{inf,student}.ethz.ch
^ permalink raw reply
* Re: [PATCH/RFC] New date format: local_original
From: Jeff King @ 2009-10-07 12:54 UTC (permalink / raw)
To: Tuomas Suutari; +Cc: git
In-Reply-To: <200910062209.47606.tuomas.suutari@gmail.com>
On Tue, Oct 06, 2009 at 10:09:47PM +0300, Tuomas Suutari wrote:
> Formats date and time with local and original timezone representation
> in same string. They both can be useful at the same time: local
> timezone for relating timestamp to local events, and original timezone
> to see the author's time of the day.
>
> [...]
>
> It was hard to decide whether to use --date=local or --date=iso
> with git log, so I though that maybe I could have them both.
It's not clear to me. Do you really _like_ seeing them both, or did you
simply want to see local dates in the iso format, but those two options
(which are conceptually orthogonal) could not be used at the same time?
If the latter, then maybe we should resurrect the patch that allows
"--date=local --date=iso" to do what you want. From this thread:
http://thread.gmane.org/gmane.comp.version-control.git/112026
If the former, then should the options be orthogonal? That is, should it
be a new format combining the two, or should it be an option to show, in
your preferred format, the time in both local and original time zones?
E.g., something like:
$ git log --date=iso --local-dates-too
commit bf01a69ed40e1afcf56aff143f7523da2ce263ed
Author: Johannes Schindelin <Johannes.Schindelin@gmx.de>
Date: 2009-10-04 00:41:55 +0200
Local: 2009-10-03 17:41:55 -0500
And then you can use it with "normal" dates, iso dates, rfc2822 dates,
etc.
I dunno. I have to admit I never personally really wanted anything
except the default date format, unless I was parsing it for something
special.
-Peff
^ permalink raw reply
* Re: Code reuse
From: Sitaram Chamarty @ 2009-10-07 12:30 UTC (permalink / raw)
To: Philip Herron; +Cc: git
In-Reply-To: <ac07bcaf0910061218x148374d0u66b36fae1466ea98@mail.gmail.com>
On Wed, Oct 7, 2009 at 12:48 AM, Philip Herron
<herron.philip@googlemail.com> wrote:
> I am not sure if this is the right place to ask this question, but
> I've been working on a personal project a programming language
> interpreter for some time now, but i took 2 code snippets from
> git-core namely:
[snip]
> I've changed it a good bit (probably doesn't resemble much of what it
> was) to fit in with the way my stuff works but is there anything i
> need to like put in my source code to say hey this is based of
> git-core, so far is just a comment to say 'based of git-core hash.c'.
> Its an open source (GPL) program but i haven't released or made much
> noise about it yet because i want to work on it more myself.
In general, the GPL's main requirement is that whoever gets the binary
should also get the code (I'm over simplifying but that's basically
it). It actually doesn't say much about giving credit, except (from
<HEAD:COPYING>):
"If the software is modified by someone else and passed on, we want
its recipients to know that what they have is not the original, so
that any problems introduced by others will not reflect on the
original authors' reputations"
and
"a) You must cause the modified files to carry prominent notices
stating that you changed the files and the date of any change."
That's basically it...
It would seem to me that, if you changed them significantly, and going
by the above logic, you don't need to do *anything* regarding
attribution.
^ permalink raw reply
* [PATCH] README: git lives at http://git-scm.com these days
From: Stefan Naewe @ 2009-10-07 12:14 UTC (permalink / raw)
To: git; +Cc: gitster, Stefan Naewe
Signed-off-by: Stefan Naewe <stefan.naewe+git@gmail.com>
---
README | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/README b/README
index c932ab3..67cfeb2 100644
--- a/README
+++ b/README
@@ -37,7 +37,7 @@ CVS users may also want to read Documentation/gitcvs-migration.txt
("man gitcvs-migration" or "git help cvs-migration" if git is
installed).
-Many Git online resources are accessible from http://git.or.cz/
+Many Git online resources are accessible from http://git-scm.com/
including full documentation and Git related tools.
The user discussion and development of Git take place on the Git
--
1.6.4.4
^ permalink raw reply related
* Re: [PATCH 1/3] completion: fix alias listings with newlines
From: Johannes Sixt @ 2009-10-07 9:33 UTC (permalink / raw)
To: Stephen Boyd; +Cc: Shawn O. Pearce, Junio C Hamano, git
In-Reply-To: <1254905331-29516-1-git-send-email-bebarino@gmail.com>
Stephen Boyd schrieb:
> __git_aliases ()
> {
> - local i IFS=$'\n'
> - for i in $(git --git-dir="$(__gitdir)" config --get-regexp "alias\..*" 2>/dev/null); do
> - i="${i#alias.}"
> - echo "${i/ */}"
> + local i
> + git --git-dir="$(__gitdir)" config -z --get-regexp "alias\..*" 2>/dev/null |
> + while IFS= read -rd '' i; do
> + echo ${i#alias.} | cut -d' ' -f1
> done
> }
Is it necessary to change the body of the loop? Your version spawns two
processes on each iteration, while the original spawned no processes.
You can avoid the pipeline (i.e. yet another process) using a "here-string":
local i aliases=$(git --git-dir="$(__gitdir)" config -z \
--get-regexp "alias\..*" 2>/dev/null)
while IFS= read -rd '' i; do
i="${i#alias.}"
echo "${i/ */}" # could be: echo "${i%% *}"
done <<< "$aliases"
but I don't know how well bash handles variable values with embedded NULs.
-- Hannes
^ permalink raw reply
* Question: Odd merging behaviour with copied/moved files
From: Michael Harbeck @ 2009-10-07 8:52 UTC (permalink / raw)
To: git
Hello,
I'd just had the following situation:
A repository with a file: File1
A clone of this repository.
I made some changes to File1 in this repository and checked them in
Now someone decide to to rename and copy the File1 in the first repository and
checked those changes in. Now there is no File1 any more in the first repository.
After a while I pulled from this first repository. My changes are only merged in
one file! I think this behavior is strange.
In the second case its also strange, that if there is a copy in the first
repository, after a pull my changes in the copied file are also missing.
Is there a possibility to get warned about these situations, or better is there
an automatic way to merge my changes to both pulled files?
Thanks,
Michael
^ permalink raw reply
* [PATCH 2/3] completion: update am, commit, and log
From: Stephen Boyd @ 2009-10-07 8:48 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: Junio C Hamano, git
In-Reply-To: <1254905331-29516-1-git-send-email-bebarino@gmail.com>
git am learned --scissors, git commit learned --dry-run and git log
learned --decorate=long|short recently.
Signed-off-by: Stephen Boyd <bebarino@gmail.com>
---
contrib/completion/git-completion.bash | 9 +++++++--
1 files changed, 7 insertions(+), 2 deletions(-)
diff --git a/contrib/completion/git-completion.bash b/contrib/completion/git-completion.bash
index 332be99..2ab8c5e 100755
--- a/contrib/completion/git-completion.bash
+++ b/contrib/completion/git-completion.bash
@@ -668,7 +668,7 @@ _git_am ()
--3way --committer-date-is-author-date --ignore-date
--ignore-whitespace --ignore-space-change
--interactive --keep --no-utf8 --signoff --utf8
- --whitespace=
+ --whitespace= --scissors
"
return
esac
@@ -894,6 +894,7 @@ _git_commit ()
__gitcomp "
--all --author= --signoff --verify --no-verify
--edit --amend --include --only --interactive
+ --dry-run
"
return
esac
@@ -1179,6 +1180,10 @@ _git_log ()
__gitcomp "$__git_log_date_formats" "" "${cur##--date=}"
return
;;
+ --decorate=*)
+ __gitcomp "long short" "" "${cur##--decorate=}"
+ return
+ ;;
--*)
__gitcomp "
$__git_log_common_options
@@ -1191,7 +1196,7 @@ _git_log ()
--pretty= --format= --oneline
--cherry-pick
--graph
- --decorate
+ --decorate --decorate=
--walk-reflogs
--parents --children
$merge
--
1.6.5.rc2.17.gdbc1b
^ permalink raw reply related
* [PATCH 1/3] completion: fix alias listings with newlines
From: Stephen Boyd @ 2009-10-07 8:48 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: Junio C Hamano, git
Since commit 518ef8f (completion: Replace config --list with
--get-regexp, 2009-09-11) an alias config value containing a newline
would break the completion of aliases. Instead of setting the IFS to the
newline, use git-config's null termination to separate aliases with the
null character.
An example .gitconfig causing the breakage.
[alias]
whowhat = "log -1 --pretty='format:%an <%ae>\n%s'"
wont-complete = ...
Signed-off-by: Stephen Boyd <bebarino@gmail.com>
---
This is the best I can come up with. I'm not sure about using the
d option of read though.
contrib/completion/git-completion.bash | 8 ++++----
1 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/contrib/completion/git-completion.bash b/contrib/completion/git-completion.bash
index 2c2a0d4..332be99 100755
--- a/contrib/completion/git-completion.bash
+++ b/contrib/completion/git-completion.bash
@@ -600,10 +600,10 @@ __git_porcelain_commandlist="$(__git_porcelain_commands 2>/dev/null)"
__git_aliases ()
{
- local i IFS=$'\n'
- for i in $(git --git-dir="$(__gitdir)" config --get-regexp "alias\..*" 2>/dev/null); do
- i="${i#alias.}"
- echo "${i/ */}"
+ local i
+ git --git-dir="$(__gitdir)" config -z --get-regexp "alias\..*" 2>/dev/null |
+ while IFS= read -rd '' i; do
+ echo ${i#alias.} | cut -d' ' -f1
done
}
--
1.6.5.rc2.17.gdbc1b
^ permalink raw reply related
* [PATCH 3/3] completion: add dirstat and friends to diff options
From: Stephen Boyd @ 2009-10-07 8:48 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: Junio C Hamano, git
In-Reply-To: <1254905331-29516-2-git-send-email-bebarino@gmail.com>
Signed-off-by: Stephen Boyd <bebarino@gmail.com>
---
I sent this a while back, no response. If no response again I'll drop.
contrib/completion/git-completion.bash | 2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/contrib/completion/git-completion.bash b/contrib/completion/git-completion.bash
index 2ab8c5e..a5fe1df 100755
--- a/contrib/completion/git-completion.bash
+++ b/contrib/completion/git-completion.bash
@@ -927,6 +927,8 @@ __git_diff_common_options="--stat --numstat --shortstat --summary
--inter-hunk-context=
--patience
--raw
+ --dirstat --dirstat= --dirstat-by-file
+ --dirstat-by-file= --cumulative
"
_git_diff ()
--
1.6.5.rc2.17.gdbc1b
^ permalink raw reply related
* [PATCH] Teach 'rebase -i' the command "reword"
From: Björn Gustavsson @ 2009-10-07 6:13 UTC (permalink / raw)
To: gitster; +Cc: git
Make it easier to edit just the commit message for a commit
using 'git rebase -i' by introducing the "reword" command.
Signed-off-by: Björn Gustavsson <bgustavsson@gmail.com>
---
Re-roll of my patch with improvements to the documentation
and help text suggested by Johannes Sixt and Stephen Boyd.
Documentation/git-rebase.txt | 9 ++++++---
git-rebase--interactive.sh | 9 +++++++++
t/lib-rebase.sh | 6 +++---
t/t3404-rebase-interactive.sh | 14 ++++++++++++++
4 files changed, 32 insertions(+), 6 deletions(-)
diff --git a/Documentation/git-rebase.txt b/Documentation/git-rebase.txt
index 0aefc34..33e0ef1 100644
--- a/Documentation/git-rebase.txt
+++ b/Documentation/git-rebase.txt
@@ -368,14 +368,17 @@ By replacing the command "pick" with the command "edit", you can tell
the files and/or the commit message, amend the commit, and continue
rebasing.
+If you just want to edit the commit message for a commit, replace the
+command "pick" with the command "reword".
+
If you want to fold two or more commits into one, replace the command
"pick" with "squash" for the second and subsequent commit. If the
commits had different authors, it will attribute the squashed commit to
the author of the first commit.
-In both cases, or when a "pick" does not succeed (because of merge
-errors), the loop will stop to let you fix things, and you can continue
-the loop with `git rebase --continue`.
+'git-rebase' will stop when "pick" has been replaced with "edit" or
+when a command fails due to merge errors. When you are done editing
+and/or resolving conflicts you can continue with `git rebase --continue`.
For example, if you want to reorder the last 5 commits, such that what
was HEAD~4 becomes the new HEAD. To achieve that, you would call
diff --git a/git-rebase--interactive.sh b/git-rebase--interactive.sh
index 23ded48..a43ee22 100755
--- a/git-rebase--interactive.sh
+++ b/git-rebase--interactive.sh
@@ -340,6 +340,14 @@ do_next () {
pick_one $sha1 ||
die_with_patch $sha1 "Could not apply $sha1... $rest"
;;
+ reword|r)
+ comment_for_reflog reword
+
+ mark_action_done
+ pick_one $sha1 ||
+ die_with_patch $sha1 "Could not apply $sha1... $rest"
+ output git commit --amend
+ ;;
edit|e)
comment_for_reflog edit
@@ -752,6 +760,7 @@ first and then run 'git rebase --continue' again."
#
# Commands:
# p, pick = use commit
+# r, reword = use commit, but edit the commit message
# e, edit = use commit, but stop for amending
# s, squash = use commit, but meld into previous commit
#
diff --git a/t/lib-rebase.sh b/t/lib-rebase.sh
index 260a231..62f452c 100644
--- a/t/lib-rebase.sh
+++ b/t/lib-rebase.sh
@@ -9,8 +9,8 @@
#
# "[<lineno1>] [<lineno2>]..."
#
-# If a line number is prefixed with "squash" or "edit", the respective line's
-# command will be replaced with the specified one.
+# If a line number is prefixed with "squash", "edit", or "reword", the
+# respective line's command will be replaced with the specified one.
set_fake_editor () {
echo "#!$SHELL_PATH" >fake-editor.sh
@@ -32,7 +32,7 @@ cat "$1".tmp
action=pick
for line in $FAKE_LINES; do
case $line in
- squash|edit)
+ squash|edit|reword)
action="$line";;
*)
echo sed -n "${line}s/^pick/$action/p"
diff --git a/t/t3404-rebase-interactive.sh b/t/t3404-rebase-interactive.sh
index 4cae019..3a37793 100755
--- a/t/t3404-rebase-interactive.sh
+++ b/t/t3404-rebase-interactive.sh
@@ -470,4 +470,18 @@ test_expect_success 'avoid unnecessary reset' '
test 123456789 = $MTIME
'
+test_expect_success 'reword' '
+ git checkout -b reword-branch master &&
+ FAKE_LINES="1 2 3 reword 4" FAKE_COMMIT_MESSAGE="E changed" git rebase -i A &&
+ git show HEAD | grep "E changed" &&
+ test $(git rev-parse master) != $(git rev-parse HEAD) &&
+ test $(git rev-parse master^) = $(git rev-parse HEAD^) &&
+ FAKE_LINES="1 2 reword 3 4" FAKE_COMMIT_MESSAGE="D changed" git rebase -i A &&
+ git show HEAD^ | grep "D changed" &&
+ FAKE_LINES="reword 1 2 3 4" FAKE_COMMIT_MESSAGE="B changed" git rebase -i A &&
+ git show HEAD~3 | grep "B changed" &&
+ FAKE_LINES="1 reword 2 3 4" FAKE_COMMIT_MESSAGE="C changed" git rebase -i A &&
+ git show HEAD~2 | grep "C changed"
+'
+
test_done
--
1.6.4.4
^ permalink raw reply related
* Re: [PATCH] Makefile: enable THREADED_DELTA_SEARCH on SunOS
From: Jeff King @ 2009-10-07 2:42 UTC (permalink / raw)
To: Brandon Casey; +Cc: gitster, git, Brandon Casey
In-Reply-To: <mMewRoxOZmBOCPocSz21A5zYKJozFCOnBBMfDefojFl0CJbciZjKAX7fE8hBoRYahowcn4j9VisPKCj9cOHGaw@cipher.nrlssc.navy.mil>
On Tue, Oct 06, 2009 at 08:02:22PM -0500, Brandon Casey wrote:
> Any objections? I've been compiling with THREADED_DELTA_SEARCH since I've
> been compiling on Solaris with no problems.
No complaint here. It seems to build and run fine on my pretty vanilla
Solaris 8 setup.
-Peff
^ permalink raw reply
* [PATCH] Makefile: enable THREADED_DELTA_SEARCH on SunOS
From: Brandon Casey @ 2009-10-07 1:02 UTC (permalink / raw)
To: gitster; +Cc: git, peff, Brandon Casey
From: Brandon Casey <drafnel@gmail.com>
Signed-off-by: Brandon Casey <casey@nrlssc.navy.mil>
---
Any objections? I've been compiling with THREADED_DELTA_SEARCH since I've
been compiling on Solaris with no problems.
-brandon
Makefile | 1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/Makefile b/Makefile
index 12defd4..dd3d520 100644
--- a/Makefile
+++ b/Makefile
@@ -734,6 +734,7 @@ ifeq ($(uname_S),SunOS)
NO_MKSTEMPS = YesPlease
NO_REGEX = YesPlease
NO_EXTERNAL_GREP = YesPlease
+ THREADED_DELTA_SEARCH = YesPlease
ifeq ($(uname_R),5.7)
NEEDS_RESOLV = YesPlease
NO_IPV6 = YesPlease
--
1.6.5.rc2.17.gdbc1b
^ permalink raw reply related
* Re: [PATCH/RFC] builtin-checkout: suggest creating local branch when appropriate to do so
From: Junio C Hamano @ 2009-10-06 20:33 UTC (permalink / raw)
To: Eugene Sajine; +Cc: Mikael Magnusson, git
In-Reply-To: <76c5b8580910060943k6172e3a5waee2f92c403e5cc3@mail.gmail.com>
Eugene Sajine <euguess@gmail.com> writes:
> As for the solution i would choose the "simplest thing that will work" - so
> i think that we just have to notify user about his suicide attempt to
> checkout nonlocal branch and offer him a correct syntax to go with.
We already do that, without going interactive, for warning unintended
detachment:
$ git checkout origin/next
Note: moving to 'origin/next' which isn't a local branch
If you want to create a new branch from this checkout, you may do so
(now or later) by using -b with the checkout command again. Example:
git checkout -b <new_branch_name>
...
As to Mikael's scenario:
>>> I can imagine this happening:
>>> % git clone git://git.git git
>>> % git checkout next
>>> do you want to checkout origin/next? y
>>> # a few days later
>>> % git fetch
>>> % git checkout next
>>> [freenode] /join #git
>>> [#git] i did git checkout next but my files are still the same?
No amount of sugarcoating the checkout syntax changes the fact that in the
user's repository there _are_ two distinct refs, origin/next and next, and
the "fetch few days later" updates only the former but never the latter.
It can only be fixed by injecting a bit of clue to the user, in a way
Dscho suggested in the thread.
^ permalink raw reply
* Re: [PATCH/RFC] builtin-checkout: suggest creating local branch when appropriate to do so
From: Junio C Hamano @ 2009-10-06 20:09 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Thomas Rast, Jeff King, Jay Soffian, git
In-Reply-To: <alpine.DEB.1.00.0910061359560.4686@intel-tinevez-2-302>
Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> So I'll stop wasting my time with this discussion.
I do not think it was a waste of time; earlier you said that you were not
proposing to include a patch that does that DWIMery, and we need to
discuss the downsides and upsides until we can figure out if it does more
good than harm.
And I think we reasonably established that this does more harm than good,
so I am Ok if you want to stop here.
^ permalink raw reply
* Code reuse
From: Philip Herron @ 2009-10-06 19:18 UTC (permalink / raw)
To: git
Hey guys
I am not sure if this is the right place to ask this question, but
I've been working on a personal project a programming language
interpreter for some time now, but i took 2 code snippets from
git-core namely:
static struct hash_table_entry *lookup_hash_entry(unsigned int hash,
const struct hash_table *table)
function from hash.c and the alloc_nr.
I've changed it a good bit (probably doesn't resemble much of what it
was) to fit in with the way my stuff works but is there anything i
need to like put in my source code to say hey this is based of
git-core, so far is just a comment to say 'based of git-core hash.c'.
Its an open source (GPL) program but i haven't released or made much
noise about it yet because i want to work on it more myself.
Anyways thanks,
--Phil
^ permalink raw reply
* [PATCH/RFC] New date format: local_original
From: Tuomas Suutari @ 2009-10-06 19:09 UTC (permalink / raw)
To: git
Formats date and time with local and original timezone representation
in same string. They both can be useful at the same time: local
timezone for relating timestamp to local events, and original timezone
to see the author's time of the day.
The format is ISO-8601 timestamp with weekday in local timezone
followed by weekday and time in original timezone in parentheses. The
weekday part makes it easier to understand the timestamps when the
days differ. For example, if local timezone is +0800, then timestamp
2009-10-04T19:37:03+0300 would be formatted as
"Mon 2009-10-05 00:37:03 (Sun 19:37:03 +0300)".
Signed-off-by: Tuomas Suutari <tuomas.suutari@gmail.com>
---
It was hard to decide whether to use --date=local or --date=iso
with git log, so I though that maybe I could have them both.
Hardest part was to decide the actual format string, especially
because they tend to get so long. My solution for that,
is to drop the date part out from the other timestamp and use
weekday as a way to relate them to each other.
So, what do you think? Could this be useful for anyone else?
Any better ideas for the format string?
ps. I tried to find the relevant parts of the documentation
and tests by grepping the names of the other formats (iso8601
and rfc2822) and updated them, but I could have easily missed
something. Tests did not show any new problems, but the
cvsimport tests (t960?) didn't seem to work before or after
my changes.
Documentation/git-for-each-ref.txt | 4 ++--
Documentation/rev-list-options.txt | 4 +++-
builtin-blame.c | 3 +++
cache.h | 3 ++-
contrib/completion/git-completion.bash | 5 ++++-
date.c | 23 +++++++++++++++++++++++
t/t6300-for-each-ref.sh | 15 ++++++++++++++-
7 files changed, 51 insertions(+), 6 deletions(-)
diff --git a/Documentation/git-for-each-ref.txt b/Documentation/git-for-each-ref.txt
index 8dc873f..00525c2 100644
--- a/Documentation/git-for-each-ref.txt
+++ b/Documentation/git-for-each-ref.txt
@@ -114,8 +114,8 @@ returns an empty string instead.
As a special case for the date-type fields, you may specify a format for
the date by adding one of `:default`, `:relative`, `:short`, `:local`,
-`:iso8601` or `:rfc2822` to the end of the fieldname; e.g.
-`%(taggerdate:relative)`.
+`:iso8601`, `:rfc2822`, or `:local_original`, to the end of the
+fieldname; e.g. `%(taggerdate:relative)`.
EXAMPLES
diff --git a/Documentation/rev-list-options.txt b/Documentation/rev-list-options.txt
index bf66116..e007244 100644
--- a/Documentation/rev-list-options.txt
+++ b/Documentation/rev-list-options.txt
@@ -13,7 +13,7 @@ include::pretty-options.txt[]
Synonym for `--date=relative`.
---date={relative,local,default,iso,rfc,short,raw}::
+--date={relative,local,default,iso,rfc,short,raw,local_original}::
Only takes effect for dates shown in human-readable format, such
as when using "--pretty". `log.date` config variable sets a default
@@ -35,6 +35,8 @@ format, often found in E-mail messages.
+
`--date=default` shows timestamps in the original timezone
(either committer's or author's).
++
+`--date=local_original` shows timestamps in local and original timezone.
ifdef::git-rev-list[]
--header::
diff --git a/builtin-blame.c b/builtin-blame.c
index 7512773..4766dd5 100644
--- a/builtin-blame.c
+++ b/builtin-blame.c
@@ -2290,6 +2290,9 @@ parse_done:
case DATE_NORMAL:
blame_date_width = sizeof("Thu Oct 19 16:00:04 2006 -0700");
break;
+ case DATE_LOCAL_ORIGINAL:
+ blame_date_width = sizeof("Thu 2006-10-19 16:00:04 (Thu 16:00:04 -0700)");
+ break;
}
blame_date_width -= 1; /* strip the null */
diff --git a/cache.h b/cache.h
index a5eeead..89c3c12 100644
--- a/cache.h
+++ b/cache.h
@@ -729,7 +729,8 @@ enum date_mode {
DATE_LOCAL,
DATE_ISO8601,
DATE_RFC2822,
- DATE_RAW
+ DATE_RAW,
+ DATE_LOCAL_ORIGINAL
};
const char *show_date(unsigned long time, int timezone, enum date_mode mode);
diff --git a/contrib/completion/git-completion.bash b/contrib/completion/git-completion.bash
index 2c2a0d4..4f4ca53 100755
--- a/contrib/completion/git-completion.bash
+++ b/contrib/completion/git-completion.bash
@@ -1152,7 +1152,10 @@ __git_log_shortlog_options="
"
__git_log_pretty_formats="oneline short medium full fuller email raw format:"
-__git_log_date_formats="relative iso8601 rfc2822 short local default raw"
+__git_log_date_formats="
+ relative iso8601 rfc2822 short local default raw
+ local_original
+"
_git_log ()
{
diff --git a/date.c b/date.c
index 5d05ef6..b34a735 100644
--- a/date.c
+++ b/date.c
@@ -151,6 +151,7 @@ const char *show_date(unsigned long time, int tz, enum date_mode mode)
{
struct tm *tm;
static char timebuf[200];
+ int n;
if (mode == DATE_RAW) {
snprintf(timebuf, sizeof(timebuf), "%lu %+05d", time, tz);
@@ -185,6 +186,26 @@ const char *show_date(unsigned long time, int tz, enum date_mode mode)
weekday_names[tm->tm_wday], tm->tm_mday,
month_names[tm->tm_mon], tm->tm_year + 1900,
tm->tm_hour, tm->tm_min, tm->tm_sec, tz);
+ else if (mode == DATE_LOCAL_ORIGINAL) {
+ /* Use local timezone first... */
+ tm = time_to_tm(time, local_tzoffset(time));
+ if (!tm)
+ return NULL;
+ n = sprintf(timebuf, "%.3s %04d-%02d-%02d %02d:%02d:%02d",
+ weekday_names[tm->tm_wday],
+ tm->tm_year + 1900,
+ tm->tm_mon + 1,
+ tm->tm_mday,
+ tm->tm_hour, tm->tm_min, tm->tm_sec);
+ /* ...and then original timezone. */
+ tm = time_to_tm(time, tz);
+ if (!tm)
+ return NULL;
+ sprintf(timebuf + n, " (%.3s %02d:%02d:%02d %+05d)",
+ weekday_names[tm->tm_wday],
+ tm->tm_hour, tm->tm_min, tm->tm_sec,
+ tz);
+ }
else
sprintf(timebuf, "%.3s %.3s %d %02d:%02d:%02d %d%c%+05d",
weekday_names[tm->tm_wday],
@@ -656,6 +677,8 @@ enum date_mode parse_date_format(const char *format)
return DATE_NORMAL;
else if (!strcmp(format, "raw"))
return DATE_RAW;
+ else if (!strcmp(format, "local_original"))
+ return DATE_LOCAL_ORIGINAL;
else
die("unknown date format %s", format);
}
diff --git a/t/t6300-for-each-ref.sh b/t/t6300-for-each-ref.sh
index 8052c86..1c91b21 100755
--- a/t/t6300-for-each-ref.sh
+++ b/t/t6300-for-each-ref.sh
@@ -122,7 +122,8 @@ test_expect_success 'Check valid format specifiers for date fields' '
git for-each-ref --format="%(authordate:short)" refs/heads &&
git for-each-ref --format="%(authordate:local)" refs/heads &&
git for-each-ref --format="%(authordate:iso8601)" refs/heads &&
- git for-each-ref --format="%(authordate:rfc2822)" refs/heads
+ git for-each-ref --format="%(authordate:rfc2822)" refs/heads &&
+ git for-each-ref --format="%(authordate:local_original)" refs/heads
'
test_expect_success 'Check invalid format specifiers are errors' '
@@ -211,6 +212,18 @@ test_expect_success 'Check format "rfc2822" date fields output' '
'
cat >expected <<\EOF
+'refs/heads/master' 'Mon 2006-07-03 15:18:43 (Mon 17:18:43 +0200)' 'Mon 2006-07-03 15:18:44 (Mon 17:18:44 +0200)'
+'refs/tags/testtag' 'Mon 2006-07-03 15:18:45 (Mon 17:18:45 +0200)'
+EOF
+
+test_expect_success 'Check format "local_original" date fields output' '
+ f=local_original &&
+ (git for-each-ref --shell --format="%(refname) %(committerdate:$f) %(authordate:$f)" refs/heads &&
+ git for-each-ref --shell --format="%(refname) %(taggerdate:$f)" refs/tags) >actual &&
+ test_cmp expected actual
+'
+
+cat >expected <<\EOF
refs/heads/master
refs/remotes/origin/master
refs/tags/testtag
--
1.6.4.1
^ permalink raw reply related
* Re: Re: [PATCH/RFC] builtin-checkout: suggest creating local branch when appropriate to do so
From: Eugene Sajine @ 2009-10-06 16:43 UTC (permalink / raw)
To: Mikael Magnusson; +Cc: Euguess, git
In-Reply-To: <0016e68fd0123a175304754694b4@google.com>
It seams that my first email was eaten by the server for some
reason... Sorry, if it will be a dupe.
On Tue, Oct 6, 2009 at 12:18 PM, <Euguess@gmail.com> wrote:
Hi,
If i may have a word:
> On Oct 6, 2009 5:41am, Mikael Magnusson <mikachu@gmail.com> wrote:
>> I can imagine this happening:
>>
>> % git clone git://git.git git
>>
>> % git checkout next
>>
>> do you want to checkout origin/next? y
>>
>> # a few days later
>>
>> % git fetch
>>
>> % git checkout next
>>
>> [freenode] /join #git
>>
>> [#git] i did git checkout next but my files are still the same?
>>
I'm a new user of git and I don't think i will ever have a commit in
git.git, because I'm not a programmer (I'm QA). I was reading this topic as
carefully as i could and I think that this makes a lot of sense to address
this issue. As i understand when somebody fetches from remote repo in order
to be able to start working on the code from this remote repo you should
create tracking branch for one of the branches from remote and only then you
should do your changes or perform merges.
in case if you didn't do that and you try to checkout you will end up having
detached HEAD which is quite scary;) for non-experienced user and as i see
might lead to some unnecessary questions in this list or on IRC channel...
As for the solution i would choose the "simplest thing that will work" - so
i think that we just have to notify user about his suicide attempt to
checkout nonlocal branch and offer him a correct syntax to go with.
Something like below should work:
% git clone git://git.git git
% git checkout next
You're attempting to checkout to non-local branch. This will lead to your
HEAD being detached (our team is on its way!).
Do you want to check out local branch 'next' tracking 'origin/next' instead?
y/n
if yes, then:
Created branch "next" tracking "origin/next"
You can update it with 'git pull'.
If no - abort or continue with checkout to nonlocal branch? ('m not sure if
detaching HEAD can provide some benefits if done on purpose)
I hope I'm not missing anything...
Thanks,
Eugene
^ permalink raw reply
* Re: [RFC PATCH] bash completion: complete refs for git-grep
From: Shawn O. Pearce @ 2009-10-06 15:45 UTC (permalink / raw)
To: Thomas Rast; +Cc: git
In-Reply-To: <14ac499280c9b17f862ab13201b48c64b4827713.1254823328.git.trast@student.ethz.ch>
Thomas Rast <trast@student.ethz.ch> wrote:
> This is still RFC because, as you can see in the code below, I tried
> to avoid completing at all while the user still needs to supply a
> regex. Sadly, bash turns the COMPREPLY=() into filename completion
> anyway. Is there a way to prevent this?
Not that I know of. You can turn off default filename completion
when you register the completion function, but that then breaks
like every other git command for completion support because a lot
of them do want to complete filenames.
> + local i c=1 have_regex=""
> + while [ $c -lt $COMP_CWORD ]; do
> + i="${COMP_WORDS[c]}"
> + case "$i" in
> + -e) ;;
> + -e*) have_regex="$c" ; break ;;
> + -*) ;;
> + *) have_regex="$c"; break ;;
> + esac
> + c=$((++c))
> + done
What happens with `git grep -e a -e b`? Do we trigger into ref
completion too early when we should still be doing the regex
completion?
--
Shawn.
^ permalink raw reply
* Re: [PATCH] Documentation - pt-BR.
From: Thiago Farina @ 2009-10-06 15:20 UTC (permalink / raw)
To: Miklos Vajna; +Cc: Jeff King, Junio C Hamano, git
In-Reply-To: <20091006094701.GG32702@genesis.frugalware.org>
Hi Miklos,
On Tue, Oct 6, 2009 at 6:47 AM, Miklos Vajna <vmiklos@frugalware.org> wrote:
> On Mon, Oct 05, 2009 at 06:09:10AM -0400, Jeff King <peff@peff.net> wrote:
>> > Has anybody actually tried to format this document, either before or after
>> > your patch?
>>
>> No, I didn't, and I should have when I picked up the patch in the first
>> place. You are right, asciidoc barfs (both for html and xml generation):
>>
>> ERROR: gittutorial.txt: line 5: first section must be named NAME
>> ERROR: gittutorial.txt: line 9: second section must be named SYNOPSIS
>
> Ah, there is no language config for pt_BR.
>
> $ ls -1 /etc/asciidoc/lang-*
> /etc/asciidoc/lang-de.conf
> /etc/asciidoc/lang-en.conf
> /etc/asciidoc/lang-es.conf
> /etc/asciidoc/lang-fr.conf
> /etc/asciidoc/lang-hu.conf
> /etc/asciidoc/lang-ru.conf
In my system I only have installed lang-es.conf, how I could install the others?
>
> Once asciidoc will have a lang-pt_BR.conf, we could just use -a
> lang=pt_BR and it would happily accept this input.
>
> Thiago, could you make a lang-pt_BR.conf? It's less than 100 lines, so
> it should be easy for you. (If you can send it to the asciidoc list
> directly, it's even better.)
Sure, I made the lang-pt-BR.conf, and I sent it to asciidoc@googlegroups.com.
^ permalink raw reply
* git rev-list --pretty=raw strips empty lines
From: Rolf Bjarne Kvinge @ 2009-10-06 12:33 UTC (permalink / raw)
To: git
[-- Attachment #1: Type: text/plain, Size: 1443 bytes --]
Hi,
It seems like the --pretty=raw format strips off empty newlines from the beginning of log messages, while I'd expect the raw format to not do any transformations (just as the documentation says: "The 'raw' format shows the entire commit exactly as stored in the commit object").
I've attached a test script that I can use to reproduce with current master (dbc1b1f71052c0)
The below changes works for me, not sure if I'm right about this though (my first time here ;-)
Rolf
diff --git a/pretty.c b/pretty.c
index f5983f8..1037700 100644
--- a/pretty.c
+++ b/pretty.c
@@ -868,7 +868,7 @@ void pp_remainder(enum cmit_fmt fmt,
break;
if (is_empty_line(line, &linelen)) {
- if (first)
+ if (first && fmt != CMIT_FMT_RAW)
continue;
if (fmt == CMIT_FMT_SHORT)
break;
@@ -952,7 +952,8 @@ void pretty_print_commit(enum cmit_fmt fmt, const struct commit *commit,
}
/* Skip excess blank lines at the beginning of body, if any... */
- msg = skip_empty_lines(msg);
+ if (fmt != CMIT_FMT_RAW)
+ msg = skip_empty_lines(msg);
/* These formats treat the title line specially. */
if (fmt == CMIT_FMT_ONELINE || fmt == CMIT_FMT_EMAIL)
--
Using Opera's revolutionary e-mail client: http://www.opera.com/mail/
[-- Attachment #2: test.sh --]
[-- Type: application/octet-stream, Size: 652 bytes --]
#!/bin/bash -e
cat > msg << EOF
first line
EOF
# the following exports are just to make the size of the rev-list output only dependent on the size of the log message
export GIT_COMMITTER_NAME=Bar
export GIT_COMMITTER_EMAIL="bar@foo.com"
export GIT_COMMITTER_DATE="2000/01/01 00:00"
export GIT_AUTHOR_NAME=Foo
export GIT_AUTHOR_EMAIL="foo@bar.com"
export GIT_AUTHOR_DATE="2000/01/01 00:00"
git add msg
git commit -F msg --cleanup=verbatim
git rev-list --pretty=raw -1 HEAD | tee msg.tmp
SIZE=`cat msg.tmp | wc -c`
# current master gives a message length of 244
echo Expected message length: 259, got message length: $SIZE
git reset HEAD^ --hard
^ permalink raw reply related
* Re: [PATCH] Add the --submodule-summary option to the diff option family
From: Johannes Schindelin @ 2009-10-06 12:10 UTC (permalink / raw)
To: Jens Lehmann; +Cc: Junio C Hamano, git
In-Reply-To: <4ACB2F2D.8010503@web.de>
Hi,
On Tue, 6 Oct 2009, Jens Lehmann wrote:
> Johannes Schindelin schrieb:
> > Hi,
> >
> > On Tue, 6 Oct 2009, Junio C Hamano wrote:
> >
> >> Jens Lehmann <Jens.Lehmann@web.de> writes:
> >>
> >>>> But I really, really, really want to avoid a fork() in the common case. I
> >>>> do have some users on Windows, and I do have a few submodules in that
> >>>> project. Having too many fork() calls there would just give Git a bad
> >>>> reputation. And it has enough of that, it does not need more.
> >>> Me too thinks performance matters here. We do have a repo at my dayjob
> >>> with more than a handful of submodules and its main target platform is
> >>> windows ... so having that perform nicely is a win for us.
> >> Numbers?
> >>
> >> I'd prefer to avoid kludges that favors unsubstantiated performance
> >> argument over correctness.
> >
> > Well, having worked with msysGit for such a long time, I just _know_ that
> > a subprocess costs a substantial amount of time.
> >
> > But as you don't trust my words, maybe Jens could be so kind as to perform
> > some benchmarks? I am short on Git time budget, but I will make a commit
> > on my submodule-summary branch that allows to start a subprocess always.
>
> Sure, will do.
Okay, it is there. It is quick and dirty, so you don't even want to look
at the commit message.
Could you please run something like "time git diff --submodule-summary
--all" with and without this patch?
Thanks,
Dscho
^ permalink raw reply
* Re: [PATCH/RFC] builtin-checkout: suggest creating local branch when appropriate to do so
From: Johannes Schindelin @ 2009-10-06 12:02 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Thomas Rast, Jeff King, Jay Soffian, git
In-Reply-To: <7vvdis21qk.fsf@alter.siamese.dyndns.org>
Hi,
On Tue, 6 Oct 2009, Junio C Hamano wrote:
> Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
>
> >> 4. Are there any (scripted?) use-cases where git-checkout should fail
> >> because it was given an invalid branch name?
> >>
> >> The following gives a hint, though they could of course be fixed and
> >> the ^0 case doesn't really count:
> >>
> >> $ git grep 'git checkout .*||' -- "*.sh"
> >> git-bisect.sh: git checkout "$start_head" -- || exit
> >> git-rebase--interactive.sh: output git checkout $first_parent 2> /dev/null ||
> >> git-rebase--interactive.sh: output git checkout "$1" ||
> >> git-rebase.sh:git checkout -q "$onto^0" || die "could not detach HEAD"
> >> t/t2007-checkout-symlink.sh:git checkout -f master || exit
> >
> > Actually, in said cases (with exception of the test case, which should be
> > fine, however, having no remote branches), I would expect the user to be
> > grateful if the DWIMery would happen.
>
> Did you check the context before making that assertion?
No, but I checked the _names_ of the scripts.
In case of bisect, if I know upstream is good, I might indeed say "git
bisect good next", even if I haven't checked myself earlier.
In case of "rebase", about the same happens: if I say "git rebase next",
and there is no "next", but an "origin/next", and no other remote branch
"*/next", it is pretty clear what I mean, too.
In any case, it seems pretty clear to me that this DWIMery, while I am
pretty certain would be useful for actual users without commits in
git.git, will not make it into git.git.
So I'll stop wasting my time with this discussion.
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH] Add the --submodule-summary option to the diff option family
From: Jens Lehmann @ 2009-10-06 11:51 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Junio C Hamano, git
In-Reply-To: <alpine.DEB.1.00.0910061344070.4686@intel-tinevez-2-302>
Johannes Schindelin schrieb:
> Hi,
>
> On Tue, 6 Oct 2009, Junio C Hamano wrote:
>
>> Jens Lehmann <Jens.Lehmann@web.de> writes:
>>
>>>> But I really, really, really want to avoid a fork() in the common case. I
>>>> do have some users on Windows, and I do have a few submodules in that
>>>> project. Having too many fork() calls there would just give Git a bad
>>>> reputation. And it has enough of that, it does not need more.
>>> Me too thinks performance matters here. We do have a repo at my dayjob
>>> with more than a handful of submodules and its main target platform is
>>> windows ... so having that perform nicely is a win for us.
>> Numbers?
>>
>> I'd prefer to avoid kludges that favors unsubstantiated performance
>> argument over correctness.
>
> Well, having worked with msysGit for such a long time, I just _know_ that
> a subprocess costs a substantial amount of time.
>
> But as you don't trust my words, maybe Jens could be so kind as to perform
> some benchmarks? I am short on Git time budget, but I will make a commit
> on my submodule-summary branch that allows to start a subprocess always.
Sure, will do.
Jens
^ permalink raw reply
* Re: [PATCH] Add the --submodule-summary option to the diff option family
From: Johannes Schindelin @ 2009-10-06 11:45 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Jens Lehmann, git
In-Reply-To: <7vocok21pw.fsf@alter.siamese.dyndns.org>
Hi,
On Tue, 6 Oct 2009, Junio C Hamano wrote:
> Jens Lehmann <Jens.Lehmann@web.de> writes:
>
> >> But I really, really, really want to avoid a fork() in the common case. I
> >> do have some users on Windows, and I do have a few submodules in that
> >> project. Having too many fork() calls there would just give Git a bad
> >> reputation. And it has enough of that, it does not need more.
> >
> > Me too thinks performance matters here. We do have a repo at my dayjob
> > with more than a handful of submodules and its main target platform is
> > windows ... so having that perform nicely is a win for us.
>
> Numbers?
>
> I'd prefer to avoid kludges that favors unsubstantiated performance
> argument over correctness.
Well, having worked with msysGit for such a long time, I just _know_ that
a subprocess costs a substantial amount of time.
But as you don't trust my words, maybe Jens could be so kind as to perform
some benchmarks? I am short on Git time budget, but I will make a commit
on my submodule-summary branch that allows to start a subprocess always.
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH/RFC] builtin-checkout: suggest creating local branch when appropriate to do so
From: Junio C Hamano @ 2009-10-06 11:36 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Thomas Rast, Jeff King, Jay Soffian, git
In-Reply-To: <alpine.DEB.1.00.0910061112570.4985@pacific.mpi-cbg.de>
Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
>> 4. Are there any (scripted?) use-cases where git-checkout should fail
>> because it was given an invalid branch name?
>>
>> The following gives a hint, though they could of course be fixed and
>> the ^0 case doesn't really count:
>>
>> $ git grep 'git checkout .*||' -- "*.sh"
>> git-bisect.sh: git checkout "$start_head" -- || exit
>> git-rebase--interactive.sh: output git checkout $first_parent 2> /dev/null ||
>> git-rebase--interactive.sh: output git checkout "$1" ||
>> git-rebase.sh:git checkout -q "$onto^0" || die "could not detach HEAD"
>> t/t2007-checkout-symlink.sh:git checkout -f master || exit
>
> Actually, in said cases (with exception of the test case, which should be
> fine, however, having no remote branches), I would expect the user to be
> grateful if the DWIMery would happen.
Did you check the context before making that assertion?
- The one in git-bisect switches to (or detaches at) what was earlier
written in BISECT_START, which is either a branch name or a commit
object name, so the user definitely does not want DWIMery if it could
check out something else --- I do not think DWIMery hurts as long as
the user does not delete the original branch while bisecting, though.
- The first one in "rebase -i" is always fed a commit object name;
DWIMery is not needed (and it would not hurt).
- The second one in "rebase -i" is about switching to the branch being
rebased, and it has an explicit check to see if "$1" is a branch name;
DWIMery is not needed (and it would not hurt because of the check
before it).
- The one in "rebase" proper, as Thomas pointed out, is an explicit
request to detach, so DWIMery won't happen.
The first three cases that could trigger DWIMery fall into "DWIMery does
not hurt because it happens to be a no-op in the way it is used" category,
not "In this case, the users would actively appreciate DWIMery". IOW,
this does not look particularly a good argument to support DWIMery to me.
About the second one in "rebase -i", and also the corresponding one in
"rebase", which is:
test -z "$switch_to" || git checkout "$switch_to"
If the command did DWIM, you would fork a local branch from the remote and
immediately rebase it. Any good git tutorial teaches not to rebase work
by others, and keeping the result of such a rebase on a local branch goes
directly against it [*1*]; the script needs to be updated to protect
itself from DWIMery if we were to change "checkout" in these cases.
[Footnote]
*1* It is quite useful to temporarily rebase others work, e.g. in order to
compare what got changed in the newer version of series, so I wouldn't
object if the user did
git checkout origin/topic
git rebase $(git merge-base origin/topic@{1} origin/topic)
git show-branch origin/topic@{1} HEAD
but notice that it all happens on detached HEAD, not to be kept.
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox