On zaterdag 21 mei 2011, John Ralls wrote: > On May 21, 2011, at 10:14 AM, Geert Janssens wrote: > > On zaterdag 21 mei 2011, John Ralls wrote: > >> On May 21, 2011, at 8:29 AM, Geert Janssens wrote: > >>> On zaterdag 21 mei 2011, John Ralls wrote: > >>>> Take a look at `git log --full-history A'..B > >>>> src/gnome-utils/assistant-utils.c` (filling in the actual commit short > >>>> hashes for A' and B, of course). It should show what git thinks are > >>>> the differences. > >>> > >>> $ git log --full-history c46431964..gtk2.18 > >>> src/gnome-utils/assistant-utils.c commit > >>> b0d4b0c75fcb7f91ad60e68a1939c844e8333602 > >>> Author: Geert Janssens <[email protected]> > >>> Date: Fri May 20 16:31:42 2011 +0000 > >>> > >>> Replace obsolete gnome include with gtk include > >>> > >>> git-svn-id: svn+ssh://svn.gnucash.org/repo/gnucash/trunk@20665 > >>> > >>> 57a11ea4-9604-0410-9ed3-97b8803252fd > >>> > >>> This commit is commit A in my diagram above and is pushed to svn as > >>> revision 20665. > >> > >> OK. A bit of googling takes me to [1], which is part of what taught me > >> how to set this up. > >> > >> There, I'm reminded that the problem is likely that your git reference > >> to SVN is outdated because of the round-trip from your repo to svn to > >> github (via my server). Running git-update should patch up the > >> references so that your dcommit will work. > > > > I wish that were so: > > > > $ git-update > > warning: refname 'trunk' is ambiguous. > > Current branch trunk is up to date. > > > > $ git checkout gtk2.18 > > Switched to branch 'gtk2.18' > > > > $ git svn dcommit > > Committing to svn+ssh://[email protected]/repo/gnucash/trunk ... > > > > M src/gnome-utils/assistant-utils.c > > > > Transaction is out of date: File > > '/gnucash/trunk/src/gnome-utils/assistant- utils.c' is out of date at > > /usr/libexec/git-core/git-svn line 576 > > > > I'm afraid I don't understand this well enough to know what to do next. I > > read the link you referred to, but other than what you proposed there > > seems nothing in there that could help. > > Ah, that's not what you said you were doing. > There is no gtk2.18 branch in the svn repo, so you can't dcommit that > branch until you create one. That doesn't seem correct. I have done that without any problems for all my previous dcommits, which have been from a gtk2.18 branch, a bugfix branch,... All these branches are rebased on trunk before dcommitting, but I'm definitly running the dcommit from the working branches, not trunk.
> I think that git svn branch -m "Feature > Branch for updating Gnucash UI to gtk2.18" should do it, but you'll need > to pay attention to the git svn output make sure that it does the right > thing; you may need to dcommit the changes after creating the branch, and > you may need to fiddle with the config of your local branch so that it > tracks the new svn branch. > > This will not, of course, add your changes to trunk, and it will mean that > you will have to work in this feature branch until you're finished with > it: With Subversion, you get only one merge from a feature branch back to > trunk. > > This is probably not what you want to do. Indeed, I don't want to create additional branches in svn. > What you want to do is what you > said that you'd done in your original message: Rebase your gtk2.18 branch > onto trunk and dcommit trunk and dcommit trunk to subversion. > git checkout trunk > git rebase gtk2.18 > git svn dcommit What I have done so far which has always worked until now: Work on a git local branch (like gtk2.18), these branches are all branched off of trunk. When I'm ready to push to svn: git checkout trunk git-update git rebase trunk gtk2.18 git svn dcommit Until this last attempt this has always worked. I never needed my working branch to exist in svn, the revisions got always pushed to svn trunk. But now you seem to suggest that is backwards, and I should rebase trunk on gtk2.18 instead of the other way around ? Anyway, I tried these steps, but the error is still the same, so there must be something else not right in my local repo. > (wait until after the next update; if you hurry, you can get in before the > next one which starts at 1900Z) git-update > git checkout gtk2.18 > git merge trunk > > And you're ready to go back to work. Just for the record, my follow-up steps always were git-update git rebase trunk gtk2.18 So far I have always avoided merging, because I thought that might lead to trouble with the svn interactions. Geert _______________________________________________ gnucash-devel mailing list [email protected] https://lists.gnucash.org/mailman/listinfo/gnucash-devel
