[FR] Have a file limit before commit?

[pxwee5]

Is there a way we could collect all the changes, e.g. 10 affected files before making a commit by spock?

[jesseleite]

A file limit? Confused about your use case?

[timichango]

Sounds like he's wanting to set a threshold number for how many files need to be changed before a commit gets triggered — ie. rather than initiating a commit each time a file is altered, Spock would hold off until the threshold number (of changed files) is reached, and then commit them en-masse in a single commit, rather than individually. No? I'd guess this is coming from experiencing an overwhelming number of commits in the repo?

[Christophvh]

Could be useful, we currently have an importer running every hour for a load of entries. So every our we get about 100 git-commits. 1 for each entry changed instead of a bundled commit.

[timichango]

To some extent I can't help wondering if a scheduled commit wouldn't be more appropriate for most use-cases? Like commit every X hours, if anything's changed — rather than every X files. Both scenarios kinda seem like setting a risk-tolerance threshold (ie. we can tolerate losing X amount of data if something goes wrong between commits), but I'm more accustomed to seeing that tolerance expressed in time-based commit (or, rather, backup, more broadly) intervals, than as change-count based intervals — since a change-count based interval, could, for example, if the change frequency was low, mean that no backups/commits happen for a long time.

[pxwee5]

Well, right now it's commiting on every action, my editor saves like 30 times for 1 blog post. So I have 30 commits.

What if we put all the changed files in an array buffer, and then have the menubar say how many unsaved changes.

Users can click the button to make a commitment to save the page. It's 1 more step to the whole process but it'll make the repository squeaky clean.

[jasonvarga]

Interesting ideas, but I'd say this is outside the scope of Spock.

[Christophvh]

Sad to hear it, because this seems like exactly within the scope of Spock since it has nothing to do with statamic itself but with the way Spock commits. Gonna add this image here. Our site is still running on staging and we almost have 1000 commits just from a week that seems very dirty.

[pxwee5]

It has everything to do with Spock. What @Christophvh has uploaded is a very real issue experienced by many teams running their marketing website on Statamic and rely on Spock to properly save the content creator's work.

My team's git repository looks exactly like Chris'.

[jesseleite]

This seems like exactly within the scope of Spock since it has nothing to do with statamic itself but with the way Spock commits.

It has everything to do with Spock.

There's definitely room for future improvements, but it's out of scope for Spock because it's not Spock's job to group commits; Spock simply listens to events and commits once per event. A lot of what's being asked here would require fundamentally large changes in the Statamic core itself. Maybe we can improve some of this for Spock in v3.

To some extent I can't help wondering if a scheduled commit wouldn't be more appropriate for most use-cases.

"Most" is subjective here, and as you said there's added risk because of what could go wrong in between scheduled commits. Spock's ears are designed for events, but if you want a schedule based commit instead, it wouldn't be too hard to whip up your own command and task addon 😊

[timichango]

@jesseleite I totally agree re: scheduling not really being Spock's purview — to clarify, I was thinking of commit scheduling in the same context you mentioned: as something performed by another tool.

I've got my own issues with Spock/Core (the whole thing with reordering entries triggering a litany of commits, rather than a single commit for the reorder), but fundamentally I think the one-change/one-commit paradigm fits for what it is trying to achieve.

[jackmcdade]

You could just have a cron job that does git add --all && git commit "regular push from prod" and you wouldn't need Spock.

[timichango]

^ precisely

[timichango]

For my purposes, I'm looking into structuring my projects as pairs of repositories: one for the core/theme/etc, and another for the /content directory, so they can have different commit strategies applied that are relevant to the needs of both. That way it ultimately is less relevant (at least insofar as a heap of content commits makes navigating dev-related commits unwieldy) if the content commits go go bananas all over the(ir own) repo.

[jackmcdade]

Sure thing, nothing holding you up from configuring your own tooling. Spock is a swiss army knife that just reacts to events, which happens to be super useful for auto committing changes in most circumstances. That's it :)

[timichango]

Is there an event tied to the expiry of a CP login session? That might be something useful to leverage, with Spock, if so...

[jesseleite]

@timichango I notice you've mentioned the entry re-ordering thing here which is valid, but a separate issue. Created a new issue for that specifically https://github.com/statamic/spock/issues/33 🙂