Hi All,
There are really two separate issues here I think. One is "squashing"
within the Amber tree - I think this is what led to what Dave
originally observed. This probably should be done rarely if at all,
and then only if the change is a very localized one: for example, if I
make a bunch of incremental changes to some of the trajectory files in
cpptraj on a local branch, say Traj_AmberNetcdf.cpp and
Traj_AmberRestartNC.cpp, I could squash those into a single commit
when merging back to master without making the history obscure.
However, if I also on that branch modify stuff in sander, or the docs
etc, I should *not* squash because then the history can get confusing
(as Dave noted).
The second is "squashing" when moving over from GitHub. Right now this
is a crucial step to avoid polluting the Amber GIT history. These
"squashes" are localized to the packages they belong to (cpptraj,
parmed, pytraj) and will not affect the history of other files in
AmberTools. As long as a record of the "squash" is kept (which is what
cpptraj does currently) I don't feel this is a big problem (it's even
less of a problem if merging from GitHub is done after every pull
request, which it probably should be). But concerns have been raised,
so before any hasty action is taken I think it would probably be a
good idea for us all to hash this out at the developers meeting.
-Dan
On Wed, Feb 24, 2016 at 12:59 PM, Ross Walker <ross.rosswalker.co.uk> wrote:
>
>> On Feb 24, 2016, at 11:32 AM, Hai Nguyen <nhai.qn.gmail.com> wrote:
>>
>> hi,
>>
>> We only squash commits for cpptraj, pytraj and parmed when pulling commits
>> from github repos. Last year pytraj has > 1000 commits, cpptraj > 1000
>> commits, parmed > 1000 commits . If not squashing to few big commits, amber
>> git log will be populated and even more difficult to debug other programs.
>>
>
> I don't see the issue? These would be relevant to the files in those packages. So if I did git log ./foo I would not see all those logs so it wouldn't be an issue.
>
>> So if anyone wants to 'git blame', ... any files in those packages, he/she
>> should check corresponding github repo https://github.com/Amber-MD
>
> No no no! - this is not acceptable. We have centralized servers for AMBER. If you want to use external providers fine but it is not acceptable to require other AMBER developers to go there. This issue needs to be fixed before it gets out of hand and I am prepared to make an executive decision on this.
>
> Ross
>
>
>
> _______________________________________________
> AMBER-Developers mailing list
> AMBER-Developers.ambermd.org
> http://lists.ambermd.org/mailman/listinfo/amber-developers
--
-------------------------
Daniel R. Roe, PhD
Department of Medicinal Chemistry
University of Utah
30 South 2000 East, Room 307
Salt Lake City, UT 84112-5820
http://home.chpc.utah.edu/~cheatham/
(801) 587-9652
(801) 585-6208 (Fax)
_______________________________________________
AMBER-Developers mailing list
AMBER-Developers.ambermd.org
http://lists.ambermd.org/mailman/listinfo/amber-developers
Received on Wed Feb 24 2016 - 12:30:05 PST
