Upcoming memcached releases + rambling.

[Chris Goffinet]

Interesting debate, I've seen both camps lately. I am +1 on Dustin  
about hg though. For me, it was the Mac bundle for Textmate where I do  
all my development from that sold me. I enjoy python and after the  
things Dustin's personally showed me and his advocation, I never  
wanted to move away. I personally felt like hg just did things  
*right*. I didn't have to think, I could go back to coding instead of  
looking up some function like the --log-format or finding plugins that  
could do something like serve. In the end I don't care what we use, as  
long as its distributed and doesn't slow down patches. Thanks dormando  
for taking the time to try to get this started and moved away from SVN.

If you need any help with anything, I'd be happy to oblige.


-- 
Chris Goffinet
MyBlogLog Engineer
Yahoo!
San Francisco, CA
United States

On Feb 9, 2008, at 12:28 AM, dormando wrote:

> 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