All Projects → aspiers → git-explode

aspiers / git-explode

Licence: GPL-2.0 License
Explode linear sequence of git commits into topic branches

Programming Languages

python
139335 projects - #7 most used programming language
shell
77523 projects

Projects that are alternatives of or similar to git-explode

comptroller
A simple and lightweight tool to manage your monorepo.
Stars: ✭ 26 (-39.53%)
Mutual labels:  dependency-manager, dependency-analysis
alphasql
AlphaSQL provides Integrated Type and Schema Check and Parallelization for SQL file set mainly for BigQuery
Stars: ✭ 35 (-18.6%)
Mutual labels:  dependency-analysis, dependency-graph
Dependency Cruiser
Validate and visualize dependencies. Your rules. JavaScript, TypeScript, CoffeeScript. ES6, CommonJS, AMD.
Stars: ✭ 2,326 (+5309.3%)
Mutual labels:  dependency-analysis, dependency-graph
merge-confidence
The home of WhiteSource's Merge Confidence feature, for Renovate and WhiteSource Remediate
Stars: ✭ 41 (-4.65%)
Mutual labels:  dependency-manager, dependency-analysis
kebechet
I'm Kebechet bot, goddess of freshness - I will keep your source code fresh and up-to-date
Stars: ✭ 23 (-46.51%)
Mutual labels:  dependency-manager, dependency-analysis
asset-graph-webpack-plugin
Webpack plugin to easily get assets dependency graph based on entry point
Stars: ✭ 13 (-69.77%)
Mutual labels:  dependency-analysis, dependency-graph
javascript
Basic Primitives Diagrams for JavaScript - data visualization components library that implements organizational chart and multi-parent dependency diagrams, contains implementations of JavaScript Controls and PDF rendering plugins.
Stars: ✭ 46 (+6.98%)
Mutual labels:  dependency-analysis, dependency-graph
react
Basic Primitives Diagrams for React. Data visualization components library that implements organizational chart and multi-parent dependency diagrams.
Stars: ✭ 15 (-65.12%)
Mutual labels:  dependency-analysis, dependency-graph
efda
Evaluation Framework for Dependency Analysis (EFDA)
Stars: ✭ 34 (-20.93%)
Mutual labels:  dependency-analysis
flatn
flat node dependencies
Stars: ✭ 18 (-58.14%)
Mutual labels:  dependency-manager
revctrl.org
An extract, as complete as I can make it, of content from the revctrl.org wiki
Stars: ✭ 13 (-69.77%)
Mutual labels:  revision-control
express-router-dependency-graph
A static code analysis tool that creates a dependency graph for express routing.
Stars: ✭ 26 (-39.53%)
Mutual labels:  dependency-graph
git-bonsai
Tend the branches of your git garden
Stars: ✭ 15 (-65.12%)
Mutual labels:  branches
ansible-viz
Graph relationships between Ansible playbooks / roles / tasks / vars etc. via static analysis
Stars: ✭ 33 (-23.26%)
Mutual labels:  dependency-graph
dependency-check-py
🔐 Shim to easily install OWASP dependency-check-cli into Python projects
Stars: ✭ 44 (+2.33%)
Mutual labels:  dependency-analysis
oga-maven-plugin
🧩 Old GroupIds Alerter - A Maven plugin that checks for deprecated groupId+artifactId (e.g. did you know that graphql-spring-boot-starter moved from com.graphql-java to com.graphql-java-kickstart?).
Stars: ✭ 22 (-48.84%)
Mutual labels:  dependency-analysis
npmdc
ruby gem to check for missed NPM dependencies
Stars: ✭ 38 (-11.63%)
Mutual labels:  dependency-analysis
change-git-author
Update the commit history of your git repository to resolve incorrect author information.
Stars: ✭ 58 (+34.88%)
Mutual labels:  commits
ngmodule-viz
Visualize the dependencies between the NgModules in your Angular 2+ application
Stars: ✭ 35 (-18.6%)
Mutual labels:  dependency-graph
Injection
Lightweight swift dependency manager
Stars: ✭ 15 (-65.12%)
Mutual labels:  dependency-manager

git-explode

git-explode is a tool for automatically exploding a single git branch into a number of smaller branches which are textually independent. It uses git-deps to automatically detect textual dependencies between the commits in the branch, and calculates the grouping and ordering of commits into independent sub-topics from which the new branches are created.

I have blogged about git-explode and related tools, and also publically spoken about the tool several times:

Use case #1

The most obvious use case for this tool is helping improve the "hygiene" of branch management, so that each branch in your repository is tightly and cleanly scoped to a single logical topic.

For example during work on feature branch, you might become aware of an opportunity to refactor some existing code, and might decide to take advantage of that opportunity immediately, by adding refactoring commits to the tip of the feature branch. And during the refactoring, you may even spot a bug, and end up also adding a bugfix to the same feature branch.

