[dev] [commits] Horde-Hatchery branch ActiveSync updated. cc9c0cfd083b224741082301389822bc075e5e3c

[Michael Rubinsky]

Quoting Michael M Slusarz <slusarz at horde.org>:

> Quoting Michael Rubinsky <mrubinsk at horde.org>:
>
>> Quoting Michael M Slusarz <slusarz at horde.org>:
>>
>>> This is a major issue with updating/rebasing a branch: it makes  
>>> these commit messages worthless.  I have no idea which of these  
>>> changes are exclusive to the ActiveSync branch and which changes  
>>> are the result of rebasing from master.  Until/unless someone can  
>>> alter the commit generation script to fix this, I think we need to  
>>> avoid rebasing/updating topic branches.
>>
>> We were recently having some major discussion about this in IRC,  
>> and then also between Ben and I in email since we were both having  
>> issues with our topic branches. (Ben, can you forward my reply to  
>> your email to to dev@? I can't seem to find my Sent Mail copy).  
>> Personally, I think it's a major issue to not keep topic branches  
>> current.  I agree the _branch_ history can get muddled, but that is  
>> resolved once the topic branch is merged, then rebased with remote  
>> master. Yes, for some topic branches that are short-lived, this  
>> probably isn't an issue...but for branches that either introduce  
>> major changes, or are likely to be longer living, I think it's  
>> important to keep the branches in sync...especially if the idea is  
>> to have other people/devs want to try out the code, it should be  
>> the most recent code from master, with only the changes relevant to  
>> the topic.
>
> I have no problems with keeping the topic branch current (I do the  
> same thing).  The issue is solely with our reporting script.
>
>> Does anyone know of other major projects using Git, and what they  
>> do to handle this sort of thing?  I've seen projects with SVN that  
>> doe things like adding commits that basically just say "Syncing  
>> with trunk" or similar, but I don't think something like that is  
>> possible with the way git does things...maybe the answer lies  
>> somehere in our post-commit scripts?
>
> That's what I think - it's our post-commit scripts that needed  
> tweaking.  I just don't have a bunch of time currently to look into  
> this.  IIRC, when I was originally modifying the script, I found  
> almost zero documentation in the rest of the web about modified  
> post-commit e-mail scripts.  Maybe things have changed, or my  
> google-fu is weak, but that was the situation.
>
> I am positive that there is some way with the myriad of git commands  
> to determine which commits in a topic branch are already contained  
> in the master branch.  In fact, this is what git cherry does - the  
> challenge is to write the code that would exclude these shared  
> commits from the e-mail messages (maybe replacing with a single line  
> of 'synced X # of changes from master', possibly with a revision  
> range string).

Yes, it *looks* like doing something like `git cherry master` and  
doing some comparisons in the first do loop in  
generate_update_branch_email() should do the trick. If nobody beats me  
to it, I'll play around with it and see what I can come up. The only  
thing I'm not sure about is that since the revision ids are different  
in each branch, instead of ignoring them, should we report them as  
something like "rev xxx appears to be cherry-picked from yyy on  
master" or similar? It feels wrong to just count them/ignore them  
since the ids are different.

Thanks,
mike

--
The Horde Project (www.horde.org)
mrubinsk at horde.org

"Time just hates me. That's why it made me an adult." - Josh Joplin