* Wine + GIT
@ 2005-12-05 23:29 Mike McCormack
2005-12-06 2:03 ` Jeff Garzik
` (2 more replies)
0 siblings, 3 replies; 18+ messages in thread
From: Mike McCormack @ 2005-12-05 23:29 UTC (permalink / raw)
To: git
Hi All,
The Wine project has started maintaining a wine.git in parallel to the
Wine CVS. To introduce Wine developers to GIT, we've put together a
short introduction on the Wine Wiki on using GIT to maintain patches.
You can find it at:
http://wiki.winehq.org/GitWine
Comments, flames, corrections and additions welcome :)
Mike
^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: Wine + GIT
2005-12-05 23:29 Wine + GIT Mike McCormack
@ 2005-12-06 2:03 ` Jeff Garzik
2005-12-06 2:26 ` Junio C Hamano
2005-12-06 17:08 ` J. Bruce Fields
2005-12-06 2:18 ` Jeff Garzik
2005-12-06 9:02 ` Marco Costalba
2 siblings, 2 replies; 18+ messages in thread
From: Jeff Garzik @ 2005-12-06 2:03 UTC (permalink / raw)
To: Mike McCormack; +Cc: git
Mike McCormack wrote:
> Hi All,
>
> The Wine project has started maintaining a wine.git in parallel to the
> Wine CVS. To introduce Wine developers to GIT, we've put together a
> short introduction on the Wine Wiki on using GIT to maintain patches.
> You can find it at:
> http://wiki.winehq.org/GitWine
Very cool! :)
Comments:
1) I wrote a git howto for kernel hackers, 95% of which applies to other
projects as well: http://linux.yyz.us/git-howto.html
2) The "git-foo" commands are apparently uncool. "git foo ..." is
preferred.
3) replace
git-diff-index -p HEAD
with
git diff HEAD
4) "git commit -a" can often replace git-update-index+git-commit
5) never ever do
git-checkout -f HEAD
HEAD should always be a symlink. 'git checkout -f master' is probably
what you want.
6) For merges with hand-merged conflicts, I could have sworn that either
a "git commit -a" or 'git-update-index' + 'git commit' was required.
Maybe I'm wrong, or that has changed?
^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: Wine + GIT
2005-12-05 23:29 Wine + GIT Mike McCormack
2005-12-06 2:03 ` Jeff Garzik
@ 2005-12-06 2:18 ` Jeff Garzik
2005-12-06 23:08 ` Nick Hengeveld
2005-12-06 9:02 ` Marco Costalba
2 siblings, 1 reply; 18+ messages in thread
From: Jeff Garzik @ 2005-12-06 2:18 UTC (permalink / raw)
To: Mike McCormack; +Cc: git
Mike McCormack wrote:
> Hi All,
>
> The Wine project has started maintaining a wine.git in parallel to the
> Wine CVS. To introduce Wine developers to GIT, we've put together a
> short introduction on the Wine Wiki on using GIT to maintain patches.
> You can find it at:
>
> http://wiki.winehq.org/GitWine
One other comment: http:// is the slowest of all three transports.
git:// (git daemon) is preferred, followed by rsync.
http:// takes forever, comparatively.
Jeff
^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: Wine + GIT
2005-12-06 2:03 ` Jeff Garzik
@ 2005-12-06 2:26 ` Junio C Hamano
2005-12-06 17:08 ` J. Bruce Fields
1 sibling, 0 replies; 18+ messages in thread
From: Junio C Hamano @ 2005-12-06 2:26 UTC (permalink / raw)
To: Jeff Garzik; +Cc: git, Mike McCormack
Jeff Garzik <jgarzik@pobox.com> writes:
> 5) never ever do
> git-checkout -f HEAD
>
> HEAD should always be a symlink. 'git checkout -f master' is probably
> what you want.
Correct. "git checkout -f HEAD" is a redundant way to say
"I screwed up and would want to revert the mess in my working
tree to my branch head". You do not need to say HEAD; "git
checkout -f" (or "git reset --hard" if you really want to clean
things up) would do.
> 6) For merges with hand-merged conflicts, I could have sworn that either
> a "git commit -a" or 'git-update-index' + 'git commit' was required.
> Maybe I'm wrong, or that has changed?
That has not changed. With the recent 0.99.9l change, I suspect
that the example on the wiki page (without update-index) would
fail to commit -- the index is now left unmerged after a failed
automerge.
The paragraph "Once you have finished editting [sic]..." needs
to be followed by:
git-update-index those paths you hand corrected
git-commit
^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: Wine + GIT
2005-12-05 23:29 Wine + GIT Mike McCormack
2005-12-06 2:03 ` Jeff Garzik
2005-12-06 2:18 ` Jeff Garzik
@ 2005-12-06 9:02 ` Marco Costalba
2 siblings, 0 replies; 18+ messages in thread
From: Marco Costalba @ 2005-12-06 9:02 UTC (permalink / raw)
To: Mike McCormack; +Cc: git
Mike McCormack wrote:
> Hi All,
>
> The Wine project has started maintaining a wine.git in parallel to the
> Wine CVS. To introduce Wine developers to GIT, we've put together a
> short introduction on the Wine Wiki on using GIT to maintain patches.
> You can find it at:
>
> http://wiki.winehq.org/GitWine
>
> Comments, flames, corrections and additions welcome :)
>
about
"Finally, there's a nice (but a bit slow) tool to view your GIT repository named
[WWW] gitk. It gives you a view of the repository that looks like this:"
May I sugest also qgit (http://sourceforge.net/projects/qgit).
It's faster then gitk and has some more feature too.
Thanks
Marco
___________________________________
Yahoo! Mail: gratis 1GB per i messaggi e allegati da 10MB
http://mail.yahoo.it
^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: Wine + GIT
2005-12-06 2:03 ` Jeff Garzik
2005-12-06 2:26 ` Junio C Hamano
@ 2005-12-06 17:08 ` J. Bruce Fields
2005-12-06 17:33 ` Junio C Hamano
2005-12-06 19:01 ` Jeff Garzik
1 sibling, 2 replies; 18+ messages in thread
From: J. Bruce Fields @ 2005-12-06 17:08 UTC (permalink / raw)
To: Jeff Garzik; +Cc: Mike McCormack, git
On Mon, Dec 05, 2005 at 09:03:31PM -0500, Jeff Garzik wrote:
> 2) The "git-foo" commands are apparently uncool. "git foo ..." is
> preferred.
How does e.g. git-diff differ from git diff? I thought they were
equivalent.--b.
^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: Wine + GIT
2005-12-06 17:08 ` J. Bruce Fields
@ 2005-12-06 17:33 ` Junio C Hamano
2005-12-06 17:39 ` J. Bruce Fields
2005-12-06 19:01 ` Jeff Garzik
1 sibling, 1 reply; 18+ messages in thread
From: Junio C Hamano @ 2005-12-06 17:33 UTC (permalink / raw)
To: J. Bruce Fields; +Cc: git
"J. Bruce Fields" <bfields@fieldses.org> writes:
> On Mon, Dec 05, 2005 at 09:03:31PM -0500, Jeff Garzik wrote:
>> 2) The "git-foo" commands are apparently uncool. "git foo ..." is
>> preferred.
>
> How does e.g. git-diff differ from git diff? I thought they were
> equivalent.--b.
For now, but to futureproof your document and its readers, it is
better spelled as "git frotz" not "git-frotz".
There is a long time-horizon plan to move most of the things out
of /usr/bin/, and codewise we have the infrastructure to do it
today. The only reason we haven't done so is that it would break
scripts written by people who learned git from documents that
tell them to write things in dash form, "git-diff".
^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: Wine + GIT
2005-12-06 17:33 ` Junio C Hamano
@ 2005-12-06 17:39 ` J. Bruce Fields
2005-12-06 17:53 ` Jon Loeliger
0 siblings, 1 reply; 18+ messages in thread
From: J. Bruce Fields @ 2005-12-06 17:39 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
On Tue, Dec 06, 2005 at 09:33:02AM -0800, Junio C Hamano wrote:
> There is a long time-horizon plan to move most of the things out
> of /usr/bin/, and codewise we have the infrastructure to do it
> today. The only reason we haven't done so is that it would break
> scripts written by people who learned git from documents that
> tell them to write things in dash form, "git-diff".
I've enjoyed getting tab completions without having to add whatever's
required to my .bashrc to teach it about git subcommands. Oh well, I'll
get over it.
I suppose the git-subcommand convention will continue for the purpose of
naming manpages?
--b.
^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: Wine + GIT
2005-12-06 17:39 ` J. Bruce Fields
@ 2005-12-06 17:53 ` Jon Loeliger
2005-12-06 21:22 ` git shorthands (was: Re: Wine + GIT) Andreas Ericsson
2005-12-07 0:56 ` Wine + GIT Ben Clifford
0 siblings, 2 replies; 18+ messages in thread
From: Jon Loeliger @ 2005-12-06 17:53 UTC (permalink / raw)
To: J. Bruce Fields; +Cc: Junio C Hamano, Git List
On Tue, 2005-12-06 at 11:39, J. Bruce Fields wrote:
> I've enjoyed getting tab completions without having to add whatever's
> required to my .bashrc to teach it about git subcommands. Oh well,
> I'll
> get over it.
I believe this effort is already well under way.
Uh, I also thought we were going to place it in
some "contrib" directory too...?
Also, before I learned of that bash completion effort,
I was contemplating modifying the git.c command recognition
so that it effectively did this:
cmd = ... whatever from command line
if (exec(cmd)) works then
happily clean up and exit
else
using the existing directory scan as a new function,
determine if "cmd" is a proper prefix of some command,
if it is unique then
exec(unique-cmd-disambiguated)
else
complain that it is not unique
fi
fi
That way:
"git mer" would fail
"git merge" would run "git-merge"
"git merge-" would fail
"git merge-o" would fail,
"git-merge-oc" would run "git-merge-octopus".
Any interest? Overkill? Bad idea?
jdl
^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: Wine + GIT
2005-12-06 17:08 ` J. Bruce Fields
2005-12-06 17:33 ` Junio C Hamano
@ 2005-12-06 19:01 ` Jeff Garzik
2005-12-06 19:06 ` Mike McCormack
1 sibling, 1 reply; 18+ messages in thread
From: Jeff Garzik @ 2005-12-06 19:01 UTC (permalink / raw)
To: J. Bruce Fields; +Cc: Mike McCormack, git
J. Bruce Fields wrote:
> On Mon, Dec 05, 2005 at 09:03:31PM -0500, Jeff Garzik wrote:
>
>>2) The "git-foo" commands are apparently uncool. "git foo ..." is
>>preferred.
>
>
> How does e.g. git-diff differ from git diff? I thought they were
> equivalent.--b.
The specific git-diff-XXX command example was longer.
In general, there is not much difference, except that I was admonished
to avoid the git-XXX in my howto. I suppose that makes sense if the
git-XXX programs are moved out of $prefix/bin, leaving only $prefix/bin/git.
Jeff
^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: Wine + GIT
2005-12-06 19:01 ` Jeff Garzik
@ 2005-12-06 19:06 ` Mike McCormack
0 siblings, 0 replies; 18+ messages in thread
From: Mike McCormack @ 2005-12-06 19:06 UTC (permalink / raw)
To: Jeff Garzik; +Cc: J. Bruce Fields, git
Jeff Garzik wrote:
> In general, there is not much difference, except that I was admonished
> to avoid the git-XXX in my howto. I suppose that makes sense if the
> git-XXX programs are moved out of $prefix/bin, leaving only
> $prefix/bin/git.
Using the git-* commands means that tab completion works, which is good
for impatient people with bad memories, like myself :)
Mike
^ permalink raw reply [flat|nested] 18+ messages in thread
* git shorthands (was: Re: Wine + GIT)
2005-12-06 17:53 ` Jon Loeliger
@ 2005-12-06 21:22 ` Andreas Ericsson
2005-12-07 0:56 ` Wine + GIT Ben Clifford
1 sibling, 0 replies; 18+ messages in thread
From: Andreas Ericsson @ 2005-12-06 21:22 UTC (permalink / raw)
To: Git List
Jon Loeliger wrote:
>
> That way:
> "git mer" would fail
> "git merge" would run "git-merge"
> "git merge-" would fail
> "git merge-o" would fail,
> "git-merge-oc" would run "git-merge-octopus".
>
> Any interest? Overkill? Bad idea?
>
I think it's overkill. It would be better, methinks, to add mnemonic-ish
shorthands for the porcelainish commands, so that
git fp => git-format-patch
git co => git-checkout
git up => git-update-index
git octo => git-merge-octopus
git fsck => git-fsck-objects
git hash => git-hash-object
and so on...
This because non-ambiguous is rarely logical (for git at least, which
has 'git-<family>-<action | object-type>) unless one knows the entire
command anyways. Ambiguity may also be introduced by later commands, and
then you'll need to re-learn them. I always find that annoying.
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: Wine + GIT
2005-12-06 2:18 ` Jeff Garzik
@ 2005-12-06 23:08 ` Nick Hengeveld
2005-12-06 23:27 ` Andreas Ericsson
0 siblings, 1 reply; 18+ messages in thread
From: Nick Hengeveld @ 2005-12-06 23:08 UTC (permalink / raw)
To: Jeff Garzik; +Cc: Mike McCormack, git
On Mon, Dec 05, 2005 at 09:18:54PM -0500, Jeff Garzik wrote:
> One other comment: http:// is the slowest of all three transports.
> git:// (git daemon) is preferred, followed by rsync.
>
> http:// takes forever, comparatively.
Has that been the general git user experience? While there are
certainly disadvantages to the http transport, I didn't think that
performance was one of them.
For comparison, I ran some clones this morning/afternoon with the
following results:
Clone of kernel.org/pub/scm/git/git.git
http
real 0m24.204s real 0m25.750s real 0m24.094s
user 0m5.870s user 0m5.530s user 0m5.350s
sys 0m0.660s sys 0m0.710s sys 0m0.600s
rsync
real 1m3.952s real 1m3.417s real 1m4.360s
user 0m0.090s user 0m0.130s user 0m0.120s
sys 0m0.210s sys 0m0.230s sys 0m0.210s
git
real 0m54.715s real 0m55.928s real 0m56.411s
user 0m0.980s user 0m0.980s user 0m1.040s
sys 0m0.220s sys 0m0.140s sys 0m0.160s
Clone of kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git
http
real 4m59.959s real 5m28.512s real 6m9.109s
user 1m38.400s user 1m34.350s user 1m35.700s
sys 0m7.640s sys 0m8.180s sys 0m7.510s
rsync
real 19m47.218s real 19m46.739s real 21m41.875s
user 0m3.960s user 0m4.260s user 0m4.000s
sys 0m5.060s sys 0m4.680s sys 0m4.860s
git
real 19m43.014s real 19m36.692s real 20m43.277s
user 0m23.180s user 0m23.070s user 0m23.230s
sys 0m8.210s sys 0m8.590s sys 0m11.240s
--
For a successful technology, reality must take precedence over public
relations, for nature cannot be fooled.
^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: Wine + GIT
2005-12-06 23:08 ` Nick Hengeveld
@ 2005-12-06 23:27 ` Andreas Ericsson
0 siblings, 0 replies; 18+ messages in thread
From: Andreas Ericsson @ 2005-12-06 23:27 UTC (permalink / raw)
To: git
Nick Hengeveld wrote:
> On Mon, Dec 05, 2005 at 09:18:54PM -0500, Jeff Garzik wrote:
>
>
>>One other comment: http:// is the slowest of all three transports.
>>git:// (git daemon) is preferred, followed by rsync.
>>
>>http:// takes forever, comparatively.
>
>
> Has that been the general git user experience?
It certainly is for me, and I know most of my colleagues think so too.
> While there are
> certainly disadvantages to the http transport, I didn't think that
> performance was one of them.
>
> For comparison, I ran some clones this morning/afternoon with the
> following results:
>
When you clone you need to get all the objects. If the objects aren't
packed on the remote end (which is usually the case), the git protocol
will pack them for you which takes quite some time for a large repo and
puts the server under considerable stress.
When you pull incrementally the native git protocol does some figuring
out of the minimum set of packs it needs to send you.
>
> Clone of kernel.org/pub/scm/git/git.git
>
> http
> real 0m24.204s real 0m25.750s real 0m24.094s
> user 0m5.870s user 0m5.530s user 0m5.350s
> sys 0m0.660s sys 0m0.710s sys 0m0.600s
>
> rsync
> real 1m3.952s real 1m3.417s real 1m4.360s
> user 0m0.090s user 0m0.130s user 0m0.120s
> sys 0m0.210s sys 0m0.230s sys 0m0.210s
>
> git
> real 0m54.715s real 0m55.928s real 0m56.411s
> user 0m0.980s user 0m0.980s user 0m1.040s
> sys 0m0.220s sys 0m0.140s sys 0m0.160s
>
In general, rsync:// should be the fastest protocol to clone over. Why
you got the numbers listed above I have no idea, but I'm guessing the
rsync daemon was under quite a bit of stress. http could in that case be
faster since apache handles multiple clients better than rsync, but only
if you're on a very fast line with low round trip time to the server as
it needs to do a lot of downloading and checking to see where it's at
and what it needs.
You may also want to take notice of the fact that the git-daemon can use
cached pack-files, in which case it doesn't have to do so much manual
packing. If cache-files are present, the git protocol *should* be the
fastest to clone over as well.
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: Wine + GIT
2005-12-06 17:53 ` Jon Loeliger
2005-12-06 21:22 ` git shorthands (was: Re: Wine + GIT) Andreas Ericsson
@ 2005-12-07 0:56 ` Ben Clifford
1 sibling, 0 replies; 18+ messages in thread
From: Ben Clifford @ 2005-12-07 0:56 UTC (permalink / raw)
To: Jon Loeliger, J. Bruce Fields; +Cc: Git List
On 7 Dec 2005, at 04:53, Jon Loeliger wrote:
> On Tue, 2005-12-06 at 11:39, J. Bruce Fields wrote:
>
>> I've enjoyed getting tab completions without having to add whatever's
>> required to my .bashrc to teach it about git subcommands. Oh well,
>> I'll
>> get over it.
>
> I believe this effort is already well under way.
> Uh, I also thought we were going to place it in
> some "contrib" directory too...?
>
The (latest as of now) code for cogito is in cogito's contrib/
directory.
You can get stg,cogito,git,gitk completion code from my repo with:
cg clone http://www.hawaga.org.uk/gitcompletion.git
(I posted a note about it the other day on this git list, entitled
'bash completions code for git+porcelain)
--
Ben • ベン • Бэн • 벤 • 班明
http://www.hawaga.org.uk/ben/
My email is high latency but best way to contact me. Alternatively,
SMS number(s) at above URL.
^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: Wine + GIT
2005-12-08 9:29 ` Fredrik Kuivinen
@ 2005-12-08 18:17 ` Junio C Hamano
0 siblings, 0 replies; 18+ messages in thread
From: Junio C Hamano @ 2005-12-08 18:17 UTC (permalink / raw)
To: Fredrik Kuivinen; +Cc: linux, git, junkio
Fredrik Kuivinen <freku045@student.liu.se> writes:
> However, in some other cases such as rename/rename, file/directory and
> add/add conflicts "a~A" and "a~B" will be created in the working
> directory. The recursive strategy will (or, is supposed to) tell you
> about such things, though.
I think one reason for this was because read-tree -m was the
only way to create higher stage entries in the index, and after
detecting renames, the recursive merge strategy did not have a
good way to insert these as different stages in the index.
I extended update-index --index-info a little bit to let people
insert higher stage entries in the index, so we could if we
wanted to.
Here are the differences I know about between resolve and
recursive other than ~A ~B:
- in add/add case, merge-one-file tries to be cuter and leaves
conflict-marked merge result.
- content conflict in a renamed path gets its index entry
collapsed, unlike other content conflicts.
^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: Wine + GIT
2005-12-08 7:30 linux
@ 2005-12-08 9:29 ` Fredrik Kuivinen
2005-12-08 18:17 ` Junio C Hamano
0 siblings, 1 reply; 18+ messages in thread
From: Fredrik Kuivinen @ 2005-12-08 9:29 UTC (permalink / raw)
To: linux; +Cc: git, junkio
On Thu, Dec 08, 2005 at 02:30:00AM -0500, linux@horizon.com wrote:
> (Grump... I just noticed that the "recursive" merge stratgy *doesn't*
> generate a merged file containing conflict markers, at least not in
> the case I tried. Instead I get "a~HEAD" and "a~branch" files.
> Time to fix the docs...)
In the most common case, i.e., when you have a file 'a' in the common
ancestor and 'a' have been modified in both A and B (where A and B are
the branches we are going to merge) then the recursive strategy should
generate a merged file with merge(1), which will produce conflict
markers if there are conflicts. Any other behaviour is a bug.
However, in some other cases such as rename/rename, file/directory and
add/add conflicts "a~A" and "a~B" will be created in the working
directory. The recursive strategy will (or, is supposed to) tell you
about such things, though.
- Fredrik
^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: Wine + GIT
@ 2005-12-08 7:30 linux
2005-12-08 9:29 ` Fredrik Kuivinen
0 siblings, 1 reply; 18+ messages in thread
From: linux @ 2005-12-08 7:30 UTC (permalink / raw)
To: git, junkio
> The paragraph "Once you have finished editting [sic]..." needs
> to be followed by:
>
> git-update-index those paths you hand corrected
> git-commit
This is what happens when you have people too used to using the
pre-porcelain plumbing.
How about just
git-commit <the paths you hand corrected>
If you forget any, the commit will fail, but they will have been
updated in the index, and you don't need to mention them again in the
next attempt.
(Grump... I just noticed that the "recursive" merge stratgy *doesn't*
generate a merged file containing conflict markers, at least not in
the case I tried. Instead I get "a~HEAD" and "a~branch" files.
Time to fix the docs...)
^ permalink raw reply [flat|nested] 18+ messages in thread
end of thread, other threads:[~2005-12-08 18:17 UTC | newest]
Thread overview: 18+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2005-12-05 23:29 Wine + GIT Mike McCormack
2005-12-06 2:03 ` Jeff Garzik
2005-12-06 2:26 ` Junio C Hamano
2005-12-06 17:08 ` J. Bruce Fields
2005-12-06 17:33 ` Junio C Hamano
2005-12-06 17:39 ` J. Bruce Fields
2005-12-06 17:53 ` Jon Loeliger
2005-12-06 21:22 ` git shorthands (was: Re: Wine + GIT) Andreas Ericsson
2005-12-07 0:56 ` Wine + GIT Ben Clifford
2005-12-06 19:01 ` Jeff Garzik
2005-12-06 19:06 ` Mike McCormack
2005-12-06 2:18 ` Jeff Garzik
2005-12-06 23:08 ` Nick Hengeveld
2005-12-06 23:27 ` Andreas Ericsson
2005-12-06 9:02 ` Marco Costalba
2005-12-08 7:30 linux
2005-12-08 9:29 ` Fredrik Kuivinen
2005-12-08 18:17 ` Junio C Hamano
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.