Skip to content

HTTPS clone URL

Subversion checkout URL

You can clone with
or
.
Download ZIP

Loading…

Several Species of Small Furry Animals ___________(next branch; next release) #1220

Closed
tarsius opened this Issue · 18 comments

3 participants

@tarsius
Owner

Usage: To use Magit's next branch you also need Git-mode's next branch. You should always update both repositories at the same time. Dash is also required; get it here. You might also want to remove all customization and then rebuild it after having updated.


Status: The following things have to be completed before next can be merged into master:

  • #877 Improve cherry-pick and interactive rebase. This is necessary because the Magit specific "rewrite" functionality has already been removed and Magit's cherry-pick support cannot quite replace it yet.
  • #1261 Implement new Ediff support. The old implementation was removed and people would miss it without a substitute.
  • Postponed until after 2.1.0 Finish the new popup functionality. This includes #1321 and #876 but also a little more.
  • Document important new functionality. Actually properly document everything, including old stuff, see #1096.
  • Fix all the known nasty bugs.

Roadmap toward the next release:

The next release will be named 2.1.0. This is inspired by now Emacs is versioned, i.e. there never is a N.0.M release.

Currently the snapshots on Melpa and Melpa-Stable have different names but the respective latest snapshots are otherwise identical. I had to make recent Magit versions available on Melpa-Stable, because users were expecting something more recent than 1.2.1.

Once the above issues have been taken care of Magit will enter feature freeze. I will recreate maint from master. The snapshots on Magit-Stable will be build by tagging the tip of that branch. But because I have stopped backporting features (see below), I don't expect there to be many such snapshots. Then I will merge next into master and remove the former.

Melpa (unstable) will continue to build packages from the master branch, which now includes the numerous changes previously only in next. Currently only a handful users (that I am aware of) are using the next branch, so once the majority of Magit users starts using that version, regressions will come to light.

So there then needs to be a several week period to iron out these issues before 2.1.0 can be released. Until that happens, users who prefer suffering the idiosyncrasies of the old version over suffering the less familiar regressions in the new version, can stick to the former by using Melpa-Stable.

Once 2.1.0 is released, the version on Melpa-Stable will always be the latest actual release (whether minor or major, feature or bugfix) and the version on Melpa will once more be a truly bleeding edge snapshot, as it used to be until the the separation of master and next earlier this year.


No more backporting: Taking effect immediately I will no longer backport features and fixes to insignificant misfeatures from next to master. This allows me to focus my efforts on getting next ready for the merge into master.

@tarsius tarsius added this to the 2.1.0 milestone
@tarsius tarsius self-assigned this
@PureAbstract

.....gathered together in a cave and grooving with a pic(t|axe)?

This was referenced
Closed
@tarsius tarsius removed their assignment
@tarsius tarsius changed the title from Several Species of Small Furry Animals ________________(the next branch) to Several Species of Small Furry Animals _______(the next branch, next release)
@tarsius tarsius changed the title from Several Species of Small Furry Animals _______(the next branch, next release) to Several Species of Small Furry Animals ___________(next branch; next release)
This was referenced
@tarsius tarsius self-assigned this
@Silex

Does next require something special (emacs 24.4 maybe)? I keep getting messages like or: magit-section-children accessing a non-magit-section

Backtrace: http://codepad.org/T3BoM4Up

@tarsius
Owner

23.2 is no longer supported, the new minimal version is 24.1 (for pcase mostly). So you are probably still fine, I would expect :-) If Emacs is to old then merely loading magit causes an error, informing the user about it.

You have advised magit-status, remove that advice. If you still get an error then also remove all customization - the values of some options were changed in incompatible ways. A likely problem is that one of the magit-*-sections-hooks contains a function that no longer exists.

Obviously I will have to document these things before merging into master, and maybe also define some obsolete variable and function aliases.

@Silex

I am on 24.3... I thought I tried without any customization but probably PEBKAC. I'll try again :)

@Silex

Ok, next works fine and seems awesome :+1:

@Silex

Ok here is a few comments so far:

  • staging/unstaging annoyingly scrolls the status buffer to the top (because of refresh) and very often you had scrolled down and you need to do it again. Ideally I'd like if it either kepts the buffer as it was scrolled or made it so the next stageable hunk is at the top of the screen, that way pressing s n s n s n n n s is convenient.
  • commit enhancements like "instance fixup" c F are awesome
  • the new rebase popup is awesome, except for r f (autosquash) which never did what I expected it to do. What is it supposed to do? I expected it to be equivalent to r e C-c
  • soft reset to some version (x key) doens't keep the index. Not sure you need to restore old behavior back but it was kinda useful sometimes, e.g to quickly edit a previous commit.
  • log seems much faster
  • with-editor TRAMP interactive rebase :heart_eyes:
  • C-u F F becoming F C-u F to choose which remote is a bit more annoying to type, but I'm pretty sure you have good reasons.

All in all next is awesome, good work :+1:

@tarsius
Owner

staging/unstaging annoyingly scrolls the status buffer to the top (because of refresh)

That shouldn't happen. Un-/staging now actually is the only special case which is explicitly handled, to prevent exactly this.

the new rebase popup is awesome, except for r f (autosquash) which never did what I expected it to do. What is it supposed to do? I expected it to be equivalent to r e C-c

It creates the commit but unlike "instand squash" keeps it as the new HEAD commit. Think of it as "intend to squash". And then you use r e C-c to actually do it (or better r f). This could be useful for example when you know that the modifications would require manual conflict resolution and you don't want to deal with that right now. Or during a review when you want to propose a fix, but are not done discussing whether it is required. Or if that's really the way to fix...

soft reset to some version (x key) doens't keep the index.

