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
