[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Rewriting bzrmerge.el
From: |
Eli Zaretskii |
Subject: |
Re: Rewriting bzrmerge.el |
Date: |
Sat, 15 Nov 2014 18:32:39 +0200 |
> Date: Sat, 15 Nov 2014 07:40:54 -0800
> From: Paul Eggert <address@hidden>
>
> To be honest, I never used bzrmerge.el the few times that I merged, and I
> doubt
> whether anybody noticed.
If you didn't have to deal with commits that are marked "backported"
or "don't merge to trunk", then the merge is a trivial VCS job, and
indeed doesn't need any help.
Otherwise, bzrmerge.el saves a lot of manual, error-prone typing, no
more, no less.
> More generally, I sense that there's a tension here between having the
> repository reflect the actual history of changes, warts and all, and having
> the
> repository reflect the history of changes in a nice tidy organized way.
> Having
> done a fair bit of software archeology myself I must say that I far prefer
> the
> former. (Plus, it's less work for the non-archeologists....)
I don't think bzrmerge changed anything in this department.
- Rewriting bzrmerge.el (was: git transition issues), David Engster, 2014/11/15
- Re: Rewriting bzrmerge.el, Paul Eggert, 2014/11/15
- Re: Rewriting bzrmerge.el, Stefan Monnier, 2014/11/15
- Re: Rewriting bzrmerge.el, David Engster, 2014/11/15
- Re: Rewriting bzrmerge.el, David Engster, 2014/11/15
- Re: Rewriting bzrmerge.el, Stefan Monnier, 2014/11/15
- Re: Rewriting bzrmerge.el, David Engster, 2014/11/21
- Re: Rewriting bzrmerge.el, Eli Zaretskii, 2014/11/22
- Re: Rewriting bzrmerge.el, David Engster, 2014/11/22
- Re: Rewriting bzrmerge.el, Eli Zaretskii, 2014/11/22
- Re: Rewriting bzrmerge.el, David Engster, 2014/11/22
- Re: Rewriting bzrmerge.el, Eli Zaretskii, 2014/11/22