* Re: [PATCH/RFC] builtin-checkout: suggest creating local branch when appropriate to do so
From: Johannes Schindelin @ 2009-10-06 9:16 UTC (permalink / raw)
To: Thomas Rast; +Cc: Jeff King, Jay Soffian, git
In-Reply-To: <200910060932.24377.trast@student.ethz.ch>
Hi,
On Tue, 6 Oct 2009, Thomas Rast wrote:
> Jeff King wrote:
> > On Mon, Oct 05, 2009 at 11:17:09PM +0200, Johannes Schindelin wrote:
> >
> > > > $ git checkout next
> > > > error: pathspec 'next' did not match any file(s) known to git.
> > >
> > > Actually, we should really think long and hard why we should not
> > > automatically check out the local branch "next" in that case. I mean,
> > > really long and hard, and making sure to take user-friendliness into
> > > account at least as much as simplicity of implementation.
> >
> > Some devil's advocate questions:
> >
> > 1. How do we find "origin/next" given "next"? What are the exact
> > lookup rules? Do they cover every case? Do they avoid surprising
> > the user?
> >
> > 2. What do we do if our lookup is ambiguous (e.g., "origin/next" and
> > "foobar/next" both exist)?
> >
> > 3. If our lookup does have ambiguities or corner cases, is it better
> > to simply be suggesting to the user, rather than proceeding with an
> > action?
>
> If I may add another:
>
> 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.
I have to clarify something here: I am not proposing to include a patch
that does that DWIMery. We need to discuss the downsides and upsides
until we can be pretty certain that it does more good than harm.
Unfortunately, this list does not seem to be very inviting to pure users,
who I hoped would chime in on this issue.
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH/RFC] builtin-checkout: suggest creating local branch when appropriate to do so
From: Matthieu Moy @ 2009-10-06 9:28 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Jeff King, Jay Soffian, git
In-Reply-To: <alpine.DEB.1.00.0910061111410.4985@pacific.mpi-cbg.de>
Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> Hi,
>
> On Mon, 5 Oct 2009, Jeff King wrote:
>
>> Some devil's advocate questions:
>>
>> 1. How do we find "origin/next" given "next"? What are the exact
>> lookup rules? Do they cover every case? Do they avoid surprising
>> the user?
>
> I am sure your strategy would be the same as mine: enumerate all remote
> branches, strip the remote nickname, and compare. If there are
> ambiguities, tell the user and stop.
>
>> 2. What do we do if our lookup is ambiguous (e.g., "origin/next" and
>> "foobar/next" both exist)?
>
> See above.
One problem with this approach is that if users get used to the
behavior, the command will have great probability to end up in a
user's script, then the script will "work" as long as there is no
ambiguity, and cease to work afterwards. And for the user of the
script, this will sound like "WTF, it was working yesterday and it's
broken now".
So, the good thing with being strict, even if giving advice in case of
failure, is that it teaches the user the reliable way to do.
All that said, I'm not sure how serious this is, but we're in a
"devil's advocate" session, so I'm still allowed to speak ;-).
The other fear I have is to create confusion. Today, it's quite clear
that "next" is not the same as "origin/next". With some DWIMery on top
of this, a naive user may think they are more or less the same, and
then not understand what "git fetch" does and why it's not the same as
"git pull".
--
Matthieu Moy
http://www-verimag.imag.fr/~moy/
^ permalink raw reply
* Re: [PATCH/RFC] builtin-checkout: suggest creating local branch when appropriate to do so
From: Mikael Magnusson @ 2009-10-06 9:41 UTC (permalink / raw)
To: Matthieu Moy; +Cc: Johannes Schindelin, Jeff King, Jay Soffian, git
In-Reply-To: <vpqiqesna6x.fsf@bauges.imag.fr>
2009/10/6 Matthieu Moy <Matthieu.Moy@grenoble-inp.fr>:
> Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
>
>> Hi,
>>
>> On Mon, 5 Oct 2009, Jeff King wrote:
>>
>>> Some devil's advocate questions:
>>>
>>> 1. How do we find "origin/next" given "next"? What are the exact
>>> lookup rules? Do they cover every case? Do they avoid surprising
>>> the user?
>>
>> I am sure your strategy would be the same as mine: enumerate all remote
>> branches, strip the remote nickname, and compare. If there are
>> ambiguities, tell the user and stop.
>>
>>> 2. What do we do if our lookup is ambiguous (e.g., "origin/next" and
>>> "foobar/next" both exist)?
>>
>> See above.
>
> One problem with this approach is that if users get used to the
> behavior, the command will have great probability to end up in a
> user's script, then the script will "work" as long as there is no
> ambiguity, and cease to work afterwards. And for the user of the
> script, this will sound like "WTF, it was working yesterday and it's
> broken now".
>
> So, the good thing with being strict, even if giving advice in case of
> failure, is that it teaches the user the reliable way to do.
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?
--
Mikael Magnusson
^ permalink raw reply
* Re: [PATCH] Documentation - pt-BR.
From: Miklos Vajna @ 2009-10-06 9:47 UTC (permalink / raw)
To: Jeff King; +Cc: Junio C Hamano, Thiago Farina, git
In-Reply-To: <20091005100910.GA866@coredump.intra.peff.net>
[-- Attachment #1: Type: text/plain, Size: 1015 bytes --]
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
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.)
[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* Re: [PATCH] tests: make all test files executable
From: Jeff King @ 2009-10-06 10:00 UTC (permalink / raw)
To: Mark Rada; +Cc: Junio C Hamano, git
In-Reply-To: <4ACAA15E.6090403@mailservices.uwaterloo.ca>
On Mon, Oct 05, 2009 at 09:46:06PM -0400, Mark Rada wrote:
> No changes, just a resend. This should work; I assume
> the problem last time was a human error (me :(), or
> something weird that happens with saving e-mail drafts
> between Apple Mail and Thunderbird (they share).
This version looks fine (though I fixed up and applied the old one, so
it is only useful as an experment). Whatever you did differently worked.
:)
> Jeff, please explain what you meant by `inscrutable
> binary'? It is an ASCII text file according to file.
> ¯\(°_o)/¯
When I looked at in mutt, it was full of binary garbage. But looking at
it more closely, the attachment is bogus. Look at:
http://article.gmane.org/gmane.comp.version-control.git/129522/raw
You have a message/rfc822 attachment which claims to be encoded using
base64. But there's a bunch of extra text at the top before the base64
starts, which throws off the decoding, leading to the binary garbage.
So the .eml format appears to be a subset of the headers, followed by
the base64-encoded body. But your mail client, in attaching it, marked
it as base64-encoded, which is just wrong. But in theory that is a
problem in transporting the file to the list. For you to "git am" it
yourself, we'll assume you saw the raw contents.
Even then, it is still a confusing format. Instead of the headers
looking like
From: whatever
there is a line break, so they appear as
From:
whatever
and of course there are no mime headers indicating that body is
base64-encoded. So it is definitely not an rfc822 message, which is what
"git am" is expecting.
-Peff
^ permalink raw reply
* Re: [PATCH/RFC] builtin-checkout: suggest creating local branch when appropriate to do so
From: Johannes Schindelin @ 2009-10-06 10:04 UTC (permalink / raw)
To: Mikael Magnusson; +Cc: Matthieu Moy, Jeff King, Jay Soffian, git
In-Reply-To: <237967ef0910060241q671baafav93fe6402a4c510c5@mail.gmail.com>
Hi,
On Tue, 6 Oct 2009, Mikael Magnusson 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 imagined more something like this:
$ git clone git://git.git git
$ git checkout next
Automatically checking out local branch 'next' tracking 'origin/next'.
Please update it with 'git pull'.
Ciao,
Dscho
^ permalink raw reply
* [RFC PATCH] bash completion: complete refs for git-grep
From: Thomas Rast @ 2009-10-06 10:08 UTC (permalink / raw)
To: git; +Cc: Shawn O. Pearce
Attempt ref completion once we have seen a regular expression, to help
the user with entering the <treeish> arguments.
Signed-off-by: Thomas Rast <trast@student.ethz.ch>
---
The use-case for this is actually a bit protracted but came up on IRC
yesterday: pasky asked if there was a simple way to grep through a
certain file in all refs.
Turns out git-grep already has half the required support: when given a
series of refs, it prefixes the matches with the ref, so the output is
already in a useful format.
Sadly it does not appear to support --all, --branches or similar
(which would be material for a separate patch). But bash completion
can step in here: with M-*, it can expand all possible completions for
the current word onto the command line.
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? Otherwise the regex
complication should probably just go away and we can complete refs
always.
contrib/completion/git-completion.bash | 18 ++++++++++++++++++
1 files changed, 18 insertions(+), 0 deletions(-)
diff --git a/contrib/completion/git-completion.bash b/contrib/completion/git-completion.bash
index 6fd7e1d..c8cced6 100755
--- a/contrib/completion/git-completion.bash
+++ b/contrib/completion/git-completion.bash
@@ -1048,6 +1048,24 @@ _git_grep ()
return
;;
esac
+
+ 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
+
+ if [ -n "$have_regex" ]; then
+ __gitcomp "$(__git_refs)"
+ return
+ fi
+
COMPREPLY=()
}
--
1.6.5.rc2.251.g34f85
^ permalink raw reply related
* Re: [PATCH] Add the --submodule-summary option to the diff option family
From: Jens Lehmann @ 2009-10-06 10:58 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Junio C Hamano, git
In-Reply-To: <alpine.DEB.1.00.0910052251190.4985@pacific.mpi-cbg.de>
Johannes Schindelin schrieb:
>>> I have no idea why "submodule --summary" uses --first-parent, but
>>> personally, I would _hate_ it not to see the merged commits in the
>>> diff.
>>>
>>> For a summary, you might get away with seeing
>>>
>>> > Merge bla
>>> > Merge blub
>>> > Merge this
>>> > Merge that
>>>
>>> but in a diff that does not cut it at all.
>> As long as bla/blub/this/that are descriptive enough, I do not see at all
>> why you think "summary" is Ok and "diff" is not. If your response were
>> "it is just a matter of taste; to some people (or project) --first-parent
>> is useful and for others it is not", I would understand it, and it would
>> make sense to use (or not use) --first-parent consistently between this
>> codepath and "submodule --summary", though.
>
> You may be used to git.git's quality of naming the branches you merge.
>
> Sadly, this is not the common case.
IMHO both arguments are valid, using --first-parent really is a matter of
taste *and* it is dependent on the quality of branch naming whether it is
useful or not.
But when both commands shall produce the same output, i think we have to
use --first-parent as default, no? And maybe we could add another option
to diff which can change that behaviour according to users taste?
> 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.
Jens
^ permalink raw reply
* Re: [PATCH] Add the --submodule-summary option to the diff option family
From: Junio C Hamano @ 2009-10-06 11:36 UTC (permalink / raw)
To: Jens Lehmann; +Cc: Johannes Schindelin, git
In-Reply-To: <4ACB22E9.3010001@web.de>
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.
Thanks.
^ 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
* 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] 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/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: 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
* 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] 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
* 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: 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
* [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
* 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
* 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
* 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
* [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] 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] 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
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