-3

I read posts (e.g., 1, 2, 3) that recommend triggering a CI build process by pushing an empty git commit.

I don't understand how this is a good idea as the commit history will be peppered with meaningless entries, and they can't be removed without re-writing the hashes (e.g., git rebase --interactive, anything from this list), so any clean-up will require a force push (which should be avoided if others also work on that branch).

For example,

BEFORE REBASE:

* c074c70 (HEAD -> master) yet another major item
* bd8e835 trigger CI
* 49ddd75 trigger CI
* f895e9f this is important
* a7da744 trigger CI
* cec6a60 trigger CI
* 96e84f7 init

$ git rebase --interactive 96e84f7

AFTER DROPPING ALL EMPTY COMMITS:

* e441b17 (HEAD -> master) yet another major item
* fc67d54 this is important
* 96e84f7 init

THE ONLY COMMIT THAT RETAINED IT'S ORIGINAL HASH IS "init".
toraritte
  • 6,300
  • 3
  • 46
  • 67
  • 4
    A workflow that depends on empty commits to the VCS to trigger CI/CD is an abuse of VCS. That simply makes no sense. There are so many better options for the latter (e.g. a chat bot that listens for certain messages). Ya'll should rethink your setup. – Inigo Jul 19 '21 at 13:30
  • 2
    I agree. You're underthinking this, not overthinking it. Take a larger view: why are you in the situation of pushing empty commits directly to main, or indeed of editing main directly at all? – matt Jul 19 '21 at 13:33
  • I was asking this because I know little to nothing about this topic but your comments do put things into perspective, thanks! Also, just to clarify, the downvotes are reflections on the outlined idea, and not because the question is of low quality and/or doesn't belong to this forum, right? – toraritte Jul 19 '21 at 13:48
  • I think the downvotes are probably correctly there. This seems quite opinion based. Since it's a "why is this practice a bad idea". Which usually attracts low quality answers. Although it's easy to see it downvoted for being bad practice (users aren't perfect moderators). – James Jul 19 '21 at 14:31
  • `so any clean-up will require a force push (which should be avoided if others also work on that branch).` Is a force-push really so unreasonable? I make heavy use of `git rebase -i` in my workflow. A good git history is a story which explains the choices made in developing a feature, which is rarely the same as the series of experiments done to figure out how to implement something. – Nick ODell Jul 19 '21 at 20:48
  • @NickODell I rebase and force push **a lot** on personal stuff too but if there is a larger project with many contributors it may not be the best to force push to `master`/`main` frequently, when a lot of that clean-up could be done _before_ the commits get there. – toraritte Jul 19 '21 at 20:53
  • 1
    @toraritte That's a good point. It's important to only use rebase when it won't disrupt others. – Nick ODell Jul 19 '21 at 20:55

1 Answers1

1

Based on the comments, this is not a good general practice, and I believe the point of the mentioned posts is that

  • it can be done (but one probably shouldn't)
  • this can be used to test a CI/CD build service/system without having to add a contrived change.

It seems that a good general rule would be to push empty commits only to personal work branches, and remove them before a pull request and/or merging to master/main

The thread Pushing empty commits to remote asks questions (see below) that would answer this same question but they have been completely ignored in that thread.

Are there any disadvantages/consequences of pushing empty commits? Is there any problem I might face in future because of this empty commit??

toraritte
  • 6,300
  • 3
  • 46
  • 67