From: Dustin Sallings <dustin@xxxxxxx>
Date: February 9, 2008 5:30:48 PM PST
To: dormando <dormando@xxxxxxxxx>
Cc: memcached list <memcached@xxxxxxxxxxxxxxx>
Subject: Re: Upcoming memcached releases + rambling.
On Feb 9, 2008, at 0:28, dormando wrote:
incoming/outgoing:
If I _think_ I understand these right, you can actually sometimes git
diff with the second repo as an argument. That'll show the
differences
since the target repo/branch (git diff . /path/to/other/repo#branch),
which will be incoming or outgoing.
Hmm... Trying that, but it doesn't take ``origin'' nor the URL of
origin as an argument. Not quite what I'm looking for anyway...
That'll show the raw changes... for showing the difference in
changeset,
you can do a: git log --since HEAD origin
... if origin were the remote repo. If you don't have the latest
changes, fetch more, rebase your repo on top of that, then git log
--since will show you what you have to upload.
My log (1.5.3.7) doesn't have --since (fatal: unrecognized
argument: --since)
Otherwise you can use git fetch to "pull" the remote changes into a
branch but not apply anywhere, then use git log with relative
commit ids
to show the changesets (with -p to show the full changes!)
Is that the old..new stuff it printed when I fetched? I guess
that's close enough to what I want to accomplish, but it only seems
to work once I've got the changes.
Unless I'm getting my wires crossed and this is a patch management
thinger, in that case it's 'git format-patch' and 'git am' (although
there's an alternative to am).
OK, I don't think this is doing what what I want. I did a ``git
format-patch origin..'' and it didn't do anything. I rebased my
changes and did it and it included a bunch of changes I didn't
make. I did a ``git checkout HEAD'' to try to go back to sanity and
format-patch now includes just the things I changed.
I think ``git log origin..'' does what I want here (except in the
case of git svn in which case origin is called something else and
doesn't show up under git remote).
export:
Appears to be git log --pretty=[format] [-p] ?
I think it's probably ``git log --pretty=raw -n 1 -p [id]''
I haven't tried git-am to see if it would apply this properly. git-
apply does not (it modifies the tree, I want the change committed by
the original author with the original date, etc...).
bundle:
git bundle, same feature. push/pull accept bundles too, it seems.
Right. The equiv seems to be:
git bundle create /some/file origin..
serve:
You got me here. I've been doing the "scp a bare repo up to my
webhost,
run a script to prep it for http pull's" thing. Usually takes a few
minutes if I don't forget what to do, and the basic tutorials show
how
to do this.
You can do the above with mercurial, but they don't advertise it
much because it's slow on the consumer side. You don't need a
script or anything to prep it, though. Just dump your working tree
on a web server.
No built in webbrick a-like though. I guess that's twistd?
Or something? Dunno, that's pretty swanky, but my laptop doesn't
usually
have direct internet access so I upload it to my webhost anyway.
No, python has a built-in web server. It's just using that.
Mercurial does appear to work better with pushing things around,
while
git is primarily pull oriented. I don't mind the loss there, pushing
between distributed repos is kinda crazy. Or maybe I just haven't
used
hg enough.
pull is definitely better than push in general. Except in the case
I ran into yesterday where the only option I had other than pushing
was emailing a bundle. :)
I've spread git within a company of 15+ developers (now way more? I
hope) to replace SVN. Slow adoption at first but they love it, and
were
having very severe performance problems.
That's good. I'm sure I just haven't learned it enough yet. You
may provide me with an opportunity to do so. :)
I think a bunch of the ruby folk use git? We should have someone
who can
say a word or two about it?
All the ruby stuff I can find uses svn, it's like...built into the
tools. They may be using git-svn, but that's really a different
tool from what I can tell. For example, cloning a git-svn clone
doesn't give you a git-svn clone.
Should memcached choose git, it may be as simple as putting up a
page that says, ``this is how you clone, this is how you work,
this is
how you submit your changes back.''
I've been stuck in the stone-age with git apparently! Every time I go
read the tutorials I find four other commands I don't need to run
anymore. It looks like with 1.4 or 1.5+ all you need to do is
clone, do
some git remote's, and 'git pull' until you're bored. Then rebase
your
branch on top of origin, and git-format-patch a patch series. Or
shove
your repo up with http accessability and tell someone to pull.
In which case I'd add a remote for their repo and pull into a branch.
Anyway, I'm totally glad you asked because it finally gave me
something
to look up. Brian once asked about bundle, but I had yet to find a
difference :)
Well here's a summary of the differences in commands so far. Let's
assume I've done a clone of the hypothetical git repo and hg repo.
The following commands would be equivalent based on what I found up
here:
Look for incoming changes:
hg in
git fetch && git log [copy and paste in the stuff from the old..new
line]
Look for outgoing changes:
hg out
git fetch && git log origin..
Export a single changeset to be moved elsewhere:
hg export [change]
git log --pretty=raw -n 1 -p [change]
Import an exported changeset:
hg import /some/file
git ??? /some/file
Send changes as individual email patches:
# note: hg requires patchbomb to be enabled in your .hgrc for this
hg email -o
git format-patch origin.. && ??email script?? [0-9]*.patch
Send changes as a single portable patch series:
hg out -p
git fetch origin && git log -p origin..
Send changes as a single bundle:
hg bundle /some/file
git bundle create /some/file origin..
[then send /some/file as an attachment]
Share changes via plain http:
[hg]# rsync -va tree/ server:public_html/tree/
[git]# rsync -va tree/ server:public_html/tree/ && ssh server "??
setup-tree??"
Share changes on a LAN party:
hg serve
git daemon --base-path=$PWD --export-all
This is actually good progress (although perhaps a bad forum).
I've been wanting a git cheat sheet, and this is helping me get it
together.
Of course, when it comes to contributing, I think there will have
to some published recommendations on how to contribute changes.
--
Dustin Sallings
