Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.python > #77031 > unrolled thread

Re: Python vs C++

Back to article view | Back to comp.lang.python

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Re: Python vs C++ Amirouche Boubekki <amirouche.boubekki@gmail.com> - 2014-08-26 10:12 +0200
    Re: Python vs C++ alex23 <wuwei23@gmail.com> - 2014-08-27 15:43 +1000
      Re: Python vs C++ Ian Kelly <ian.g.kelly@gmail.com> - 2014-08-27 00:23 -0600
      Re: Python vs C++ Ian Kelly <ian.g.kelly@gmail.com> - 2014-08-27 00:33 -0600
      Re: What is acceptable as 'open-source'?  [was Python vs C++] "Frank Millman" <frank@chagford.com> - 2014-08-27 09:50 +0200
        Re: What is acceptable as 'open-source'? Paul Rubin <no.email@nospam.invalid> - 2014-08-27 09:38 -0700
          Re: What is acceptable as 'open-source'? Marko Rauhamaa <marko@pacujo.net> - 2014-08-27 20:14 +0300
            Re: What is acceptable as 'open-source'? Rustom Mody <rustompmody@gmail.com> - 2014-08-27 10:41 -0700
            Re: What is acceptable as 'open-source'? Chris Angelico <rosuav@gmail.com> - 2014-08-28 08:46 +1000
              Re: What is acceptable as 'open-source'? Marko Rauhamaa <marko@pacujo.net> - 2014-08-28 08:31 +0300
                Re: What is acceptable as 'open-source'? Chris Angelico <rosuav@gmail.com> - 2014-08-28 15:44 +1000
        Re: What is acceptable as 'open-source'?  [was Python vs C++] Christian Gollwitzer <auriocus@gmx.de> - 2014-08-27 21:41 +0200
      Re: What is acceptable as 'open-source'? [was Python vs C++] Chris Angelico <rosuav@gmail.com> - 2014-08-27 18:03 +1000
      Re: What is acceptable as 'open-source'?  [was Python vs C++] Ned Batchelder <ned@nedbatchelder.com> - 2014-08-27 07:54 -0400
        Re: What is acceptable as 'open-source'?  [was Python vs C++] Rustom Mody <rustompmody@gmail.com> - 2014-08-27 10:29 -0700
          hg, git, fossil, ... [was Re: What is acceptable as 'open-source'? [was Python vs C++]] Ethan Furman <ethan@stoneleaf.us> - 2014-08-27 11:26 -0700
          Re: hg, git, fossil, ... [was Re: What is acceptable as 'open-source'? [was Python vs C++]] Skip Montanaro <skip@pobox.com> - 2014-08-27 13:51 -0500
            Re: hg, git, fossil, ... Marko Rauhamaa <marko@pacujo.net> - 2014-08-28 08:58 +0300
              Re: hg, git, fossil, ... Tim Chase <python.list@tim.thechases.com> - 2014-08-28 09:56 -0500
              Re: hg, git, fossil, ... Ned Batchelder <ned@nedbatchelder.com> - 2014-08-28 11:39 -0400
                Re: hg, git, fossil, ... Marko Rauhamaa <marko@pacujo.net> - 2014-08-28 19:17 +0300
                  Re: hg, git, fossil, ... Tim Chase <python.list@tim.thechases.com> - 2014-08-28 11:32 -0500
                  Re: hg, git, fossil, ... Chris Angelico <rosuav@gmail.com> - 2014-08-29 02:38 +1000
                    Re: hg, git, fossil, ... Marko Rauhamaa <marko@pacujo.net> - 2014-08-28 22:37 +0300
                      Re: hg, git, fossil, ... Chris Angelico <rosuav@gmail.com> - 2014-08-29 09:08 +1000
                      Re: hg, git, fossil, ... Lele Gaifax <lele@metapensiero.it> - 2014-08-29 09:43 +0200
                        Re: hg, git, fossil, ... Marko Rauhamaa <marko@pacujo.net> - 2014-08-29 10:54 +0300
                  Re: hg, git, fossil, ... Terry Reedy <tjreedy@udel.edu> - 2014-08-28 13:40 -0400
                  Re: hg, git, fossil, ... Tim Delaney <timothy.c.delaney@gmail.com> - 2014-08-29 07:25 +1000
                  Re: hg, git, fossil, ... Mark Lawrence <breamoreboy@yahoo.co.uk> - 2014-08-28 22:41 +0100
                  Re: hg, git, fossil, ... Ian Kelly <ian.g.kelly@gmail.com> - 2014-08-28 20:20 -0600
                    Re: hg, git, fossil, ... Marko Rauhamaa <marko@pacujo.net> - 2014-08-29 08:59 +0300
                      Re: hg, git, fossil, ... Chris Angelico <rosuav@gmail.com> - 2014-08-29 17:20 +1000
                        Re: hg, git, fossil, ... Marko Rauhamaa <marko@pacujo.net> - 2014-08-29 10:48 +0300
                  Re: hg, git, fossil, ... Chris Angelico <rosuav@gmail.com> - 2014-08-29 12:24 +1000
                    Re: hg, git, fossil, ... Rustom Mody <rustompmody@gmail.com> - 2014-08-28 19:53 -0700
              Re: hg, git, fossil, ... Ian Kelly <ian.g.kelly@gmail.com> - 2014-08-28 19:56 -0600
                Re: hg, git, fossil, ... Marko Rauhamaa <marko@pacujo.net> - 2014-08-29 08:50 +0300
                  Re: hg, git, fossil, ... Chris Angelico <rosuav@gmail.com> - 2014-08-29 17:19 +1000
                    Re: hg, git, fossil, ... Marko Rauhamaa <marko@pacujo.net> - 2014-08-29 10:43 +0300
          Re: hg, git, fossil, ... [was Re: What is acceptable as 'open-source'? [was Python vs C++]] Ethan Furman <ethan@stoneleaf.us> - 2014-08-27 11:58 -0700
          Re: hg, git, fossil, ... [was Re: What is acceptable as 'open-source'? [was Python vs C++]] Chris Angelico <rosuav@gmail.com> - 2014-08-28 09:07 +1000
      Re: Python vs C++ Amirouche Boubekki <amirouche.boubekki@gmail.com> - 2014-08-27 15:15 +0200
      Re: What is acceptable as 'open-source'? [was Python vs C++] "Frank Millman" <frank@chagford.com> - 2014-08-28 15:44 +0200
      Re: What is acceptable as 'open-source'? [was Python vs C++] Chris Angelico <rosuav@gmail.com> - 2014-08-28 23:58 +1000

