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! In Christ, Aaron Laws On Tue, Apr 29, 2014 at 6:04 PM, Piotr Krukowiecki <piotr.krukowie...@gmail.com> wrote: > 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. > > Hi, > > 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
