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

Wed Sep 6 08:02:35 PDT 2017

On Wed, Sep 6, 2017 at 2:43 AM, Ralph Versteegen <teeemcee at gmail.com> wrote:

> 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?
>
>
Oops! I should have done a better job of keeping track of what exactly I
did. I didn't realize anything was messed up.

I tried dcommit from my FEATURE_itembrowse branch, but got some conflicts.
I tried to cancel, and I thought I did so successfully, but I might have
gone wrong right there.

Then I switched to my wip branch, and tried to rebase it with git rebase
FEATURE_itembrowse wip

This also failed with the same conflicts, which were mostly about my
changes to the release/release-linux-*.sh scripts.

I bit the bullet and worked through resolving the conflicts and completing
the rebase.

There were two times when it seemed to be trying to apply and
already-applied change, and I used --skip which I thoguht was just skipping
redundant edits to release/release-linux-*.sh
but which might, in fact, have been skipping more than I meant to.

I do think I ran "git svn fetch" in there somewhere, but I admit I don't
remember exactly when.

I then looked at git log on my wip branch. I saw all my itembrowse, and I
saw a couple of your recent commits right before them, so I thought
everything was cool.

I think next I did git svn dcommit and it seemed to work.

Finally I pushed back to my github, and it warned me my branch divered, but
I --forced it (which I probably shouldn't have done?)

>
> 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),
>

I am pretty sure I ran "git svn fetch" but I don't think I ran "git fetch
svn"

> 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.
>
>
No problem. I don't think I was using git fetch svn anyway.

> 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).
>

Done! Seemed to work. https://pastebin.com/raw/5dknwkix

> 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.
>

Done. I did not have any extra commits on wip, it did look like it was
restoring some stuff. https://pastebin.com/raw/T96y5M4h

I checked git log, and confirmed that all the revisions between 9235 and
9255 are included.

> 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.
>

Not trying this, since there does not seem to be a need

> 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)
>
>
I don't think git-svn is to blame, I think my clumsy rebase work probably
caused this

> 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.
>
>
Done, and seemed to work fine! https://pastebin.com/raw/5WJDN8p5

> 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.)
>
>
I deleted it from github's gui but thank you for letting me know the
command-line way to do it :)

> Phew.
>

Thank you so much for helping me fix my mess :)

---
James

>
> 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
>>>
>>>
>>
>
> _______________________________________________
> 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/55ded312/attachment-0001.html>