Page 2 of 3 — ← Prev page 1 [2] 3  Next page →

#77220 — Re: hg, git, fossil, ...

Ned Batchelder <ned@nedbatchelder.com>:

> I feel like I am misunderstanding you.  My summary of what you just said
> is, "I have two scenarios where my code went through different sequences
> of changes to end up with the same content.  I expect both of those
> paths will show the same history."  That sounds nonsensical to me, so I
> must be misunderstanding you.  The path the file followed (that is, the
> sequence of changes that made the file what it is), *is* the history of
> the file.

Not the file but the repository.

Imagine we have CPython 3.9. It might have an ancient implementation of
the deque. Then somebody realizes there's an embarrassing bug that
requires a simple fix in a C file. The fix is implemented in HEAD. Then,
it is propagated down to 3.9, 3.8, ... 3.0. You obviously couldn't use
"hg pull" for the propagation since hg would insist on propagating all
the unrelated features as well.

With TeamWare, Bitkeeper(?) and CVS the process is simple since they
retain the file scope. Propagating a fix from HEAD to 3.0 is equivalent
to propagating a fix from 3.0 to HEAD. After the pull/push, if you look
at the version history, you couldn't say which way the process went
since the pull/push operation itself doesn't leave a trace. (Well, in
CVS, it does, but that's bad.)

In large repositories (like CPython), you have independent modules with
relatively independent (and typically linear) histories. Hg and git
don't want to respect that independence.

As I said before, the problem is alleviated or goes away if you split
your large repositories into tiny repositories. Then, looking at the
example above, you could have a collections repository. CPython 3.0 and
3.9 might use the same version of the collections component. The bug
would then be fixed in collections and both CPython 3.0 and 3.9 would
simply update their component dependency to the latest and greatest
collections.


Marko

[toc] | [prev] | [next] | [standalone]

#77222 — Re: hg, git, fossil, ...

On 2014-08-28 19:17, Marko Rauhamaa wrote:
> > I feel like I am misunderstanding you.  My summary of what you
> > just said is, "I have two scenarios where my code went through
> > different sequences of changes to end up with the same content.
> > I expect both of those paths will show the same history."  That
> > sounds nonsensical to me, so I must be misunderstanding you.  The
> > path the file followed (that is, the sequence of changes that
> > made the file what it is), *is* the history of the file.  
> 
> Not the file but the repository.
> 
> Imagine we have CPython 3.9. It might have an ancient
> implementation of the deque. Then somebody realizes there's an
> embarrassing bug that requires a simple fix in a C file. The fix is
> implemented in HEAD. Then, it is propagated down to 3.9, 3.8, ...
> 3.0. You obviously couldn't use "hg pull" for the propagation since
> hg would insist on propagating all the unrelated features as well.

