Hi
I've eliminated all the (my) archive branches and pruned my obsolete
bug branches.
It looks as if there are a couple that Axel could prune and a few
more that Adolfo could prune.
In EGIT, just delete all remote tracking archive/bug branches and
then fetch from upstream to get a cleaned up display.
I'm finding that neither rebase nor merge works very satisfactorily
when there is a conflict, and I find the pop-up dialog and
OURS/THEIRS bracketing unfathomable when both are MINE, particularly
when changes seem to be whitespace related. I find a manual cherry
pick iteration a much better way to rewrite an out-of-date branch
onto local master. Once complete the out-of-date branch can be reset
hard to local master, which can then be reset hard back to upstream
master.
Regards
Ed
On 26/08/2011 16:54, Adolfo Sánchez-Barbudo Herrera wrote:
Ed,
+1. Let's see if the SR1 RC2 is smoothly done the next week, so
that I might spend some time sorting out the bugs and branches I
have in hands.... I think that some of them are solved and they
could probably be removed.
Regards,
Adolfo.
El 26/08/2011 9:58, Ed Willink escribió:
Hi
I think that we felt that archive branches might be useful for
retaining the history of a particular branch.
This does not appear to be the case. Once the successful branch
is rebased onto master, all the relevant history is 'merged', so
there is no particular use for the archive branch which is just
an end-of-activity marker. The true history is identifiable from
the [xxxxxx] commit comment prefixes and the compressed time
recap at the rebase transaction. If a real marker for the
end-of-activity is required then a tag is of course possible.
It seems that the only 'bug' branches worth keeping are those
that have not been exploited, so I propose that
bug/xxxxxx is a work in progress that will probably be exploited
archive/xxxxxx is a work abandoned, that might be revivable
later
There should be very few archive/xxxxxx, and only a few
bug/xxxxxx.
Regards
Ed
|
