Lele Gaifax :
> 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-pi
Chris Angelico :
> On Fri, Aug 29, 2014 at 3:59 PM, Marko Rauhamaa 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
smalli
Chris Angelico :
> 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 w
Marko Rauhamaa writes:
> Chris Angelico :
>
>> 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
On Fri, Aug 29, 2014 at 3:59 PM, Marko Rauhamaa 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 n
On Fri, Aug 29, 2014 at 3:50 PM, Marko Rauhamaa wrote:
> Ian Kelly :
>
>> On Wed, Aug 27, 2014 at 11:58 PM, Marko Rauhamaa 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, c
Ian Kelly :
> 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
Ian Kelly :
> On Wed, Aug 27, 2014 at 11:58 PM, Marko Rauhamaa 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 sam
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 revisio
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 com
On Thu, Aug 28, 2014 at 10:17 AM, Marko Rauhamaa 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
On Wed, Aug 27, 2014 at 11:58 PM, Marko Rauhamaa 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-live
On Fri, Aug 29, 2014 at 5:37 AM, Marko Rauhamaa wrote:
> Chris Angelico :
>
>> 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 t
On 28/08/2014 22:25, Tim Delaney wrote:
On 29 August 2014 02:32, Tim Chase mailto:python.l...@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
On 29 August 2014 02:32, Tim Chase 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 corre
Chris Angelico :
> 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 ver
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, ...
On Fri, Aug 29, 2014 at 2:17 AM, 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 t
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 hi
Ned Batchelder :
> 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
On 8/28/14 1:58 AM, Marko Rauhamaa wrote:
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' -->
On 2014-08-28 08:58, Marko Rauhamaa wrote:
> 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'
Skip Montanaro :
> The "simple hg commands" are generally not all that different (in my
> limited experience) than the "simple git commands," for some
> definition of "simple." Stuff like clone, init, push, pull, commit,
> the small number of commands you use day in, day out. When you get
> beyond
On Thu, Aug 28, 2014 at 4:51 AM, Skip Montanaro wrote:
> The "simple hg commands" are generally not all that different (in my limited
> experience) than the "simple git commands," for some definition of "simple."
> Stuff like clone, init, push, pull, commit, the small number of commands you
> use
On Wed, Aug 27, 2014 at 1:26 PM, Ethan Furman wrote:
> I use hg because 1) python-dev uses hg; and 2) I understand the simple hg
> commands. I find git confusing, and my main uses are commit, pull, update,
> an occasional merge, and a rare rollback -- not complicated stuff.
The "simple hg comm
On 08/27/2014 11:51 AM, Skip Montanaro wrote:
Thank God for StackOverflow. :-)
+1 QotW
--
https://mail.python.org/mailman/listinfo/python-list
On 08/27/2014 10:29 AM, Rustom Mody wrote:
Git has won the battle
Good thing there's room for more than one technology.
I use hg because 1) python-dev uses hg; and 2) I understand the simple hg commands. I find git confusing, and my main
uses are commit, pull, update, an occasional merge, a
27 matches
Mail list logo