So now you have a feature branch which is polluted by commits which perform refactoring and bugfixing. If you were to submit this branch for code review as a single GitHub pull request (or GitLab merge request, or Gerrit change topic), it would be a lot harder for your collaborators to review than if you had separately submitted three smaller reviews, one for the bugfix, one for the refactoring, and one for the new feature.

In this scenario, git-explode comes to the rescue! Rather than you having to manually separate out the commits into topic branches, it can do all the hard work for you with a single command.

Textual vs. semantic (in)dependence

Astute readers will note that textual independence (as detected by git-deps and used by git-explode) is not the same as semantic / logical independence. Textual independence means that the changes can be applied in any order without incurring conflicts, but this is not a reliable indicator of logical independence. (This caveat is also noted in the README for git-deps.)

For example a change to a function and corresponding changes to the tests and/or documentation for that function would typically exist in different files. So if those changes were in separate commits within a branch, running git-explode on the branch would place those commits in separate branches even though they are logically related, because changes in different files (or even in different areas of the same files) are textually independent.

So in this case, git-explode would not behave exactly how we might want. And for as long as AI is an unsolved problem, it is very unlikely that it will ever develop totally reliable behaviour. So does that mean git-explode is useless? Absolutely not!

Firstly, when best practices for commit structuring are adhered to, changes which are strongly logically related should be placed within the same commit anyway. So in the example above, a change to a function and corresponding changes to the tests and/or documentation for that function should all be within a single commit. (Although this is not the only valid approach; for a more advanced meta-history grouping mechanism, see git-dendrify.)

Secondly, whilst textual independence does not imply logical independence, the converse is much more commonly true: logical independence typically implies textual independence. So while it might not be too uncommon for git-explode to separate logically-related changes into different branches, it should be pretty rare that it groups logically unrelated changes on the same branch. Combining this with the fact that git makes it easier to join commits on separate branches back together into one branch than to split them apart suggests that git-explode still has plenty of potential for saving effort.

Thirdly, it is often unhelpful to allow the quest for the perfect become the enemy of the good - a tool does not have to be perfect to be useful; it only has to be better than performing the same task without the tool.

Further discussion on these points can be found in an old thread from the git mailing list.

Ultimately though, "the proof is in the pudding", so try it out and see!

Other use cases

As already explained above, the most obvious use case is cleaning up the mess caused by logically independent commits all mashed together into one branch. However here are some further use cases. If you can think of others, please submit them!

Use case #2: Decompose changes for porting

If you need to backport or forward-port changes between two branches, git-explode could be used to first decompose the source branch into textually independent topic branches. Then before any porting starts, informed decisions can be made about which topics to port and which not to port, and in which order. Each decomposed topic branch is guaranteed to be textually independent from the others, so they can be ported separately - indeed even concurrently by different people - thereby greatly reducing the risk of conflicts when the independent topic branches are merged together into the target branch.

Use case #3: Publishing a previously private codebase

Emmet's idea about a company who needs to publish a private codebase but needs to clean it up first. Similar to 1. but on a bigger scale.

Use case #4: Breaking down giant commits

Split giant commit into commits one per hunk, then regroup into topics along with previous related commits. (Note that the previous related commits are required here for the regrouping to work, since hunks within a single commit are by definition independent of each other.)

Installation

Please see the INSTALL.rst file.

Usage

Usage is fairly self-explanatory if you run git explode -h:

usage: git-explode [-h] [--version] [-d] [-p PREFIX] [-c NUM] BASE HEAD

Explode linear sequence of commits into topic branches

positional arguments:
  BASE                  base of sequence to explode
  HEAD                  head of sequence to explode

optional arguments:
  -h, --help            show this help message and exit
  --version             show program's version number and exit
  -d, --debug           Show debugging
  -p PREFIX, --prefix PREFIX
                        prefix for all created topic branches
  -c NUM, --context-lines NUM
                        Number of lines of diff context to use [1]

Development / support / feedback

Please see the CONTRIBUTING.rst file.

History

I first announced the intention to build this tool on the git mailing list in May 2016; however at the time I was under the mistaken impression that I could build it out of the git-splice and git-transplant commands which I was working on at that time.

Thanks to SUSE's generous Hack Week policy, I have had the luxury of working on this as a Hack Week project.

In May 2018 I took advantage of another Hack Week to apply more polish and make the first release. This was in preparation for demonstrating the software at a Meetup event of the Git London User Group.

License

Released under GPL version 2 in order to be consistent with git's license, but I'm open to the idea of dual-licensing if there's a convincing reason.

Note that the project description data, including the texts, logos, images, and/or trademarks, for each open source project belongs to its rightful owner. If you wish to add or remove any projects, please contact us at [email protected].