[git-svn] [bug report] Index in strange state after git svn rebase

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hi Everybody,

Please Cc: me, I am not subscribed

I'm encountering an issue with "git svn rebase". Included in this
email is a summary of the issue, and it is fully detailed in this
stackoverflow question:
http://stackoverflow.com/questions/13183534/why-does-git-rebase-leave-opposite-sets-of-modifications-in-the-stage-and-the

I and several other people think it's a bug, but I could not find any
reference to it in the mailing list archive.

Some people have the same issue with the same svn repository, which is
quite large.

Unfortunately I have not been able to reproduce it completely from
scratch with a new svn repository. I seems to happen only on large
repository with a lot of history, branches, and files.

Here is the summary:

*What I wanted to do:*

In a branch tracking an svn remote, fetch team's content and rebase my
commit after them.


*What I did:*

Git version: "git version 1.7.10.msysgit.1"
With a clean working copy and empty index, I typed: "git svn rebase"


*What I expected:*

Fetch a couple of commits, then a successful rebase, with at the end
an empty index, and a clean working copy.


*What actually happened:*

Fetch a couple of commits, then a successful rebase, with at the end
an index containing modification that revert my commit, and a working
copy containing the expected content ("the revert of the revert")


Please feel free to contact me directly or via the SO question for any
useful additional information.

Thanks,
Samuel Rossille
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]