No, you wouldn't use "hg pull" nor "git pull" but rather "git
cherry-pick" or what Mercurial calls "transplant" (I've not used this
in Mercurial, but I believe it's an extension).

That would apply just that patch/diff to the older version rather
than the entire history of changes between 3.{n<9} and 3.9 versions.

-tkc

[toc] | [prev] | [next] | [standalone]

#77223 — Re: hg, git, fossil, ...

On Fri, Aug 29, 2014 at 2:17 AM, Marko Rauhamaa <marko@pacujo.net> wrote:
> Imagine we have CPython 3.9. It might have an ancient implementation of
> the deque. Then somebody realizes there's an embarrassing bug that
> requires a simple fix in a C file. The fix is implemented in HEAD. Then,
> it is propagated down to 3.9, 3.8, ... 3.0. You obviously couldn't use
> "hg pull" for the propagation since hg would insist on propagating all
> the unrelated features as well.

What you're saying, though, is that there's something inherently
special about file boundaries. You want files to be magically
separable within a repo. Why? What's the significance of the file?

In reality, it's highly unlikely that this simple fix is the only
change that's ever occurred to that file, so I very much doubt that
your proposal would even work. With git/hg, the merge is exactly the
same whether there've been changes to other files or changes to other
parts of the same file, because file boundaries just aren't that
special. This is basically a cherry-picking job; I know how to do it
in git (git cherry-pick some_commit_reference), although I'm not sure
the best way in hg - a quick Google search suggests 'hg graft', but at
very worst, all you have to do is export a patch and reimport it.
Chances are it'll apply cleanly even in cases where your proposed
magic wouldn't work.

ChrisA

[toc] | [prev] | [next] | [standalone]

#77228 — Re: hg, git, fossil, ...

Chris Angelico <rosuav@gmail.com>:

> What you're saying, though, is that there's something inherently
> special about file boundaries. You want files to be magically
> separable within a repo. Why? What's the significance of the file?

Files do have that magic property. That's only an approximation, but it
is a very accurate and fitting approximation. Developers have a strong
tendency of collecting functions to files. More to the point,
functionality may be split across multiple files, but a large repository
is far too blunt an abstraction.

As I have mentioned, Darcs tries to get everything right. I haven't used
it, but I have read it sometimes gets entangled in its smart algorithms.

> In reality, it's highly unlikely that this simple fix is the only
> change that's ever occurred to that file, so I very much doubt that
> your proposal would even work.

I have actually found the reverse to be true. Most fixes are very local,
and in large repositories, most files don't experience any change for
over numerous releases.

> With git/hg, the merge is exactly the same whether there've been
> changes to other files or changes to other parts of the same file,
> because file boundaries just aren't that special. This is basically a
> cherry-picking job;

Yes, that's cherry-picking. You also have manual patching and manual
editing. All methods are in use, manual editing in particular. That's
because of the awkward repo-level abstraction.


Marko

[toc] | [prev] | [next] | [standalone]

#77242 — Re: hg, git, fossil, ...

On Fri, Aug 29, 2014 at 5:37 AM, Marko Rauhamaa <marko@pacujo.net> wrote:
> Chris Angelico <rosuav@gmail.com>:
>
>> What you're saying, though, is that there's something inherently
>> special about file boundaries. You want files to be magically
>> separable within a repo. Why? What's the significance of the file?
>
> Files do have that magic property. That's only an approximation, but it
> is a very accurate and fitting approximation. Developers have a strong
> tendency of collecting functions to files. More to the point,
> functionality may be split across multiple files, but a large repository
> is far too blunt an abstraction.

Very frequently I've moved patches around that affect just one
function in one file. There's some granularity at the file level, some
at the function level, some at the class level (if you have that
concept in your repo), etc, etc, etc. You'll find changes that affect
one of any of the above.

>> In reality, it's highly unlikely that this simple fix is the only
>> change that's ever occurred to that file, so I very much doubt that
>> your proposal would even work.
>
> I have actually found the reverse to be true. Most fixes are very local,
> and in large repositories, most files don't experience any change for
> over numerous releases.

You're talking about a file having never changed across nine Python
releases, which happen roughly every year and a half. That's a file
that doesn't change for well over a decade, and now you want to
backport a change across all those releases. Even allowing for some
measure of exaggeration (CPython doesn't release patches for that many
versions), I'm still dubious that there hasn't been any sort of
sweeping change in that much time.

