Wine + GIT

Wine + GIT

[Mike McCormack]

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

Re: Wine + GIT

[Jeff Garzik]

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?

Re: Wine + GIT

[Junio C Hamano]

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

Re: Wine + GIT

[J. Bruce Fields]

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.

Re: Wine + GIT

[Junio C Hamano]

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

Re: Wine + GIT

[J. Bruce Fields]

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.

Re: Wine + GIT

[Jon Loeliger]

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

git shorthands (was: Re: Wine + GIT)

[Andreas Ericsson]

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

Re: Wine + GIT

[Ben Clifford]

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.

Re: Wine + GIT

[Jeff Garzik]

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

Re: Wine + GIT

[Mike McCormack]

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

Re: Wine + GIT

[Jeff Garzik]

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

Re: Wine + GIT

[Nick Hengeveld]

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.

Re: Wine + GIT

[Andreas Ericsson]

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

Re: Wine + GIT

[Marco Costalba]

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

Re: Wine + GIT

[linux]

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

Re: Wine + GIT

[Fredrik Kuivinen]

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

Re: Wine + GIT

[Junio C Hamano]

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.