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

Wed Sep 6 10:55:42 PDT 2017

On 7 September 2017 at 05:32, James Paige <Bob at hamsterrepublic.com> wrote:

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

No, you can use branches however you want. But before using git svn
dcommit, to be safe (contrary to what I said originally), check whichever
branch you're committing from has svn/wip as an ancestor, e.g. by rebasing
it on top of svn/wip. Lots of other ways to do that. E.g. if your wip
branch is equal to svn/wip, you could do "git rebase feature_x wip" (wip is
now checked out), "git branch -d feature_x", "git svn dcommit"

>
>
>
>> 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-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/9b74dec0/attachment-0001.html>