>> With git/hg, the merge is exactly the same whether there've been
>> changes to other files or changes to other parts of the same file,
>> because file boundaries just aren't that special. This is basically a
>> cherry-picking job;
>
> Yes, that's cherry-picking. You also have manual patching and manual
> editing. All methods are in use, manual editing in particular. That's
> because of the awkward repo-level abstraction.

Yes, cherry-picking happens. And in git, it's really easy. Ditto with
'hg graft', I'm sure, although I've never used it so Tim Delaney may
have to confirm that. If the file really hasn't changed, then the
cherry-pick will work.

ChrisA

[toc] | [prev] | [next] | [standalone]

#77262 — Re: hg, git, fossil, ...

Marko Rauhamaa <marko@pacujo.net> writes:

> Chris Angelico <rosuav@gmail.com>:
>
>> What you're saying, though, is that there's something inherently
>> special about file boundaries. You want files to be magically
>> separable within a repo. Why? What's the significance of the file?
>
> Files do have that magic property. That's only an approximation, but it
> is a very accurate and fitting approximation. Developers have a strong
> tendency of collecting functions to files. More to the point,
> functionality may be split across multiple files, but a large repository
> is far too blunt an abstraction.
>
> As I have mentioned, Darcs tries to get everything right. I haven't used
> it, but I have read it sometimes gets entangled in its smart algorithms.

Well, even conceding the file specialty, and more than that acknowledging
the extraordinary beauty of the darcs model, it too considers a patch
spanning several files as an atomic operation.

So, even if it makes very very easy to "cherry-pick" a given changeset,
it still insist in carrying in all the changes it involves: in your
scenario, you'd still need to withdraw the (unwanted) modifications
applied to the other files, recording an additional changeset with the
reverts.

As you cited in a later messages, unlike other systems which focuses in
tracking files *content*, darcs tracks *patches*: files content is
solely determined by the patches collected in the repository they
live. Darcs patch theory "promises" that non-conflicting patches may be
applied in any order (they can be commuted at will), that's what makes
"cherry-picking" a very common/no fuss operation. OTOH, that's also
exactly the main reason (the other is performance...) why Linus
discarded that tool when he looked around for a Bitkeeper replacement.

ciao, lele.
-- 
nickname: Lele Gaifax | Quando vivrò di quello che ho pensato ieri
real: Emanuele Gaifas | comincerò ad aver paura di chi mi copia.
lele@metapensiero.it  |                 -- Fortunato Depero, 1929.

[toc] | [prev] | [next] | [standalone]

#77264 — Re: hg, git, fossil, ...

Lele Gaifax <lele@metapensiero.it>:

> Well, even conceding the file specialty, and more than that acknowledging
> the extraordinary beauty of the darcs model, it too considers a patch
> spanning several files as an atomic operation.

Yes. Darcs wants to get it right.

> So, even if it makes very very easy to "cherry-pick" a given
> changeset, it still insist in carrying in all the changes it involves:
> in your scenario, you'd still need to withdraw the (unwanted)
> modifications applied to the other files, recording an additional
> changeset with the reverts.

Darcs would probably be perfect, conceptually. According to rumors (the
Wikipedia article, for example), that rigor can come with a severe
performance penalty.

So we have two approximations of the Darcs ideal: file-level and
repo-level. The repo-level approximation is over-protective, the
file-level approximation is under-protective. I prefer the slight
under-protection to over-protection. (I guess that's I'm using Python in
the first place.)


Marko

[toc] | [prev] | [next] | [standalone]

#77226 — Re: hg, git, fossil, ...

On 8/28/2014 12:17 PM, Marko Rauhamaa wrote:

> Imagine we have CPython 3.9. It might have an ancient implementation of
> the deque. Then somebody realizes there's an embarrassing bug that
> requires a simple fix in a C file. The fix is implemented in HEAD. Then,
> it is propagated down to 3.9, 3.8, ... 3.0.

For CPython and mecurial, that is the wrong direction. We start with the 
earliest branch and merge forward. Security fixes start with 3.2, bug 
fixes with 3.4.

> You obviously couldn't use "hg pull" for the propagation

One uses hg merge to merge, so this does not make sense.

 > since hg would insist on propagating all
> the unrelated features as well.

Once a patch has been pushed, others pull it. So one does use hg pull 
for propagation in that sense. For each branch, one gets the patches 
that have been applied to the branch, as one should. It is our intention 
that each changeset, whether applied to one or many files, leaves the 
repository in a coherent state.

