git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
* git-rebase eats empty commits
@ 2008-07-08 13:59 Michael J Gruber
  2008-07-12 22:12 ` Stephan Beyer
  0 siblings, 1 reply; 5+ messages in thread
From: Michael J Gruber @ 2008-07-08 13:59 UTC (permalink / raw)
  To: git

[-- Attachment #1: Type: text/plain, Size: 880 bytes --]

"git commit" allows empty commits with the "--allow-empty" option, i.e. 
commits which introduce no change at all. This is sometimes useful for 
keeping a log of untracked work related to tracked content.

"git rebase" removes empty commits, for the good reason that rebasing 
may make certain commits obsolete; but I don't want that in the case 
mentioned above. Is there any way to specify "--preserve-empty" or similar?

The attached script and log show the effect: a series A B C D of commits 
is rebased onto A'; the result is A' C', with the empty commits B and D 
disappearing.

grafts and filter-branch helped me solve a particular case of that 
effect, but I think it will show up again, so an option for rebase would 
be useful.

Michael

P.S.: I also noticed that 'Switched to a new branch "temp"' is written 
to stderr, everything else to stdout. Is that as intended?

[-- Attachment #2: empty.log --]
[-- Type: text/x-log, Size: 816 bytes --]

Initialized empty Git repository in /tmp/mjg/t/empty/.git/
Created initial commit b3104c1: 1
 1 files changed, 1 insertions(+), 0 deletions(-)
 create mode 100644 a
Created commit 7265e0c: empty 1
Created commit 9b67221: 2
 1 files changed, 1 insertions(+), 0 deletions(-)
 create mode 100644 b
Created commit 0778af2: empty 2
0778af2a5003df310cb9dc3c4fff1f8992619610 empty 2
9b67221a363103ebc78fc052c382637a87ef04e6 2
7265e0c1a35c95bd6fcf739a9f815b300ba9d9cc empty 1
b3104c148e1dd6ce8fd23cddb71734e45e7d9132 1
Switched to a new branch "temp"
Created commit d9ad4bc: rewritten 1
 1 files changed, 1 insertions(+), 0 deletions(-)
 create mode 100644 a
First, rewinding head to replay your work on top of it...
Applying 2
d81ec616edd3ed600a60dbd63d4d0f4a7263387f 2
d9ad4bcd2fb5e78f2f430733f2dc36453a653221 rewritten 1

[-- Attachment #3: empty.sh --]
[-- Type: application/x-shellscript, Size: 400 bytes --]

^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: git-rebase eats empty commits
  2008-07-08 13:59 git-rebase eats empty commits Michael J Gruber
@ 2008-07-12 22:12 ` Stephan Beyer
  2008-07-14 15:01   ` Michael J Gruber
  0 siblings, 1 reply; 5+ messages in thread
From: Stephan Beyer @ 2008-07-12 22:12 UTC (permalink / raw)
  To: Michael J Gruber; +Cc: git

Hi,

Michael J Gruber wrote:
> "git commit" allows empty commits with the "--allow-empty" option, i.e.  
> commits which introduce no change at all. This is sometimes useful for  
> keeping a log of untracked work related to tracked content.
>
> "git rebase" removes empty commits, for the good reason that rebasing  
> may make certain commits obsolete; but I don't want that in the case  
> mentioned above. Is there any way to specify "--preserve-empty" or 
> similar?

First I can speak for git-sequencer: there is no such thing as a
"preserve empty" option, but currently, when you are picking a commit
that has already been applied so that no changes occur, it will pause.
(It will not pause if it is a fast-forward.)
Yet, I was unsure if this is a "correct" behavior, but it seemed to be
useful, because you can inspect the situation.

In my mind, the same should happen with an empty commit, so I tested it:
 1. It pauses.
 2. In that pause I only need to run "git commit --allow-empty" and I have
    the picked empty patch with that commit message.

So if this behavior is kept, there is no such need for such an option.

Now I'm checking it with the old rebase-i (I'm always referring to
git-rebase--interactive as rebase-i) and exactly the same behavior
occurs.

But rebase is not rebase-i.
So I've also checked both, pure rebase and rebase-m: then the empty commit
is lost.

To sum up, use rebase -i and when it's pausing, do "git commit --allow-empty"
and then "git rebase --continue" and you have what you want.

Regards,
  Stephan

-- 
Stephan Beyer <s-beyer@gmx.net>, PGP 0x6EDDD207FCC5040F

^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: git-rebase eats empty commits
  2008-07-12 22:12 ` Stephan Beyer
