Feature-request: multiple file commit edit via web gui (do not force user to commit/save for every single change)

For the web-ui people, it would be really rad to make changes to several files, then, commit it all-at-once. At the moment, for every single change, one is forced to commit. It should save quite a bit of cpu power from all those extra rebuilds, no?

i feel like i’m abusing the !@#$ out of GitHub Pages by using the web-ui to make a web-site… :confused:

[organization: sorry to not categorize, but i didn’t see one for feature requests or feedback, just a tag]

  1. Create a branch off of the github pages branch
  2. Create a branch off that branch
  3. On that second branch, change a file
  4. Change another file
  5. Create a PR from the second branch into the first branch
  6. Squash merge the PR
  7. When you’re ready, you can merge your middle branch into github pages

(You might not need the intermediate branch, but it’s useful to think about it in abstraction.)

1 Like

hmmm, yeah, making changes on a new branch is indeed the current workaround… not bad either, since the option is there in the web gui next to the commit/save button… i’m guessing it’ll rebuild upon merge. i’ll try it!

i vaguely remember having a ~gh-pages branch ages ago, but now all i see is main. Not sure if this has changed…

I don’t really know why a second branch is wanted nor needed… but i trust ya :stuck_out_tongue:

I can’t remember why I liked having an extra intermediate.

But, yes, I’ve done some very complicated things using only the web UI while driving it from a mobile browser.

So this isn’t a hypothetical sequence.

I tend to use lots of extra intermediates. E.g. to hide the fact that I’m using pull requests to create these amalgamated commits.

Here, I think it lets you or me review the changes before I make the final merge request, or decide to make additional edits. E.g. make three changes, squish them together. And then make new additions to it before I decide I’m done.