-- 
Terry Jan Reedy

[toc] | [prev] | [next] | [standalone]

#77238 — Re: hg, git, fossil, ...

[Multipart message — attachments visible in raw view] — view raw

On 29 August 2014 02:32, Tim Chase <python.list@tim.thechases.com> wrote:

>
> No, you wouldn't use "hg pull" nor "git pull" but rather "git
> cherry-pick" or what Mercurial calls "transplant" (I've not used this
> in Mercurial, but I believe it's an extension).
>

hg transplant has been deprecated for a long time now. The correct command
for cherry-picking is hg graft.

I do sometimes miss the ability to easily cherry-pick the changes in a
single file. When grafting, you graft the entire revision, and then need to
revert individual files and amend the changeset if you don't want the graft
as-is. It's a bit messy, and could cause problems if you later do a merge
that includes the originally-grafted changeset on top of the amended
changeset (since the changes committed to the amended changeset will be
considered during the merge).

Tim Delaney

[toc] | [prev] | [next] | [standalone]

#77240 — Re: hg, git, fossil, ...

On 28/08/2014 22:25, Tim Delaney wrote:
> On 29 August 2014 02:32, Tim Chase <python.list@tim.thechases.com
> <mailto:python.list@tim.thechases.com>> wrote:
>
>
>     No, you wouldn't use "hg pull" nor "git pull" but rather "git
>     cherry-pick" or what Mercurial calls "transplant" (I've not used this
>     in Mercurial, but I believe it's an extension).
>
> hg transplant has been deprecated for a long time now. The correct
> command for cherry-picking is hg graft.
>
> I do sometimes miss the ability to easily cherry-pick the changes in a
> single file. When grafting, you graft the entire revision, and then need
> to revert individual files and amend the changeset if you don't want the
> graft as-is. It's a bit messy, and could cause problems if you later do
> a merge that includes the originally-grafted changeset on top of the
> amended changeset (since the changes committed to the amended changeset
> will be considered during the merge).
>
> Tim Delaney
>

Surely a lot of the hassle with version control systems could be avoided 
if people were to write bug free code in the first place? :)

-- 
My fellow Pythonistas, ask not what our language can do for you, ask
what you can do for our language.

Mark Lawrence

[toc] | [prev] | [next] | [standalone]

#77248 — Re: hg, git, fossil, ...

On Thu, Aug 28, 2014 at 10:17 AM, Marko Rauhamaa <marko@pacujo.net> wrote:
> In large repositories (like CPython), you have independent modules with
> relatively independent (and typically linear) histories. Hg and git
> don't want to respect that independence.
>
> As I said before, the problem is alleviated or goes away if you split
> your large repositories into tiny repositories. Then, looking at the
> example above, you could have a collections repository. CPython 3.0 and
> 3.9 might use the same version of the collections component. The bug
> would then be fixed in collections and both CPython 3.0 and 3.9 would
> simply update their component dependency to the latest and greatest
> collections.

So then to tag or branch a release I guess you would create the same
tag/branch on every single component subrepository?  And when you need
to checkout that old version you checkout every subrepository
independently. Sounds painful, but not unworkable.

But then what do you do if you need to checkout an intermediate
revision of the project that isn't tagged? This need does arise. You
can't just checkout the revision you want of a particular component,
because that old revision of that component may not be compatible with
the other components at HEAD. Even if it is, you're still checking out
a version of the repository that never actually existed. You can't
expect to reproduce behavior at a particular revision if you can't
even consistently recreate the revision.

[toc] | [prev] | [next] | [standalone]

#77257 — Re: hg, git, fossil, ...

Ian Kelly <ian.g.kelly@gmail.com>:

> So then to tag or branch a release I guess you would create the same
> tag/branch on every single component subrepository? And when you need
> to checkout that old version you checkout every subrepository
> independently. Sounds painful, but not unworkable.

Where I work, we actually have "made a science" out of componentization.
The individual components are very similar to linux's development
packages. They are released internally and have their own life cycles.
In particular, they are not rebuilt when the dependent application is
built.

> that old revision of that component may not be compatible with the
> other components at HEAD.

You don't alter ABIs. Component versioning and interdependencies are
managed rigorously. Even ABI breakages could be handled should they
arise.

> Even if it is, you're still checking out a version of the repository
> that never actually existed. You can't expect to reproduce behavior at
> a particular revision if you can't even consistently recreate the
> revision.

Generally, components only go forward linearly. If your ancient
application version needs a fresh bug fix in a component, it gets the
latest and greatest component version. Branching is supported but has
yet to be needed.


