Ah, I missed that dcommit entails a rebase. I thought it just
complained if one needed to take place, so I always do a rebase
"manually" before dcommit. I agree, and would not want my other refs
moved around if the change is that drastic.
The workaround is not so bad anyway: git reset on the left-behind
refs. Thanks for the replies!
On Tue, Apr 29, 2014 at 6:04 PM, Piotr Krukowiecki
> On Mon, Apr 28, 2014 at 9:26 PM, Aaron Laws <dartm...@gmail.com> wrote:
>> The way I understand it, when `git svn dcommit` is run, new commits
>> are created (A' is created from A adding SVN information), then the
>> current branch is moved to point to A'. Why don't we move any other
>> refs that were pointing to A over to A' ? What would be the point of
>> continuing to point to A? I'm interested in looking into coding this
>> change to git-svn, but I would like to hear some feedback first.
> I think A' might not always be simply (A + SVN info). I think you can
> dcommit when you're not up to date. So A' will have a different
> parent than A (will be automatically rebased on top of current branch
> tip). Other refs pointing to A might be used as bookmarks, and moving
> them from A to A' would be a significant change.
> Piotr Krukowiecki
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html