RESOLVED WONTFIX Bug 34206
Improve update-webkit's Git code-path to support mirrors and resolve-ChangeLogs
https://bugs.webkit.org/show_bug.cgi?id=34206
Summary Improve update-webkit's Git code-path to support mirrors and resolve-ChangeLogs
Tor Arne Vestbø
Reported 2010-01-27 01:08:44 PST
Improve update-webkit's Git code-path to support mirrors and resolve-ChangeLogs
Attachments
Patch (6.93 KB, patch)
2010-01-27 01:46 PST, Tor Arne Vestbø
no flags
updated to exit(1) if we couldnt resolve all conflicts (6.95 KB, patch)
2010-01-27 01:53 PST, Tor Arne Vestbø
no flags
Tor Arne Vestbø
Comment 1 2010-01-27 01:46:18 PST
Tor Arne Vestbø
Comment 2 2010-01-27 01:53:14 PST
Created attachment 47511 [details] updated to exit(1) if we couldnt resolve all conflicts
Adam Barth
Comment 3 2010-02-02 20:42:12 PST
Looks plausible to me, but I don't read Perl very well. Certainly much more awesome than my version. :)
Evan Martin
Comment 4 2010-02-02 21:40:59 PST
+ # Check the git config for a possible mirror remote we can use + my $remotes = `git config --get-regexp "^remote\..+\.url"`; + if ($remotes =~ /^remote\.(.*?)\.url .*?\/webkit\.git$/mi) { If I'm reading this right, you're considering any url ending with webkit.git as a webkit mirror? I can see what you're trying to do, but seems a bit weak. You might consider doing what we do in Chrome: make both "git fetch" as well as "git svn rebase" update the same branch. When you use the git fetch to advance the remote branch, the next time you run a git svn command git recognizes that you've fetched the commits via another mechanism and just fast-forwards its index. It's just a minor tweak to how you set up git-svn: http://code.google.com/p/chromium/wiki/UsingGit#Initial_Setup
Tor Arne Vestbø
Comment 5 2010-02-17 01:59:52 PST
(In reply to comment #4) > + # Check the git config for a possible mirror remote we can use > + my $remotes = `git config --get-regexp "^remote\..+\.url"`; > + if ($remotes =~ /^remote\.(.*?)\.url .*?\/webkit\.git$/mi) { > > If I'm reading this right, you're considering any url ending with webkit.git as > a webkit mirror? I can see what you're trying to do, but seems a bit weak. True, you could have more remotes (personal repos for example) that also end with webkit.git. If did it this way instead of hardcoding git.webkit.org/webkit.git so that it would also work for mirrors like gitorius.org/webkit/webkit.git, but I guess we should be a bit more explicit. > You might consider doing what we do in Chrome: make both "git fetch" as well as > "git svn rebase" update the same branch. When you use the git fetch to advance > the remote branch, the next time you run a git svn command git recognizes that > you've fetched the commits via another mechanism and just fast-forwards its > index. It's just a minor tweak to how you set up git-svn: > http://code.google.com/p/chromium/wiki/UsingGit#Initial_Setup That's a nice trick, but it assumes that the git mirror has a branch named trunk. Neither git.webkit.org/webkit.git or gitorious.org/webkit/webkit.git are set up like this, they have a master-branch. It also assumes the user remembers to svn init with that prefix and not use the full trunk URL. I also remember seeing some problems when doing this myself, possibly due to bugs in git. git-svn would get very confused if if though it had fetched something and then the mirror was lagging so it reset the branch to a svn revision before what git-svn thought it had fetched, etc. That's why the script uses git-cherry to make sure the master is ahead of the git-svn branch before updating it. Anyways, I'll upload a new patch that does not have the resolve-ChangeLog-logic, which is no longer needed once the merge-driver patch lands.
Ahmad Saleem
Comment 6 2022-09-10 15:17:41 PDT
Is it needed anymore? Thanks!
Alexey Proskuryakov
Comment 7 2022-09-10 16:22:20 PDT
It's not.
Note You need to log in before you can comment on or make changes to this bug.