[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: base
From: |
Eli Zaretskii |
Subject: |
Re: base |
Date: |
Fri, 27 Aug 2010 16:52:20 +0300 |
> From: "Stephen J. Turnbull" <address@hidden>
> Cc: address@hidden,
> address@hidden
> Date: Fri, 27 Aug 2010 22:03:13 +0900
>
> > > No, you can provide some representative workflows that are enough
> > > for you.
>
> > Actually, I meant some representative workflows that should cover
> > the common use-cases.
>
> By "common use cases" you evidently mean "but not anything that a git
> user might want," or even "that a typical user can express in ordinary
> terms and a git user could achieve by manipulating the DAG" (see below
> for an example).
No, I meant use-cases that are of interest to ordinary users, as
opposed to technicians.
> > bzr switch THE_OTHER_BRANCH
>
> Thank you for playing. Unfortunately, not only isn't that efficient,
> it doesn't work at all without a fair amount of additional explanation:
>
> address@hidden /tmp/test/bar $ bzr switch ../foo
> bzr: ERROR: Cannot switch a branch, only a checkout.
It is documented to work only with checkouts.
> But it's not clear to me whether the obvious change to that workflow,
> ie, checkout from "../foo" in "bar", actually has the semantics of
> git, though, and I bet you have no idea either. For example, suppose
> I want to merge two branches in that checkout, but preserve the
> possibility of switching to either of the parents in the future. This
> is trivial in git: git checkout foo; git merge bar; git branch foo^
> old-foo. The obvious solution in bzr (bzr checkout -r before:) *does
> not work*; it is not a branch and you cannot commit.
Some combination of "bzr merge -r" with appropriately chosen pair of
revision should be able to do the trick, I think.
> (At least,
> that's what the dox say.) So I expect I'd have to do a bit more
> preparation to get a usable approximation to git colocated branches.
Why bother, if you can easily branch and work in a separate tree?
> > cd A && bzr rebase --onto=revno:-3 ../C
>
> Thank you for playing. Unfortunately, this doesn't work in several
> cases. I could get trunk commits or branch B commits I don't want.
I don't understand what didn't work for you, but it could be due to
bugs in `rebase'.
> Translated to non-DAG terms, the scenario is "just add Miles's feature
> and no extra crap". To expand a bit (but still use only commonly
> understood development concepts), "I just want Drew's branch with
> Miles's feature. But I don't want anything in Tom's branch that isn't
> required to implement Miles's feature, I don't want any random work
> done on the trunk since C branched, and I don't want the stuff that
> Drew added to C in his last two commits."
>
> I think "just add Miles's feature and no extra crap" is a reasonable
> thing to want. It probably would not occur to you to ask your VCS to
> do it unless you understand the DAG, though.
I see no problems doing what you want with a series of "bzr merge"
commands. "bzr rebase" is simpler, but if it doesn't work, "merge"
will.
And I don't see any reason to "understand the DAG", either. What's to
understand, anyway? I know what a DAG is, and I think I have some idea
what "bzr merge" does to a history. I don't pretend being a
technician, but what I know is enough for what I do. It was enough to
suggest solution to your riddles, even though I never needed to do any
of that. So what if some of the solutions have limitations or hit
upon bugs? that's not what this was about.
> 1 out of 3 ain't bad. :-)
You are a darling.
- Re: base, (continued)
- Re: base, David Kastrup, 2010/08/26
- Re: base, Stephen J. Turnbull, 2010/08/27
- Re: base, Óscar Fuentes, 2010/08/27
- Re: base, Stephen J. Turnbull, 2010/08/28
- Re: base, Stephen J. Turnbull, 2010/08/26
- Re: base, Eli Zaretskii, 2010/08/26
- Re: base, Stephen J. Turnbull, 2010/08/27
- Re: base,
Eli Zaretskii <=
- Re: base, Miles Bader, 2010/08/27
- Re: base, Eli Zaretskii, 2010/08/27
- Re: base, Stephen J. Turnbull, 2010/08/28
- Re: base, Eli Zaretskii, 2010/08/28
- Re: base, Leo, 2010/08/28
- Re: base, Eli Zaretskii, 2010/08/28
- Re: base, Leo, 2010/08/28
- Re: base, Stephen J. Turnbull, 2010/08/28
- Re: base, Eli Zaretskii, 2010/08/28
- Re: base, Stephen J. Turnbull, 2010/08/29