On Thu, Dec 2, 2010 at 9:47 AM, Philip Jackson <[email protected]> wrote:
> At Wed, 01 Dec 2010 13:39:15 -0500,
> Dave Abrahams wrote:
>
>> As *huge* fans of magit, me and my colleagues are very concerned
>> about some of the recent changes.  We're seeing lots of important
>> functionality broken (log all, snapshot, commit with amend...) and
>
> Don't forget you're pulling from a bleeding-edge development repo.

Good point.  Is there a stable release tag we should be using to judge
the state of things?

> I don't remember commit with amend being broken.

It's broken from a design point-of-view, because there's no way to
recover the old log message (unless it happens to be in the log
message ringbuffer).

> The --all bug (https://github.com/philjackson/magit/issues/issue/88) I
> pushed the fix literally minutes after you reported it.

I appreciate that; really, I do.

> Snapshot is/was broken?

* It doesn't save the index by default anymore.  That's an alarming change.
* Furthermore, applying a stash doesn't restore the index even if it was saved.
* Just having to hit more than one key is broken from a usability point-of-view.

The whole idea of snapshot is that without interrupting your workflow,
you create a checkpoint that takes you back to exactly where you were
no matter what else you do next.

We were giving a training on Magit yesterday and discovered the
problems then, which was embarrassing because we'd been raving about
how wonderful and game-changing Magit is.  We were even about 80
revisions back from HEAD because when I tried the HEAD the night
before we immediately found log --all to be broken.  When we found the
snapshot problems we went back and checked HEAD but they're still
there.

>> recent design decisions have been pushing many highly-useful
>> (formerly) single-keystroke commands into two-level pop-up buffers...
>
> We were simply running out of keys, really we had to do something to
> free some up.

Well, snapshot used to be on the `Z' key, which is now unbound.
Logging has a billion options now, which is really nice from a
flexibility point-of-view, but from a usability point-of-view it would
have been much better (in our opinion) to keep the `l' binding for the
usual shortlog case people do tens of times a day and require a prefix
to pop up the grid of options for more unusual requirements.
Personally I use the `log --all' option most and shortlog a little
less, but I gather that pattern is not so common.

> There was discussions, proof of concepts (which Óscar
> kindly did) and branches which I asked people to try out and comment
> on.

Sorry; didn't know about this list until yesterday.  Was mostly just
an extremely happy user until then.

> Now isn't a great time to complain about them to be honest, having
> said that, there's still room for change if you can reason them well
> enough.

I'm tryin', here.

> The other problem is there's no test suite. There was talk on
> emacs-devel about including a framework officially (ert, I think) so
> we can write tests when that happens hopefully mitigating regressions.

Lack of automated testing seems to be a problem that affects much more
than just magit.

>> So I guess we're just wondering what's happening, and if there's
>> anything we can do to influence the general direction.
>
> Code and discussion are two ways to influence development. I can see
> you've made several feature requests, that's fine but if you are
> willing to take the time to implement stuff you should as I'm far more
> likely to just merge it.

We have and will continue to submit patches.

>>  We've already made some contributions to magit and would be happy
>> to continue to do so, but don't want to waste our time trying to
>> counteract "bad commits."
>
> Aren't "bad commits" called "bugs" elsewhere?

Well, I think I meant "regressions."

> Why is fixing them a
> waste of your time? Is it a waste of mine?

It's one thing to fix newly-introduced bugs, but it's something else
to be trying to fight against the current.  I guess we just want to
make sure we're not swimming upstream.

-- 
Dave Abrahams
BoostPro Computing
http://www.boostpro.com

Reply via email to