Mail Archives: geda-user/2015/09/03/09:36:15
On Thu, Sep 03, 2015 at 02:18:48PM +0200, Markus Hitter (mah AT jump-ing DOT de) [via geda-user AT delorie DOT com] wrote:
> Am 02.09.2015 um 23:43 schrieb Vladimir Zhbanov (vzhbanov AT gmail DOT com) [via geda-user AT delorie DOT com]:
> > On Wed, Sep 02, 2015 at 01:21:21PM +0200, Markus Hitter (mah AT jump-ing DOT de) [via geda-user AT delorie DOT com] wrote:
> > ...
> >> - Once a topic branch is done ( = all commits on master) it gets removed. Duplicate commits are pointless.
> > I don't think so. If you use 'git cherry-pick', and it is sometimes
> > better than merging/rebasing, you'll have duplicate commits in different
> > branches. Then you can do just 'git merge -s ours ...' to not include
> > unneeded patches and to have history as is, having at the same time
> > necessary branches in master and marking branch as fully merged/closed.
> > (I'm just working on Riccardo Lucchese's patch-set and I believe doing
> > it this way (and probably using the strategy 'theirs' to continue the
> > branch) would be the best option.)
>
> TBH, I consider the concept of merging to be a concept of the past. Following development by rebasing is much cleaner and if each commit on a branch is fine, these commits can be picked to master just as well. Fast-forward merges and fast-forward rebases do the same anyways.
>
> When following master by rebasing it doesn't matter wether you use 'ours' or 'theirs', either way only differences are left in the branch. If no differences remain, the branch becomes empty (and pointless).
I've meant the case when it's easier to rearrange using cherry-pick some
useful commits and then apply them to master, and make up a new branch
from others, re-applying the rest of patches, rather than rebase all
stuff as is. In such a case, history may be left as is to let other
developers cherry-pick some other changes which, e.g., are waiting for
moving to using more recent libs, or requiring more close attention to
be applied. Using 'ours' merge may mean the work on the branch has been
completed, and all needed stuff is already in master or in other
branches, leaving opportunities of pulling something from there and of
allowing the developers to look through the real history. OTOH, the
number of branches could be decreased.
To make it more clear, now I'm working on Riccardo Lucchese's patch set,
the first version of which Roland has applied as a new branch to the
geda-gaf repo. Now I see some patches require bumping of gtk+ or glib
versions, some are not needed, some require reformatting, and some
cannot be applied for various reasons (e.g., some mistakes). So, I've
decided to rearrange and reformat them (using stgit and fugitive), and
then apply only those of them which I am certain aren't breaking
anything. Then, I'm planning to merge the existing branch using the
'ours' strategy and a bit later make another one which would contain
valuable changes that could be used in later releases.
...
> > And... Why don't you send your proposal to the devel list as well?
>
> Because there is no developer list?
>
> http://wiki.geda-project.org/geda:mailinglists
The link
https://lists.launchpad.net/geda-developers/
is on the developers' page
http://wiki.geda-project.org/geda:developer#developer_mailing_list
Oh, for some reason, I see your posts there. You seem to be a bit
forgetful ;)
Cheers,
Vladimir
- Raw text -