I just ran into a funny edge-case when doing a long rebase: one of
the rewritten commits got a sha1 starting with one of the abbreviated
sha1's of a commit still to be applied.
As a result, the rebase stopped with a funny-looking short SHA1 ... was
ambiguous, which would not have occured if the
On 27 June 2013 18:55, Yann Dirson dir...@bertin.fr wrote:
I just ran into a funny edge-case when doing a long rebase: one of
the rewritten commits got a sha1 starting with one of the abbreviated
sha1's of a commit still to be applied.
As a result, the rebase stopped with a funny-looking
David bouncingc...@gmail.com writes:
I'm not sure that rebase could predict the new hashes without actually
creating
the prior commits? So maybe the short SHA1 is too short?
It's OK to show the short sha1 to the user, but git rebase could and
should expand these to complete sha1 right after
On 27 June 2013 21:04, Matthieu Moy matthieu@grenoble-inp.fr wrote:
David bouncingc...@gmail.com writes:
I'm not sure that rebase could predict the new hashes without actually
creating
the prior commits? So maybe the short SHA1 is too short?
It's OK to show the short sha1 to the user,
Matthieu Moy matthieu@grenoble-inp.fr writes:
David bouncingc...@gmail.com writes:
I'm not sure that rebase could predict the new hashes without actually
creating
the prior commits? So maybe the short SHA1 is too short?
It's OK to show the short sha1 to the user, but git rebase could
Junio C Hamano gits...@pobox.com writes:
It could be something as simple like this (not tested).
git-rebase--interactive.sh | 19 +++
1 file changed, 19 insertions(+)
diff --git a/git-rebase--interactive.sh b/git-rebase--interactive.sh
index f953d8d..6766b44 100644
---
6 matches
Mail list logo
