Closed rdmurphy closed 3 years ago
Hi Ryan π
This sounds like an interesting rare edge case.
The call to git fetch
has been added in #108 to fix a problem with slashes in branch names. Calling git fetch
solved the problem but, in hindsight, feels like a dirty hack.
I've just created #131 with ideas to solve this problem.
git fetch --depth=3
will only get the last 3 commits of the repo, instead of the entire history.skip_fetch: true
is a new option to skip git fetch
entirely.Would be great if you could give both options a try.
To still use git-fetch
, update your Workflow to point to #131 branch like this:
-- uses: stefanzweifel/git-auto-commit-action@v4
+- uses: stefanzweifel/git-auto-commit-action@git-fetch-depth
To skip the call to git-fetch
you also have to add skip_fetch
to your Workflow file.
-- uses: stefanzweifel/git-auto-commit-action@v4
+- uses: stefanzweifel/git-auto-commit-action@git-fetch-depth
+ with:
+ skip_fetch: true
Would love to hear back, which version got better results for you.
As you mentioned, calling git fetch
isn't really necessary. Will work in a future PR to remove that call completely.
Hey @stefanzweifel β that's great! I'll give this a shot and report back.
Okay! I can confirm that passing skip_fetch: true
worked for us and exponentially sped things up @stefanzweifel. So that's awesome!
Regarding the default depth β is there a reason you picked 3
instead of 1
(or any other number)? I've used --depth
a few times with that command and was wondering what made 3
more appealing as a default. I could see a version of this where someone could pass in their own flags to git fetch
, but if the plan is to get rid of that call entirely one day then maybe that is moot.
But anyway β skipping fetch worked for us. π Thank you!
Glad to hear that it worked.
I've chosen --depth=3
instead of --depth=1
because I thought that 1
might not be enough and break something for some users. But I think I will switch to --depth=1
.
I will update my PR and tag a new version soon. I will keep both the skip_fetch
-option and the updated call to git fetch
. Fetching only the last few commits should speed things up for other users too.
Sounds great, Iβll keep an eye out for it. Thank you for the quick turn around!
v4.8.0 has been released. If you have been using @v4
of the Action you autmatically get the update.
Thanks again for reporting this issue!
Is your feature request related to a problem? Please describe. Hello! π I'm a big fan of this action, but I've hit an interesting edge case and I was wondering if there's maybe a solution for it to be added. We have a repo with an workflow that clones the repo, runs a command (that updates a single file) and uses this action to re-commit it back. The branch that was checked out with
actions/checkout@v2
is the same one that's being committed to β meaning all the information to make the commit should already be present. However, this repo has a massive history and tons of branches and tags, so whengit-auto-commit-action
does thisgit fetch
call, it takes forever. The script we're running takes ~20 seconds to complete, and thegit fetch
is taking ~8 minutes.Describe the solution you'd like Is there a
git
safe way to either 1) not do thatgit fetch
call at all if the current branch and the target branch are the same, 2) make thatgit fetch
call retrieve less history? Either with a custom flag a user may append to thegit fetch
call (like howpush_options
works) or some other method?Describe alternatives you've considered The only option we've come up with is not using this action. π Which is fine, but I really like what you have setup here!
Thank you!