--filter=[origin/main] vs --filter=[origin/main...HEAD]

[harshits2808]

Summary

TLDR - What is the difference bettween --filter=[origin/main] and --filter=[origin/main...HEAD] ? I thought they are the same but they aren't

Context :
I wanted a way to run all the changes made in my branch compared to the main branch.

Initially, I saw a few people using --filter=...[origin/main], so I tried that and it worked nicely, but if there are any extra changes pushed into main, then it would run those extra packages as well.

Then I moved onto using --filter=...[${{ github.event.pull_request.base.sha}}...HEAD] which solved the previous problem, but now if someone rebased the PR with main, it would include those extra changes as well.

So I made something complicated --filter=...[$(git merge-base origin/main HEAD)...HEAD] which worked, but someone suggested to just use --filter="...[origin/main...HEAD] and that also worked!

But in my head, --filter="...[origin/main...HEAD] and --filter="...[origin/main] should do that same thing as they are just trying to find the difference between main and current commit? What have I misunderstood? I went through the documentation and other similar threads but was unable to figure out anything

Additional information

Found this thread which also states that HEAD is chosen as the default value - #1442 (comment)

I tried the following in my local -

1. Create a branch turbo-test-branch-1
2. Checkout a branch turbo-test-branch-2 from the branch turbo-test-branch-1
3. Make changes in the hub package in the turbo-test-branch-2 branch
4. Make change in the backend package in the turbo-test-branch-1 branch

The I ran the following commands on the turbo-test-branch-2 branch and received the output -

harshit@Harshits-MBP Project % npm run unit-test -- --filter="[origin/turbo-test-branch-1]" --graph

> monorepo@0.0.1 unit-test
> dotenv -- turbo unit-test --filter=[origin/turbo-test-branch-1] --graph


digraph {
        compound = "true"
        newrank = "true"
        subgraph "root" {
                "[root] backend#unit-test" -> "[root] ___ROOT___"
                "[root] hub#unit-test" -> "[root] ___ROOT___"
        }
}

harshit@Harshits-MBP Project % npm run unit-test -- --filter="[origin/turbo-test-branch-1...HEAD]" --graph

> monorepo@0.0.1 unit-test
> dotenv -- turbo unit-test --filter=[origin/turbo-test-branch-1...HEAD] --graph


digraph {
        compound = "true"
        newrank = "true"
        subgraph "root" {
                "[root] hub#unit-test" -> "[root] ___ROOT___"
        }
}

We can see that --filter=[origin/turbo-test-branch-1...HEAD] only shows the hub package which was changed in the turbo-test-branch-2 branch. But, using --filter=[origin/turbo-test-branch-1 also adds the backend package into the list

Example

No response

[NicholasLYang]

Hey, yeah this is subtle and slightly confusing. If a git range has a defined end, e.g. [a...b], we do not include staged or uncommitted changes. If it has only a start, e.g. [a], we include staged or uncommitted changes.

However, I don't think that's your issue. The other main difference is that [a...b] underneath the hood calls git diff a...b, while [a] calls git diff a. Note the three dots in a...b. This gets the diff between the merge-base of a and b and b (git docs). This is effectively getting the diff that is your branch. With git diff a, that's getting the difference between a and your current commit (git docs). So in the case where that's main, that will include both the code added in main and the code added in your branch.

We likely could do a better job of explaining this, but also, this is basically git's behavior one to one.

Fun note, git diff a..b is a different thing that gets the difference between the two commits without a merge base. Gotta love when a single . makes so much difference!

[harshits2808]

Thank you @NicholasLYang !!

Yea if I had known a little bit more about how git commands work, I should have been able to figure it out myself. Live and learn!

I would definitely suggest to add a line or two about this behavior in the turbo documentation, if possible. I feel that this must be a very common use case for turbo and a lot of average joes like me wouldn't know about the intricacies git commands.