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: [email protected] [[email protected]] on behalf of Ryosuke Niwa
[[email protected]]
Sent: Thursday, March 08, 2012 4:25 PM
To: Joe Mason
Cc: Hugo Parente Lima; [email protected]
Subject: Re: [webkit-dev] Moving to Git?
On Thu, Mar 8, 2012 at 12:44 PM, Jochen Eisinger
<[email protected]<mailto:[email protected]>> wrote:
On Thu, Mar 8, 2012 at 9:12 PM, Ryosuke Niwa
<[email protected]<mailto:[email protected]>> 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
<[email protected]<mailto:[email protected]>> 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
<[email protected]<mailto:[email protected]>> 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.
_______________________________________________
webkit-dev mailing list
[email protected]
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
