Skip to main content

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

Hi Axel

You really should learn to use EGit; it's actually very useable once you follow Laurent's advice and realize that the History View (which was cosmetic in CVS) is very rich in EGit.

To me the requirement is to have
- active branches for work in progress
- dead branches to avoid losing history
and to minimize the inconvenience downstream caused by not being able to 'remove' the dead branches upstream without permanently deleting them.

Giving dead branches a distinctive name allows them all to be deleted downstream with a select and delete action. This is tolerable until a better solution is found.

I don't see how you propose to facilitate hiding dead branches without manually examining each candidate for hiding. You assume "everyone probably knows on which bug branches he/she is actively working". I certainly don't. I've already lost control of some early branches from when I didn't understand EGit; I'm steadily cleaning up. As project leader I need to see what everyone is working on. Both you and Adolfo appear to have four active branches. Six digit numbers are not very mnemonic, so I doubt that you can remember them all.


        Ed Willink

On 17/08/2011 20:57, Axel Uhl wrote:

I don't understand your proposal. It takes me about 1 minute per bug to
check with Bugzilla whether it's really active. This becomes unscalable

personally, I see two primary use cases for the bug/* branches:

 - work on a fix for the bug
- understand a bug fix's history (this shows whether/where/when the fix was merged, but that's not my primary concern when I look at a bug's history).

I wouldn't use git as the primary source for understanding which bug is currently being worked on. I see Bugzilla as the means for this.

With this, and with regular fetch activities, I end up with bug/* branches and origin/bug/* branches which after the rename are duplicates of the corresponding archive/* and origin/archive/* branches. This clutters the list of branches in the local git of everyone fetching regularly and requires time for everyone locally to remove the now redundant bug/* branches. Besides, a quick glance at the local list of branches then cannot even be used to detect whether a bug is closed or not. This would require a "git ls-remote" instead (is this supported by eGit?).

once there are 100 bug branches. With the renaming, I know that I lose
no significant history by deleting the archive branches, and there are
only a modest 10, hopefully decreasing to 5, active bug branches to
check for deletion when I want further pruning.

Deleting an archive branch may lose interesting history for developments on bug/* branches which so far haven't been merged into any other branch but then have been classified as WONTFIX or similar. Conversely, everyone probably knows on which bug branches he/she is actively working. Tracking can then be limited to those bug/* branches.

Therefore, I again would like to suggest to just not rename bug/* branches after merging.

-- Axel
_______________________________________________ mailing list

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

Back to the top