James <[email protected]> writes: > There are some quirks (for me) that might be easier to explain or > resolve as a 'non git-fu-er' such as: > > It seems that the 'update source' button doesn't update staging, only > master, so I always have to run git checkout staging, git pull and > then merge staging manually with dev/local_working.
Personally, I rebase my patches on master. If staging has moved ahead, that means that pushing will fail. One can either wait until master has caught up, or one can rebase on the current staging. However, if the current staging has to be backed out for some reason (like Patchy complaining), then any rebase on staging will reintroduce the problematic patches. One can forge ahead by doing something like git rebase origin/staging dev/local_working~0 which will only rebase a _copy_ of local_working on staging, leaving the original local_working intact. > As we eventually push to staging (and not master) and as staging > should theoretically always be the same as (or ahead of) master, that > updating staging rather than master would make more sense? Or perhaps > just do both trees. Both, I should think. > Also I don't know if we can automate the merging of staging with > dev/local_working (or if that is dangerous to do) so that the two are > always the same? As I have a very primitive kind of workflow there may > be problems doing that. See above. > So in those 'one-off' cases I can just check in to staging and ask > someone to cherry pick to 2.18. I think that the stable branches should have their own dedicated cherry-picker (depending on how long we maintain stuff, this can be different people for different branches). So far that has been me with the latest releases. -- David Kastrup _______________________________________________ lilypond-devel mailing list [email protected] https://lists.gnu.org/mailman/listinfo/lilypond-devel
