On Thu, Aug 6, 2009 at 2:06 PM, Marc-Antoine Ruel<mar...@chromium.org> wrote: >> Say DEPS says web...@revision A, and you have webkit at revision A~10. >> gclient sync should probably fast-forward your checkout. >> >> Say DEPS says web...@revision A, and then you've checked out trunk and >> have local changes. gclient sync should probably... do nothing? >> >> But then how do we tell "DEPS checked them out at A~10 before, so we >> should fast forward to A" from "they checked out A~10 because that was >> trunk at the time, so we should fast forward to trunk"? > > I assume s/trunk/HEAD/g
Yeah, the SVN HEAD, not the git one. Confusing. :( > But I still don't understand your sentence. Doesn't `git svn rebase > --revision A` work for that or I misunderstood? I presume it will back > merge if needed? I didn't think rebase takes a --revision argument... My examples were bad. Let me try again. Suppose current DEPS says WebKit at revision A. I am tweaking WebKit stuff so I started at the newest version I can find, version B. I have made a local commit on top of that, call it C. Now I do a gclient sync, and my DEPS updates to request some other WebKit version D. In the meantime, the newest WebKit available is now version E. (Note that D can be earlier or later than B.) In this circumstance I think I should remain on commit C. But if C=B, then maybe I should end up at E? Or if you think rebasing is correct, should I rebase C onto E or C onto D? And what if I have local uncommitted changes -- then rebasing isn't possible? Finally, what if D is an *earlier* commit than A (we rolled back DEPS for some reason), do I rebase my work in C backwards? Etc. etc. And say A=B=C (that is, I'm not working on WebKit at all), I think you probably want to end up on D. But detecting that A=C means you need the DEPS file from *before* you synced (to get A). What I had done before was add a tag to each git repo called "gclient" that always pointed at the version requested by gclient, and then left it up to you whether you wanted to check that out or not. And then you can compare your current commit to the gclient tag and warn appropriately. But I think git is confusing enough for most people so someone (I think it was Tony?) pointed out I can keep it even simpler and say "figure it out yourself". --~--~---------~--~----~------------~-------~--~----~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~----------~----~----~----~------~----~------~--~---