Upcoming memcached releases + rambling.

[dormando]

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

(I'm on 1.5.4 as of this week... although the differences shouldn't be
huge).
That's what I get for spewing things off the top of my head :)
git log --since="two months ago"
... shows the last two months of changes.
git log v2.6.24..origin
... shows the changes since v2.6.24 of the kernel (I'm testing this
against my linux-2.6 checkout).
git log v2.6.24..origin Documentation/
... shows changes in documentation since the v2.6.24 tag (if you've
fetched or merged origin since).

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

I've never thought to try showing changeset differences without pulling
first. Habitually I'll pull into a branch then git log or git diff
between that and master. Not saying it's not possible, but I've never
"had" to do it. Can't find any commands to do it wither.

(this probably isn't exact syntax, but):
git pull newbranch http://path/to/git/repo#branch
... used to work okay.
Adding remotes is also easy:
git remote add dsal http://path/to/dsal.git
git fetch dsal
git branch -r
[... displays your branches...]
git pull . dsal/updates
[... merges your updates into master, prepping for rel or whatever...]

Then it's just `git fetch dsal` to track the changes. git log, git diff
work directly against the remotes, and `git pull localrepo
dsal/whatever` gives you a local branch to toy with if necessary.

>     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'm not a master with format-patch yet. I get the feeling it only really
works well if you're rebasing properly  Tricky but there's flow to it. I
got all jazzed up to use git-am to apply the outstanding memcached
patches, but:

Applying bin-incr patch
error: doc/binary-protocol-plan-v2.xml: does not exist in index
error: memcached.c: does not exist in index
error: memcached.h: does not exist in index
Patch failed at 0001.
When you have resolved this problem run "git-am --resolved".
If you would prefer to skip this patch, instead run "git-am --skip".

... obviously this paths thing sucks. Hachi has ideas on how to clean up
the branch and tag layout to be proper descendents of what we want. But
it's boring work. If fixed though, it could be very fast work :)

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

That works.

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

See above :\ Haven't found a 'patch -p2'-alike that would make git-am
not barf on the paths yet.

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

I made this sound harder than it is. It's just three commands, but
sometimes I wrap it with a script:
http://www.kernel.org/pub/software/scm/git/docs/user-manual.html#exporting-via-http
... replace the 'mv' with 'rsync' and it's an insta-clone from my laptop
to my git repo tree at consoleninja.net.

Also: http://www.kernel.org/pub/software/scm/git/docs/git-instaweb.html
Just found this, but haven't tried it yet :) Assumes lighttpd, apache,
or webrick exists (since libc doesn't come with an httpd yet).

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

Heh :) So push works, it's just a little more confusing (have to do a
merge to update your working tree afterwards).

>     That's good.  I'm sure I just haven't learned it enough yet.  You
> may provide me with an opportunity to do so.  :)

Updating my own git knowledge is pretty fun too :)

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

github.com is from some ruby folks. I think rubinius uses git too? At
least a few of the folks I know work out of an svn repo using git-svn
the way I've been for danga.

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

Thankfully that's pretty easy. We could whip up a 'get your shit going'
with just 4-5 commands, and some gentle introductions to branching
otherwise.

>     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:

These are impressively short for the common operations! I think if you
change the workflow a little git would compress down a smidge more (and
have to figure out one or two more of these missing commands?) but it
won't be nearly as terse as hg.

An issue either way will be cleaning up the tags/branches so the trees
can actually be fixed (I say trees since this'll have to happen for the
other danga projects too, but that's now entirely off topic). Since
'server' isn't actually the root of the tree. We should have four
different repos for memcached instead of the one. Then branches would
make more sense and `git-am` would probably work.

This is probably all easier than I'm making it sound. Sorry, sometimes I
overcomplicate process :) I'm still learning.

-Dormando