| Summary: | git-webkit should have equivalent of svn up | ||
|---|---|---|---|
| Product: | WebKit | Reporter: | Ryosuke Niwa <rniwa> |
| Component: | Tools / Tests | Assignee: | Nobody <webkit-unassigned> |
| Status: | RESOLVED CONFIGURATION CHANGED | ||
| Severity: | Normal | CC: | bdakin, ggaren, jbedard, webkit-bug-importer |
| Priority: | P2 | Keywords: | InRadar |
| Version: | WebKit Nightly Build | ||
| Hardware: | Unspecified | ||
| OS: | Unspecified | ||
| See Also: |
https://bugs.webkit.org/show_bug.cgi?id=215862 https://bugs.webkit.org/show_bug.cgi?id=220442 https://bugs.webkit.org/show_bug.cgi?id=229625 https://bugs.webkit.org/show_bug.cgi?id=235861 |
||
|
Description
Ryosuke Niwa
2021-03-05 18:55:50 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. 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. 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 |