From: Randal L. Schwartz <hidden> Date: 2016-06-15 22:53:42
quoted
quoted
quoted
quoted
"Rich" == Rich Pixley [off-list ref] writes:
Rich> I think we have different definitions of "easily". This is
Rich> simple, first use sorts of stuff.
Have you read the Pro Git book?
Have you read the gitcore-tutorial page?
Have you read the gitworkflows manpage?
The processes for "simple, first use" sorts of stuff never gets into
the complexity you are describing. You're definitely into more advanced
stuff and then complain when you also need to be more advanced to set it
up. Not sure what your goal is, then.
--
Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095
[off-list ref] <URL:http://www.stonehenge.com/merlyn/>
Smalltalk/Perl/Unix consulting, Technical writing, Comedy, etc. etc.
See http://methodsandmessages.posterous.com/ for Smalltalk discussion
Rich> I think we have different definitions of "easily". This is
Rich> simple, first use sorts of stuff.
Have you read the Pro Git book?
Yes. The things it covers, it mostly covers well. But it's lacking a lot.
There's nothing in it about repository networks, how to get stuff out of
my index, reset, and it's not very good about explaining that things
like rebase screw up your repository in ways that make sharing
impossible. I know that because of how mercurial works and from reverse
engineering what must be required, not from reading git doc.
And I've spent close to a week now trying to use git on this project,
throwing away repositories, patching by hand, and trying to sort out why
git was refusing to push for me. That wasn't explained at all nor do
the git error messages explain what's happening.
Have you read the gitcore-tutorial page?
Not recently. It was pretty much impenetrable the first few times
through. I was looking for how to use git, I wasn't interested in all
of the gory details of how it stored everything.
Just skimmed again. Will need to read it again more thoroughly, though
I don't see anything on the stuff we've been discussing.
Have you read the gitworkflows manpage?
Yes, but not in a long time. It seems to be more about the policies of
working on git source code than about usage of git.
The processes for "simple, first use" sorts of stuff never gets into
the complexity you are describing. You're definitely into more advanced
stuff and then complain when you also need to be more advanced to set it
up. Not sure what your goal is, then.
This stuff isn't advanced anymore. It's kind of standard. My complaint
is that doing standard stuff like this shouldn't require advanced work.
I have days, weeks into git learning curve so far, I've clearly only
begun, and I have a big list of things I still can't do in git, though I
can do them in other source code control systems. In contrast, I was up
and using mercurial in about a day and a half, including all of the
stuff we've discussed, and all of the things I've even read about in
git. Learning mq's only took about 20 minutes.
--rich
From: Michael Witten <hidden> Date: 2016-06-15 22:53:42
On Tue, May 1, 2012 at 9:57 PM, Rich Pixley [off-list ref] wrote:
In contrast, I was up and using mercurial in about a day and a half,
including all of the stuff we've discussed, and all of the things I've even
read about in git. Learning mq's only took about 20 minutes.
Fortunately, git is based on extremely simple principles.
Unfortunately, git grew out of really bright people hacking stuff
together in order to get sh!t dun; the result is not approachably or
even well documented, the UI is sometimes a bit of a kludge, the API
is probably nonexistent, and the terminology is so loosely thrown
about that it's easy to forget which way is up in discussions.
(Note, though, that Junio has done a laudable job of keeping the
whole experiment going strong).
Having recognized these deficiencies, I suggest that you provide
at least one tiny little use case that doesn't work as you'd
like; it should be in the form of a command line example that we
can all reproduce and discuss precisely.
On Tue, May 1, 2012 at 9:57 PM, Rich Pixley [off-list ref] wrote:
quoted
In contrast, I was up and using mercurial in about a day and a half,
including all of the stuff we've discussed, and all of the things I've
even
read about in git. Learning mq's only took about 20 minutes.
Fortunately, git is based on extremely simple principles.
Unfortunately, git grew out of really bright people hacking stuff
together in order to get sh!t dun; the result is not approachably or
even well documented, the UI is sometimes a bit of a kludge, the API
is probably nonexistent, and the terminology is so loosely thrown
about that it's easy to forget which way is up in discussions.
(Note, though, that Junio has done a laudable job of keeping the
whole experiment going strong).
Having recognized these deficiencies, I suggest that you provide
at least one tiny little use case that doesn't work as you'd
like; it should be in the form of a command line example that we
can all reproduce and discuss precisely.
--
A bit of browsing found
http://stevelosh.com/blog/2009/08/a-guide-to-branching-in-mercurial/ which
helped with some of the confusion about the different meanings of "branch".
It looks like an Hg branch is a Git clone. Git can be hard work until one
'gets' how and why the new DVCS approach works. Plus learing the UI.
It is very hard to change one's mindset about how/why/when the old VCS
approach broke (or isn't). The common VCS approach is based on drawing
office practices from before the Titanic was built. It is only very recently
that the reproduction and verification cost for data duplication have
dropped sufficiently that a DVCS is the better approach. The historical
approach was to protect the single 'master' item (with lots of admin &
process). Now it's about 'status accounting' - do I have the right copy at
the right status - i.e. the declared master sha1.
Philip
A bit of browsing found
http://stevelosh.com/blog/2009/08/a-guide-to-branching-in-mercurial/
which helped with some of the confusion about the different meanings
of "branch". It looks like an Hg branch is a Git clone. Git can be
hard work until one 'gets' how and why the new DVCS approach works.
Plus learing the UI.
Aha, now this thread finally makes some sense. So when Rich
wants a "branch" with several tips, he actually wants several
Git clones (repositories) with the same Git branch checked out -
and some of them with local commits to it.
And these commits can be shared as remote branches between the
clones, which in Hg-speak means that in one particular clone,
Git will "bookmark" the other clones' tips.
--
Hallvard
A bit of browsing found
http://stevelosh.com/blog/2009/08/a-guide-to-branching-in-mercurial/
which helped with some of the confusion about the different meanings
of "branch". It looks like an Hg branch is a Git clone. Git can be
hard work until one 'gets' how and why the new DVCS approach works.
Plus learing the UI.
Aha, now this thread finally makes some sense. So when Rich
wants a "branch" with several tips, he actually wants several
Git clones (repositories) with the same Git branch checked out -
and some of them with local commits to it.
Yes.
And these commits can be shared as remote branches between the
clones, which in Hg-speak means that in one particular clone,
Git will "bookmark" the other clones' tips.
Well, no. In hg, these are all managed. So there's no scaling issue.
They can all push/pull together, since they are really all just one
shared branch. Adding a new repository to the mix is trivial. And
either pushes or pulls can be used, or any combo.
With git, I must manually make space for each and every repository,
manually track which set of changes are where, manually track which need
to be merged, and manually track which repositories are looking at which
git branches so that they don't collide, or only collide in the current
repository and only when I'm prepared to merge them.
(The bookmark solution appears to be what hg-git uses. Hg-git is an hg
extension to allow push/pull/clone from git repositories using hg.
Unfortunately, it doesn't translate git submodules into hg
subrepositories - yet.)
--rich
On Tue, May 1, 2012 at 9:57 PM, Rich Pixley[off-list ref] wrote:
quoted
In contrast, I was up and using mercurial in about a day and a half,
including all of the stuff we've discussed, and all of the things I've even
read about in git. Learning mq's only took about 20 minutes.
Fortunately, git is based on extremely simple principles.
Unfortunately, git grew out of really bright people hacking stuff
together in order to get sh!t dun; the result is not approachably or
even well documented, the UI is sometimes a bit of a kludge, the API
is probably nonexistent, and the terminology is so loosely thrown
about that it's easy to forget which way is up in discussions.
(Note, though, that Junio has done a laudable job of keeping the
whole experiment going strong).
Thank you for acknowledging that.
Having recognized these deficiencies, I suggest that you provide
at least one tiny little use case that doesn't work as you'd
like; it should be in the form of a command line example that we
can all reproduce and discuss precisely.
I think I already have. And you've given me an approach that is largely
functional in git. It's not wonderful, but it's mostly functional.
I'll post my comparison elsepost.
--rich
On Thu, 03 May 2012 11:20:56 -0700, Rich Pixley [off-list ref]
wrote:
On 5/3/12 09:08 , Hallvard Breien Furuseth wrote:
quoted
Aha, now this thread finally makes some sense. So when Rich
wants a "branch" with several tips, he actually wants several
Git clones (repositories) with the same Git branch checked out -
and some of them with local commits to it.
Yes.
quoted
And these commits can be shared as remote branches between the
clones, which in Hg-speak means that in one particular clone,
Git will "bookmark" the other clones' tips.
Well, no. In hg, these are all managed. So there's no scaling
issue. They can all push/pull together, since they are really all
just one shared branch. Adding a new repository to the mix is
trivial. And either pushes or pulls can be used, or any combo.
With git, I must manually make space for each and every repository,
manually track which set of changes are where, manually track which
need to be merged, and manually track which repositories are looking
at which git branches so that they don't collide, or only collide in
the current repository and only when I'm prepared to merge them.
(...)
If you say so. I don't know Hg and I'm not about to try to guess
if you're stuck in another misconception about Git or not, nor
to re-read this entire thread substituting "clone" for "branch".
Anyway, I notice you're now giving practical Hg examples to go
with your Hg vocabulary instead talking Git in Hg vocabulary, so
hopefully this'll get cleared up.
Anyway, if you have not done so already: If you show this too with
a practical Hg example instead of talking Git in a Hg vocabulary,
maybe someone can help.
--
Hallvard
From: Felipe Contreras <hidden> Date: 2016-06-15 22:53:44
On Wed, May 2, 2012 at 12:56 AM, Michael Witten [off-list ref] wrote:
On Tue, May 1, 2012 at 9:57 PM, Rich Pixley [off-list ref] wrote:
quoted
In contrast, I was up and using mercurial in about a day and a half,
including all of the stuff we've discussed, and all of the things I've even
read about in git. Learning mq's only took about 20 minutes.
Fortunately, git is based on extremely simple principles.
Unfortunately, git grew out of really bright people hacking stuff
together in order to get sh!t dun; the result is not approachably or
even well documented, the UI is sometimes a bit of a kludge, the API
is probably nonexistent, and the terminology is so loosely thrown
about that it's easy to forget which way is up in discussions.
(Note, though, that Junio has done a laudable job of keeping the
whole experiment going strong).
You are a prime example of this experiment called 'life', also based
on extremely simple principles, mostly through trial and error. Design
is overrated :)
--
Felipe Contreras
From: Michael Witten <hidden> Date: 2016-06-15 22:53:44
On Fri, May 4, 2012 at 7:30 PM, Felipe Contreras
[off-list ref] wrote:
On Wed, May 2, 2012 at 12:56 AM, Michael Witten [off-list ref] wrote:
quoted
On Tue, May 1, 2012 at 9:57 PM, Rich Pixley [off-list ref] wrote:
quoted
In contrast, I was up and using mercurial in about a day and a half,
including all of the stuff we've discussed, and all of the things I've even
read about in git. Learning mq's only took about 20 minutes.
Fortunately, git is based on extremely simple principles.
Unfortunately, git grew out of really bright people hacking stuff
together in order to get sh!t dun; the result is not approachably or
even well documented, the UI is sometimes a bit of a kludge, the API
is probably nonexistent, and the terminology is so loosely thrown
about that it's easy to forget which way is up in discussions.
(Note, though, that Junio has done a laudable job of keeping the
whole experiment going strong).
You are a prime example of this experiment called 'life', also based
on extremely simple principles, mostly through trial and error. Design
is overrated :)
There is no process other than trial and error, or more precisely,
variation and selection.
Note, though, that the levels of sophistication involved with variation
and selection differ among manifestations of this process.