Pull after commit

[koppor]

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 #187). It maybe is #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.

[EndBug]

I think you're right, you'll need to commit before pulling and rebasing.

With that said, I don't think I want to add a new input to change the command order: the fact that you can modify the pull strategy already makes the action complex, while this is meant just to be a quick way to commit and push changes.

You haven't posted your workflow so I don't know exactly what inputs you're using, but here's what I can suggest: you can use the action without pulling and pushing, and then do it manually with a couple of git commands.
You can disable pulling and pushing with the following inputs:

pull_strategy: 'NO-PULL'
push: false

You can then add a step that runs your two commands:

- run: |
    git pull --rebase
    git push

I hope this helps you solve your issue. I know that "just do it manually" may not be the answer you were expecting, but I think it's better to keep the action oriented towards the more basic functionalities.

[koppor]

@EndBug Thank you for the long answer. I implemented it exactly this way.

My question would be: pull will never work if there are uncommitted changes. Thus, why would one ever do a pull before a commit?

Example output (https://github.com/latextemplates/LNCS/runs/3368317275)

Error: Error: error: Your local changes to the following files would be overwritten by merge:
    README.md

[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 ;)

[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.

[koppor]

I get following output (https://github.com/latextemplates/LNCS/runs/3606084744)

Error: Error: error: cannot pull with rebase: Your index contains uncommitted changes.
error: please commit or stash them.

According to https://stackoverflow.com/a/43262939/873282 one should use --autostash. Maybe, I can pass that as parameter to pull_strategy?

[EndBug]

The pull_strategy input doesn't currently support multiple arguments, but it should! I'll try to add this feature, maybe renaming pull_strategy to just pull

[koppor]

I am trying v8 today. With --rebase --autostash, it works. 🎉

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.

In my normal git workflow, I would do git add .; git commit; git pull --rebase; git push. I think, this is the way, the usage is intended. When one starts with changing files, one does it from a specific commit X. Then the changes should be based on that commit X and not any other commit based on X (name it Y).

As far as I understand your interpretation, you favor following git command sequence when committing something: git stash; git pull; git stash pop; git add .; git commit; git pull.