Wine + 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

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?

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

Using the git-* commands means that tab completion works, which is good for impatient people with bad memories, like myself :)

Mike

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".

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.

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

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                   [email protected]
OP5 AB                             www.op5.se
Tel: +46 8-230225                  Fax: +46 8-230231

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.

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.

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

One other comment: http:// is the slowest of all three transports. git:// (git daemon) is preferred, followed by rsync.

http:// takes forever, comparatively.

Jeff

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.

It certainly is for me, and I know most of my colleagues think so too.

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.

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                   [email protected]
OP5 AB                             www.op5.se
Tel: +46 8-230225                  Fax: +46 8-230231

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