3 ms·

> git branch, git tag, and git for-each-ref all learned the --no-contains option to match their existing --contains option. This can let you ask which tags or b

by styfle 9y ago

> git branch, git tag, and git for-each-ref all learned the --no-contains option to match their existing --contains option. This can let you ask which tags or branches don't have a particular bug (or bugfix). I'm surprised that didn't exist already. Several years ago, I worked on a tool to scan SVN merge history and save in a graph database so one could ask this type of question, "Does this branch contain the fix?". Or the opposite, "Which branches do not contain this fix?". It was a mess because there were 8 million commits in the repo and clients ranged from SVN 1.4 to SVN 1.8 (the server was upgraded too). It would have made more sense to use git for something like that but it's hard to get thousands of devs to switch.

MBlume 9y ago
Pretty sure this already existed with different syntax. Under those circumstances I'd probably use git svn, I always found git svn to be a better svn client than svn.
- styfle 9y ago
  Does git svn build a local git repo out of the svn server or just act as a normal svn client?
avar 9y ago
I implemented that feature in the 2.13 release, glad to see interest in it, more details on how it works & can be used from the commit message[1]: This allows for finding the last-good rollout tag given a known-bad <commit>. Given a hypothetically bad commit cf5c725, the git version to revert to can be found with this hacky two-liner: (git tag -l 'v[0-9]*'; git tag -l --contains cf5c725 'v[0-9]*') | sort | uniq -c | grep -E '^ *1 ' | awk '{print $2}' | tail -n 10 With this new --no-contains option the same can be achieved with: git tag -l --no-contains cf5c725 'v[0-9]*' | sort | tail -n 10 As the filtering machinery is shared between the tag, branch & for-each-ref commands, implement this for those commands too. A practical use for this with "branch" is e.g. finding branches which were branched off between v2.8.0 and v2.10.0: git branch --contains v2.8.0 --no-contains v2.10.0 1. https://github.com/git/git/commit/ac3f5a346860b824e083c5d305757c3260565475 https://github.com/git/git/commit/ac3f5a346860b824e083c5d305...
- styfle 9y ago
  Very cool! Thanks for the examples and linking back to the commit :+1:

by styfle 9y ago

MBlume 9y ago

Pretty sure this already existed with different syntax. Under those circumstances I'd probably use git svn, I always found git svn to be a better svn client than svn.

styfle 9y ago
Does git svn build a local git repo out of the svn server or just act as a normal svn client?

avar 9y ago

I implemented that feature in the 2.13 release, glad to see interest in it, more details on how it works & can be used from the commit message[1]: This allows for finding the last-good rollout tag given a known-bad <commit>. Given a hypothetically bad commit cf5c725, the git version to revert to can be found with this hacky two-liner: (git tag -l 'v[0-9]*'; git tag -l --contains cf5c725 'v[0-9]*') | sort | uniq -c | grep -E '^ *1 ' | awk '{print $2}' | tail -n 10 With this new --no-contains option the same can be achieved with: git tag -l --no-contains cf5c725 'v[0-9]*' | sort | tail -n 10 As the filtering machinery is shared between the tag, branch & for-each-ref commands, implement this for those commands too. A practical use for this with "branch" is e.g. finding branches which were branched off between v2.8.0 and v2.10.0: git branch --contains v2.8.0 --no-contains v2.10.0 1. https://github.com/git/git/commit/ac3f5a346860b824e083c5d305757c3260565475 https://github.com/git/git/commit/ac3f5a346860b824e083c5d305...

styfle 9y ago
Very cool! Thanks for the examples and linking back to the commit :+1: