Re: Git autostash doesn't

2017-03-09 Thread Brandon Allbery 
On Thu, Mar 9, 2017 at 5:39 PM, Ryan Schmidt 
wrote:
>
> > On Mar 9, 2017, at 14:18, Brandon Allbery  wrote:
> > On Thu, Mar 9, 2017 at 2:51 PM, Ryan Schmidt 
> wrote:
> > Why won't it automatically stash? Usually it does, but apparently not
> when there are conflicts.
> >
> > The manpage for git pull warns that --autostash has edge
> cases/restrictions.
>
> I only see:
>

Gleh. I thought there was a full discussion in there somewhere, but I just
tried to chase it through git-rebase and git-config and neither had more
than the minimal warning. But I thought one of the issues people raised
against making autostash the default was specifically that there are nasty
edge cases other than the mentioned one of possibly leading to significant
conflicts when the stashed changes are applied.

That said, there is also the implicit one: it's only applicable if
rebasing. Merges will merge with your changes, not stash them; rebases need
to work from a tree that matches a series of upstream commits (possibly
with additional local commits, but no uncommitted changes) and force
stashing.

-- 
brandon s allbery kf8nh   sine nomine associates
allber...@gmail.com  ballb...@sinenomine.net
unix, openafs, kerberos, infrastructure, xmonadhttp://sinenomine.net

Re: Git autostash doesn't

2017-03-09 Thread Ryan Schmidt 

> On Mar 9, 2017, at 14:18, Brandon Allbery  wrote:
> 
> 
> On Thu, Mar 9, 2017 at 2:51 PM, Ryan Schmidt  wrote:
> Why won't it automatically stash? Usually it does, but apparently not when 
> there are conflicts.
> 
> The manpage for git pull warns that --autostash has edge cases/restrictions.

I only see:

 --autostash, --no-autostash
 Before starting rebase, stash local modifications away (see git-stash(1)) 
if
 needed, and apply the stash when done.  --no-autostash is useful to 
override
 the rebase.autoStash configuration variable (see git-config(1)).

 This option is only valid when "--rebase" is used.

Re: Git autostash doesn't

2017-03-09 Thread Brandon Allbery 
On Thu, Mar 9, 2017 at 2:51 PM, Ryan Schmidt 
wrote:

> Why won't it automatically stash? Usually it does, but apparently not when
> there are conflicts.


The manpage for git pull warns that --autostash has edge cases/restrictions.

-- 
brandon s allbery kf8nh   sine nomine associates
allber...@gmail.com  ballb...@sinenomine.net
unix, openafs, kerberos, infrastructure, xmonadhttp://sinenomine.net

Re: gitlab tags

2017-03-09 Thread Mojca Miklavec 
On 9 March 2017 at 20:34, Jonathan Stickel wrote:
> On 3/9/17 11:26 , Mojca Miklavec wrote:
>>
>> I would say that we should create a PortGroup for GitLab.
>
> Sure, that would be helpful, but it looks like only 3 ports are currently
> associated with gitlab:
>
> So probably not worth the work at the moment.

It doesn't matter if that contributes (a lot) to simplicity of the Portfiles.

Mojca

Git autostash doesn't

2017-03-09 Thread Ryan Schmidt 
I don't understand why I get the error:

Please commit your changes or stash them before you merge.

when the command I'm running (via "sudo port sync") is "/opt/local/bin/git pull 
--rebase --autostash".

Why won't it automatically stash? Usually it does, but apparently not when 
there are conflicts.

Re: gitlab tags

2017-03-09 Thread Jonathan Stickel 

On 3/9/17 11:26 , Mojca Miklavec wrote:

On 9 March 2017 at 16:42, Jonathan Stickel  wrote:

I am trying to make a port for git-latexdiff. It is hosted on gitlab:

https://gitlab.com/git-latexdiff/git-latexdiff

The project has "tags" which look similar to github's tags (and releases). I
am having trouble specifying the "master_sites" and "distname" variables for
the port in order to download the appropriately tagged tarball. The download
link, e.g.,

https://gitlab.com/git-latexdiff/git-latexdiff/repository/archive.tar.gz?ref=v1.1.4

automatically morphs into a download file of

