[webkit-dev] Moving to Git?

[Joe Mason]

I agree that git's hashes are less friendly than the monotonically increasing commit numbers from svn or p4.  I've occasionally been given a pair of git hashes and had no idea which one came first, or even if they were in the same branch.

"git log --oneline <hash>" is a pretty simple way to list all the commits coming before the given <hash>, so you can see the order of them.  Other than that, maybe a post-commit hook that automatically puts a

Aside: here's a neat command to map git hash's to svn-style ascending numbers: git log --oneline <hash>|cat -b

$ git log --oneline e865bb0|cat -b|head
     1  e865bb0 [Qt WK2] Remove duplicate code related to dialog handling in QQuickWebView https://bugs.webkit.org/show_bug.cgi?id=80557
     2  a6b3dd6 Fix flaky test by decreasing granularity of cues (cues cover longer time intervals). The flakiness seems to appear because the video is paused synchronously, while missed events events are dispatched asynchronously.
     3  9e20583 [Qt] Rebaseline after r110072.
     4  4e072d9 [Qt] Windows build fix.ommit
     5  7c7ab53 [chromium] Unreviewed gardening.
     6  7c004bc Web Inspector: The function had to return a hash but it returned just address. https://bugs.webkit.org/show_bug.cgi?id=80591
     7  d4c2667 Unreviewed single line fix. The function had to return a hash but it returned just address.
     8  7b5de0b [chromium] Unreviewed gardening.
     9  5540031 <shadow> should be rendered correctly. https://bugs.webkit.org/show_bug.cgi?id=78596
    10  9040697 Speech JavaScript API: SpeechRecognitionAlternative, Result and ResultList https://bugs.webkit.org/show_bug.cgi?id=80424

...except of course that this is descending numbers (1 is the most recent) and they're not persistent, so telling somebody "commit 8" only works if they're starting from the same point.  Which makes them not incredibly useful.

________________________________
From: ryosuke.niwa at gmail.com [ryosuke.niwa at gmail.com] on behalf of Ryosuke Niwa [rniwa at webkit.org]
Sent: Thursday, March 08, 2012 4:25 PM
To: Joe Mason
Cc: Hugo Parente Lima; webkit-dev at lists.webkit.org
Subject: Re: [webkit-dev] Moving to Git?

On Thu, Mar 8, 2012 at 12:44 PM, Jochen Eisinger <jochen at chromium.org<mailto:jochen at chromium.org>> wrote:
On Thu, Mar 8, 2012 at 9:12 PM, Ryosuke Niwa <rniwa at webkit.org<mailto:rniwa at webkit.org>> wrote:
The simplicity. In git, I have to worry about things like committing local changes before rebasing to master, or stashing, etc... In svn, all I have to do is to run "svn up".

I wonder, do you really run svn up that much? I'd expect that this breaks your checkout every now and then if some dependencies change. I usually run update-webkit, which should hide the rebasing actions from you

I do that at least 5-6 times a day if not more.

On Thu, Mar 8, 2012 at 12:58 PM, John Yani <vanuan at gmail.com<mailto:vanuan at gmail.com>> wrote:
> I don't think so. I like the simplicity of svn. While git client works
> great, I always get frustrated by the complexity of having multiple branches
> locally and the amount of work required to merge the remote changes on the
> branch I'm working on.

What do you mean?

# fetch from origin master and merge into the current branch
git pull origin mtaster

Huh? That's not equivalent to svn up at all.

On Thu, Mar 8, 2012 at 1:19 PM, Joe Mason <jmason at rim.com<mailto:jmason at rim.com>> wrote:
What Ryosuke seems to be complaining about is that if you have changes to your working copy, "svn up" will automatically merge them, which could lead to conflicts you have to untangle, while "git pull --rebase" will give an error telling you you must commit or stash them first.  So the real equivalent to "svn up" is "git stash && git pull --rebase origin/master && git stash pop".  And "git stash pop" will start pretty much the same merging process as svn's if there are conflicts.

Right. But I can't bother to type that much myself. Maybe my complain will go away if someone had implemented webkit-patch up that does this automatically.

This is only slightly more complicated

I'd say astoundingly more complicated because of

and has the benefit that if something goes wrong, your changes remain explicitly in the git stash, where you can get at them with commands like "git stash show" or "git stash branch"

whereas unless svn has features I don't know about, if "svn up" does unexpected things the only record of your changes is a series of conflict markers you'll need to resolve.

But I can just run svn diff to create a backup if I really wanted to save the original change. But I've never had a trouble merging things so it's hard for me to tell if that's really useful or not.

And you can always make a "git-up" script that does "git stash && git pull --rebase origin/master && git stash pop", so the command you type won't even be any longer than "svn up", but will give you more safety.

That'll certainly be an improvement. I still dislike git hashes though. If someone implements such a script in webkit-patch and we can automatically assign svn-revision like numbers to all commits, I can be convinced to use git.

- Ryosuke


---------------------------------------------------------------------
This transmission (including any attachments) may contain confidential information, privileged material (including material protected by the solicitor-client or other applicable privileges), or constitute non-public information. Any use of this information by anyone other than the intended recipient is prohibited. If you have received this transmission in error, please immediately reply to the sender and delete this information from your system. Use, dissemination, distribution, or reproduction of this transmission by unintended recipients is not authorized and may be unlawful.