search

ome / scc

OME tools for managing the Git(Hub) workflow
https://pypi.org/project/scc/
GNU General Public License v2.0
0 stars 15 forks source link

Don't recursively merge branches #194

Closed manics closed 9 years ago

manics commented 9 years ago

scc merge dev_4_4 --comment -Dnone -Imanics/snoopys-sandbox:added-2 will attempt to merge manics/snoopys-sandbox:added-2 into the main (expected) and submodule repo (oops).

sbesson commented 9 years ago

Ah, likely a side-effect of improvements in https://github.com/openmicroscopy/snoopycrimecop/pull/193. Since we have potentially non-matching fork/main repo names, there is no way to guess whether a branch is related to the top-level repository or a submodule.

manics commented 9 years ago

How about limit branch-merging to the top-level? I'll open a PR if this sounds reasonable.

sbesson commented 9 years ago

One of the use cases of this branch merging was actually to have custom Bio-Formats branches /cc @melissalinkert @chris-allan

manics commented 9 years ago

git.py::GitRepository::merge_base() might do the trick

chris-allan commented 9 years ago

This is why in almost all our PR focused workflows we use --shallow.

sbesson commented 9 years ago

Let's have a discussion soon, I just realized the recent changes to support repos with mismatching names broke (or at least add unnecessary complexity) to the workflow described above. At this point, I would rather list all the concrete use cases and make an proper decision on the design on the custom branch merging command.

manics commented 9 years ago

OK. This only came up because I was working on the conflicting files comment PR https://github.com/manics/snoopycrimecop/compare/possible_conflicts_new