There are now several magit-reset-{*} variants, bind x to whatever you prefer. I think what magit-reset does without a prefix-argument is the most reasonable default. Because I would think that if you don't even want to keep HEAD, then the index probably also isn't all that meaningful.

So this is the most reasonable way to reset, if you think of it as "killing HEAD" then we should use the "kill key" k. I have considered that but not implemented that (yet?) because all commits except for HEAD would have to be handled differently, i.e. remove the commit in a automatic "interactive" rebase. Which is a bit more complicated.

Not sure you need to restore old behavior back but it was kinda useful sometimes, e.g to quickly edit a previous commit.

HEAD? Then I would use c e (as it doesn't throw away the commit message). For older commits you would also throw away the commits "in between". When is that useful? With a collection of wip commits I suppose, is that it? In such cases I create that final wip commit and then immediately do an interactive rebase (or if the first commit doesn't have a meaningful message a reset).

C-u F F becoming F C-u F to choose which remote is a bit more annoying to type, but I'm pretty sure you have good reasons.

The plan is to never require prefix arguments when invoking an action from a popup. In most cases that will be accomplished by having more actions. In this case we might have something like

F Push to [origin]
o Push to remote

[..] indicates use of a different face, and origin actually is the value of branch.<branch>.remote.

@Silex

staging/unstaging annoyingly scrolls the status buffer to the top (because of refresh)

That shouldn't happen. Un-/staging now actually is the only special case which is explicitly handled, to prevent exactly this.

Hum, I'll find out why it happens then.

Edit: This is now being discussed in #1453.

the new rebase popup is awesome, except for r f (autosquash) which never did what I expected it to do. What is it supposed to do? I expected it to be equivalent to r e C-c

It creates the commit but unlike "instand squash" keeps it as the new HEAD commit. Think of it as "intend to squash". And then you use r e C-c to actually do it (or better r f). This could be useful for example when you know that the modifications would require manual conflict resolution and you don't want to deal with that right now. Or during a review when you want to propose a fix, but are not done discussing whether it is required. Or if that's really the way to fix...

I think you missunderstood. I'm well aware of c f or c F and they are awesome, what I'm talking about is r f which in my undersanding should behave like r e C-c, except it doesn't. I'll make a test repo to illustrate it (had conflicts with r f but not with r e C-c).

C-u F F becoming F C-u F to choose which remote is a bit more annoying to type, but I'm pretty sure you have good reasons.

The plan is to never require prefix arguments when invoking an action from a popup. In most cases that will be accomplished by having more actions. In this case we might have something like
F Push to [origin]
o Push to remote

Sounds much nicer than the prefix argument indeed! Thanks.

@tarsius
Owner

I think you missunderstood. [...] I what I'm talking about is r f

Indeed, I misunderstood. r f doesn't start the rebase with the parent of the commit at point like r e C-C does. Instead it starts with the tip of the branch tracked by the current branch. The idea behind this is that one shouldn't change history beyond that point so all commits that have fixup commits likely come later. To some extend this assumes that this tracked branch is a remote branch, so no history rewriting should be done on the commits it contains. When the tracked branch is a local branch, this might not apply. Also, from a quick look it seems that this will fail when the current branch doesn't have an upstream - there is no proper fallback.

@Silex

Ah, ok yeah it can be useful. Thanks for the informations!

@tarsius
Owner

I have postponed "finishing" the current incarnation of the "popups". It makes more sense to finish most other things now, and later after 2.1.0 has finally been released, implement idefix.el without adding yet another intermediate implementation. Without postponing this huge change the release would never happen.

The current implementation makes popups customizable, which was often requested. Unfortunately because it is an intermediate implementation, these customizations will eventually break when I write idefix. That's what I wanted to avoid by delaying the release of 2.1.0.

@tarsius
Owner

I am done now creating new libraries from code previously in magit.el.

@tarsius
Owner

I am done now creating new libraries from code previously in magit.el.

Turns out I was wrong about that. Or since the new magit-stash.el and magit-backup.el consists mostly of new code, I guess I wasn't after all :-)

@Silex

I just has an idea.. is it already planned to make some doc about how to use the new interface when next is merged? If not, I think creating a wiki page would help a lot... there was some recent ticket about next impression, and most people trying out next ask questions like: how do I do X? How do I do Y?

A simple page like:

What Before After
Branch manager b v y
Complete log l -al l l -A l
@tarsius
Owner

That's a great idea. The manual certainly has to be updated but that doesn't mean that such a table wouldn't be useful too. The manual will only document the new way and only seldom mention how things used to be.

Do you intend to work on that? That would be awesome. What page title do you have in mind or does the new https://github.com/magit/magit/wiki/Tips-and-Tricks work for the time being?

@Silex

Yeah ok I'll write some initial version. Let's use the tips n' tricks page for now, we can always move it on a page of its own later.

It's been a while since I use next now, so the only problem is that I forgot a bit how the "old magit" was. I'll probably reinstall the MELPA version when filling the page, but if you already have a list in your head of stuffs that changed just reply here and I'll take care of extracting the infos to the wiki page.

@Silex

@tarsius: okay, it's a start https://github.com/magit/magit/wiki/Tips-and-Tricks

Tell me what I forgot in the "new features" section :)

I reused the "old magit" to check.... man the old popups are so empty! so few options :)

@tarsius
Owner

Closing this in favor of a yet-to-be-created "Roadmap towards 2.1.0" which should arrive this weekend. This issue was mainly intended for the early adopters, the roadmap will be for all users who want to know how much longer they have to wait for the next release (not that I am going to give a definite answer to that :-)

@tarsius tarsius closed this
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Something went wrong with that request. Please try again.