We should either make `git-webkit pull` or add a new command which behaves like `svn up`, in that it automatically rebases local uncommitted changes against the latest trunk.
For this command, it's very important for that I can do the equivalent of mine-full/mine-conflict. The whole git checkout --ours/--theirs business is way too confusing.
Oh, also very important. We need an equivalent of: svn up -r X Like: git-webkit up -c=<commit-identifier> And that should checkout that exact version of "main" branch without getting into a detached state, creating a new branch, etc... Ideally, this command will also support rN form of Subversion revision so that we can go from Subversion version on trac / bugzilla / etc... straight to checking it out on GitHub clone.
<rdar://problem/75171216>
We already have `git-webkit checkout <arg>`, which supports identifiers, revisions (in SVN and git-svn) and hashes (in git), but there are some missing pieces to it, namely, how this works when there are local edits. I think avoiding the detached HEAD state is not something we should strive for. `git-webkit checkout <arg>` and `git-webkit pull` should behave in the detached HEAD state (not hard when branches have a defined priority, and ours do).
(In reply to Jonathan Bedard from comment #4) > We already have `git-webkit checkout <arg>`, which supports identifiers, > revisions (in SVN and git-svn) and hashes (in git), but there are some > missing pieces to it, namely, how this works when there are local edits. That is good to know but does it create a new branch or modify the existing branch? I really want to modify the existing / current branch. > I think avoiding the detached HEAD state is not something we should strive > for. `git-webkit checkout <arg>` and `git-webkit pull` should behave in the > detached HEAD state (not hard when branches have a defined priority, and > ours do). I mean... as long as detached HEAD state doesn't cause any problems with all other tools I have no problem with it. We just need to make sure none of the tools we use result in some kind of obscure error message.
Addressed this in https://bugs.webkit.org/show_bug.cgi?id=220442 and https://bugs.webkit.org/show_bug.cgi?id=229625, closing this bug
(In reply to Jonathan Bedard from comment #6) > Addressed this in https://bugs.webkit.org/show_bug.cgi?id=220442 and > https://bugs.webkit.org/show_bug.cgi?id=229625, closing this bug Your bug says update PR request when running git-webkit up. What if I had local uncommitted changes and ran git-webkit up? Does it automatically rebase instead of error'ing out with "there is uncommitted local change" nonsense?
This issue't resolved still. Tracking it in https://bugs.webkit.org/show_bug.cgi?id=235861