WebKit Bugzilla
New
Browse
Log In
×
Sign in with GitHub
or
Remember my login
Create Account
·
Forgot Password
Forgotten password account recovery
RESOLVED CONFIGURATION CHANGED
222847
git-webkit should have equivalent of svn up
https://bugs.webkit.org/show_bug.cgi?id=222847
Summary
git-webkit should have equivalent of svn up
Ryosuke Niwa
Reported
2021-03-05 18:55:50 PST
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.
Attachments
Add attachment
proposed patch, testcase, etc.
Ryosuke Niwa
Comment 1
2021-03-05 19:11:01 PST
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.
Ryosuke Niwa
Comment 2
2021-03-05 19:39:33 PST
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.
Radar WebKit Bug Importer
Comment 3
2021-03-08 08:31:21 PST
<
rdar://problem/75171216
>
Jonathan Bedard
Comment 4
2021-03-08 08:45:45 PST
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).
Ryosuke Niwa
Comment 5
2021-03-08 19:05:37 PST
(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.
Jonathan Bedard
Comment 6
2021-09-07 12:23:29 PDT
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
Ryosuke Niwa
Comment 7
2021-09-07 12:40:50 PDT
(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?
Ryosuke Niwa
Comment 8
2022-01-29 12:50:12 PST
This issue't resolved still. Tracking it in
https://bugs.webkit.org/show_bug.cgi?id=235861
Note
You need to
log in
before you can comment on or make changes to this bug.
Top of Page
Format For Printing
XML
Clone This Bug