Path: csiph.com!v102.xanadu-bbs.net!xanadu-bbs.net!goblin2!goblin.stu.neva.ru!newsfeed.xs4all.nl!newsfeed1a.news.xs4all.nl!xs4all!newsgate.cistron.nl!newsgate.news.xs4all.nl!post.news.xs4all.nl!not-for-mail
MIME-Version: 1.0
In-Reply-To: <87tx4xw3ye.fsf@elektro.pacujo.net>
References: <CAKUKWzmnnrpm-9SVNAFu3G9vYf2w0ewAhnGeOge8B2NsDujamQ@mail.gmail.com> <CAL7_Mo_YOJZnHAAhHEb=CV3_QNwOm1hDGHrjZ94TVHKow-OWSg@mail.gmail.com> <CALwzid=1-VAvwW8kgjwx6w1wkF2cmcQjVUG676Ta5QEjHLKUHw@mail.gmail.com> <mailman.13445.1409041203.18130.python-list@python.org> <ltjr5j$q4o$1@dont-email.me> <CALwzidkRO_hrYamwXBk0go-w1OJ6Ty6mYB_c5vHXB6okGOLg6g@mail.gmail.com> <ltk2ko$ble$1@ger.gmane.org> <mailman.13503.1409140498.18130.python-list@python.org> <57afe6cf-7cc4-4334-9f21-fdb8a6e70f30@googlegroups.com> <53FE22C7.3090806@stoneleaf.us> <mailman.13519.1409165474.18130.python-list@python.org> <87tx4xw3ye.fsf@elektro.pacujo.net>
From: Ian Kelly <ian.g.kelly@gmail.com>
Date: Thu, 28 Aug 2014 19:56:08 -0600
Subject: Re: hg, git, fossil, ...
To: Python <python-list@python.org>
Content-Type: text/plain; charset=UTF-8
Precedence: list
Newsgroups: comp.lang.python
Message-ID: <mailman.13592.1409277418.18130.python-list@python.org>
Lines: 51
NNTP-Posting-Host: 2001:888:2000:d::a6
Xref: csiph.com comp.lang.python:77247

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.