<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On 7 September 2017 at 05:32, James Paige <span dir="ltr"><<a href="mailto:Bob@hamsterrepublic.com" target="_blank">Bob@hamsterrepublic.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote"><span class="gmail-">On Wed, Sep 6, 2017 at 10:12 AM, Ralph Versteegen <span dir="ltr"><<a href="mailto:teeemcee@gmail.com" target="_blank">teeemcee@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote"><span>On 7 September 2017 at 03:02, James Paige <span dir="ltr"><<a href="mailto:Bob@hamsterrepublic.com" target="_blank">Bob@hamsterrepublic.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote"><span>On Wed, Sep 6, 2017 at 2:43 AM, Ralph Versteegen <span dir="ltr"><<a href="mailto:teeemcee@gmail.com" target="_blank">teeemcee@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div>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.</div><div>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?<br></div><div><br></div></div></blockquote><div><br></div></span>Oops! I should have done a better job of keeping track of what exactly I did. I didn't realize anything was messed up.<br></div><div class="gmail_quote"><br></div><div class="gmail_quote">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.</div></div></div></blockquote><div><br></div></span><div>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.</div><div><br></div>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...</div></div></div></blockquote><div><br></div></span><div>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?</div></div></div></div></blockquote><div><br></div><div><div></div>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" <br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><span class="gmail-"><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"></div><div class="gmail_quote">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 :)<br></div></div></div></blockquote><div><br></div><div><br></div></span><div>That sounds cool! I will try it out :)<br></div><span class="gmail-"><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"></div><div class="gmail_quote"><span><br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><br></div><div class="gmail_quote">Then I switched to my wip branch, and tried to rebase it with git rebase FEATURE_itembrowse wip</div></div></div></blockquote><div><br></div></span><div>You weren't rebasing git-svn commits on TOP of commits not in svn, were you? That would definitely be bad. <br></div></div></div></div></blockquote><div><br></div></span><div>I don't think I was.</div><div><br></div><div>...unless maybe part of my first attempt at rebasing succeeded, and then my second attempt at rebasing was on top of those?<br></div><div><div class="gmail-h5"><div><br></div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div></div><span><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><br></div><div class="gmail_quote">This also failed with the same conflicts, which were mostly about my changes to the release/release-linux-*.sh scripts.<br></div><div class="gmail_quote"><br></div><div class="gmail_quote">I bit the bullet and worked through resolving the conflicts and completing the rebase.</div><div class="gmail_quote"><br></div><div class="gmail_quote">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<span class="gmail-m_-8275688692413493624m_-3140905650611477295gmail-m_-2437542841923092686m_-8035808387007537190gmail-"> <br></span>but which might, in fact, have been skipping more than I meant to.<br></div><div class="gmail_quote"><br></div><div class="gmail_quote">I do think I ran "git svn fetch" in there somewhere, but I admit I don't remember exactly when.</div><div class="gmail_quote"><br></div><div class="gmail_quote">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.</div><div class="gmail_quote"><br></div><div class="gmail_quote">I think next I did git svn dcommit and it seemed to work.</div><div class="gmail_quote"><br></div><div class="gmail_quote">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?)<br></div></div></div></blockquote><div><br></div></span><div>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.<br></div><span><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><span> <blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div>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), </div></div></blockquote><div><br></div></span><div>I am pretty sure I ran "git svn fetch" but I don't think I ran "git fetch svn"<br></div><span><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div>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.</div><div>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.<br></div><div><br></div><div>So, new guidance: don't use "git fetch svn" if you're using "git svn" commands directly.<br></div><div><br></div></div></blockquote><div><br></div></span>No problem. I don't think I was using git fetch svn anyway.<br></div><div class="gmail_quote"><span><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div>But first we have to fix your branches. I assume that your svn/wip remote branch is equal to your wip one.</div><div>Just do "git fetch svn" to correct svn/wip (I've made sure it's currently correct in the mirror).</div></div></blockquote><div><br></div></span><div>Done! Seemed to work. <a href="https://pastebin.com/raw/5dknwkix" target="_blank">https://pastebin.com/raw/5dknw<wbr>kix</a><br></div><span><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div>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.</div></div></blockquote><div><br></div></span><div>Done. I did not have any extra commits on wip, it did look like it was restoring some stuff. <a href="https://pastebin.com/raw/T96y5M4h" target="_blank">https://pastebin.com/raw/T96y5<wbr>M4h</a></div></div></div></div></blockquote><br></span></div><div class="gmail_quote">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 <span>reset --hard instead.<br></span></div><div><div class="gmail-m_-8275688692413493624h5"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div><br></div><div>I checked git log, and confirmed that all the revisions between 9235 and 9255 are included.<br></div><span><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div>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.</div></div></blockquote><div><br></div></span><div>Not trying this, since there does not seem to be a need</div><span><div><br></div><div> <br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div><br></div><div>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)<br></div><div><br></div><div></div></div></blockquote><div><br></div></span><div>I don't think git-svn is to blame, I think my clumsy rebase work probably caused this<br></div><span><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div>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.<br></div><div><br></div></div></blockquote><div><br></div></span><div>Done, and seemed to work fine! <a href="https://pastebin.com/raw/5WJDN8p5" target="_blank">https://pastebin.com/raw/5WJDN<wbr>8p5</a><br></div><span><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div></div><div><br></div><div>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".<br></div><div>(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.)<br></div><div><br></div></div></blockquote><div><br></div></span><div>I deleted it from github's gui but thank you for letting me know the command-line way to do it :)<br></div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div></div><div>Phew.<br></div></div></blockquote><div><br></div><div>Thank you so much for helping me fix my mess :)</div><div><br></div><div>---</div><div>James<br></div><div><div class="gmail-m_-8275688692413493624m_-3140905650611477295gmail-m_-2437542841923092686h5"><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div></div><div><div class="gmail-m_-8275688692413493624m_-3140905650611477295gmail-m_-2437542841923092686m_-8035808387007537190gmail-h5"><div class="gmail_extra"><br><div class="gmail_quote">On 6 September 2017 at 03:19, Ralph Versteegen <span dir="ltr"><<a href="mailto:teeemcee@gmail.com" target="_blank">teeemcee@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div>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.<br></div><div></div><div class="gmail_extra"><br></div><div class="gmail_extra">*But svn does support merges... I don't know how git-svn handles those.</div><div class="gmail_extra"><br></div><div class="gmail_extra">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.<br></div><div><div class="gmail-m_-8275688692413493624m_-3140905650611477295gmail-m_-2437542841923092686m_-8035808387007537190gmail-m_-941231565656591366m_-1565027473381030543h5"><div class="gmail_extra"><br><div class="gmail_quote">On 6 September 2017 at 02:36, James Paige <span dir="ltr"><<a href="mailto:Bob@hamsterrepublic.com" target="_blank">Bob@hamsterrepublic.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div><div><div><div>Okay, I think that makes sense!<br><br></div>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<br><br></div>That seems to make sense to me, thank you.<br><br></div>Out of curiosity, what breaks if I do a merge?<br><br>---<br></div>James<br></div><div class="gmail-m_-8275688692413493624m_-3140905650611477295gmail-m_-2437542841923092686m_-8035808387007537190gmail-m_-941231565656591366m_-1565027473381030543m_-1820995280344959849HOEnZb"><div class="gmail-m_-8275688692413493624m_-3140905650611477295gmail-m_-2437542841923092686m_-8035808387007537190gmail-m_-941231565656591366m_-1565027473381030543m_-1820995280344959849h5"><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Sep 5, 2017 at 5:04 AM, Ralph Versteegen <span dir="ltr"><<a href="mailto:teeemcee@gmail.com" target="_blank">teeemcee@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div><div>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:</div><div><div>git rebase A master # any commits to master will follow after those in A<br></div><div>git branch -d A<br></div><div>git svn dcommit # pushing any commits on A or on master to svn<br></div><div><br></div></div></div><div>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).</div><div>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.<br></div><div><br></div><div>So anyway, if you're on branch A, you can just do:</div><div></div><div>git svn dcommit</div><div>git checkout master</div><div>git svn rebase # If there were no extra commits to master, master and A should now be identical<br></div><div>git branch -d A<br></div><div><br></div><br></div><div class="gmail_extra"><br><div class="gmail_quote"><div><div class="gmail-m_-8275688692413493624m_-3140905650611477295gmail-m_-2437542841923092686m_-8035808387007537190gmail-m_-941231565656591366m_-1565027473381030543m_-1820995280344959849m_-7135792200877317013h5">On 5 September 2017 at 11:06, James Paige <span dir="ltr"><<a href="mailto:Bob@hamsterrepublic.com" target="_blank">Bob@hamsterrepublic.com</a>></span> wrote:<br></div></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div><div class="gmail-m_-8275688692413493624m_-3140905650611477295gmail-m_-2437542841923092686m_-8035808387007537190gmail-m_-941231565656591366m_-1565027473381030543m_-1820995280344959849m_-7135792200877317013h5"><div dir="ltr"><div><div>Hey, TMC, what workflow do you use when you want to merge a feature branch before you "git svn dcommit" it?<br><br></div>I remember being warned that ordinary merges are a source of problems.<br><br>---<br></div>James<br></div>
<br></div></div>______________________________<wbr>_________________<br>
Ohrrpgce mailing list<br>
<a href="mailto:ohrrpgce@lists.motherhamster.org" target="_blank">ohrrpgce@lists.motherhamster.o<wbr>rg</a><br>
<a href="http://lists.motherhamster.org/listinfo.cgi/ohrrpgce-motherhamster.org" rel="noreferrer" target="_blank">http://lists.motherhamster.org<wbr>/listinfo.cgi/ohrrpgce-motherh<wbr>amster.org</a><br>
<br></blockquote></div><br></div>
<br>______________________________<wbr>_________________<br>
Ohrrpgce mailing list<br>
<a href="mailto:ohrrpgce@lists.motherhamster.org" target="_blank">ohrrpgce@lists.motherhamster.o<wbr>rg</a><br>
<a href="http://lists.motherhamster.org/listinfo.cgi/ohrrpgce-motherhamster.org" rel="noreferrer" target="_blank">http://lists.motherhamster.org<wbr>/listinfo.cgi/ohrrpgce-motherh<wbr>amster.org</a><br>
<br></blockquote></div><br></div>
</div></div><br>______________________________<wbr>_________________<br>
Ohrrpgce mailing list<br>
<a href="mailto:ohrrpgce@lists.motherhamster.org" target="_blank">ohrrpgce@lists.motherhamster.o<wbr>rg</a><br>
<a href="http://lists.motherhamster.org/listinfo.cgi/ohrrpgce-motherhamster.org" rel="noreferrer" target="_blank">http://lists.motherhamster.org<wbr>/listinfo.cgi/ohrrpgce-motherh<wbr>amster.org</a><br>
<br></blockquote></div><br></div></div></div></div>
</blockquote></div><br></div></div></div></div>
<br>______________________________<wbr>_________________<br>
Ohrrpgce mailing list<br>
<a href="mailto:ohrrpgce@lists.motherhamster.org" target="_blank">ohrrpgce@lists.motherhamster.o<wbr>rg</a><br>
<a href="http://lists.motherhamster.org/listinfo.cgi/ohrrpgce-motherhamster.org" rel="noreferrer" target="_blank">http://lists.motherhamster.org<wbr>/listinfo.cgi/ohrrpgce-motherh<wbr>amster.org</a><br>
<br></blockquote></div></div></div><br></div></div>
<br>______________________________<wbr>_________________<br>
Ohrrpgce mailing list<br>
<a href="mailto:ohrrpgce@lists.motherhamster.org" target="_blank">ohrrpgce@lists.motherhamster.o<wbr>rg</a><br>
<a href="http://lists.motherhamster.org/listinfo.cgi/ohrrpgce-motherhamster.org" rel="noreferrer" target="_blank">http://lists.motherhamster.org<wbr>/listinfo.cgi/ohrrpgce-motherh<wbr>amster.org</a><br>
<br></blockquote></div><br></div></div></div></div>
<br>______________________________<wbr>_________________<br>
Ohrrpgce mailing list<br>
<a href="mailto:ohrrpgce@lists.motherhamster.org" target="_blank">ohrrpgce@lists.motherhamster.o<wbr>rg</a><br>
<a href="http://lists.motherhamster.org/listinfo.cgi/ohrrpgce-motherhamster.org" rel="noreferrer" target="_blank">http://lists.motherhamster.org<wbr>/listinfo.cgi/ohrrpgce-motherh<wbr>amster.org</a><br>
<br></blockquote></div></div></div><br></div></div>
<br>______________________________<wbr>_________________<br>
Ohrrpgce mailing list<br>
<a href="mailto:ohrrpgce@lists.motherhamster.org">ohrrpgce@lists.motherhamster.<wbr>org</a><br>
<a href="http://lists.motherhamster.org/listinfo.cgi/ohrrpgce-motherhamster.org" rel="noreferrer" target="_blank">http://lists.motherhamster.<wbr>org/listinfo.cgi/ohrrpgce-<wbr>motherhamster.org</a><br>
<br></blockquote></div><br></div></div>