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

Wed Sep 6 10:12:07 PDT 2017

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

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

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

>
> 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-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/20170907/921b8194/attachment-0001.html>