Thanks, landed.

@holzman: Okay, I think I understand.

We get not'd branches first…

^CURRENT_BRANCH ^BRANCH_B ^BRANCH_C

You're saying that in the case you've outlined that CURRENT_BRANCH and BRANCH_B are the same value, right?

So you then will remove only one of them, leaving essentially:

^BRANCH_B ^BRANCH_C

To which we add...

^OLD_REV and NEW_REV, meaning that we'll pass the following to rev-list:

^BRANCH_B ^BRANCH_C ^OLD_REV NEW_REV

From which I rev-list will now return the empty set, given that it excludes commits reachable from the not'd commits, and given that ^BRANCH_B == ^CURRENT_BRANCH. And I guess the whole point is that (the null set) is what you want back in this case, right?

On 07/02/12 14:02, James Berry wrote:

@holzman: Okay, I think I understand.

We get not'd branches first…

^CURRENT_BRANCH ^BRANCH_B ^BRANCH_C

You're saying that in the case you've outlined that CURRENT_BRANCH and BRANCH_B are the same value, right?

So you then will remove only one of them, leaving essentially:

^BRANCH_B ^BRANCH_C

To which we add...

^OLD_REV and NEW_REV, meaning that we'll pass the following to rev-list:

^BRANCH_B ^BRANCH_C ^OLD_REV NEW_REV

From which I rev-list will now return the empty set, given that it excludes commits reachable from the not'd commits, and given that ^BRANCH_B == ^CURRENT_BRANCH. And I guess the whole point is that (the null set) is what you want back in this case, right?

---

Reply to this email directly or view it on GitHub:
https://github.com/bitboxer/git-commit-notifier/pull/137#issuecomment-6716958

Right. I noticed this issue while playing around with it:
https://github.com/bitboxer/git-commit-notifier/issues/138

Can you think of a good way to handle multi-branch pushes? Nothing
occurred to me without us tracking some kind of state (maybe briefly via
pre-commit and post-commit).

• B

@holzman I haven't thought much about #138. I think I would take a really hard look at the data that the commit hook gets in this multi-branch case. We rely pretty hard on the refname parameter to the commit hook. Are you calling the commit_notifier properly with standard input still setup? If not, then the commit notifier in executor.rb won't be able to properly parse multiple lines of input and won't receive information about commits to multiple refs. The 2 and 3 argument cases in Executor are both essentially bogus because of this.