Upcoming memcached releases + rambling.

[dormando]

Dustin Sallings wrote:
> 
> On Feb 8, 2008, at 20:33, dormando wrote:
> 
>> Half of the committers use git, half use hg, and none of them like SVN!
>> What a pain. I spent an hour earlier reading hg/git comparisons too.
>> It's maddening how little it matters anymore (most reviews were pre-git
>> 1.5, and pre-merc 0.9).
> 
> 
>     I've seen lots of people using git for their own work, but not
> enough using it in a distributed fashion.  I've been asking questions
> about how to collaborate with git, but I can't seem to find any git
> experts who will answer questions.

Omfg, I'm so glad you actually asked questions! :) So far I've just been
reading stuff like "Well they both worked the same, but had some odd
quirks, so we picked (mercurial|git)!"

>     For example, a coworker was working from home today and couldn't get
> his crap cisco vpn working.  Instead, he punched a hole in his firewall
> and typed ``hg serve'' so I could grab work he was doing and send him
> work everyone else was doing.

I bet that's the same as my crap cisco vpn!

> 
>     serve, bundle, export, import, incoming, and outgoing don't seem to
> have equivalences in git.

I'll do this backwards, and just at a glance: I'll read more when I'm
feeling better.

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.

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.

I think my knowledge on how to do this in git is a bit dated, so I'll go
read (I started with git in 0.99 series, where it was missing most of
these fancy "usability features", so sometimes I do things the hard way
still).

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

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

export:

Appears to be git log --pretty=[format] [-p] ?

bundle:

git bundle, same feature. push/pull accept bundles too, it seems.

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

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.

>     I've contributed changes to both git and hg projects and haven't had
> good luck submitting changes upstream.   I'd be interesting in talking
> to people who collaborate on projects using git both as first and
> second-level contributors to see if their experiences are any better
> than mine.  I don't doubt that I may be doing it wrong.

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.

I think a bunch of the ruby folk use git? We should have someone who can
say a word or two about it?

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

-Dormando