Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.python > #77259
| Path | csiph.com!v102.xanadu-bbs.net!xanadu-bbs.net!feeder.erje.net!eu.feeder.erje.net!newsfeed.xs4all.nl!newsfeed3.news.xs4all.nl!xs4all!newsgate.cistron.nl!newsgate.news.xs4all.nl!post.news.xs4all.nl!not-for-mail |
|---|---|
| Return-Path | <rosuav@gmail.com> |
| X-Original-To | python-list@python.org |
| Delivered-To | python-list@mail.python.org |
| X-Spam-Status | OK 0.003 |
| X-Spam-Evidence | '*H*': 0.99; '*S*': 0.00; 'repository': 0.05; 'modify': 0.07; 'plenty': 0.07; '*is*': 0.09; 'comments?': 0.09; 'considered,': 0.09; 'feature,': 0.09; 'git': 0.09; 'linear': 0.09; 'merging': 0.09; 'so?': 0.09; 'cc:addr:python-list': 0.11; 'bug': 0.12; 'systems.': 0.12; "wouldn't": 0.14; 'changes': 0.15; 'deque': 0.16; 'docstrings': 0.16; 'fine.': 0.16; 'fork': 0.16; 'from:addr:rosuav': 0.16; 'from:name:chris angelico': 0.16; 'hint': 0.16; 'intrinsic': 0.16; 'mercurial,': 0.16; 'patches': 0.16; 'philosophy.': 0.16; 'rule.': 0.16; 'all.': 0.16; 'wrote:': 0.18; 'wed,': 0.18; 'file,': 0.19; 'not,': 0.20; 'command': 0.22; '>>>': 0.22; 'code,': 0.22; 'aug': 0.22; 'otherwise,': 0.22; 'saying': 0.22; 'separate': 0.22; 'cc:addr:python.org': 0.22; 'example.': 0.24; 'merge': 0.24; 'decide': 0.24; 'earlier': 0.24; 'cc:2**0': 0.24; "i've": 0.25; 'source': 0.25; 'header:In-Reply- To:1': 0.27; 'specifically': 0.29; 'patch': 0.29; 'reporting': 0.29; "doesn't": 0.30; 'skip:+ 30': 0.30; 'then.': 0.30; 'message- id:@mail.gmail.com': 0.30; 'work.': 0.31; 'code': 0.31; 'lines': 0.31; 'url:wiki': 0.31; 'are.': 0.31; 'argue': 0.31; 'branches': 0.31; 'default,': 0.31; 'url:wikipedia': 0.31; 'file': 0.32; 'this.': 0.32; 'probably': 0.32; 'another': 0.32; 'text': 0.33; 'says': 0.33; 'cases': 0.33; 'development.': 0.33; 'fri,': 0.33; 'actual': 0.34; 'comment': 0.34; 'there,': 0.34; 'problem': 0.35; "can't": 0.35; 'skip:- 50': 0.35; 'common': 0.35; 'one,': 0.35; 'operations': 0.35; 'usual': 0.35; 'but': 0.35; 'received:google.com': 0.35; 'are,': 0.36; 'i.e.': 0.36; 'ordered': 0.36; 'revert': 0.36; 'set.': 0.36; 'done': 0.36; "didn't": 0.36; 'url:org': 0.36; 'should': 0.36; 'half': 0.37; 'two': 0.37; 'area': 0.37; 'being': 0.38; 'branch': 0.38; 'depends': 0.38; 'files': 0.38; 'pm,': 0.38; 'rather': 0.38; 'quote': 0.39; 'even': 0.60; 'skip:u 10': 0.60; 'easy': 0.60; 'commands': 0.60; 'ian': 0.60; 'problems.': 0.60; 'new': 0.61; 'skip:* 10': 0.61; "you're": 0.61; 'choose': 0.64; 'more': 0.64; 'different': 0.65; 'between': 0.67; 'user,': 0.69; 'respect': 0.70; 'citizens.': 0.84; 'commands.': 0.84; 'forks': 0.84; 'partially': 0.84; 'subject:, ...': 0.84; 'treats': 0.84; 'favour': 0.91; 'thing,': 0.91; 'to:none': 0.92; 'numerous': 0.93; 'story.': 0.93 |
| DKIM-Signature | v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:cc :content-type:content-transfer-encoding; bh=qp4rwOXgB1BeFaJs9fHrjUd+MuvFM8a9coI5zSo+bg8=; b=QQ/FVCJMS9UTSG0K24bMJ9i03jzll8LWL/K4oozIaSPexPRXnmzOZwo8SJ6h0yMzEz xLLJvrEJNn/06HURV8V6dRta/3otcemBQ2eK9w3KX+Mb/enM3AmzrLYovcrT2WYEk+Zk N/Dtw0gqeBoumvQNZgzWgwxmggiaO/jUuwokftNp7PG9JL7g1O+fd7oJkJSAYwbDVDQ8 jYa9Z5KHoB+qyvozpugjt8avKvUnhcE8rdlDA/1aFG6ClzhtVdwd51FlUUIYb94L4azr o9P9KFRrdBtUqIWL9v7tRboofIJv39jW1fPe2ixxqJmtRJZQFPxSBwTxpvviUVwJdm7K fzgw== |
| MIME-Version | 1.0 |
| X-Received | by 10.42.84.9 with SMTP id j9mr9729437icl.60.1409296752719; Fri, 29 Aug 2014 00:19:12 -0700 (PDT) |
| In-Reply-To | <8738cfx2t0.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> <mailman.13592.1409277418.18130.python-list@python.org> <8738cfx2t0.fsf@elektro.pacujo.net> |
| Date | Fri, 29 Aug 2014 17:19:12 +1000 |
| Subject | Re: hg, git, fossil, ... |
| From | Chris Angelico <rosuav@gmail.com> |
| Cc | "python-list@python.org" <python-list@python.org> |
| Content-Type | text/plain; charset=UTF-8 |
| Content-Transfer-Encoding | quoted-printable |
| X-BeenThere | python-list@python.org |
| X-Mailman-Version | 2.1.15 |
| Precedence | list |
| List-Id | General discussion list for the Python programming language <python-list.python.org> |
| List-Unsubscribe | <https://mail.python.org/mailman/options/python-list>, <mailto:python-list-request@python.org?subject=unsubscribe> |
| List-Archive | <http://mail.python.org/pipermail/python-list/> |
| List-Post | <mailto:python-list@python.org> |
| List-Help | <mailto:python-list-request@python.org?subject=help> |
| List-Subscribe | <https://mail.python.org/mailman/listinfo/python-list>, <mailto:python-list-request@python.org?subject=subscribe> |
| Newsgroups | comp.lang.python |
| Message-ID | <mailman.13599.1409296763.18130.python-list@python.org> (permalink) |
| Lines | 102 |
| NNTP-Posting-Host | 2001:888:2000:d::a6 |
| X-Trace | 1409296763 news.xs4all.nl 2970 [2001:888:2000:d::a6]:47170 |
| X-Complaints-To | abuse@xs4all.nl |
| Xref | csiph.com comp.lang.python:77259 |
Show key headers only | View raw
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
Back to comp.lang.python | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread
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
csiph-web