Marko

[toc] | [prev] | [next] | [standalone]

#77260 — Re: hg, git, fossil, ...

On Fri, Aug 29, 2014 at 3:59 PM, Marko Rauhamaa <marko@pacujo.net> wrote:
> Where I work, we actually have "made a science" out of componentization.
> The individual components are very similar to linux's development
> packages. They are released internally and have their own life cycles.
> In particular, they are not rebuilt when the dependent application is
> built.

Then they're fundamentally separate, and they belong in separate
repos. Do you actually enforce that one file == one component
everywhere?

ChrisA

[toc] | [prev] | [next] | [standalone]

#77263 — Re: hg, git, fossil, ...

Chris Angelico <rosuav@gmail.com>:

> On Fri, Aug 29, 2014 at 3:59 PM, Marko Rauhamaa <marko@pacujo.net> wrote:
> Then they're fundamentally separate, and they belong in separate
> repos. Do you actually enforce that one file == one component
> everywhere?

No, not quite. One-file components exist, but the typical component is
smallish.

Point is, there has never been parallel development on any of the
components so git hasn't created any issues.


Marko

[toc] | [prev] | [next] | [standalone]

#77249 — Re: hg, git, fossil, ...

On Fri, Aug 29, 2014 at 12:20 PM, Ian Kelly <ian.g.kelly@gmail.com> wrote:
> But then what do you do if you need to checkout an intermediate
> revision of the project that isn't tagged? This need does arise. You
> can't just checkout the revision you want of a particular component,
> because that old revision of that component may not be compatible with
> the other components at HEAD. Even if it is, you're still checking out
> a version of the repository that never actually existed. You can't
> expect to reproduce behavior at a particular revision if you can't
> even consistently recreate the revision.

See, that's where he and we fundamentally disagree. My view, your
view, git's view, and hg's view, is that all files in a repo are
intrinsically linked - that "checking out an intermediate revision"
means checking out that revision across the entire source tree.
Marko's view is that you check out an intermediate revision of the one
failing file. In my experience, you can't always say which is the
failing file, and even if you can, you can't just check out an old
version of that file and expect it to work with the new versions of
everything else, because there WILL be parallel changes - and lots of
them.

ChrisA

[toc] | [prev] | [next] | [standalone]

#77251 — Re: hg, git, fossil, ...

On Friday, August 29, 2014 7:54:44 AM UTC+5:30, Chris Angelico wrote:
> On Fri, Aug 29, 2014 at 12:20 PM, Ian Kelly wrote:
> > But then what do you do if you need to checkout an intermediate
> > revision of the project that isn't tagged? This need does arise. You
> > can't just checkout the revision you want of a particular component,
> > because that old revision of that component may not be compatible with
> > the other components at HEAD. Even if it is, you're still checking out
> > a version of the repository that never actually existed. You can't
> > expect to reproduce behavior at a particular revision if you can't
> > even consistently recreate the revision.

> See, that's where he and we fundamentally disagree. My view, your
> view, git's view, and hg's view, is that all files in a repo are
> intrinsically linked - that "checking out an intermediate revision"
> means checking out that revision across the entire source tree.
> Marko's view is that you check out an intermediate revision of the one
> failing file. In my experience, you can't always say which is the
> failing file, and even if you can, you can't just check out an old
> version of that file and expect it to work with the new versions of
> everything else, because there WILL be parallel changes - and lots of
> them.

There is a basic dogma in git-land that there are 2 gits: git-porcelain
and git git-plumbing.  Since most people use the porcelain exclusively that
gets identified as git.  But that is not the case. Here is Linus on the intention of git as a (non-hierarchical) filesystem:

Linus Torvalds said:
| you can just see git as a filesystem - it's content-
| addressable, and it has a notion of versioning, but I really really
| designed it coming at the problem from the viewpoint of a _filesystem_
| person (hey, kernels is what I do), and I actually have absolutely _zero_
| interest in creating a traditional SCM system.

from http://marc.info/?l=linux-kernel&m=111314792424707



Other instances of git-as-a-filesystem:


Using git plumbing for a backup system:

https://github.com/bup/bup

What Marko wants: 
http://git.661346.n2.nabble.com/RFC-Zit-the-git-based-single-file-content-tracker-td1366498.html

Other attempts (all failed so far) at moving beyond the 40-year old hierarchical paths
http://www.theguardian.com/technology/2006/jun/29/insideit.guardianweeklytechnologysection

[toc] | [prev] | [next] | [standalone]

#77247 — Re: hg, git, fossil, ...

