Dear community: feedback highly appreciated ❤️

[AndreasAugustin]

Hi dear community,

It would be super nice if you could give some feedback about the action 🚀

I am super interested in some stories about how you use the action and some insights 👀 e.g.

• which features do you use, e.g.
  • the released docker images
  • gpg sign
  • hooks
  • ...
• how are you using the action
• what do you like, dislike
• which features are you missing
• do you use the action within github enterprise servers (and how)
• are you missing some guidelines/documentation
• ...

Getting feedback is not super easy so I like to try it this way. (just leave some comments ❤️ )

Thanks and regards

Andreas

[XtraIce]

@AndreasAugustin So I'm currently using the script this action is based around, and call it with a make target. Something rather bothersome I've run into and am currently trying to remedy.

After performing a sync and merge the contents, future syncs still hold the same old content. There is no history kept to prevent commits that have already been pulled in from being redone. This is typically bothersome with templated documentation that wants to override the actual documentation every-time. The root cause is the --squash which puts all the commits into the commit message, so there is no trace of it in the history of child repo.

At the same time, I understand not wanting to pollute the child repo with the whole commit history of the template repo. So currently trying to remedy a way of keeping track of commits already sync'd. One idea thrown around was tagging the merge with the commit hash of the template-repo head, so that can be referenced later on so the script knows where to start from.

Curious to know if there's other ideas or maybe this is already fixed somewhere in this action but outside the script. Thanks!

[JessicaS11]

We, the University of Washington eScience Institute Hackweek team, are using this action to minimize time and effort in porting centralized changes from our template to our event-specific JupyterBooks (e.g. ICESat-2, GeoSMART, SnowEx). It solves a long outstanding challenge for how to make sure that the updates created during the running of an event can easily be ported back into our template; now we can simply make the changes in the template and immediately apply them to the particular use case of the template without manually importing a list of cherry picked commits or worrying we'll miss something.

Thanks for all the hard work creating and maintaining this action and super fast responses when we've faced issues!