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

Reply via email to