@ 2008-07-14 15:01   ` Michael J Gruber
  2008-07-15 20:19     ` Stephan Beyer
  0 siblings, 1 reply; 5+ messages in thread
From: Michael J Gruber @ 2008-07-14 15:01 UTC (permalink / raw)
  To: git

Stephan Beyer venit, vidit, dixit 13.07.2008 00:12:
> Hi,
> 
> Michael J Gruber wrote:
>> "git commit" allows empty commits with the "--allow-empty" option, i.e.  
>> commits which introduce no change at all. This is sometimes useful for  
>> keeping a log of untracked work related to tracked content.
>>
>> "git rebase" removes empty commits, for the good reason that rebasing  
>> may make certain commits obsolete; but I don't want that in the case  
>> mentioned above. Is there any way to specify "--preserve-empty" or 
>> similar?
> 
> First I can speak for git-sequencer: there is no such thing as a
> "preserve empty" option, but currently, when you are picking a commit
> that has already been applied so that no changes occur, it will pause.
> (It will not pause if it is a fast-forward.)
> Yet, I was unsure if this is a "correct" behavior, but it seemed to be
> useful, because you can inspect the situation.
> 
> In my mind, the same should happen with an empty commit, so I tested it:
>  1. It pauses.
>  2. In that pause I only need to run "git commit --allow-empty" and I have
>     the picked empty patch with that commit message.
> 
> So if this behavior is kept, there is no such need for such an option.
> 
> Now I'm checking it with the old rebase-i (I'm always referring to
> git-rebase--interactive as rebase-i) and exactly the same behavior
> occurs.
> 
> But rebase is not rebase-i.
> So I've also checked both, pure rebase and rebase-m: then the empty commit
> is lost.
> 
> To sum up, use rebase -i and when it's pausing, do "git commit --allow-empty"
> and then "git rebase --continue" and you have what you want.

I assume this is with git from master? With git 1.5.6.2 rebase -i 
doesn't stop there, not even when I change "pick" to "edit"!

So, I guess for now I'll use my hacked git-rebase ("-m", I didn't hack 
git-format-patch), maybe 1.6.0 will behave as described above. Anyway 
thanks for the hint about distinguishing between rebase and rebase -i.

Michael

^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: git-rebase eats empty commits
  2008-07-14 15:01   ` Michael J Gruber
@ 2008-07-15 20:19     ` Stephan Beyer
  2008-07-16  9:24       ` Michael J Gruber
  0 siblings, 1 reply; 5+ messages in thread
From: Stephan Beyer @ 2008-07-15 20:19 UTC (permalink / raw)
  To: Michael J Gruber; +Cc: git

Hi,

Michael J Gruber wrote:
> Stephan Beyer venit, vidit, dixit 13.07.2008 00:12:
>> To sum up, use rebase -i and when it's pausing, do "git commit --allow-empty"
>> and then "git rebase --continue" and you have what you want.
>
> I assume this is with git from master? With git 1.5.6.2 rebase -i  
> doesn't stop there, not even when I change "pick" to "edit"!

Hmm, in fact this is with my git from Debian, from master and my
sequencer-based one:

	$ /usr/bin/git --version
	git version 1.5.6
	$ ./git --version
	git version 1.5.6.3.350.g6c11a
	$ git --version
	git version 1.5.6.3.506.g902dd

And, btw, the reason of this behavior is no special case in rebase-i,
it's just that git-cherry-pick fails (exit status != 0), if you pick an
empty commit (and then rebase-i will pause because of conflict). And
*this* is because builtin-revert.c runs git-commit without --allow-empty.
This has never changed, so I cannot believe that the behavior changed in
any version of git. Or I am missing a point.

	$ git cherry-pick empty		# empty is an empty commit tagged as "empty"
	Already uptodate!
	Finished one cherry-pick.
	# Not currently on any branch.
	# Untracked files:
	[...]
	nothing added to commit but untracked files present (use "git add" to track)
	$ echo $?
	1
	$ EDITOR=touch git commit --allow-empty
	Created commit 145f1d0: empty

The same happens when doing rebase -i instead of cherry-pick.

Regards,
  Stephan

-- 
Stephan Beyer <s-beyer@gmx.net>, PGP 0x6EDDD207FCC5040F

^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: git-rebase eats empty commits
  2008-07-15 20:19     ` Stephan Beyer
