0

I know that I can use this 

git diff master..feature_branch

Which will output all differences between those two branches.

Now, my question is, how can I get only the differences coming from feature_branch.

In other words, I want to know

What does feature_branch would add to master if I were to merge them ?

scharette
  • 9,437
  • 8
  • 33
  • 67
  • 2
    This seems like a duplicate of [git diff to see what a merge would introduce](https://stackoverflow.com/questions/11727102/), but on the other hand there is no accepted answer to the dupe target. But these two threads should probably be joined once(/if) you get a satisfactory answer to this question. – dfrib Aug 01 '18 at 16:05
  • @dfri Thanks for the link. What is the good practice when things like that happens ? Should I wait for an answer or this should be closed as dupe? – scharette Aug 01 '18 at 16:09
  • 1
    I honestly don't know what would be the best practice, but I would wait for an answer before linking this (or the other) one. Even if I as OP found an other older thread myself but didn't find the single (non-accepted) answer satisfactory, I would consider opening a new thread and explicitly pointing our that there is no satisfactory answer in the previously asked question. Anyway, you might want to try out the [triple dot](https://stackoverflow.com/a/17617690/4573247) approach, and if it works, answer this question yourself (and then we'll attempt to close the other one pointing at this one). – dfrib Aug 01 '18 at 16:21
  • 1
    Possible duplicate of [git diff to see what a merge would introduce](https://stackoverflow.com/questions/11727102/git-diff-to-see-what-a-merge-would-introduce) – phd Aug 01 '18 at 16:24
  • 1
    @dfri Thanks for that. it works perfectly. – scharette Aug 01 '18 at 16:28
  • 1
    I'm not sure if there is a meta post about this, but it seems like the right thing is (or would be) to ask and answer, then close the *other* question as a duplicate of the *newer* one, if the other question won't ever get an answer chosen... – torek Aug 01 '18 at 16:34
  • 1
    @torek This is kind of a really interesting situation, because I'm the author of a thread that is somewhat similar to what you're suggesting. I think by editing it we could really underline a specific problem that we would need to address. Have a look at the [post](https://meta.stackoverflow.com/q/371293/7692463). I could potentially write another thread also. – scharette Aug 01 '18 at 16:37
  • 1
    I suggest that, once you can accept your own answer, we follow @torek's advice and close the older question (that I linked to above) as a duplicate _to_ this one. As torek is a gold badge user of `git` tag, he should be able to single-handedly perform this dupe link. – dfrib Aug 01 '18 at 16:44
  • @torek I actually opened a [thread](https://meta.stackoverflow.com/q/371891/7692463) on meta since I want to know I think this situation is interesting. – scharette Aug 01 '18 at 17:39
  • 1
    @dfri Let's see what people think at meta before. – scharette Aug 01 '18 at 17:39

1 Answers1

2

The triple dot notation solved it for me, since it basically compares the second branch relatively to the first one.

git diff master...feature_branch

Note though that this will only work for committed changes.

If ever you're like me and you're actually cleaning your branches and was wondering how to check if it had potential un-merged content, I highly recommend using 

git branch -d feature_branch

Note the -d (lowercase flag). By passing that if ever you have un-merged content you will receive this kind of message

error: The branch 'feature_branch' is not fully merged.
If you are sure you want to delete it, run 'git branch -D feature_branch'.
scharette
  • 9,437
  • 8
  • 33
  • 67
  • This (`git diff master...feature`) is usually the way to go. There's a minor bug in Git where, if there is more than one merge base, the triple-dot notation misfires here. You can tell if this has occurred if you know how to spot a combined diff. – torek Aug 01 '18 at 16:35