Upcoming memcached releases + rambling.

[Jeff King]

[I'm not on the list, so please cc me in replies]

On Fri, Feb 08, 2008 at 09:21:16PM -0800, Dustin Sallings wrote:

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

Please, if you have git questions, feel free to ask them on the git list
(which I am cc'ing here).

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

I don't know hg well at all, but I will attempt to translate (please
correct me if I'm wrong on any hg behavior).

"hg serve" runs a web repo browser and a pull server. In git, these
duties are split. Depending on what you want, you can:
  - for allowing people to pull from you, you can use git-daemon
  - for repository browsing, run an instance of gitweb. There is a
    git-instaweb script for doing one-off "I just need to set this up
    for a minute" versions.
  - you can also allow people to pull via http; just copy your '.git'
    directory somewhere that is accessible by the web server
  - you can also allow people to pull via ssh; just give them an ssh
    account and point them to host:/path/to/repo

"hg bundle" has an equivalent in git: "git bundle"

"hg export" seems to generate the commit message + patch for a set of
commits. The git equivalent is "git format-patch" which puts each patch
in its own mbox file (you can also use "git format-patch --stdout >mbox"
to put them all in one mbox.

"hg import" presumably applies the results of "hg export". In git, this
is "git am" (where am stands for apply mailbox), which applies the
changes from an entire mbox one by one.

"incoming" and "outgoing" seem to basically be diffs against remote
repositories (i.e., "what do I have that he doesn't" and vice versa). In
git, you would do a "git fetch" to say "contact the remote repository
and get what he has, but don't update any of my branches" followed by
"git log origin..HEAD" (what does I have that he doesn't) or "git log
HEAD..origin" (the opposite). You can also use the symmetric difference
with a graphical browser like gitk: "gitk origin...HEAD" which will show
everything that he has and everything you have, down to the point where
the two histories last diverged.

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

Again, if you have specific questions, please feel free to ask on the
git list. We are more than happy to help out if we can.

> 	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 don't know hg very well, but my impression is that the implementation
is quite similar to git and that writing a document "translating"
commands from one system to the other would be feasible.

-Peff