geda-developers team mailing list archive

[DJ Delorie <dj@xxxxxxxxxxx>]

> 2) how important is it for the branch to be "latest master + LP###"
> rather than "latest state of LP###"?

One of pcb's big problems is that patches go stale pretty quickly.  It
would be very useful if a patch could be "maintained" such that, once
it's approved, it can be easily applied to master.  So the LP branches
are not just for testing, but also for keeping patches current until
they're done.

This is different than, say, a pre-release or major change branch,
where we want to have a more stable branch point to work off.

> 3) there may be a distinction between how you make changes *within*
> a patch branch, and how you merge the changes back once the branch
> is "ready".

Ideally we'd be able to pull the patch set from an LP branch into
master as a single commit, rather than have a string of patches that
just fix bugs in each other or whatnot.  One big problem I have with
patches is if they *don't* apply at first, it gets messy pretty
quickly trying to deal with them.

> If you decide that you want the feature branch workflow to involve
> history smashing,

I personally have no objection to collapsing the commit history into a
single entry when a patch set is collapsed into a single commit on
master.  In that case, the history for each branch/master reflects the
actions that occurred on that branch/master.  Losing the history of
how a patch evolves is no different than what happens when a user does
all the work locally and submits a completed patch.

I also have no particular desire to keep LP branches around forever.
They are temporary, and once their purpose is served, are no longer
useful.

> 5) if you decide that you definitely want feature branches to be
> "latest master + LP###", then you can either regularly merge from
> master to the feature branch, or you can regularly rebase the
> feature branch.

Which one leads to gitk showing the branch as a small thread off a
recent point in master?  What I'd like to avoid is having commit
points show up more than once in the tree view.