Mail Archives: geda-user/2012/11/21/14:49:59
Markus Hitter wrote:
> Am 20.11.2012 20:14, schrieb Britton Kerin:
>> 3. Bob rebases, which breaks something that he doesn't catch
> > 4. Bob pushes
> > 5. Its a hard mess to sort out since you don't have any
>> working version with Bob's changes in the canonical repository
>
> The idea is to rebase not the master branch, but feature/debug
> branches and cherry-pick the reviewed parts of debug/feature branches
> into master until the other branch dissolves into nothing. This way
> you can bisect in detail on the master branch to find regressions.
>
> Merging tends to expose the problem you describe. A merge is like one
> big commit with all the changes between two branches. When searching
> regressions, you can go back on only one of the two branches. What, if
> both branches work fine, but not the combination/merge of both?
>
>
> my $0.02
> Markus
>
Hi all,
FWIW, I (often) create a patch from a commit in a topic branch and apply
that patch to master.
This keeps the same hash in both master and the topic branch, while
cherry-picking gives a different (new) hash for the commit.
Dunno if this breaks git internal stuff though, never had any problems.
Kind regards,
Bert Timmerman.
- Raw text -