git-latexdiff-v1.1.4-dc84273afc2e366d6c4f98a07052e651c7d297dd.tar.gz

I've used the github portgroup to mange this with github-hosted ports, but
there is no "gitlab" portgroup.


I would say that we should create a PortGroup for GitLab.

Mojca



Sure, that would be helpful, but it looks like only 3 ports are 
currently associated with gitlab:


[...]/release/tarballs/ports $ grep -Ri "gitlab" .
./archivers/libaec/Portfile:homepage 
https://gitlab.dkrz.de/k202009/libaec
./gnome/uhttpmock/Portfile:homepage 
https://gitlab.com/groups/${name}
./kde/kcm-baloo-advanced/Portfile:git.url 
https://gitlab.com/baloo-kcmadv/baloo-kcmadv.git
./kde/kcm-baloo-advanced/Portfile:homepage 
https://gitlab.com/baloo-kcmadv/baloo-kcmadv


So probably not worth the work at the moment.

Jonathan

Re: gitlab tags

2017-03-09 Thread Jonathan Stickel 

On 3/9/17 10:11 , Joshua Root wrote:

On 2017-3-10 02:42 , Jonathan Stickel wrote:

I am trying to make a port for git-latexdiff. It is hosted on gitlab:

https://gitlab.com/git-latexdiff/git-latexdiff

The project has "tags" which look similar to github's tags (and
releases). I am having trouble specifying the "master_sites" and
"distname" variables for the port in order to download the appropriately
tagged tarball. The download link, e.g.,

https://gitlab.com/git-latexdiff/git-latexdiff/repository/archive.tar.gz?ref=v1.1.4



automatically morphs into a download file of

git-latexdiff-v1.1.4-dc84273afc2e366d6c4f98a07052e651c7d297dd.tar.gz

I've used the github portgroup to mange this with github-hosted ports,
but there is no "gitlab" portgroup.

Any help is appreciated.


I don't know about Gitlab specifically, but if they really don't have
any other way to download the source, you can use the ?dummy= trick:



- Josh


Thanks, appending "&dummy=" worked in this case.

Re: gitlab tags

2017-03-09 Thread Mojca Miklavec 
On 9 March 2017 at 16:42, Jonathan Stickel  wrote:
> I am trying to make a port for git-latexdiff. It is hosted on gitlab:
>
> https://gitlab.com/git-latexdiff/git-latexdiff
>
> The project has "tags" which look similar to github's tags (and releases). I
> am having trouble specifying the "master_sites" and "distname" variables for
> the port in order to download the appropriately tagged tarball. The download
> link, e.g.,
>
> https://gitlab.com/git-latexdiff/git-latexdiff/repository/archive.tar.gz?ref=v1.1.4
>
> automatically morphs into a download file of
>
> git-latexdiff-v1.1.4-dc84273afc2e366d6c4f98a07052e651c7d297dd.tar.gz
>
> I've used the github portgroup to mange this with github-hosted ports, but
> there is no "gitlab" portgroup.

I would say that we should create a PortGroup for GitLab.

Mojca

Re: gitlab tags

2017-03-09 Thread Joshua Root 

On 2017-3-10 02:42 , Jonathan Stickel wrote:

I am trying to make a port for git-latexdiff. It is hosted on gitlab:

https://gitlab.com/git-latexdiff/git-latexdiff

The project has "tags" which look similar to github's tags (and
releases). I am having trouble specifying the "master_sites" and
"distname" variables for the port in order to download the appropriately
tagged tarball. The download link, e.g.,

https://gitlab.com/git-latexdiff/git-latexdiff/repository/archive.tar.gz?ref=v1.1.4


automatically morphs into a download file of

git-latexdiff-v1.1.4-dc84273afc2e366d6c4f98a07052e651c7d297dd.tar.gz

I've used the github portgroup to mange this with github-hosted ports,
but there is no "gitlab" portgroup.

Any help is appreciated.


I don't know about Gitlab specifically, but if they really don't have 
any other way to download the source, you can use the ?dummy= trick:




- Josh

gitlab tags

2017-03-09 Thread Jonathan Stickel 

I am trying to make a port for git-latexdiff. It is hosted on gitlab:

https://gitlab.com/git-latexdiff/git-latexdiff