On Wed, Aug 27, 2014 at 11:58 PM, Marko Rauhamaa <marko@pacujo.net> wrote:
> I don't think a working VC system needs to contain much more than that.
> Hg stays closer to the simple ideal than git, which really fails at
> being a black box. I don't see why git has staging or branches, for
> example.

I use short-lived development branches in git all the time. Start
working on a bug or feature, checkout a new branch specifically for
that work. Make changes, commit, make changes, commit, make changes,
commit, finish the feature, merge back into master. Once the branch is
merged back in, I just delete it. If something else comes up that I
need to work on while I'm on a feature branch, I can easily just do a
checkpoint commit and create a clean new branch from master to work
on. I never do any actual development work on master.

I find staging less useful, but it occasionally comes in handy when
I'm ready to commit some work but there are these other files I've
already changed that should really be part of the next commit.

> Or why can't I revert my changes to a file easily?

"git checkout <filename>" is not easy?

> The main problem with hg (and git) is the way cherrypicking is done.
>
> See these graphics:
>
>  [1]   Product-Ver1
>             |
>             | bugfix
>             |
>             V          feature development
>        Product-Ver1' ----------------------> Product-Ver2'
>
>                        feature development
>  [2]   Product-Ver1 -----------------------> Product-Ver2
>                                                   |
>                                                   | bugfix
>                                                   |
>                            cherry-picking         V
>        Product-Ver1' <---------------------- Product-Ver2'
>
>
> My beef is this: The starting point and end result of [1] and [2] is
> identical. The version histories of Product-Ver1' and Product-Ver2'
> should usually also be identical. In hg and git, they are not. In CVS,
> they are not. In SVN, they are not.

Why should they be identical? If they are, then that means they're not
accurately reporting the actual history of the repository. I don't
understand why you would even want this.

[toc] | [prev] | [next] | [standalone]

#77256 — Re: hg, git, fossil, ...

Ian Kelly <ian.g.kelly@gmail.com>:

> On Wed, Aug 27, 2014 at 11:58 PM, Marko Rauhamaa <marko@pacujo.net> wrote:
>> I don't see why git has staging or branches, for example.
>
> I use short-lived development branches in git all the time. Start
> working on a bug or feature, checkout a new branch specifically for
> that work.

I do the same thing, but I use forks ("git clone"). Branches and forks
are conceptually almost identical, so why pollute your concept set with
extras?

>> Or why can't I revert my changes to a file easily?
>
> "git checkout <filename>" is not easy?

Unfortunately, that's only half the story. If you have added but never
committed the file, the command is:

   git rm --cached <filename>

I've been in more complicated situations as well.

> Why should they be identical? If they are, then that means they're not
> accurately reporting the actual history of the repository. I don't
> understand why you would even want this.

I don't think the repository should have one, linear narrative. Rather a
large repository has numerous independent narratives.

To quote <URL: http://en.wikipedia.org/wiki/Darcs>:

   Darcs treats patches as first-class citizens. For the user, a
   repository can be seen as a set of patches, where each patch is not
   necessarily ordered with respect to other patches i.e. the set of
   patches is only a partially ordered set. In many cases patches can be
   independently transmitted between various repositories.

   Many branching, merging and cherry-picking operations that would
   require additional commands with snapshot-based systems like Git or
   Mercurial, can be directly done with Darcs with the usual ‘pull’ and
   ‘push’ commands.

   [...]

   Intuitively, a patch B depends on another patch A if A provides the
   content that B modifies. This means that patches that modify
   different parts of the code are considered, by default, independent.


Say you make a change to CPython's GC and I make a parallel change to the
deque implementation:

   common repo ---------------------------------------------------->
        \                                  /          /conflict!
        |\    GC work                     /          /
        | +------------------------------+          /
         \                                         /
          \   deque work                          /
           +-------------------------------------+

Hg and git report a conflict and force me to "merge," IOW, decide which
change comes earlier in the linear history.

A conflict and merge should be rare and hint at development process
problems. In hg and git, they are unavoidable, everyday occurrences. To
put it bluntly, hg and git do not support parallel development.


Marko

[toc] | [prev] | [next] | [standalone]

#77259 — Re: hg, git, fossil, ...

On Fri, Aug 29, 2014 at 3:50 PM, Marko Rauhamaa <marko@pacujo.net> wrote:
> Ian Kelly <ian.g.kelly@gmail.com>:
>
>> On Wed, Aug 27, 2014 at 11:58 PM, Marko Rauhamaa <marko@pacujo.net> wrote:
>>> I don't see why git has staging or branches, for example.
>>
>> I use short-lived development branches in git all the time. Start
>> working on a bug or feature, checkout a new branch specifically for
>> that work.
>
> I do the same thing, but I use forks ("git clone"). Branches and forks
> are conceptually almost identical, so why pollute your concept set with
> extras?

