search

mrward / nuget

Modified version of NuGet.Core that works with MonoDevelop on Linux. Used in the MonoDevelop NuGet addin.
Other
11 stars 4 forks source link

Branch structure looks strange #3

Closed ArsenShnurkov closed 9 years ago

ArsenShnurkov commented 9 years ago

There are many branches which are not merged into master. Black line for master branch is replaced by something another. It not looks like

2010-01-05, Vincent Driessen - http://nvie.com/posts/a-successful-git-branching-model/ 2011/08/31, Scott Chacon - http://scottchacon.com/2011/08/31/github-flow.html

mrward commented 9 years ago

The master branch is tracking master on nuget.codeplex.com. Since the last time I updated the master branch on my fork the NuGet team have added only one commit to master on nuget.codeplex.com.

ArsenShnurkov commented 9 years ago

Why not to make some "mono_master" branch then?

To merge all other branches into one.

mrward commented 9 years ago

I could do but I would never use that branch. Currently everything is on feature branches.

The plan for the repository was to be a mirror of the official NuGet repository with features branches so you can see the patches that have been applied to a particular release of NuGet.

ArsenShnurkov commented 9 years ago

But I am unable to merge other branches (2.8.3-monodevelop and 2.8.5-monodevelop in particular) into master branch, because feature branches should be rebased before merging (and they are not).

For example, I can't push a simple patch for master branch into your branch without conflicts, because your branch is not rebased - see https://github.com/mrward/nuget/pull/7

I understood, that branches should not be rebased (for the purpose of creating patches), because they are derived from the commits/tags in master, where versions was fixed/released (and not from the latest point of master).

So, I don't understood, how to get latest sources with all patches (this is what master branch should do). This happens, because new features are not merged into master (or into another single branch).

I can get 2.8.5-monodevelop branch (or create my new feature branch from it) and make my commits for 2.8.5-monodevelop but then I don't understand how I should gather patches from other branches (like 2.8.3 registry check and others, and new changes from master branch).

I would never use that branch

So, what one should do? 1) take master 2) make his own new branch from master 3) duplicate each your branch, rebase, merge into the new branch 4) merge the final result into master (what if whey don't accept these changes?) 5) and only after that make his new feature branch 6) push new feature into master (and into your branches) right ?

This questions are risen because I don't see, that your oldest version (2.8.5-monodevelop) merges all changes from previous versions (no links in github graph). May be earlier changes are merged into master earlier, but I don't know about that.

If you haven't managed to push changes into upstream before 2.8.5 release, then shouldn't you accumulate them in latest branch like this - https://github.com/mrward/nuget/pull/8 ?

I can imagine that you just create 2 patches and apply them during the build, but you force all maintainers to repeat doing the same.

mrward commented 9 years ago

Unfortunately this is how the official NuGet source looks like. The official NuGet master branch has not been updated. I was looking at this yesterday and one fix that went into master never made it into any of the 2.8 branches.

Basically the whole mrward/nuget repo is supposed to be a copy of the official NuGet repository. Then I create a branch off the current NuGet branch (e.g. 2.8.5) and name it after monodevelop and then apply some patches which are cherry-picked.

This basic process is also the same process that is done on mono/nuget. It is basically a mirror of the official NuGet source code but separate release branches are created for mono that have mono specific patches on it.

Not sure exactly what the problem is. If you want to make a change to 2.8.5-monodevelop branch then fork the repo and make a change to the 2.8.5-monodevelop branch. To see the changes you can compare the 2.8.5 branch with the 2.8.5-monodevelop branch.