Re: LILY-GIT PITA

[David Kastrup]

James <address@hidden> 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