* Re: [RFC PATCH] Make the rebase edit mode really end up in an edit state
From: Sverre Rabbelier @ 2009-01-15 12:55 UTC (permalink / raw)
To: Pieter de Bie
Cc: Johannes Schindelin, Johan Herland, git, Johannes Sixt,
Anders Melchiorsen, gitster
In-Reply-To: <19A8FAC6-A27A-4D6B-A276-02EE17F0E5F5@frim.nl>
On Thu, Jan 15, 2009 at 13:52, Pieter de Bie <pieter@frim.nl> wrote:
> I think this demonstrates that you can do a lot more with 'edit' than just
> edit.
> 'redact' etc also don't cover it. Perhaps just a general 'pause' or
> something?
>
> You can then put something like 'pause -- pause, for example to amend
> commit'
> in the description part.
That makes sense, perhaps we could name the feature described by the
OP something like "reset", as that is what it actually does?
--
Cheers,
Sverre Rabbelier
^ permalink raw reply
* [PATCH 2/2] t3404: Add test case for auto-amending only edited commits after "edit"
From: Stephan Beyer @ 2009-01-15 12:56 UTC (permalink / raw)
To: git; +Cc: Johannes Schindelin, Dmitry Potapov, gitster, Stephan Beyer
In-Reply-To: <1232024176-16600-1-git-send-email-s-beyer@gmx.net>
Add a test case for the bugfix introduced by commit c14c3c82d
"git-rebase--interactive: auto amend only edited commit".
Signed-off-by: Stephan Beyer <s-beyer@gmx.net>
---
t/t3404-rebase-interactive.sh | 17 +++++++++++++++++
1 files changed, 17 insertions(+), 0 deletions(-)
diff --git a/t/t3404-rebase-interactive.sh b/t/t3404-rebase-interactive.sh
index 1182b46..2cc8e7a 100755
--- a/t/t3404-rebase-interactive.sh
+++ b/t/t3404-rebase-interactive.sh
@@ -388,6 +388,23 @@ test_expect_success 'aborted --continue does not squash commits after "edit"' '
git rebase --abort
'
+test_expect_success 'auto-amend only edited commits after "edit"' '
+ test_tick &&
+ FAKE_LINES="edit 1" git rebase -i HEAD^ &&
+ echo "edited again" > file7 &&
+ git add file7 &&
+ FAKE_COMMIT_MESSAGE="edited file7 again" git commit &&
+ echo "and again" > file7 &&
+ git add file7 &&
+ test_tick &&
+ (
+ FAKE_COMMIT_MESSAGE="and again" &&
+ export FAKE_COMMIT_MESSAGE &&
+ test_must_fail git rebase --continue
+ ) &&
+ git rebase --abort
+'
+
test_expect_success 'rebase a detached HEAD' '
grandparent=$(git rev-parse HEAD~2) &&
git checkout $(git rev-parse HEAD) &&
--
1.6.1.160.gecdb
^ permalink raw reply related
* [PATCH 1/2] t3404: Add test case for aborted --continue after "edit"
From: Stephan Beyer @ 2009-01-15 12:56 UTC (permalink / raw)
To: git; +Cc: Johannes Schindelin, Dmitry Potapov, gitster, Stephan Beyer
Add a test case for the bugfix introduced by commit 8beb1f33d
"git-rebase-interactive: do not squash commits on abort".
Signed-off-by: Stephan Beyer <s-beyer@gmx.net>
---
t/t3404-rebase-interactive.sh | 15 +++++++++++++++
1 files changed, 15 insertions(+), 0 deletions(-)
diff --git a/t/t3404-rebase-interactive.sh b/t/t3404-rebase-interactive.sh
index 7d10a27..1182b46 100755
--- a/t/t3404-rebase-interactive.sh
+++ b/t/t3404-rebase-interactive.sh
@@ -373,6 +373,21 @@ test_expect_success '--continue tries to commit, even for "edit"' '
test $parent = $(git rev-parse HEAD^)
'
+test_expect_success 'aborted --continue does not squash commits after "edit"' '
+ old=$(git rev-parse HEAD) &&
+ test_tick &&
+ FAKE_LINES="edit 1" git rebase -i HEAD^ &&
+ echo "edited again" > file7 &&
+ git add file7 &&
+ (
+ FAKE_COMMIT_MESSAGE=" " &&
+ export FAKE_COMMIT_MESSAGE &&
+ test_must_fail git rebase --continue
+ ) &&
+ test $old = $(git rev-parse HEAD) &&
+ git rebase --abort
+'
+
test_expect_success 'rebase a detached HEAD' '
grandparent=$(git rev-parse HEAD~2) &&
git checkout $(git rev-parse HEAD) &&
--
1.6.1.160.gecdb
^ permalink raw reply related
* [PATCH] t3501: check that commits are actually done
From: Stephan Beyer @ 2009-01-15 13:03 UTC (permalink / raw)
To: git; +Cc: gitster, Stephan Beyer
The basic idea of t3501 is to check whether revert
and cherry-pick works on renamed files.
But as there is no pure cherry-pick/revert test, it is
good to also check if commits are actually done in that
scenario.
Signed-off-by: Stephan Beyer <s-beyer@gmx.net>
---
This patch was originally motivated because of a bug that
I introduced in my repo while hacking on cherry-pick/revert.
None of the cherry-pick test cases failed, so I thought
this tiny addition is useful.
t/t3501-revert-cherry-pick.sh | 2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/t/t3501-revert-cherry-pick.sh b/t/t3501-revert-cherry-pick.sh
index 6da2128..bb4cf00 100755
--- a/t/t3501-revert-cherry-pick.sh
+++ b/t/t3501-revert-cherry-pick.sh
@@ -45,6 +45,7 @@ test_expect_success 'cherry-pick after renaming branch' '
git checkout rename2 &&
git cherry-pick added &&
+ test $(git rev-parse HEAD^) = $(git rev-parse rename2) &&
test -f opos &&
grep "Add extra line at the end" opos
@@ -54,6 +55,7 @@ test_expect_success 'revert after renaming branch' '
git checkout rename1 &&
git revert added &&
+ test $(git rev-parse HEAD^) = $(git rev-parse rename1) &&
test -f spoo &&
! grep "Add extra line at the end" spoo
--
1.6.1.160.gecdb
^ permalink raw reply related
* Re: [PATCH take 3 0/4] color-words improvements
From: Teemu Likonen @ 2009-01-15 13:03 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Thomas Rast, Junio C Hamano, git, Santi Béjar
In-Reply-To: <alpine.DEB.1.00.0901151337080.3586@pacific.mpi-cbg.de>
Johannes Schindelin (2009-01-15 13:41 +0100) wrote:
> Exactly because it works logically, I do not want to change it. This is
> what the user said, and for a change, it could be what the user meant.
I'm just saying that it would be helpful (to me at least) if the man
page included this advice. Thomas Rast already suggested this in his
version of the man page change:
You may want to append `|\S` to your regular expression to make sure
that it matches all non-whitespace characters.
^ permalink raw reply
* Re: [ANNOUNCE] tig-0.13
From: Jonas Fonseca @ 2009-01-15 13:06 UTC (permalink / raw)
To: git
In-Reply-To: <20090115014617.GC6937@b2j>
bill lam <cbill.lam@gmail.com> wrote Thu, Jan 15, 2009:
> On Thu, 15 Jan 2009, Jonas Fonseca wrote:
> > Yes, it works. You can either create a file called config.make with a
> > line saying:
> >
> > LDLIBS = -lncursesw
> >
> > or use the configure file. If you are not using the tarball generate it
> > with:
> >
> > make configure
>
> I use the git source. Even after make configure and ./configure, it
> still links to the non-unicode ncurses.
I haven't tested the configure script on a lot of system, so it might be
a bit debian/ubuntu/gentoo centered in that use of ncursesw requires the
presence of a {/usr/incude/}ncursesw/ncurses.h header. Where are the
unicode ncurses.h files found on your system?
> Should it make ncursesw as
> default if detected available albeit this can be changed manually?
I would prefer that the "default" (running make without configure) has
as few dependencies as possible. Since the unicode version of ncurses is
probably more rare than the non-unicode version it is probably a bad
idea to use ncursesw by default. However, if you use the configure
script ncursesw is the default, when it is available.
--
Jonas Fonseca
^ permalink raw reply
* Re: [PATCH v2] checkout: implement "-" shortcut name for last branch
From: Johannes Schindelin @ 2009-01-15 13:15 UTC (permalink / raw)
To: Johannes Sixt; +Cc: Thomas Rast, git, Junio C Hamano
In-Reply-To: <496EE559.3060901@viscovery.net>
Hi,
On Thu, 15 Jan 2009, Johannes Sixt wrote:
> Thomas Rast schrieb:
> > Let git-checkout save the old branch as a symref in LAST_HEAD, and
> > make 'git checkout -' switch back to LAST_HEAD, like 'cd -' does in
> > the shell.
>
> /me likes this feature.
>
> git rebase (-i or not) calls checkout behind the scenes if the
> two-argument form is used:
>
> git rebase [-i] master topic
>
> and 'topic' is not the current branch. You may want to add a test that
> ensures that rebase sets LAST_HEAD in this case.
>
> You must make sure that commits referenced by LAST_HEAD are not
> garbage-collected. (I don't know if this happens anyway for symrefs in .git.)
Note: if you used reflogs for that feature, the garbage collection could
not have killed the commit. However, it is quite possible that the
branch was deleted.
Ciao,
Dscho
^ permalink raw reply
* Re: [RFC PATCH] Make the rebase edit mode really end up in an edit state
From: Pieter de Bie @ 2009-01-15 12:57 UTC (permalink / raw)
To: Johannes Schindelin
Cc: Sverre Rabbelier, Johan Herland, git, Johannes Sixt,
Anders Melchiorsen, gitster
In-Reply-To: <alpine.DEB.1.00.0901151325310.3586@pacific.mpi-cbg.de>
On Jan 15, 2009, at 12:36 PM, Johannes Schindelin wrote:
> BTW I was not fully happy with 'edit' back then, either, which is the
> reason why I showed the usage in the comment _above_ the commit
> list. But
> nobody could suggest a name that I found convincingly better.
(BTW, I reply to this thread because I'm also often confused with the
rebase. The thing that hits me most is that with resolving conflicts,
you have to do a 'git commit' and with 'edit', you have to do a 'git
commit --amend'. This can get confusing if you set up an interactive
rebase where you have some new picks or squashes, and also an edit.
If the rebase stops, you first have to carefully read whether you're
supposed to do a 'git commit' or a 'git commit --amend', and remember
that until you're finished with the changes).
- Pieter
^ permalink raw reply
* Re: [RFC PATCH] Make the rebase edit mode really end up in an edit state
From: Pieter de Bie @ 2009-01-15 12:52 UTC (permalink / raw)
To: Johannes Schindelin
Cc: Sverre Rabbelier, Johan Herland, git, Johannes Sixt,
Anders Melchiorsen, gitster
In-Reply-To: <alpine.DEB.1.00.0901151325310.3586@pacific.mpi-cbg.de>
On Jan 15, 2009, at 12:36 PM, Johannes Schindelin wrote:
> If at all, I'd introduce 'examine' as a synonym to 'edit' (might be
> more
> intuitive).
>
> However, for the same reason (is it intuitive?) I am not fully
> convinced
> of 'amend' either. Because --amend _can_ mean that you change the
> diff of the commit. Maybe 'correct', 'redact' or 'rephrase'?
I think this demonstrates that you can do a lot more with 'edit' than
just edit.
'redact' etc also don't cover it. Perhaps just a general 'pause' or
something?
You can then put something like 'pause -- pause, for example to
amend commit'
in the description part.
^ permalink raw reply
* autoconf: C99 format check
From: Julius Naperkowski @ 2009-01-15 13:22 UTC (permalink / raw)
To: git
I am trying to cross-compile git for mips on a x86 host. But it seems that it is
impossible to pass the C99 Format check in the configure script when
cross_compile mode is activated because the script quits even before it starts
the testprogramm. Is this behavior intentional?
configure: CHECKS for programs
checking for mips-linux-cc... ccache mips-linux-uclibc-gcc
checking for C compiler default output file name... a.out
checking whether the C compiler works... yes
checking whether we are cross compiling... yes
checking for suffix of executables...
checking for suffix of object files... o
checking whether we are using the GNU C compiler... yes
checking whether ccache mips-linux-uclibc-gcc accepts -g... yes
checking for ccache mips-linux-uclibc-gcc option to accept ISO C89... none needed
checking if linker supports -R... no
checking if linker supports -Wl,-rpath,... yes
checking for mips-linux-gar... mips-linux-uclibc-ar
checking for gtar... /bin/tar
checking for asciidoc... no
configure: CHECKS for libraries
checking for SHA1_Init in -lcrypto... no
checking for SHA1_Init in -lssl... no
checking for curl_global_init in -lcurl... no
checking for XML_ParserCreate in -lexpat... no
checking for iconv in -lc... no
checking for iconv in -liconv... no
checking for deflateBound in -lz... no
checking for socket in -lc... yes
configure: CHECKS for header files
checking how to run the C preprocessor... ccache mips-linux-uclibc-gcc -E
checking for grep that handles long lines and -e... /bin/grep
checking for egrep... /bin/grep -E
checking for ANSI C header files... yes
checking for sys/types.h... yes
checking for sys/stat.h... yes
checking for stdlib.h... yes
checking for string.h... yes
checking for memory.h... yes
checking for strings.h... yes
checking for inttypes.h... yes
checking for stdint.h... yes
checking for unistd.h... yes
checking sys/select.h usability... yes
checking sys/select.h presence... yes
checking for sys/select.h... yes
checking for old iconv()... yes
configure: CHECKS for typedefs, structures, and compiler characteristics
checking for struct dirent.d_ino... yes
checking for struct dirent.d_type... yes
checking for struct sockaddr_storage... yes
checking for struct addrinfo... yes
checking for getaddrinfo... (cached) yes
checking for library containing getaddrinfo... none required
checking whether formatted IO functions support C99 size specifiers...
configure: error: cannot run test program while cross compiling
See `config.log' for more details.
A snippet of the configure script:
...
4928: # Define NO_C99_FORMAT if your formatted IO functions (printf/scanf et.al.)
4929: # do not support the 'size specifiers' introduced by C99, namely ll, hh,
4930: # j, z, t. (representing long long int, char, intmax_t, size_t, ptrdiff_t).
4931: # some C compilers supported these specifiers prior to C99 as an extension.
4932: { echo "$as_me:$LINENO: checking whether formatted IO functions support
C99 size specifiers" >&5
4933: echo $ECHO_N "checking whether formatted IO functions support C99 size
specifiers... $ECHO_C" >&6; }
4934: if test "${ac_cv_c_c99_format+set}" = set; then
4935: echo $ECHO_N "(cached) $ECHO_C" >&6
4936: else
4937: # Actually git uses only %z (%zu) in alloc.c, and %t (%td) in mktag.c
4938: if test "$cross_compiling" = yes; then
4939: { { echo "$as_me:$LINENO: error: cannot run test program while cross
compiling
4940: See \`config.log' for more details." >&5
4941: echo "$as_me: error: cannot run test program while cross compiling
4942: See \`config.log' for more details." >&2;}
4943: { (exit 1); exit 1; }; }
4944: else
4945: cat >conftest.$ac_ext <<_ACEOF
4946: /* confdefs.h. */
4947: _ACEOF
4948: cat confdefs.h >>conftest.$ac_ext
4949: cat >>conftest.$ac_ext <<_ACEOF
...
--
Julius
^ permalink raw reply
* Re: [PATCH take 3 0/4] color-words improvements
From: Thomas Rast @ 2009-01-15 13:27 UTC (permalink / raw)
To: Teemu Likonen; +Cc: Johannes Schindelin, Junio C Hamano, git, Santi Béjar
In-Reply-To: <871vv4soul.fsf@iki.fi>
[-- Attachment #1: Type: text/plain, Size: 795 bytes --]
Teemu Likonen wrote:
> Johannes Schindelin (2009-01-15 13:41 +0100) wrote:
>
> > Exactly because it works logically, I do not want to change it. This is
> > what the user said, and for a change, it could be what the user meant.
>
> I'm just saying that it would be helpful (to me at least) if the man
> page included this advice. Thomas Rast already suggested this in his
> version of the man page change:
>
> You may want to append `|\S` to your regular expression to make sure
> that it matches all non-whitespace characters.
Dscho requested that I put the extended docs in one of my patches, so
it's currently in
http://article.gmane.org/gmane.comp.version-control.git/105716
Comments welcome of course.
--
Thomas Rast
trast@{inf,student}.ethz.ch
[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* Re: rebase -p confusion in 1.6.1
From: Johannes Schindelin @ 2009-01-15 13:34 UTC (permalink / raw)
To: Sitaram Chamarty; +Cc: git
In-Reply-To: <slrngmu4j5.e1u.sitaramc@sitaramc.homelinux.net>
Hi,
On Thu, 15 Jan 2009, Sitaram Chamarty wrote:
> While trying to understand "rebase -p", I came across some
> very unexpected behaviour that made me throw in the towel
> and ask for help!
>
> [... some script with some aliases ...]
I turned this into a proper test case (to show what would be most helpful
if you report bugs like this in the future).
If nobody beats me to it, I'll work on it tonight.
-- snipsnap --
t/t3409-rebase-preserve-merges.sh | 28 ++++++++++++++++++++++++++++
1 files changed, 28 insertions(+), 0 deletions(-)
diff --git a/t/t3409-rebase-preserve-merges.sh b/t/t3409-rebase-preserve-merges.sh
index e6c8327..5e2128c 100755
--- a/t/t3409-rebase-preserve-merges.sh
+++ b/t/t3409-rebase-preserve-merges.sh
@@ -92,4 +92,32 @@ test_expect_success '--continue works after a conflict' '
)
'
+test_commit () {
+ : > "$1" &&
+ git add "$1" &&
+ test_tick &&
+ git commit -m "$1" "$1"
+}
+
+test_expect_success 'test case from Sitaram' '
+
+ git checkout master &&
+ test_commit a1 &&
+ git checkout -b work &&
+ test_commit b1 &&
+ git checkout master &&
+ test_commit a3 &&
+ git checkout work &&
+ git merge master &&
+ test_commit b3 &&
+ echo before: &&
+ git log --graph --pretty=oneline --decorate --abbrev-commit &&
+ test -f b3 &&
+ git rebase -p master &&
+ echo after: &&
+ git log --graph --pretty=oneline --decorate --abbrev-commit &&
+ test -f b3
+
+'
+
test_done
^ permalink raw reply related
* Re: rebase -p confusion in 1.6.1
From: Stephan Beyer @ 2009-01-15 13:38 UTC (permalink / raw)
To: Sitaram Chamarty; +Cc: git
In-Reply-To: <slrngmu4j5.e1u.sitaramc@sitaramc.homelinux.net>
Hi Sitaram,
Sitaram Chamarty wrote:
> The outputs I got really confused me. Before the "rebase
> -p", the tree looked like
>
> * 78ffda9... (refs/heads/work) b4
> * be1e3a4... b3
> * cd8d893... Merge branch 'master' into work
> |\
> | * 0153c27... (refs/heads/master) a4
> | * 74f4387... a3
> * | f1b0c1c... b2
> * | 2e202d0... b1
> |/
> * b37ae36... a2
> * ed1e1bc... a1
>
> But afterward, this is what it looks like -- all the "b"
> commits are gone!
>
> * 0153c27... (refs/heads/work, refs/heads/master) a4
> * 74f4387... a3
> * b37ae36... a2
> * ed1e1bc... a1
>
> What did I do wrong/misunderstand?
Hmm, you are rebasing onto master which is merged into the branch you
want to rebase. So, I think the correct output should be the same like
git rebase without -p, ie
* 1337bee... (refs/heads/work) b4
* deadbee... b3
* badbeef... b2
* fa1afe1... b1
* 0153c27... (refs/heads/master) a4
* 74f4387... a3
* b37ae36... a2
* ed1e1bc... a1
This is because master is already merged into work and a preserved
merge will see that everything is already merged in.
Well, so I think you've discovered a bug.
> (2) git config alias.lg log --graph --pretty=oneline --abbrev-commit --decorate
Funny, I have exactly the same alias, but named "logk".
> git init
> testci a1 a2
> git checkout -b work
> testci b1 b2
> git checkout master
> testci a3 a4
> git checkout work
> git merge master
> testci b3 b4
> git --no-pager lg # graph before rebase -p
> git rebase -p master
> git --no-pager lg # graph after rebase -p
Thanks and regards,
Stephan
--
Stephan Beyer <s-beyer@gmx.net>, PGP 0x6EDDD207FCC5040F
^ permalink raw reply
* Re: rebase -p confusion in 1.6.1
From: Michael J Gruber @ 2009-01-15 13:39 UTC (permalink / raw)
To: Sitaram Chamarty; +Cc: git, Stephen Haberman
In-Reply-To: <slrngmu4j5.e1u.sitaramc@sitaramc.homelinux.net>
Sitaram Chamarty venit, vidit, dixit 15.01.2009 11:39:
> Hello all,
>
> While trying to understand "rebase -p", I came across some
> very unexpected behaviour that made me throw in the towel
> and ask for help!
>
> The outputs I got really confused me. Before the "rebase
> -p", the tree looked like
>
> * 78ffda9... (refs/heads/work) b4
> * be1e3a4... b3
> * cd8d893... Merge branch 'master' into work
> |\
> | * 0153c27... (refs/heads/master) a4
> | * 74f4387... a3
> * | f1b0c1c... b2
> * | 2e202d0... b1
> |/
> * b37ae36... a2
> * ed1e1bc... a1
>
> But afterward, this is what it looks like -- all the "b"
> commits are gone!
>
> * 0153c27... (refs/heads/work, refs/heads/master) a4
> * 74f4387... a3
> * b37ae36... a2
> * ed1e1bc... a1
>
> What did I do wrong/misunderstand?
>
> Here's how to recreate. Note that "testci" is a shell
> function and "lg" is a git alias. They are, respectively,
> (1) testci() { for i; do echo $i > $i; git add $i; git commit -m $i; done; }
> (2) git config alias.lg log --graph --pretty=oneline --abbrev-commit --decorate
>
> git init
> testci a1 a2
> git checkout -b work
> testci b1 b2
> git checkout master
> testci a3 a4
> git checkout work
> git merge master
> testci b3 b4
> git --no-pager lg # graph before rebase -p
> git rebase -p master
> git --no-pager lg # graph after rebase -p
>
First of all: git 1.6.0.6 gives you the unchanged graph after using
rebase -i -p (git 1.6.1 adds -i behind you back and sets up a dummy
editor). In any case, git rebase should not simply eat those commits -
either leave them alone or rewrite them. git bisect says
d80d6bc146232d81f1bb4bc58e5d89263fd228d4 is first bad commit
commit d80d6bc146232d81f1bb4bc58e5d89263fd228d4
Author: Stephen Haberman <stephen@exigencecorp.com>
Date: Wed Oct 15 02:44:39 2008 -0500
rebase-i-p: do not include non-first-parent commits touching UPSTREAM
so I'll cc the bad guy ;)
Second, what result do you expect? If the merge is to be preserved then
b1, b2 can't be simply ripped out - or else you get the linear structure
which rebase without '-p' delivers. The merge base (as returned by git
merge-base) between work and master is a4, i.e. master, so that the
expected result with '-p' is the one from 1.6.0.6 (unchanged graph).
Cheers,
Michael
^ permalink raw reply
* Re: [RFC PATCH] Make the rebase edit mode really end up in an edit state
From: Johannes Schindelin @ 2009-01-15 13:41 UTC (permalink / raw)
To: Adeodato Simó
Cc: Sverre Rabbelier, Johan Herland, git, Johannes Sixt,
Anders Melchiorsen, gitster
In-Reply-To: <20090115124433.GA4484@chistera.yi.org>
[-- Attachment #1: Type: TEXT/PLAIN, Size: 159 bytes --]
Hi,
On Thu, 15 Jan 2009, Adeodato Simó wrote:
> editmsg?
Has the same first letter as 'edit'. Would be confusing with the shortcut
'e', no?
Ciao,
Dscho
^ permalink raw reply
* Re: [RFC PATCH] Make the rebase edit mode really end up in an edit state
From: Sverre Rabbelier @ 2009-01-15 13:41 UTC (permalink / raw)
To: Johannes Schindelin
Cc: Adeodato Simó, Johan Herland, git, Johannes Sixt,
Anders Melchiorsen, gitster
In-Reply-To: <alpine.DEB.1.00.0901151440380.3586@pacific.mpi-cbg.de>
On Thu, Jan 15, 2009 at 14:41, Johannes Schindelin
<Johannes.Schindelin@gmx.de> wrote:
> On Thu, 15 Jan 2009, Adeodato Simó wrote:
>> editmsg?
>
> Has the same first letter as 'edit'. Would be confusing with the shortcut
> 'e', no?
"msgedit" with shortcut 'm'?
--
Cheers,
Sverre Rabbelier
^ permalink raw reply
* Re: [RFC PATCH] Make the rebase edit mode really end up in an edit state
From: Johannes Schindelin @ 2009-01-15 13:42 UTC (permalink / raw)
To: Sverre Rabbelier
Cc: Johan Herland, git, Johannes Sixt, Anders Melchiorsen, gitster
In-Reply-To: <bd6139dc0901150445l51f3b861n5bbd85bb6d1382b6@mail.gmail.com>
Hi,
On Thu, 15 Jan 2009, Sverre Rabbelier wrote:
> On Thu, Jan 15, 2009 at 13:36, Johannes Schindelin
> <Johannes.Schindelin@gmx.de> wrote:
> > If at all, I'd introduce 'examine' as a synonym to 'edit' (might be more
> > intuitive).
>
> Examine suggests that you cannot change the commit (you can look, but
> don't touch it!), no?
So if you want to look but don't touch it, you can do exactly that.
Brilliant, isn't it?
Ciao,
Dscho
^ permalink raw reply
* Re: [RFC PATCH] Make the rebase edit mode really end up in an edit state
From: Adeodato Simó @ 2009-01-15 13:43 UTC (permalink / raw)
To: Johannes Schindelin
Cc: Sverre Rabbelier, Johan Herland, git, Johannes Sixt,
Anders Melchiorsen, gitster
In-Reply-To: <alpine.DEB.1.00.0901151440380.3586@pacific.mpi-cbg.de>
* Johannes Schindelin [Thu, 15 Jan 2009 14:41:14 +0100]:
> Hi,
> On Thu, 15 Jan 2009, Adeodato Simó wrote:
> > editmsg?
> Has the same first letter as 'edit'. Would be confusing with the shortcut
> 'e', no?
Yes, you are right. I always write the full word myself, so I forgot
abbreviations are supported and commonly used.
--
Adeodato Simó dato at net.com.org.es
Debian Developer adeodato at debian.org
A lie can go round the world before the truth has got its boots on.
-- Terry Pratchett
^ permalink raw reply
* Re: [RFC PATCH] Make the rebase edit mode really end up in an edit state
From: Björn Steinbrink @ 2009-01-15 13:46 UTC (permalink / raw)
To: Pieter de Bie
Cc: Johannes Schindelin, Sverre Rabbelier, Johan Herland, git,
Johannes Sixt, Anders Melchiorsen, gitster
In-Reply-To: <8B5B7148-B900-4E01-9B2C-16C251966F7F@frim.nl>
On 2009.01.15 12:57:04 +0000, Pieter de Bie wrote:
>
> On Jan 15, 2009, at 12:36 PM, Johannes Schindelin wrote:
>
>> BTW I was not fully happy with 'edit' back then, either, which is the
>> reason why I showed the usage in the comment _above_ the commit list.
>> But
>> nobody could suggest a name that I found convincingly better.
>
> (BTW, I reply to this thread because I'm also often confused with the
> rebase. The thing that hits me most is that with resolving conflicts,
> you have to do a 'git commit' and with 'edit', you have to do a 'git
> commit --amend'. This can get confusing if you set up an interactive
> rebase where you have some new picks or squashes, and also an edit.
> If the rebase stops, you first have to carefully read whether you're
> supposed to do a 'git commit' or a 'git commit --amend', and remember
> that until you're finished with the changes).
You can handle both cases with:
git add -u # Or whatever
git rebase --continue
Only when you split a commit, you have to explicitly reset and commit.
Björn
^ permalink raw reply
* Re: [RFC PATCH] Make the rebase edit mode really end up in an edit state
From: Johan Herland @ 2009-01-15 13:54 UTC (permalink / raw)
To: git
Cc: Sverre Rabbelier, Johannes Sixt, Johannes Schindelin,
Anders Melchiorsen, gitster
In-Reply-To: <bd6139dc0901150352t2d2fa388x3eb842bbc8c4baa6@mail.gmail.com>
On Thursday 15 January 2009, Sverre Rabbelier wrote:
> On Thu, Jan 15, 2009 at 11:01, Johan Herland wrote:
> > "modify" does the "git reset --soft HEAD^" (Anders' suggestion)
> > "amend" requires a "git commit --amend" (current behaviour)
>
> Why have amend do the same as edit?
The names I chose are somewhat arbitrary, since we obviously have to
keep on bikeshedding until we have something everybody can agree to.
However, my rationale was that IMO the word "edit" more closely matches
Anders' suggestion, and is therefore somewhat misleading as a
description of the current behaviour. But we obviously cannot change
the meaning of "edit" without upsetting current users. Therefore,
introduce "amend" to more accurately describe the current behaviour. As
for "modify", it was simply the best synonym for "edit" I could find.
...Johan
--
Johan Herland, <johan@herland.net>
www.herland.net
^ permalink raw reply
* Re: rebase -p confusion in 1.6.1
From: Stephan Beyer @ 2009-01-15 13:55 UTC (permalink / raw)
To: Michael J Gruber; +Cc: Sitaram Chamarty, git, Stephen Haberman
In-Reply-To: <496F3C99.1040800@drmicha.warpmail.net>
Hi,
> First of all: git 1.6.0.6 gives you the unchanged graph after using
> rebase -i -p.
This is true and it is a far better behavior than now, but I think it's
not the expected behavior. (I have written about the behavior I'd expect
in another reply to the original mail.)
Also
git rebase -i -p master
should do the same as
git rebase -i -p --onto master master
or am I wrong?
But the latter does
$ git rebase --onto master -i -p master
fatal: Needed a single revision
Invalid base
instead of resulting in an unchanged graph.
(Tested with 1.5.6.5, the only other version I have installed besides
my master branch)
Regards,
Stephan
--
Stephan Beyer <s-beyer@gmx.net>, PGP 0x6EDDD207FCC5040F
^ permalink raw reply
* Re: [RFC PATCH] Make the rebase edit mode really end up in an edit state
From: Sverre Rabbelier @ 2009-01-15 13:56 UTC (permalink / raw)
To: Johannes Schindelin
Cc: Johan Herland, git, Johannes Sixt, Anders Melchiorsen, gitster
In-Reply-To: <alpine.DEB.1.00.0901151442230.3586@pacific.mpi-cbg.de>
On Thu, Jan 15, 2009 at 14:42, Johannes Schindelin
<Johannes.Schindelin@gmx.de> wrote:
> So if you want to look but don't touch it, you can do exactly that.
> Brilliant, isn't it?
Yes, ofcourse, but the current edit does allow you to modify (with
'git commit --amend')...
I agree with Johan Herland though, Bikeshedding ftw :).
--
Cheers,
Sverre Rabbelier
^ permalink raw reply
* Re: [RFC PATCH] Make the rebase edit mode really end up in an edit state
From: Stephan Beyer @ 2009-01-15 13:57 UTC (permalink / raw)
To: Sverre Rabbelier
Cc: Johannes Schindelin, Adeodato Simó, Johan Herland, git,
Johannes Sixt, Anders Melchiorsen, gitster
In-Reply-To: <bd6139dc0901150541o491ee9b8n1b5f3540a924b89e@mail.gmail.com>
Hi,
Sverre Rabbelier wrote:
> >> editmsg?
> >
> > Has the same first letter as 'edit'. Would be confusing with the shortcut
> > 'e', no?
>
> "msgedit" with shortcut 'm'?
*sigh* If I was just not so late with sequencer...
There it is "pick -e" (or "pick --edit").
Regards,
Stephan
--
Stephan Beyer <s-beyer@gmx.net>, PGP 0x6EDDD207FCC5040F
^ permalink raw reply
* Re: rebase -p confusion in 1.6.1
From: Johannes Schindelin @ 2009-01-15 13:58 UTC (permalink / raw)
To: Stephan Beyer; +Cc: Sitaram Chamarty, git
In-Reply-To: <20090115133808.GA10045@leksak.fem-net>
Hi,
On Thu, 15 Jan 2009, Stephan Beyer wrote:
> Hmm, you are rebasing onto master which is merged into the branch you
> want to rebase. So, I think the correct output should be the same like
> git rebase without -p, ie
>
> * 1337bee... (refs/heads/work) b4
> * deadbee... b3
> * badbeef... b2
> * fa1afe1... b1
> * 0153c27... (refs/heads/master) a4
> * 74f4387... a3
> * b37ae36... a2
> * ed1e1bc... a1
>
> This is because master is already merged into work and a preserved
> merge will see that everything is already merged in.
I guess the problem is that the list shown in the editor says 'noop'.
This does not happen without -p, so something is borked in the commit
listing with -p.
Which is no wonder: the code after line 652 in git-rebase--interactive.sh
that handles -p is utterly incomprehensible.
Remember: there is code that is so simple that it has no obvious flaws,
and there is code that is so complicated that it has no obvious flaws.
IMO (and I said so much back then), it was the biggest mistake of the
whole patch series that it was so intrusive and changed everything. It's
not like I did not warn anybody.
The point is: you could _easily_ handle -p with _almost the same_
rev-list command; you'd just have to make sure that --no-merges is
skipped.
And then you only have to make sure that the current commit is the
(possibly rewritten version of the) first parent of the next commit to
pick.
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH v2] checkout: implement "-" shortcut name for last branch
From: Thomas Rast @ 2009-01-15 13:59 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Johannes Sixt, git, Junio C Hamano
In-Reply-To: <alpine.DEB.1.00.0901151413250.3586@pacific.mpi-cbg.de>
[-- Attachment #1: Type: text/plain, Size: 1476 bytes --]
Johannes Schindelin wrote:
> On Thu, 15 Jan 2009, Johannes Sixt wrote:
> > You must make sure that commits referenced by LAST_HEAD are not
> > garbage-collected. (I don't know if this happens anyway for symrefs in .git.)
>
> Note: if you used reflogs for that feature, the garbage collection could
> not have killed the commit. However, it is quite possible that the
> branch was deleted.
Suddenly I'm not so sure about either behaviour any more.
Consider:
$ git commit -m initial
[master (root-commit)]: created 812c476: "initial"
1 files changed, 1 insertions(+), 0 deletions(-)
create mode 100644 foo
$ git checkout $(git rev-parse HEAD)
Note: moving to "812c476ca23e25efa7e4d7081153ba657a127d95" 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>
HEAD is now at 812c476... initial
$ git branch -D master
Deleted branch master (812c476).
$ git for-each-ref
$ git reflog expire --expire=now --all
$ git prune --expire now
$ git show
fatal: bad object HEAD
$ git show 812c476
fatal: ambiguous argument '812c476': unknown revision or path not in the working tree.
Use '--' to separate paths from revisions
Oops.
Some quick RTFS shows that it indeed "only" cares about refs and
reflogs.
--
Thomas Rast
trast@{inf,student}.ethz.ch
[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 197 bytes --]
^ 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