Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [] 'archive' branches

I removed archive/348504 as requested. Not sure which differences in git history you are referring to. I don't know anymore which commit ID archive/348504 pointed to...

-- Axel

On 8/30/2011 7:19 AM, Ed Willink wrote:
Hi Axel

Looking at for ~11-Jun shows that

archive/348504 is just a 'tag' and so might as well be deleted

archive/348502 successfully archives a branch development history, which
I had concluded was not possible. The corresponding EGIT history looks
messier, but perhaps merge is good after all.

Can you explain what you did that makes the history for 348502 better,
and that for 348504 worse (there is a kink on EGIT) than I have been
achieving by cherrypicking/rebasing?

349157. See Bugzilla.



On 29/08/2011 22:03, Axel Uhl wrote:

what about 349157? The bug is still open, but Ed seemed to have a plan
how to fix this that exceeded what I had in mind doing. Shall I close
/ delete the branch?

I've "archived":

- 348502
- 348504

344368 and 349117 I consider important work in progress. I just
currently lack the time to continue on them and hope to be able to
pick them up early October again.

-- Axel

On 08/29/2011 10:36 AM, Ed Willink wrote:

I've eliminated all the (my) archive branches and pruned my obsolete bug


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.



On 26/08/2011 16:54, Adolfo Sánchez-Barbudo Herrera wrote:

+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.


El 26/08/2011 9:58, Ed Willink escribió:

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.



_______________________________________________ mailing list

_______________________________________________ mailing list

No virus found in this message.
Checked by AVG -
Version: 10.0.1392 / Virus Database: 1520/3865 - Release Date: 08/29/11

_______________________________________________ mailing list

Back to the top