[petsc-dev] Updating MOAB version during download

[Jed Brown]

Barry Smith <bsmith at mcs.anl.gov> writes:

> On Jun 16, 2014, at 9:20 PM, Jed Brown <jed at jedbrown.org> wrote:
>
>> Barry Smith <bsmith at mcs.anl.gov> writes:
>>>> Are you going to add the appropriate upstream workflow to all the
>>>> --download packages?  This sounds intractable.
>>> 
>>>  I am not putting upstream workflow into any download packages. I am
>>>  wanting to do something very simple, let —download-xxx replace me
>>>  manually git clone xxxx; git checkout yyyy on some package. That is
>>>  all. (Where yyy may be a branch or a commit-hash depending on the
>>>  circumstances).
>> 
>> It clones and checks out the commit.  You can checkout the BRANCH
>> (branches are all about how the upstream package CHANGES) when you want
>> to contribute upstream (and you're entirely on your own to match up with
>> their workflow).  Why is that not sufficient?
>
>    Since —download-xxx can already track a branch 

I don't want that because tracking a branch is a broken model.  It is
just not enforced because "git checkout branchname" works just as well
as "git checkout commit-hash".

>    the only thing that is missing is managing merges from these
>    branches into next and master so that things don’t break and don’t
>    require people to remember “oh since I am tracking a moab branch I
>    have to be really careful when I merge into next/master and
>    manually fix things”.

Forget the merge problem, this is already a broken model at square one.
There is no reproducibility or reviewability.  

>    Ideally it would automatically switch from branch to commit-hash on
>    such merges in xxx.py

It should always use a commit.  The branch can change and be deleted
later.  The commit is permanent so long as it has been accepted.

>    If that is not possible then it would print a useful message to the
>    screen telling one to manually fix the xxx.py commit-hash to the
>    appropriate value when I do the merge.
>
>    Since you and Satish just go on and on about how this is a bad idea
>    instead of just telling me how to make git do this I have to assume
>    that git cannot do it and you guys are just trying to find
>    rationalizations of why I would not want to do this rather than
>    just admitting git cannot do it. So

I don't care what the tool can do because it's a broken model.  A commit
hook can check for compatibility, but it's not supposed to modify the
tree (and I think that doing so would be a sin due to ambiguous
specification).
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 818 bytes
Desc: not available
URL: <http://lists.mcs.anl.gov/pipermail/petsc-dev/attachments/20140617/e1641142/attachment.sig>