1

I have a project that makes DI using Dagger easier in Android. It is meant to bootstrap (or retrofit) new projects, not to be used as a library. Because of that, I encourage users to refactor certain parts of the project (package, class names, etc...), and I plan on providing a script to do it for them.

My question is, once projects have been bootstrapped using this one, and have made changes to the original code, how can they integrate upstream changes? I imagine they could create a branch off the initial commit, pull in the new changes, and then rebase onto it, but is there an easier solution?

Eliezer
  • 7,209
  • 12
  • 56
  • 103

1 Answers1

1

First, they need to keep a reference to that upstream repo, similar to the triangular workflow, except you won't contribute back through Pull Request to the "upstream" (here "template") repo:

https://cloud.githubusercontent.com/assets/1319791/8943755/5dcdcae4-354a-11e5-9f82-915914fad4f7.png

That way, you can git fetch upstream, and compare upstream/master with your own master, or even upstream/master and the previous upstream/master state (before the fetch), in order to detect any changes that you should incoporate into your current codebase.

Rebasing is not advised, as it changes the SHA1 of the branches being rebased, and would force the user to git push --force his/her branch to the origin repo.

A merge or even cherry-pick from upstream/master to the local branch being developed is less intrusive, and allows for a regular push afterwards.

VonC
  • 1,262,500
  • 529
  • 4,410
  • 5,250
  • Will a merge from `upstream/master` track the changes to the project since the most previous commit from `upstream/master` (e.g. refactoring the package) so that there aren't many conflicts? – Eliezer Jan 11 '16 at 06:39
  • 1
    @Eliezer the bottom line is, if two branches have diverged significantly, the risk of conflict is high no matter what. If the changes (in your repo) are minimal since the refactoring in upstream, then a merge may actually be able to do "the right thing": ie merging the right file (http://stackoverflow.com/a/3520055/6309). It won't be able to merge the right content though (http://stackoverflow.com/a/23630335/6309) – VonC Jan 11 '16 at 07:10
  • I think I get what you're saying. If there's a class in the bootstrap project `A` that a user refactors to be named `MyA`, and then upstream changes are made to `A`, git will know to apply those changes to `MyA`, and can cleanly merge depending on the change? – Eliezer Jan 11 '16 at 11:13
  • @Eliezer it will be able to do so *if* the content has not changed *too much*. If both the filename *and* its content have changed between the tow branches, there won't be any "clean" merge possible. The two might be considered as two separate elements to be manually merged. – VonC Jan 11 '16 at 11:15