* 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
* Re: [PATCH] checkout: implement "-" shortcut name for last branch
From: Thomas Rast @ 2009-01-15 14:01 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git, Junio C Hamano
In-Reply-To: <alpine.DEB.1.00.0901150141570.3586@pacific.mpi-cbg.de>
[-- Attachment #1: Type: text/plain, Size: 697 bytes --]
Johannes Schindelin wrote:
> On Thu, 15 Jan 2009, Thomas Rast wrote:
>
> > 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.
>
> Actually, what you want is in the reflog, no? So... parsing
> .git/logs/HEAD for the latest occurrence of "checkout: moving from " and
> then using everything up until the next space should give you the branch
> name, right?
It just feels wrong to grab that information from there; it's a
free-form comment field for user consumption. And it wasn't even that
hard to implement a LAST_HEAD.
--
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: [RFC PATCH] Make the rebase edit mode really end up in an edit state
From: Johannes Schindelin @ 2009-01-15 14:02 UTC (permalink / raw)
To: Stephan Beyer
Cc: Sverre Rabbelier, Adeodato Simó, Johan Herland, git,
Johannes Sixt, Anders Melchiorsen, gitster
In-Reply-To: <20090115135716.GC10045@leksak.fem-net>
Hi,
On Thu, 15 Jan 2009, Stephan Beyer wrote:
> 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").
... which obviously shares all the shortcomings of "edit".
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH v2] checkout: implement "-" shortcut name for last branch
From: Johannes Schindelin @ 2009-01-15 14:09 UTC (permalink / raw)
To: Thomas Rast; +Cc: Johannes Sixt, git, Junio C Hamano
In-Reply-To: <200901151500.01876.trast@student.ethz.ch>
Hi,
On Thu, 15 Jan 2009, Thomas Rast wrote:
> 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.
Maybe something like this would help (completely untested, though the
idea should be clear)?
-- snipsnap --
[PATCH] pack-objects --all: include HEAD, which could be detached
Signed-off-by: Johannes Schindelin <Johannes.Schindelin@gmx.de>
---
builtin-pack-objects.c | 4 ++++
1 files changed, 4 insertions(+), 0 deletions(-)
diff --git a/builtin-pack-objects.c b/builtin-pack-objects.c
index cb51916..da55671 100644
--- a/builtin-pack-objects.c
+++ b/builtin-pack-objects.c
@@ -2219,6 +2219,10 @@ int cmd_pack_objects(int argc, const char **argv, const char *prefix)
rp_ac_alloc * sizeof(*rp_av));
}
rp_av[rp_ac++] = arg;
+ if (!strcmp("--all", arg)) {
+ ALLOC_GROW(rp_av, rp_ac + 1, rp_ac_alloc);
+ rp_av[rp_ac++] = "HEAD";
+ }
continue;
}
if (!strcmp("--thin", arg)) {
^ permalink raw reply related
* Re: [PATCH] checkout: implement "-" shortcut name for last branch
From: Johannes Schindelin @ 2009-01-15 14:14 UTC (permalink / raw)
To: Thomas Rast; +Cc: git, Junio C Hamano
In-Reply-To: <200901151501.26394.trast@student.ethz.ch>
Hi,
On Thu, 15 Jan 2009, Thomas Rast wrote:
> Johannes Schindelin wrote:
> > On Thu, 15 Jan 2009, Thomas Rast wrote:
> >
> > > 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.
> >
> > Actually, what you want is in the reflog, no? So... parsing
> > .git/logs/HEAD for the latest occurrence of "checkout: moving from " and
> > then using everything up until the next space should give you the branch
> > name, right?
>
> It just feels wrong to grab that information from there; it's a
> free-form comment field for user consumption. And it wasn't even that
> hard to implement a LAST_HEAD.
There are a number of issues why I would like to avoid introducing
LAST_HEAD:
- it does not work when you are using different Git versions on the same
repository,
- it does not work when you switched recently,
- you are storing redundant information,
- yes, the field is meant for user consumption, but no, it is not
free-form,
- AFAICT your version could never be convinced to resurrect deleted
branches, without resorting to reflogs anyway.
- the reflog method reflects pretty much exactly how people work around
the lack of "checkout -" currently, so why not just use the same proven
approach?
Ciao,
Dscho
^ permalink raw reply
* Re: rebase -p confusion in 1.6.1
From: Michael J Gruber @ 2009-01-15 14:14 UTC (permalink / raw)
To: Stephan Beyer; +Cc: Sitaram Chamarty, git, Stephen Haberman
In-Reply-To: <20090115135518.GB10045@leksak.fem-net>
Stephan Beyer venit, vidit, dixit 15.01.2009 14:55:
> 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.)
Yep, I think -p should preserve only merges in side branches (and
therefore produce what you suggest, and what you get without -p). If it
preserves all merges then there is nothing to rewrite here.
BTW: How does the sequencer based rebase do in this case, and what's the
general status? If it's about to be integrated we can do without the
present script...
Michael
^ permalink raw reply
* Re: [PATCH v2] checkout: implement "-" shortcut name for last branch
From: Johannes Schindelin @ 2009-01-15 14:17 UTC (permalink / raw)
To: Thomas Rast; +Cc: Johannes Sixt, git, Junio C Hamano
In-Reply-To: <alpine.DEB.1.00.0901151508540.3586@pacific.mpi-cbg.de>
Hi,
On Thu, 15 Jan 2009, Johannes Schindelin wrote:
> [PATCH] pack-objects --all: include HEAD, which could be detached
In hind sight, it would probably be better to add this to revision.c.
Ciao,
Dscho
^ permalink raw reply
* Re: rebase -p confusion in 1.6.1
From: Johannes Schindelin @ 2009-01-15 14:25 UTC (permalink / raw)
To: Michael J Gruber; +Cc: Stephan Beyer, Sitaram Chamarty, git, Stephen Haberman
In-Reply-To: <496F44AC.2060607@drmicha.warpmail.net>
Hi,
On Thu, 15 Jan 2009, Michael J Gruber wrote:
> Stephan Beyer venit, vidit, dixit 15.01.2009 14:55:
>
> >> 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.)
>
> Yep, I think -p should preserve only merges in side branches
you mean everything in master..work?
> (and therefore produce what you suggest, and what you get without -p).
> If it preserves all merges then there is nothing to rewrite here.
The merge _is_ outside of master, so I do not understand what the heck you
are talking about.
The more I think about it, I think it's possible I broke it with the
introduction of the "noop".
However, there could be a _different_ test case where the current -p
handling shows the same error. Dunno.
Ciao,
Dscho
^ permalink raw reply
* Re: [Q] git rebase -i -p conflicts with squash
From: Constantine Plotnikov @ 2009-01-15 14:25 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git
In-Reply-To: <alpine.DEB.1.00.0901150137070.3586@pacific.mpi-cbg.de>
Here is a reproduction recipe:
Goto to some empty directory and do the following commands on (cygwin,
git 1.6.0.4):
git init
echo data1 > f.txt
git add f.txt
git commit -m second
echo data2 >> f.txt
git add f.txt
git commit -m second
echo data3 >> f.txt
git add f.txt
git commit -m third
echo '#!/usr/bin/sh' >myed.sh
echo "echo -e '2\ns/pick/s/\np\nw\nq' | ed \$1" >>myed.sh
chmod a+x myed.sh
export GIT_EDITOR=`pwd`/myed.sh
git rebase -p -i master~2
The git rebase will exit with error writing something like the
following on stderr:
Refusing to squash a merge: 3b9e0d80da20e3543225679906be1cc5cf1a9f44
Constantine
On Thu, Jan 15, 2009 at 3:38 AM, Johannes Schindelin
<Johannes.Schindelin@gmx.de> wrote:
> Hi,
>
> On Wed, 14 Jan 2009, Constantine Plotnikov wrote:
>
>> If I run git rebase --interactive with --preserve-merges option and
>> select "squash" for one of the commit, the rebase process fails with the
>> message "Refusing to squash a merge:
>> 5e775c536654640c173ba71a0af7e84bf8bc618a". However the neither commit
>> participating in the squash is a merge commit. Even more, there are no
>> merge commits in the repository at all.
>>
>> From my limited understanding of squash operation, it should fail only
>> if one of squashed commits is a merge commit, but it should be possible
>> to squash non-merge commits without problem as it looks like quite safe
>> and local operation (and I might want to preserve merges that happened
>> after squashed commits). Is it the current behaviour a bug or a feature?
>
> From your description, it seems that you are hitting an ordering bug of
> rebase -i -p.
>
> But without a reproduction recipe (preferably as a patch against our
> testsuite), I cannot tell.
>
> Ciao,
> Dscho
>
>
^ permalink raw reply
* Re: rebase -p confusion in 1.6.1
From: Stephan Beyer @ 2009-01-15 14:40 UTC (permalink / raw)
To: Michael J Gruber; +Cc: Sitaram Chamarty, git, Stephen Haberman
In-Reply-To: <496F44AC.2060607@drmicha.warpmail.net>
Michael J Gruber wrote:
> BTW: How does the sequencer based rebase do in this case,
This was the first thing I checked :-)
I had to rework the rebase -i -p code for sequencer a bit, but this
case was not something I had thought about (although it may not be
too seldom), so I'm glad it comes up now.
The result is that it eats the commits a3 and a4. (But at least it does
the same with and without --onto master.) :-)
I think it's not too hard to fix.
> and what's the general status?
I'm currently highly motivated to get it done soon and I hope that it
gets into pu or next before the end of January.
Depending on how productive I am over the weekend and depending on how
many further bugs (often hidden in such special cases) I find, it
could be sent to the list next week.
> If it's about to be integrated we can do without the
> present script...
I think it will take some time and some discussions on the list until
it will be integrated. I remember, for example, Dscho, who has, since
it had first come up, always been opposed to the mark-reset /
mark-reset-merge scheme (in rebase -i -p, at least).
Other users said "Wow, this is much more flexible." ...
and this is perhaps only one thing that can lead to some bigger
discussion.
Regards,
Stephan
--
Stephan Beyer <s-beyer@gmx.net>, PGP 0x6EDDD207FCC5040F
^ permalink raw reply
* Re: cygwin git diff crash
From: Jeremy Ramer @ 2009-01-15 14:42 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Git Mailing List
In-Reply-To: <alpine.DEB.1.00.0901142333200.3586@pacific.mpi-cbg.de>
On Wed, Jan 14, 2009 at 3:33 PM, Johannes Schindelin
<Johannes.Schindelin@gmx.de> wrote:
> Hi,
>
> On Wed, 14 Jan 2009, Jeremy Ramer wrote:
>
>> Ok this is a weird issue and it's probably cygwin's fault, but I
>> haven't found any way to fix it so I' thought I would throw it out
>> here for comment.
>>
>> I am using git 1.6.0.4 on cygwin. I have a repo where if any file has
>> changes and git detects as mode 100644 I get this error:
>> $git diff
>> 3 [main] git 2744 C:\cygwin\bin\git.exe: *** fatal error - could
>> not load user32, Win32 error
>>
>> If I change the mode to 100755 git diff will work fine.
>> $chmod a+x test.cpp
>> $git diff
>> diff --git a/test.cpp b/test.cpp
>> old mode 100644
>> new mode 100755
>> index 7c0dfcd..20987a7
>> --- a/test.cpp
>> +++ b/test.cpp
>> @@ -6,9 +6,11 @@ int main()
>>
>> void func()
>> {
>> + int a;^M
>> }
>>
>> void func2()
>> {
>> + int b;^M
>> }
>>
>> Anybody have a clue as to why this might occur? I have seen this in
>> many of the repo's I use, but it is not repeatable. I tried making a
>> test repo but could not reproduce.
>
> Wow, that _is_ weird. Does your test suite pass?
>
> Ciao,
> Dscho
>
Forgive my ignorance, but I am not sure how to run the test suite. I
did a quick google search but didn't find anything. I am using
cygwin's packaged version of git and am not building it from source,
so maybe the suite is not available. If I get a chance I will try
building from source.
Jeremy
^ permalink raw reply
* Re: rebase -p confusion in 1.6.1
From: Michael J Gruber @ 2009-01-15 14:45 UTC (permalink / raw)
To: Johannes Schindelin
Cc: Stephan Beyer, Sitaram Chamarty, git, Stephen Haberman
In-Reply-To: <alpine.DEB.1.00.0901151518520.3586@pacific.mpi-cbg.de>
Johannes Schindelin venit, vidit, dixit 15.01.2009 15:25:
> Hi,
>
> On Thu, 15 Jan 2009, Michael J Gruber wrote:
>
>> Stephan Beyer venit, vidit, dixit 15.01.2009 14:55:
>>
>>>> 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.)
>> Yep, I think -p should preserve only merges in side branches
>
> you mean everything in master..work?
>
>> (and therefore produce what you suggest, and what you get without -p).
>> If it preserves all merges then there is nothing to rewrite here.
>
> The merge _is_ outside of master, so I do not understand what the heck you
> are talking about.
Easy Dscho, easy ;)
[meaning "take it such..."]
I'm not sure what -p is supposed to do:
A) Should it preserve all merge commits which it would need to rewrite?
That is lot to ask. Previous behaviour (intended or not) seemed to be to
do nothing in this case where the merge connects master and work.
B) Should it preserve only merges in side branches? I seem to mean by
that branches where the parents are on work and other branches but not
on master.
So at least on my side there is confusion about the intention behind
'-p' (say design goal), and therefore about the expectation.
> The more I think about it, I think it's possible I broke it with the
> introduction of the "noop".
>
> However, there could be a _different_ test case where the current -p
> handling shows the same error. Dunno.
It certainly worked after the noop introduction before the r-i-p series,
but not any more after. "worked" meaning it at least didn't leave out
commits in this case (but reproduced the existing DAG). I'm getting the
impression you suggest R.I.P. for r-i-p series ;) Fine with me...
Cheers,
Michael
^ 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