On Tue, 16 Jun 2009 20:45:13 -0000, Florian Weimer <f...@deneb.enyo.de>
wrote:
* Jiří Paleček:
Package: git-core
Version: 1:1.6.3.1-1
Severity: important
Hello,
I had a history similar to this:
+--------+ +-------+ +-------+ +-------+ +-------+
+-------+
| master +------+ Xs... +---+ A +---+ Ys... +---+ B +---+
Zs... |
+--------+ +-------+ +-------+ +-------+ +-------+
+-------+
This arrived garbled over here.
Sorry, but I think you get what I meant. There were, on top of master,
commits Xs, then A, then Ys, then B, then Zs. The Xs etc. means there are
multiple commits (eg. X1, X2, ...)
+--------+ +-------+ +-------+ +-------+
| master +------+ Xs... +---+ A+B +---+ Zs... |
+--------+ +-------+ +-------+ +-------+
\--
\- +-------+
\+ Ys... |
+-------+
The Ys weren't on any branch.
They are still held by the reflog, I would assume.
No, they aren't since the rebase is only put in the reflog as a whole, in
one record. However, the original (non-rebased) Ys are, of course. I had
to dig the rebased commits from git-lost-found.
This output is
expected if you deleted all the lines in the "git rebase -i" control
script after the squash commit. Are you sure you haven't done this?
Yes, the rebase-todo looked like this:
pick Xs
pick A
squash B
pick Ys
pick Zs
Also, I wouldn't assume the rebase would create any new rebased commits
from Ys, had I deleted them from rebase-todo.
Regards
Jiri Palecek
--
Using Opera's revolutionary e-mail client: http://www.opera.com/mail/
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
