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

Mike McCormack wrote:

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?

Jeff Garzik <jgarzik@pobox.com> writes:

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

On Mon, Dec 05, 2005 at 09:03:31PM -0500, Jeff Garzik wrote:

How does e.g. git-diff differ from git diff? I thought they were equivalent.--b.

"J. Bruce Fields" <bfields@fieldses.org> writes:

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

On Tue, Dec 06, 2005 at 09:33:02AM -0800, Junio C Hamano 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 suppose the git-subcommand convention will continue for the purpose of naming manpages?

--b.

On Tue, 2005-12-06 at 11:39, J. Bruce Fields wrote:

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

Jon Loeliger wrote:

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.

On 7 Dec 2005, at 04:53, Jon Loeliger wrote:

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)

J. Bruce Fields wrote:

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

Jeff Garzik wrote:

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

Mike

Mike McCormack wrote:

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

http:// takes forever, comparatively.

	Jeff

On Mon, Dec 05, 2005 at 09:18:54PM -0500, Jeff Garzik wrote:

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

Nick Hengeveld wrote:

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.

Mike McCormack wrote:

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