0

I have a release branch named release/X.X.X.X which contains all feature branches I want to deploy to production. The release branch is made on top of master which is the current state of production.

On every release day I make sure our release branch contains only those changes planned for the release. I use this command to compare the release and master branch: git log release/X.X.X.X ^master --no-merges. I then manually check the commits for keywords like "SHR-1234" which represent ticket numbers in our ticket management system. I need to compare each commit with a list of ticket numbers to identify unwanted changes.

How can I filter commits that are returned by git log release/X.X.X.X ^master --no-merges and do not contain keywords like "SHR-1234"? This way I can identify the ticket number of unwanted changes.

I tried grep and awk but the results are not useful because they don't filter out the whole commit.

clinical
  • 588
  • 4
  • 17

3 Answers3

1

The git log command provides two interesting options here:

--grep=<pattern>
       Limit the commits output to ones with log message that matches the specified pattern (regular expression). With more than one --grep=<pattern>, commits whose message matches any of the given patterns are chosen (but see --all-match).

       When --show-notes is in effect, the message from the notes is matched as if it were part of the log message.

Hence --grep lets you find commits that do contain some particular string or pattern. You want commits that do not contain (any or all) strings, so we move on to:

--invert-grep
       Limit the commits output to ones with log message that do not match the pattern specified with --grep=<pattern>.

(Incidentally, note that release/X.X.X.X ^master can also be spelled master..release/X.X.X.X. There's no machine-level reason to prefer one over the other—both wind up doing exactly the same thing internally—so use whichever you find more readable.)

torek
  • 330,127
  • 43
  • 437
  • 552
0

you can use –G ‘regular expression’ to meet your requirement

git log release/X.X.X.X ^master--no-merges -G ‘regular expression’ (include or exclude the specified commit)

lake
  • 112
  • 4
  • `-G` searches for an expression that would show up in the *patch* as an added or removed line, i.e., it depends on `git diff` output. There is also `-S` which searches for a change in the *number of occurrences* of a string (unlike `-G` this searches for a fixed string, rather than a regex, unless you add more flags). However, the OP wants to search the *commit message* text. – torek Nov 11 '16 at 11:13
0

The question title admits a slightly different answer, which could be useful to some people. A simple way to compare two branches by commit title only is to dump commit titles from each branch to a separate text file, and open these two files in a diff viewer:

git --no-pager log --pretty=format:%s master > log_master.txt
git --no-pager log --pretty=format:%s other > log_other.txt
meld log_master.txt log_other.txt

We first dump commit subjects from branch master to the file log_master.txt, then commit subjects from branch other to the file log_other.txt, and open them in the visual diff viewer meld (one alternative is kdiff3).

Ioannis Filippidis
  • 8,272
  • 8
  • 66
  • 96
  • This doesnt help the OP at all; This wont't be any different then him saying `git log OTHER ^master` . His problem is trying to identify certain commits with messages he doesnt expect; this doesnt reduce or solve the problem at all.... Ironically the problem is you focused on the title and not the content of the question. – UpAndAdam Sep 12 '17 at 02:00
  • Indeed, it leads to the same differences as `git log --pretty=format:%s other ^master`. One use of this approach is to see a comparison of where the commits that aren't contained in both branches are located with respect to other commits. – Ioannis Filippidis Sep 12 '17 at 02:25
  • You are missing the point... there won't be any commits in `master` that aren't in `other` here that OP is concerned with. `other` is ahead of `master` from when it was 'branched off ' for his version. There is no order to compare, just a list of commits that are only on `other` and OP wants to find commits in there that shouldn't be there.... when finished OP will be merging back to `master`.. which again is why there's nothing to order. You are answering a question that wasn't asked, why not ask and answer the question you keep trying to answer; that would likely be useful to others :) – UpAndAdam Sep 13 '17 at 21:13