The project has "tags" which look similar to github's tags (and 
releases). I am having trouble specifying the "master_sites" and 
"distname" variables for the port in order to download the appropriately 
tagged tarball. The download link, e.g.,


https://gitlab.com/git-latexdiff/git-latexdiff/repository/archive.tar.gz?ref=v1.1.4

automatically morphs into a download file of

git-latexdiff-v1.1.4-dc84273afc2e366d6c4f98a07052e651c7d297dd.tar.gz

I've used the github portgroup to mange this with github-hosted ports, 
but there is no "gitlab" portgroup.


Any help is appreciated.

Thanks,
Jonathan

Avoiding repeating code for python variants

2017-03-09 Thread Mojca Miklavec 
Hi,

Is there some clean way to avoid repeating the following chunk of code
four times (or more)?


variant python27 conflicts python34 python35 python36 description
{Enable GUI using Python 2.7} {

set python.version  27
set python.branch   "[string range ${python.version} 0
end-1].[string index ${python.version} end]"

depends_lib-append
path:${frameworks_dir}/Python.framework/Versions/${python.branch}/lib/python${python.branch}/site-packages/PIL:py${python.version}-Pillow
}

ROOT 6 does something similar, but I want to know if I'm missing
something obvious.


PS: In my particular case the Python 3 code was still experimental and
semi-broken some time ago. These variants allowed me to more
extensively test the port and fix the software upstream, so it was
important to be able to switch back and forth between 2.7 and 3.4. In
all honesty the variants currently hardly play any role any longer
(unless something is broken that I'm not aware of), so I could just as
well go for Python 3.6 and forget the rest. But it might be relevant
for other ports. (I wish there was a way to do the same using the
Python PortGroup.)

Thank you,
Mojca

Re: build progress bar

2017-03-09 Thread René J . V . Bertin 
On Wednesday March 08 2017 22:29:29 Clemens Lang wrote:
>Hi,
Hi,

>That function, however, also gets called from a myriad of places
>throughout other MacPorts code that is not related to build system
>output at all. Better change the Pextlib behavior to call a different
>function for output generated by the build system instead and implement
>your progress handling there, before passing the payload on to ui_info
>for logging purposes.

I don't disagree, but how would we determine from there that a build is going 
to be done (or destroot, I'd add that step too)? Or would we simply support 
progress logging for everything invoked through Pextlib's system call 
(SystemCmd, IIRC)?

That would solve the question of where to initialise and terminate the progress 
reporter but wouldn't it add an extra layer of complexity to calling the 
progressbar "class" defined in Tcl in the port client? It wouldn't be very nice 
if the system command all of a sudden starts failing when used in a context 
where that progressbar class isn't accessible.

If ui_message contains a few additional lines like below, wouldn't the overhead 
drown in the noise of what's already going on if there's nothing to report?

{{{
if {ui_may_have_progress_info} {
if {![ui_isset ports_verbose]} {
# check _reporting_progress_, initialise progress reporting if not 
set
# call a procedure that checks for and processes progress info
}
} elseif {_reporting_progress_} {
# finalise
_reporting_progress = no
}
}}}

I think that should give not more than an acceptable overhead (and a small 
enough addition to proc ui_message) at least for a first approach, allowing us 
to get a better idea what kind of progress reporting is feasible and useful. In 
this kind of situation optimisation through refactoring into compiled code is 
usually something one does in a 2nd step, when justified, no?


>You could explicitly re-set a counter at the beginning of a phase and
>then use that in between. But then again, that might also be happening
>from different files, I guess.
>
>> The logical places to inform the progress reporter that it needs to
>> rewind (or is done) are in portbuild.tcl or possibly more generically
>> in portutil.tcl (proc command_exec; start just above "Call this
>> command", finish just before returning).
>
>Yes, I agree.

I think the variation and code snippet above address the problem. I'd have to 
try to see if this can really work but I think it should, and it ought to allow 
to put all the code that does the actual progress reporting stuff in 
macports.tcl . Files that start or terminate operations that might provide 
progress info only have to set or `unset ui_may_have_progress_info` and maybe 
provide the equivalent of a function pointer to a procedure that provides the 
progress information itself.

R.