Feature/gbp pull#39
Conversation
|
Other branches should be ff otherwise something is wrong. The second part makes sense but needs a test. |
OK, makes sense.
Good, point. There were not component unit tests back in the days I originally wrote this :) |
marquiz
force-pushed
the
feature/gbp-pull
branch
from
befb786 to
2749ea7
Compare
|
I now added unit test for the --all option. I didn't include the other commit for now. But, I still think there is something broken in the gbp-pull logic when --force is used. The currently checked-out branch is merged but the others are just reset which I see kind of bad because the end result depends on the currently checked out branch. For example, if I happened to be on pq branch the debian branch would be simply reseted to whatever the upstream has. But, if I happened to be on the debian branch it would be merged, instead. Any thoughts? |
Signed-off-by: Markus Lehtonen <markus.lehtonen@linux.intel.com>
This updates all remote-tracking branches (for the remote that is fetched from) whose local branch name is identical to the remote branch name. Signed-off-by: Markus Lehtonen <markus.lehtonen@linux.intel.com>
marquiz
force-pushed
the
feature/gbp-pull
branch
from
2749ea7 to
334ccef
Compare
|
I see you pulled the patches. Thanks! However, any comments on the --force logic question I raised? |
|
@marquiz could open another PR with you proposed change regarding merge vs. reset? The code in this PR is merged. |
2 participants
No description provided.