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

[Michael M Slusarz]

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

michael

-- 
___________________________________
Michael Slusarz [slusarz at horde.org]