Upcoming memcached releases + rambling.

[Dustin Sallings]

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