[Ohrrpgce] recommended workflow for merging a git feature branch before dcommit

Wed Sep 6 02:43:39 PDT 2017

Oh no! Something has gone wrong. Your wip branch (on github) is missing
every SVN commit from 9235 to 9252, inclusive. It has svn commits from 9253
and later. Strangely, your FEATURE_itembrowse branch has the svn commits
from 9235 to 9252 but not the later ones.
I guess this means some of my advice was wrong. So what did you do? Did you
dcommit from FEATURE_itembrowse, or rebase master onto it first and then
dcommit?

OK, I think that what happened is that you did "git fetch svn" to fetch
from my git-svn mirror, which was out of date at the time (the cron job
still isn't running; I should move it to a different machine), resulting in
commits disappearing from your svn/wip remote branch (you would have seen a
"(forced update)" message) which you had already fetched directly from svn.
And I guess git-svn got confused after that point, failing to re-fetch them
because it already had.
I actually saw a similar problem myself a week ago; I wasn't sure what had
gone wrong but fixed it up and forgot about it.

So, new guidance: don't use "git fetch svn" if you're using "git svn"
commands directly.

But first we have to fix your branches. I assume that your svn/wip remote
branch is equal to your wip one.
Just do "git fetch svn" to correct svn/wip (I've made sure it's currently
correct in the mirror).
Then do "git rebase svn/wip wip" to fix wip. If you don't have any extra
commits on 'wip', then this should make svn/wip and wip equal again. If you
have extra commits, they'll be preserved. git rebase should be intelligent
enough to see that svn/wip just has some extra commits over wip.
If that doesn't work, you can do "git checkout wip", "git reset --hard
svn/wip" to force wip to be equal to svn/wip, throwing away changes.

If it turns out that git-svn is screwed up (and I guess internally it has
got the wrong commit SHA1s in its table for the last commits, which may end
up being a problem) then you can fix the problem like so: "rm -rf
.git/svn", "git svn fetch  --log-window-size=10000". Takes 5 min, mostly
doing apparently nothing. I actually ended up doing this last week. (Make
sure you do this only after "git fetch svn" as above)

After this, do "git push -f <remote>" where <remote> is the name of your
github remote (origin?); I don't know what you've called it. You need to
add -f (--force) to overwrite the existing faulty wip branch you've pushed
to github.

Finally, although you probably deleted the FEATURE_itembrowse branch
locally, it isn't automatically deleted from github. To do so, do either
(equivalently) "git push -d <remote> FEATURE_itembrowse" or "git push
<remote> :FEATURE_itembrowse".
(The : syntax is a refspec, the format is "localside:remoteside". Leaving
out the local side means "push 'nothing' as the new value of
'FEATURE_itembrowse'", which means delete it.)

Phew.

On 6 September 2017 at 03:19, Ralph Versteegen <teeemcee at gmail.com> wrote:

> The only experience I have with mixing merges with git-svn is when you did
> so recently, which caused some of your commits to get squashed. Basically,
> it doesn't work and you shouldn't use them together, since git-svn doesn't
> create any merge commits in svn*. And git-svn works by creating some svn
> commits (in that case I guess it followed the wrong parent of the merge
> commit) and then throwing away your git commits and replacing them with
> commits copied back again from svn.
>
> *But svn does support merges... I don't know how git-svn handles those.
>
> Also, you don't need to do git svn fetch before rebase because rebase
> fetches anyway. But it seems git svn fetch fetches all svn branches, and
> git svn rebase fetches just the relevant branch before rebasing onto it.
>
> On 6 September 2017 at 02:36, James Paige <Bob at hamsterrepublic.com> wrote:
>
>> Okay, I think that makes sense!
>>
>> So I could use git rebase branchname wip to use rebase as an alternative
>> to merge, or I could do my git svn dcommit from the branch, which does the
>> same thing, and then I return to wip and do get svn fetch ; git svn rebase
>>
>> That seems to make sense to me, thank you.
>>
>> Out of curiosity, what breaks if I do a merge?
>>
>> ---
>> James
>>
>> On Tue, Sep 5, 2017 at 5:04 AM, Ralph Versteegen <teeemcee at gmail.com>
>> wrote:
>>
>>> Suppose you're on branch A and have some extra commits there. The
>>> natural option would be rebase master on top of A, delete A, and dcommit
>>> from master to svn:
>>> git rebase A master  # any commits to master will follow after those in A
>>> git branch -d A
>>> git svn dcommit  # pushing any commits on A or on master to svn
>>>
>>> But it's not necessary to be on the master branch when you use git svn
>>> dcommit; unlike git push and git pull, for which each of your branches may
>>> have a remote git branch which it tracks (meaning, which push and pull act
>>> on), git svn dcommit/rebase appears to just default to the 'wip' svn
>>> trunk/branch if you're on some git branch that doesn't have an svn branch
>>> of the same name (eg "web" or "dwimmercrafty" git branches).
>>> So "git svn dcommit" will 1) fetch any new svn wip commits you don't
>>> have yet, 2) rebase the current branch on top of svn/wip, 3) make commits
>>> to svn (and update svn/wip). Well, actually I think the real order is 3, 1,
>>> 2? Since IIRC svn lets you make commits without updating first, as long as
>>> none of the same files have been modified? Making an svn commit without
>>> even having the latest svn revision so that you can verify it compiles
>>> seems fairly harmless as long as you at least test it immediately
>>> afterwards. But it happens to me by accident all the time when you've made
>>> a commit I wasn't aware of, and I've not once had a problem result from it.
>>>
>>> So anyway, if you're on branch A, you can just do:
>>> git svn dcommit
>>> git checkout master
>>> git svn rebase  # If there were no extra commits to master, master and A
>>> should now be identical
>>> git branch -d A
>>>
>>>
>>>
>>> On 5 September 2017 at 11:06, James Paige <Bob at hamsterrepublic.com>
>>> wrote:
>>>
>>>> Hey, TMC, what workflow do you use when you want to merge a feature
>>>> branch before you "git svn dcommit" it?
>>>>
>>>> I remember being warned that ordinary merges are a source of problems.
>>>>
>>>> ---
>>>> James
>>>>
>>>> _______________________________________________
>>>> Ohrrpgce mailing list
>>>> ohrrpgce at lists.motherhamster.org
>>>> http://lists.motherhamster.org/listinfo.cgi/ohrrpgce-motherhamster.org
>>>>
>>>>
>>>
>>> _______________________________________________
>>> Ohrrpgce mailing list
>>> ohrrpgce at lists.motherhamster.org
>>> http://lists.motherhamster.org/listinfo.cgi/ohrrpgce-motherhamster.org
>>>
>>>
>>
>> _______________________________________________
>> Ohrrpgce mailing list
>> ohrrpgce at lists.motherhamster.org
>> http://lists.motherhamster.org/listinfo.cgi/ohrrpgce-motherhamster.org
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.motherhamster.org/pipermail/ohrrpgce-motherhamster.org/attachments/20170906/610ff8c4/attachment.html>