Pull after commit

My use case is:

1. Have multiple parallel runs (“build matrix”)
2. Each parallel run commits in the same branch
3. For each branch:
   • commit
   • pull --rebase (enabled by pull_strategy: '--rebase' setting)
   • push

I think that @v7 first pulls and then commits. I think, it should be the other way round to ensure that a pull succeeds.

I cannot use NO_PULL, because there are surely updates for parallel job number 2 onwards (refs https://github.com/EndBug/add-and-commit/issues/187). It maybe is https://github.com/EndBug/add-and-commit/issues/67, but that issue is stale.

git status:

Changes not staged for commit:
  (use "git add <file>..." to update what will be committed)
  (use "git restore <file>..." to discard changes in working directory)
	modified:   paper-de-times-listings-cleveref.tex

no changes added to commit (use "git add" and/or "git commit -a")

output of action:

Internal logs
  > Staging files...
  > Adding files...
  > No files to remove.
  > Checking for uncommitted changes in the git working tree...
  > Found 1 changed files.
  {
    raw: '',
    remote: 'latextemplates/LNCS',
    branches: [
      { name: 'gh-pages', tracking: 'origin/gh-pages' ***,
      { name: 'lncs_alpha', tracking: 'origin/lncs_alpha' ***,
      { name: 'lncs_as', tracking: 'origin/lncs_as' ***,
      { name: 'main', tracking: 'origin/main' ***
    ],
    tags: [
      { name: '1.0.0', tracking: '1.0.0' ***,
      { name: '1.1.0', tracking: '1.1.0' ***,
      { name: '1.1.1', tracking: '1.1.1' ***,
      { name: '1.2.0', tracking: '1.2.0' ***,
      { name: '1.3.0', tracking: '1.3.0' ***,
      { name: '1.4.0', tracking: '1.4.0' ***,
      { name: '1.4.1', tracking: '1.4.1' ***,
      { name: '1.5.0', tracking: '1.5.0' ***,
      { name: '1.6.0', tracking: '1.6.0' ***,
      { name: '1.6.1', tracking: '1.6.1' ***,
      { name: '1.7.0', tracking: '1.7.0' ***,
      { name: '1.8.0', tracking: '1.8.0' ***,
      { name: '1.9.0', tracking: '1.9.0' ***,
      { name: '1.9.1', tracking: '1.9.1' ***
    ]
  ***
  > Switching/creating branch...
  M	paper-de-times-listings-cleveref.tex
  Your branch is up to date with 'origin/switch-to-github-actions'.
  
  > Pulling from remote...
  { raw: '', remote: null, branches: [], tags: [] ***
  Error: Error: error: cannot pull with rebase: Your index contains uncommitted changes.
  error: please commit or stash them.

[koppor]

It’s not totally correct: running git pull before committing won’t work only when the pull is not fast-forward (and so the changes would be overwritten by the merge).

Yeah, I just tried it with a MWE with two files.

In my case, all the parallel branches create the same changes in a file (in the concrete case: README.md). Thus, this is really an edge case (because git itself could also handle that thing when pulling).

If you ever come up with a strategy that would allow the action to support these use cases while also working as usual with the more common ones, feel free to share it here so we can add it 😉

Sure, I will!

Now seeing that this is really an edge case; and I can solve it with a short work-around, I will close the issue.

[EndBug]

It’s not totally correct: running git pull before committing won’t work only when the pull is not fast-forward (and so the changes would be overwritten by the merge). If, for example, the upstream changes don’t edit the same files, the command will just update the branch. The reason behind this command order is that it makes sure the push will be fast-forward. If the action is used to automatically compile source code it’s possible that while the job is running the branch gets another push, and this ensures that we’re committing with the updated branch.
Anyway, in the average use case (not in a matrix) there are no merge conflicts, and everything works just fine.

I love the idea of being able to customize the behavior of the action to better fit these use cases, but as of now, I’m not sure what would be the most effective and efficient way to add this kind of functionality. I just want to make sure that when I update the action I’m not just adding a workaround for single edge-cases, but a feature that can be useful to all the users (otherwise I’d be stuck adding workarounds 😅)

If you ever come up with a strategy that would allow the action to support these use cases while also working as usual with the more common ones, feel free to share it here so we can add it 😉