Why fork the repo when you can just branch? That makes no sense.
Nothing's being "polluted" here. Your comment is like pointing out
that separate text files can store documentation, so why have
docstrings and comments?

>>> Or why can't I revert my changes to a file easily?
>>
>> "git checkout <filename>" is not easy?
>
> Unfortunately, that's only half the story. If you have added but never
> committed the file, the command is:
>
>    git rm --cached <filename>
>
> I've been in more complicated situations as well.

So? What you're saying is that the staging area has its own set of
manipulation commands. If git didn't have the staging area, you
wouldn't need those commands. Fine. You can argue that you don't make
use of that particular functionality of git, but it's there, so you
have to cope with it. One easy way is to never "git add" new files
without immediately committing... then it's like lots of other source
control systems.

>> Why should they be identical? If they are, then that means they're not
>> accurately reporting the actual history of the repository. I don't
>> understand why you would even want this.
>
> I don't think the repository should have one, linear narrative. Rather a
> large repository has numerous independent narratives.
>
> To quote <URL: http://en.wikipedia.org/wiki/Darcs>:
>
>    Darcs treats patches as first-class citizens. For the user, a
>    repository can be seen as a set of patches, where each patch is not
>    necessarily ordered with respect to other patches i.e. the set of
>    patches is only a partially ordered set. In many cases patches can be
>    independently transmitted between various repositories.
>
>    Many branching, merging and cherry-picking operations that would
>    require additional commands with snapshot-based systems like Git or
>    Mercurial, can be directly done with Darcs with the usual ‘pull’ and
>    ‘push’ commands.
>
>    [...]
>
>    Intuitively, a patch B depends on another patch A if A provides the
>    content that B modifies. This means that patches that modify
>    different parts of the code are considered, by default, independent.
>
>
> Say you make a change to CPython's GC and I make a parallel change to the
> deque implementation:
>
>    common repo ---------------------------------------------------->
>         \                                  /          /conflict!
>         |\    GC work                     /          /
>         | +------------------------------+          /
>          \                                         /
>           \   deque work                          /
>            +-------------------------------------+
>
> Hg and git report a conflict and force me to "merge," IOW, decide which
> change comes earlier in the linear history.
>
> A conflict and merge should be rare and hint at development process
> problems. In hg and git, they are unavoidable, everyday occurrences. To
> put it bluntly, hg and git do not support parallel development.

You completely misuse "conflict", then. This is not a conflict. This
is just a merge. In git, merging *is* an everyday occurrence, and it's
not a problem at all. That's an intrinsic part of the philosophy.
Branching/merging is the normal way to do *everything*. Even if you
think you're not, you probably are. A merge conflict happens when
there's edits to the same or very nearby lines of code, but otherwise,
that's not a conflict at all. And git doesn't force you to choose
which comes earlier in a linear history - the normal merge says "those
two branches start from a common parent, and now have a common child".
That's not linear history at all. Of course, some repos choose to
favour rebasing over merging. I've done plenty of that; where it's a
source code policy to minimize merging - but that's not git's or hg's
rule.

Why are you so dead against merges?

ChrisA

[toc] | [prev] | [next] | [standalone]

#77261 — Re: hg, git, fossil, ...

Chris Angelico <rosuav@gmail.com>:

> Why fork the repo when you can just branch? That makes no sense.

Why branch when you can just fork? That makes no sense.

I see branches as conceptual clutter.

> One easy way is to never "git add" new files without immediately
> committing...

My original statement was there was no simple command to revert your
changes.

> then it's like lots of other source control systems.

Well, gladly, emacs's VC mode makes it look like lots of other VC
systems.

> You completely misuse "conflict", then. This is not a conflict. This
> is just a merge.

It is not a simple "git push," that's for sure. In linear development,
you can repeatedly do "git push", but if anybody has touched anything in
the meantime, you'll be blocked from doing that. The classic term for
the situation is a conflict. And the classic conflict resolution is
called a merge, which can be automatic or manual.

What I'm saying is that "git push" should almost always simply succeed,
and where there is an issue, of course you merge carefully, but you also
review your development discipline.


Marko

[toc] | [prev] | [next] | [standalone]

Page 2 of 3 — ← Prev page 1 [2] 3  Next page →

Back to top | Article view | comp.lang.python

csiph-web