@ 2008-07-16  9:24       ` Michael J Gruber
  0 siblings, 0 replies; 5+ messages in thread
From: Michael J Gruber @ 2008-07-16  9:24 UTC (permalink / raw)
  To: git

[-- Attachment #1: Type: text/plain, Size: 1503 bytes --]

Stephan Beyer venit, vidit, dixit 15.07.2008 22:19:
> Hi,
...
> any version of git. Or I am missing a point.
> 
> 	$ git cherry-pick empty		# empty is an empty commit tagged as "empty"
> 	Already uptodate!
> 	Finished one cherry-pick.
> 	# Not currently on any branch.
> 	# Untracked files:
> 	[...]
> 	nothing added to commit but untracked files present (use "git add" to track)

How would an empty commit produce untracked files? You seem to be 
testing something different.

I reattach the test case from my original post, as well as the log of 
runs with git 1.5.6.3: once with rebase and once with rebase -i.

Uuuh, doh: I interpreted

Finished one cherry-pick.
# Not currently on any branch.
nothing to commit (working directory clean)
Could not apply e1f497c... empty 1
8d0c67a675bc65d375e8a9d019500bb2a16fb1e9 rewritten 1

as the end of the (interactive) rebase operation! Nothing indicated it 
was interrupted: no message and no git status output. It all looked like 
a failed rebase.

Now, thanks to your persistence, I tried going ahead with commit --amend 
and rebase --continue, and all went fine (stopped again for empty 2, 
giving no clue; amend & cont).

So, you're right: cherry-pick stops at empty commits, so that rebase -i 
is the way to go. rebase (non-i) uses format-patch resp. merge (-m), 
which eat empty commits.

I recall some discussion about informative rb-i messages, may upcoming 
git would have saved me and will save others from this misinterpretation.

Thanks!
Michael

[-- Attachment #2: empty.sh --]
[-- Type: application/x-shellscript, Size: 400 bytes --]

[-- Attachment #3: empty.log --]
[-- Type: text/x-log, Size: 816 bytes --]

Initialized empty Git repository in /tmp/mjg/t/empty/.git/
Created initial commit 6b9e2af: 1
 1 files changed, 1 insertions(+), 0 deletions(-)
 create mode 100644 a
Created commit 8387962: empty 1
Created commit 6c4c3fe: 2
 1 files changed, 1 insertions(+), 0 deletions(-)
 create mode 100644 b
Created commit 3521900: empty 2
3521900fb7b032aa9e1f5a50a82f71785aa5c208 empty 2
6c4c3fe8b7619e1107256d0b47d0f419c05ceb69 2
8387962b740bb47662dd866eb57b4fe5ad21b355 empty 1
6b9e2afad8bed27378f0c9d23e77631be8447d37 1
Switched to a new branch "temp"
Created commit 1cced89: rewritten 1
 1 files changed, 1 insertions(+), 0 deletions(-)
 create mode 100644 a
First, rewinding head to replay your work on top of it...
Applying 2
a4116113335fc6be47fb9f8481547ea0923ac09d 2
1cced892a90024f4230a9f7aec1989ffe0b6c16f rewritten 1

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #4: empty-i.log --]
[-- Type: text/x-log; name="empty-i.log", Size: 873 bytes --]

Initialized empty Git repository in /tmp/mjg/t/empty/.git/
Created initial commit 2796c9d: 1
 1 files changed, 1 insertions(+), 0 deletions(-)
 create mode 100644 a
Created commit e1f497c: empty 1
Created commit b3867ae: 2
 1 files changed, 1 insertions(+), 0 deletions(-)
 create mode 100644 b
Created commit 2edad43: empty 2
2edad436286f39e407b83bbb448b3aa62b91aeb9 empty 2
b3867ae2a345ab30bfd68a1c7e0e19999a1eb9eb 2
e1f497c4ee7a040162faa7dcc2b6d8e41d5fd920 empty 1
2796c9d9f8fced86134e5b36462916c938c6f819 1
Switched to a new branch "temp"
Created commit 8d0c67a: rewritten 1
 1 files changed, 1 insertions(+), 0 deletions(-)
 create mode 100644 a
Rebasing (1/3)\rAlready uptodate!
Finished one cherry-pick.
# Not currently on any branch.
nothing to commit (working directory clean)
Could not apply e1f497c... empty 1
8d0c67a675bc65d375e8a9d019500bb2a16fb1e9 rewritten 1

^ permalink raw reply	[flat|nested] 5+ messages in thread

end of thread, other threads:[~2008-07-16  9:25 UTC | newest]

Thread overview: 5+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2008-07-08 13:59 git-rebase eats empty commits Michael J Gruber
2008-07-12 22:12 ` Stephan Beyer
2008-07-14 15:01   ` Michael J Gruber
2008-07-15 20:19     ` Stephan Beyer
2008-07-16  9:24       ` Michael J Gruber

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).