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

Wed Sep 6 10:32:20 PDT 2017

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

>
>
> On 7 September 2017 at 03:02, James Paige <Bob at hamsterrepublic.com> wrote:
>
>>
>>
>> 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.
>>
>
> Hmm, the fact that you got conflicts may imply that git-svn was already
> confused. But I'm already lost as to what was going on at that point. It
> appears nothing got committed to svn, since all the timestamps were the
> same, so it all happened when you dcommitted later.
>
> I guess I'd have to do some experiments to find out what is or isn't
> allowed. For now, I better advise you to make sure the branch you're trying
> to dcommit is a descendent of svn/wip (e.g. by rebasing on top of it).
> Although I haven't bothered with that in the past...
>

And to make sure that it is a descendant of svn wip, do I just need to
create the branch from wip when my wip is up-to-date with svn? Or do I have
to explicitly branch from the remote svn/wip rather than branching from my
local wip?

> Unfortunately it's easy to mess things up with git; I do so frequently :)
> I recommend using a visual git viewer, like gitk. gitk is very nice, you
> just have to create a new "view" which shows al branches at once (tick "All
> refs"). gitk is great for visualising the mess you've made :)
>

That sounds cool! I will try it out :)

>
>
>> Then I switched to my wip branch, and tried to rebase it with git rebase
>> FEATURE_itembrowse wip
>>
>
> You weren't rebasing git-svn commits on TOP of commits not in svn, were
> you? That would definitely be bad.
>

I don't think I was.

...unless maybe part of my first attempt at rebasing succeeded, and then my
second attempt at rebasing was on top of those?

>
>> 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?)
>>
>
> That "diverged" warning is very common when using git-svn correctly. If
> you make some git commits, and push them to github before you commit to
> svn, then the next time you try to push to github you'll have to --force
> it, because the commit metadata is modified when dcommiting, so they're
> different commits.
>
>
>>
>>>
>>> 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
>>
>
> Looks like git rebase had to work hard to finally figure out that the
> rebase was equivalent to git reset --hard... maybe I should just have told
> you to do git reset --hard instead.
>
>>
>> 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-motherh
>>>>>>> amster.org
>>>>>>>
>>>>>>>
>>>>>>
>>>>>> _______________________________________________
>>>>>> Ohrrpgce mailing list
>>>>>> ohrrpgce at lists.motherhamster.org
>>>>>> http://lists.motherhamster.org/listinfo.cgi/ohrrpgce-motherh
>>>>>> amster.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
>>
>>
>
> _______________________________________________
> 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/16c097a2/attachment-0001.html>