Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Re-ordering entries causes multiple commits #33

Open
jesseleite opened this issue Jan 11, 2019 · 8 comments
Open

Re-ordering entries causes multiple commits #33

jesseleite opened this issue Jan 11, 2019 · 8 comments
Labels

Comments

@jesseleite
Copy link
Member

Re-ordering entries causes multiple commits (one per entry), in contrast to re-ordering pages which fires a single PagesMoved event (and therefore a single commit).

This actually needs to be addressed in the Statamic core with a new EntriesMoved event that overrides the individual EntrySaved events, but since it's being reported in unrelated issues here (see #32 (comment) and #31 (comment)), I thought I'd create a new issue to address this specifically 🙂

@timichango
Copy link

Hey Jesse — reckon this is a dupe/related to my other issue posted a few days ago, #32

@timichango
Copy link

Or... wait, is it?

@timichango
Copy link

timichango commented Jan 11, 2019

Sorry, my bad, originally was confused and thought your comment mentioning me was on that other thread (the request someone else made for change count thresholds) #31 — and I'm a dumbass and hadn't read the whole issue thread. Derp.

@jesseleite
Copy link
Member Author

jesseleite commented Jan 12, 2019

Heyo! Adding a file limit (#31), and git hanging/performance (#32), are separate issues (though I know you mentioned the entry re-ordering thing in both of those threads).

We currently fire a single event/commit when re-ordering pages 👍, but not yet when re-ordering entries 👎 (hence the creation of this issue, to recognize this specifically as it's own bug/oversight).

@timichango
Copy link

Agreed re. file limit stuff (that wasn't my idea / I don't have a dog in that particular fight, so to speak) — was only commenting in that thread re. the multiple commits happening on reorder, on account of the broader commonality of both circumstances leading to a bloat of the commits. And it never once occurred to me that there was any relationship between the spock/git/hang issue and the notion of some sort of file count threshold.

See my comments on #32 re. the spock/reorder/hang thing (responded to a prior inquiry of yours in that thread earlier).

Cheers!

@jesseleite
Copy link
Member Author

Haha no worries man! Just trying to separate these issues out so we can properly deal with them. Take care!

@pxwee5
Copy link

pxwee5 commented Mar 12, 2019

This should be critical. I'm running into issues where:

  • I have 70 press releases
  • The 71st press release is created under the name 71.new name
  • Editor sometimes re-orders it to the first position.
  • This means 70 file renames
  • And then Spock commits them 1 by 1, SEVENTY times.

@jackmcdade
Copy link
Member

jackmcdade commented Mar 12, 2019 via email

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

4 participants