Re: [GRASS-dev] git: how to switch between branches?

[Michael Barton]

Markus and others,

I've looked at this a little now, and here is a possible workflow. For Git 
sophisticates, I realize that this negates to some extent the lightweight 
flexibility of the Git approach to versioning. And of course, not everyone has 
to do this. But to create separate source distributions in different 
directories locally, so that devs who want to can continue with their current 
workflow (at least for awhile), you should be able to do the following (example 
from RB7.4)

CMB-MacBook-Pro:grass_source cmbarton$ mkdir releasebranch_7_4
CMB-MacBook-Pro:grass_source cmbarton$ cd releasebranch_7_4
CMB-MacBook-Pro:releasebranch_7_4 cmbarton$ git clone 
https://github.com/OSGeo/grass.git
Cloning into 'grass'...
remote: Enumerating objects: 131, done.
remote: Counting objects: 100% (131/131), done.
remote: Compressing objects: 100% (113/113), done.
remote: Total 228899 (delta 31), reused 39 (delta 15), pack-reused 228768
Receiving objects: 100% (228899/228899), 232.04 MiB | 549.00 KiB/s, done.
Resolving deltas: 100% (169949/169949), done.
Checking out files: 100% (7355/7355), done.
CMB-MacBook-Pro:releasebranch_7_4 cmbarton$ cd grass
CMB-MacBook-Pro:grass cmbarton$ git checkout releasebranch_7_4
Branch 'releasebranch_7_4' set up to track remote branch 'releasebranch_7_4' 
from 'origin'.
Switched to a new branch 'releasebranch_7_4'

This will give you source files from RB7.4.

Note a couple of other alternatives:

1. You can just clone GRASS once and do a checkout to each branch you want to 
work on at any time. Git will then replace all files that differ in that branch 
from master. Not much in 7.6, many more in 7.2

2. You could have one master GRASS directory and one 'branch' directory in 
which you use checkout for each branch other than master you want to work in 
when you are in the branch directory.

Git is very flexible in this regard AFAICT. Most Git tutorials I've seen 
discuss method 1 above, with discussions of additional forks and merging of 
branches, assuming that the ultimate goal is to deploy all releases from the 
master branch. GRASS does not follow this kind of assumed 'normal' work flow. 
We are working on 2-3 different branch releases simultaneously.

Of course Git offers the opportunity to begin to rethink the overall GRASS 
workflow. But we might want to make these transitions in stages to keep 
everyone on board and limit confusion (e.g., get all up to speed on using Git 
commands to get the source code and commit revisions more or less the way we do 
now, and then work out new common workflows for doing these activities). Git's 
flexibility means that we can make these changes as incrementally or as quickly 
as works for the community.

Michael




C. Michael Barton
Director, Center for Social Dynamics & Complexity
Professor of Anthropology, School of Human Evolution & Social Change
Head, Graduate Faculty in Complex Adaptive Systems Science
Arizona State University

Currently Senior Research Fellow, Institute for Advanced Sustainability Studies
Potsdam, Deutchland

voice:  480-965-6262 (SHESC), 480-965-8130/727-9746 (CSDC)
fax: 480-965-7671 (SHESC),  480-727-0709 (CSDC)
www: http://www.public.asu.edu/~cmbarton, http://csdc.asu.edu















On May 20, 2019, at 3:00 AM, 
grass-dev-requ...@lists.osgeo.org 
wrote:

Message: 2
Date: Sun, 19 May 2019 19:27:34 +0200
From: Markus Neteler mailto:nete...@osgeo.org>>
To: GRASS developers list 
mailto:grass-dev@lists.osgeo.org>>
Subject: [GRASS-dev] git: how to switch between branches?
Message-ID:
mailto:calfmhhvwdzhoqu07q8s12qn10qmmgqdavvydpjcrktyxzhc...@mail.gmail.com>>
Content-Type: text/plain; charset="UTF-8"

Hi,

being a kind of git newbie, I'm struggly with switching between the
different release branches (and master).

Starting from a clean state (nothing downloaded yet), it this correct:

## 0. getting the code: fork in GH, then
# git clone g...@github.com:your_GH_account/grass.git
# git remote ...

Now I want the each release branch in a separate directory (!) as I
keep the compiled binaries and run GRASS directly from there.

# make a local copy of the freshly cloned source code (example: relbranch76(:
cp -rp grass grass76_branch
cd grass76_branch/

## 1. preparation: check if the local branch-copy of the remote branch exists
git branch -a

# if yes:
#   nothing to do, continue below
# if not:
#   create a new local branch that tracks a remote branch
git checkout --track upstream/releasebranch_7_6
## ?? or
##  git checkout --track remotes/upstream/releasebranch_7_6

# check
git branch -a

## 2. subsequently, switching between master and branch

# switch to branch, e.g.
git checkout upstream/releasebranch_7_6

# back to master
git checkout master

Please suggest, at non-git-expert level :-)

Markus

___
grass-dev mailing list
grass-dev@lists.osgeo.org

Re: [GRASS-dev] [GRASS GIS] #3849: Do we need to clear the screen when entering/exiting GRASS?

[GRASS GIS]

#3849: Do we need to clear the screen when entering/exiting GRASS?
--+-
  Reporter:  pmav99   |  Owner:  grass-dev@…
  Type:  enhancement  | Status:  new
  Priority:  normal   |  Milestone:
 Component:  Startup  |Version:  svn-trunk
Resolution:   |   Keywords:
   CPU:  Unspecified  |   Platform:  Unspecified
--+-

Comment (by wenzeslaus):

 No objections from me. It does not seem that other interpreters or
 environments are doing it (Python, R, Octave, Bash) even if they show a
 significant startup message by default (R, Octave). Although this ticket
 is about interactive use from command line, same is also needed to solve
 most if not all of #2639 which is about behaving as expected when stdin is
 provided (`grass --tmp-location XY --text < script.sh`). I continue with a
 modification of my comment from https://github.com/OSGeo/grass/pull/4:

 I see at least 3 different things happening:

 1. Clear happens at the beginning and at the end. (in "interactive mode",
 without `--exec`)
 2. Banner is displayed. (in "interactive mode", without `--exec`)
 3. Bunch of messages is printed (//Starting GRASS GIS...// etc.). (even
 with `--exec`)

 Here we focus on the clearing only.

 In #2639 I compared behavior to Python and R in case when standard input
 is provided. As for interactive use, Python (`python`), R (`R`), and
 Octave (`octave --no-gui`) display banners (of different lengths), but
 none of them clears the terminal (at the beginning or the end). That
 suggests that `grass` should not do that either.

 Copy-pasted command line when R, Octave, Python, and Bash are started and
 ended follows (newlines preserved, no clearing involved):

 {{{
 $ previous-command
 $ R

 R version 3.2.3 (2015-12-10) -- "Wooden Christmas-Tree"
 Copyright (C) 2015 The R Foundation for Statistical Computing
 Platform: x86_64-pc-linux-gnu (64-bit)

 R is free software and comes with ABSOLUTELY NO WARRANTY.
 You are welcome to redistribute it under certain conditions.
 Type 'license()' or 'licence()' for distribution details.

   Natural language support but running in an English locale

 R is a collaborative project with many contributors.
 Type 'contributors()' for more information and
 'citation()' on how to cite R or R packages in publications.

 Type 'demo()' for some demos, 'help()' for on-line help, or
 'help.start()' for an HTML browser interface to help.
 Type 'q()' to quit R.

 > q()
 Save workspace image? [y/n/c]: n
 $ octave --no-gui
 GNU Octave, version 4.0.0
 Copyright (C) 2015 John W. Eaton and others.
 This is free software; see the source code for copying conditions.
 There is ABSOLUTELY NO WARRANTY; not even for MERCHANTABILITY or
 FITNESS FOR A PARTICULAR PURPOSE.  For details, type 'warranty'.

 Octave was configured for "x86_64-pc-linux-gnu".

 Additional information about Octave is available at http://www.octave.org.

 Please contribute if you find this software useful.
 For more information, visit http://www.octave.org/get-involved.html

 Read http://www.octave.org/bugs.html to learn how to submit bug reports.
 For information about changes from previous versions, type 'news'.

 >> exit

 $ python
 Python 2.7.12 (default, Nov 12 2018, 14:36:49)
 [GCC 5.4.0 20160609] on linux2
 Type "help", "copyright", "credits" or "license" for more information.
 >>> exit()
 $ bash
 $ exit
 exit
 $ following-command
 }}}

-- 
Ticket URL: 
GRASS GIS 

___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] git: how to switch between branches?

[Michael Barton]

C. Michael Barton
Director, Center for Social Dynamics & Complexity
Professor of Anthropology, School of Human Evolution & Social Change
Head, Graduate Faculty in Complex Adaptive Systems Science
Arizona State University

Currently Senior Research Fellow, Institute for Advanced Sustainability Studies
Potsdam, Deutchland

voice:  480-965-6262 (SHESC), 480-965-8130/727-9746 (CSDC)
fax: 480-965-7671 (SHESC),  480-727-0709 (CSDC)
www: http://www.public.asu.edu/~cmbarton, http://csdc.asu.edu






I have similar questions.

Related to this, when we set up our MedLanD project Git repository, we also had 
some colleagues suggest using Git's forking to deal with collaborative 
development. But in the end, we decided to follow more of the  previous GRASS 
SVN approach. It relies more on good practice among developers, but it is 
easier to remember how to carry out the good practices.

Michael

On May 20, 2019, at 3:00 AM, 
grass-dev-requ...@lists.osgeo.org 
wrote:

Date: Sun, 19 May 2019 19:27:34 +0200
From: Markus Neteler mailto:nete...@osgeo.org>>
To: GRASS developers list 
mailto:grass-dev@lists.osgeo.org>>
Subject: [GRASS-dev] git: how to switch between branches?
Message-ID:
mailto:calfmhhvwdzhoqu07q8s12qn10qmmgqdavvydpjcrktyxzhc...@mail.gmail.com>>
Content-Type: text/plain; charset="UTF-8"

Hi,

being a kind of git newbie, I'm struggly with switching between the
different release branches (and master).

Starting from a clean state (nothing downloaded yet), it this correct:

## 0. getting the code: fork in GH, then
# git clone g...@github.com:your_GH_account/grass.git
# git remote ...

Now I want the each release branch in a separate directory (!) as I
keep the compiled binaries and run GRASS directly from there.

# make a local copy of the freshly cloned source code (example: relbranch76(:
cp -rp grass grass76_branch
cd grass76_branch/

## 1. preparation: check if the local branch-copy of the remote branch exists
git branch -a

# if yes:
#   nothing to do, continue below
# if not:
#   create a new local branch that tracks a remote branch
git checkout --track upstream/releasebranch_7_6
## ?? or
##  git checkout --track remotes/upstream/releasebranch_7_6

# check
git branch -a

## 2. subsequently, switching between master and branch

# switch to branch, e.g.
git checkout upstream/releasebranch_7_6

# back to master
git checkout master

Please suggest, at non-git-expert level :-)

Markus

___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

[GRASS-dev] [GRASS GIS] #3849: Do we need to clear the screen when entering/exiting GRASS?

[GRASS GIS]

#3849: Do we need to clear the screen when entering/exiting GRASS?
-+-
 Reporter:  pmav99   |  Owner:  grass-dev@…
 Type:  enhancement  | Status:  new
 Priority:  normal   |  Milestone:
Component:  Startup  |Version:  svn-trunk
 Keywords:   |CPU:  Unspecified
 Platform:  Unspecified  |
-+-
 Clearing the screen can often be problematic. More specifically, depending
 on the SHELL/terminal emulator you use you might lose the ability to
 scroll back which can be very annoying. Are there any objections in
 removing it?

-- 
Ticket URL: 
GRASS GIS 

___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] wingrass builds down

[Helmut Kudrnovsky]

Martin Landa wrote
> Hi,
> 
> so 18. 5. 2019 v 19:48 odesílatel Martin Landa 

> landa.martin@

>  napsal:
>> but unfortunately git appeared to be broken in my msys2 installation
>> (calling `git` command had no effect). So I am trying to reinstall
>> msys2 from scratch.
> 
> it helped partially. git clone is working in msys64 64bit. But fails
> in msys64 32bit environment:
> 
> $ git clone https://github.com/OSGeo/grass grass_master
> Cloning into 'grass_master'...
>   1 [main] git-remote-https 3271 child_info_fork::abort:
> \??\C:\msys32\in\msys-unistring-2.dll: Loaded to different address:
> parent(0x73) != c0xA7)
> error: cannot fork() for fetch-pack: Resource temporarily unavailable
> 
> This opens long time planned question. Do we really need to provide
> WinGRASS 32bit builds. Only 64bit builds would enough probably. Any
> opinion?

never tried here the 32bit msys2 git.

nowadays 64bit Windows boxes are very common; most of the new laptops/PCs
are 64 bit in the Windows world.

IMHO 32bit would be service for older windows boxes

Is QGIS still shipping a 32bit version? 





-
best regards
Helmut
--
Sent from: http://osgeo-org.1560.x6.nabble.com/Grass-Dev-f3991897.html
___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] wingrass builds down

[Vaclav Petras]

On Sun, May 19, 2019 at 2:03 PM Martin Landa  wrote:
>
> This opens long time planned question. Do we really need to provide
> WinGRASS 32bit builds. Only 64bit builds would enough probably. Any
> opinion? Ma

Do we have download statistics for 32bit installers?
___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] [GRASS GIS] #3722: migrate grass svn repositories to git

[GRASS GIS]

#3722: migrate grass svn repositories to git
--+-
  Reporter:  martinl  |  Owner:  grass-dev@…
  Type:  task | Status:  closed
  Priority:  major|  Milestone:
 Component:  Default  |Version:  unspecified
Resolution:  fixed|   Keywords:  svn, git, migration
   CPU:  Unspecified  |   Platform:  Unspecified
--+-
Changes (by martinl):

 * status:  new => closed
 * resolution:   => fixed


Comment:

 Done.

 * logs archived at https://grass.osgeo.org/svn2git_archive/grass-svn2git-
 logs.7z
 * svn dump archived at https://grass.osgeo.org/svn2git_archive/grass-
 svn-2019-05-19.dump.gz

-- 
Ticket URL: 
GRASS GIS 

___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] wingrass builds down

[Martin Landa]

Hi,

so 18. 5. 2019 v 19:48 odesílatel Martin Landa  napsal:
> but unfortunately git appeared to be broken in my msys2 installation
> (calling `git` command had no effect). So I am trying to reinstall
> msys2 from scratch.

it helped partially. git clone is working in msys64 64bit. But fails
in msys64 32bit environment:

$ git clone https://github.com/OSGeo/grass grass_master
Cloning into 'grass_master'...
  1 [main] git-remote-https 3271 child_info_fork::abort:
\??\C:\msys32\in\msys-unistring-2.dll: Loaded to different address:
parent(0x73) != c0xA7)
error: cannot fork() for fetch-pack: Resource temporarily unavailable

This opens long time planned question. Do we really need to provide
WinGRASS 32bit builds. Only 64bit builds would enough probably. Any
opinion? Ma

-- 
Martin Landa
http://geo.fsv.cvut.cz/gwiki/Landa
http://gismentors.cz/mentors/landa
___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

[GRASS-dev] git: how to switch between branches?

[Markus Neteler]

Hi,

being a kind of git newbie, I'm struggly with switching between the
different release branches (and master).

Starting from a clean state (nothing downloaded yet), it this correct:

## 0. getting the code: fork in GH, then
# git clone g...@github.com:your_GH_account/grass.git
# git remote ...

Now I want the each release branch in a separate directory (!) as I
keep the compiled binaries and run GRASS directly from there.

# make a local copy of the freshly cloned source code (example: relbranch76(:
cp -rp grass grass76_branch
cd grass76_branch/

## 1. preparation: check if the local branch-copy of the remote branch exists
git branch -a

# if yes:
#   nothing to do, continue below
# if not:
#   create a new local branch that tracks a remote branch
git checkout --track upstream/releasebranch_7_6
## ?? or
##  git checkout --track remotes/upstream/releasebranch_7_6

# check
git branch -a

## 2. subsequently, switching between master and branch

# switch to branch, e.g.
git checkout upstream/releasebranch_7_6

# back to master
git checkout master

Please suggest, at non-git-expert level :-)

Markus
___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] svn/trac -> git/github migration plan

[Panagiotis Mavrogiorgos]

On Sun, May 19, 2019 at 6:53 PM Martin Landa  wrote:

> Hi,
>
> ne 19. 5. 2019 v 17:43 odesílatel Markus Metz
> Ideally, you would set up the local repo such that you pull from upstream
> and push to your fork.
>
> This is doable with: https://stackoverflow.com/a/4523625/592289

Nevertheless, occasionally, you might want to pull from your personal fork
too. E.g. when  you want to collaborate on a feature with others. One way
to do this is to agree that the development will happen on a branch on your
own fork. It doesn't matter if you give write access to the other devs or
if they make Pull Requests to your own fork, in the end you will have to
pull those changes to your local repo. And in order to do that you will
have to again edit your remotes.

For the record, in the above example the other devs would have to add your
own personal repository as an additional remote.
___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] svn/trac -> git/github migration plan

[Markus Neteler]

On Sun, May 19, 2019 at 5:53 PM Martin Landa  wrote:
> ne 19. 5. 2019 v 17:43 odesílatel Markus Metz
>  napsal:
> >  For those who do have write access to upstream, it might be safer to have 
> > origin refer to the personal fork. Ideally, you would set up the local repo 
> > such that you pull from upstream and push to your fork.
>
> +1 Ma

+1 markusN
___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] svn/trac -> git/github migration plan

[Martin Landa]

Hi,

ne 19. 5. 2019 v 17:43 odesílatel Markus Metz
 napsal:
>  For those who do have write access to upstream, it might be safer to have 
> origin refer to the personal fork. Ideally, you would set up the local repo 
> such that you pull from upstream and push to your fork.

+1 Ma

-- 
Martin Landa
http://geo.fsv.cvut.cz/gwiki/Landa
http://gismentors.cz/mentors/landa
___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] svn/trac -> git/github migration plan

[Markus Metz]

On Sun, May 19, 2019 at 5:24 PM Vaclav Petras  wrote:
>
>
>
> On Sat, May 18, 2019 at 12:11 PM Markus Neteler  wrote:
>>
>>
>> On Sat, May 18, 2019 at 5:59 PM Panagiotis Mavrogiorgos
>>  wrote:
>> >
>> > I would suggest that:
>> >
>> > - even core devs fork the main repo
>> > - "origin" is the personal remote GRASS repository (e.g. in my case
https://github.com/pmav99/grass)
>> > - everyone adds the main GRASS repository as a secondary remote (e.g.
"upstream")
>>
>> yes, it sounds good to me (while my opinion only counts 0.02 cents here).
>>
>> > This way:
>> >
>> > 1. You always push to "origin" and you create a Pull Request from the
Github UI
>> > 2. To get updates you always pull from "upstream"
>> > 3. You always rebase your code to "upstream/master".
>> > 4. You don't need separate instructions for non core-devs.
>>
>> Updated in a similar way to
>>
>> https://trac.osgeo.org/grass/wiki/HowToGit#Workflowforcoredevelopers
>
>
>
> Hi, any opinions on what should be the primary and secondary remote? The
the fork or upstream? As far as I understood, Bas is suggesting adding the
fork, Panos adding the upstream. There does not seem to be that much
difference, but the commands are different, so we need to decide for the
instructions. GitHub help suggests cloning fork and adding upstream.
Syncing to upstream seems more straight forward when cloning upstream and
adding to the fork...

GDAL [0] suggests to clone upstream, then add your own fork. For those who
don't have write access to upstream it does not matter IMHO. For those who
do have write access to upstream, it might be safer to have origin refer to
the personal fork. Ideally, you would set up the local repo such that you
pull from upstream and push to your fork.

my 0.2c (trying to learn fast)

Markus M

[0]
https://github.com/OSGeo/gdal/blob/master/CONTRIBUTING.md#initiate-your-work-repository
___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] [GRASS GIS] #3844: Make Region importable from pygrass.gis

[GRASS GIS]

#3844: Make Region importable from pygrass.gis
--+-
  Reporter:  pmav99   |  Owner:  grass-dev@…
  Type:  enhancement  | Status:  closed
  Priority:  normal   |  Milestone:  7.8.0
 Component:  PyGRASS  |Version:  svn-trunk
Resolution:  fixed|   Keywords:
   CPU:  Unspecified  |   Platform:  Unspecified
--+-
Changes (by martinl):

 * status:  new => closed
 * resolution:   => fixed


Comment:

 Closed by
 https://github.com/landam/grass/commit/e328eab9738f04d173dd89b88e52e7d8dc33f2fc

-- 
Ticket URL: 
GRASS GIS 

___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] svn/trac -> git/github migration plan

[Vaclav Petras]

On Sat, May 18, 2019 at 12:11 PM Markus Neteler  wrote:

>
> On Sat, May 18, 2019 at 5:59 PM Panagiotis Mavrogiorgos
>  wrote:
> >
> > I would suggest that:
> >
> > - even core devs fork the main repo
> > - "origin" is the personal remote GRASS repository (e.g. in my case
> https://github.com/pmav99/grass)
> > - everyone adds the main GRASS repository as a secondary remote (e.g.
> "upstream")
>
> yes, it sounds good to me (while my opinion only counts 0.02 cents here).
>
> > This way:
> >
> > 1. You always push to "origin" and you create a Pull Request from the
> Github UI
> > 2. To get updates you always pull from "upstream"
> > 3. You always rebase your code to "upstream/master".
> > 4. You don't need separate instructions for non core-devs.
>
> Updated in a similar way to
>
> https://trac.osgeo.org/grass/wiki/HowToGit#Workflowforcoredevelopers
>


Hi, any opinions on what should be the primary and secondary remote? The
the fork or upstream? As far as I understood, Bas is suggesting adding the
fork, Panos adding the upstream. There does not seem to be that much
difference, but the commands are different, so we need to decide for the
instructions. GitHub help suggests cloning fork and adding upstream.
Syncing to upstream seems more straight forward when cloning upstream and
adding to the fork...
___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] grass-addons git repo clean-up

[Vaclav Petras]

On Sun, May 19, 2019 at 8:50 AM Martin Landa  wrote:

> Hi,
>
> ne 19. 5. 2019 v 11:52 odesílatel Martin Landa 
> napsal:
> > > * tools/ content could be moved to a new git repo,
> > > `grass-maintenance-tools` (any idea for better name).
>
> another option is to keep tools in `grass-addons` repo, just to move
> them into separated branch. In summary, list of branches:
>
>
I think tools should be in grass (/tools) or in maintenance.


> * grass7 (content of grass7/* dir) <-- default
> * grass6 (content of grass6/* dir)
>

This makes sense as branches. No master seems to make sense here if we
continue managing addons the same way.


> * tools (content of tools/* dir)
>

Not a branch. See above.


>
> Than content of branches will be different which is not probably a
> perfect approach. On the other hand we will minimize number of git
> repo.


The maintenance repo makes sense to me unless there is a strong reason to
put everything into the main repo.
___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] grass-addons git repo clean-up

[Nikos Alexandris]

Dear Martin and all,

is there anything add-ons authors should do from their side?

Thanks for all of the hard work, Nikos

* Martin Landa  [2019-05-19 11:06:35 +0200]:


Hi,

so 18. 5. 2019 v 22:46 odesílatel Paulo van Breugel
 napsal:

If add-ons are made available from personal repositories, will there still be a 
central page with links to all manual pages 
(https://grass.osgeo.org/grass76/manuals/addons/)? I always find this a very 
convenient place to check what add-ons are available.


yes, should work like that. But let's discuss possible implementation
(possibly a metadata file with list of all registered personal repos
in `grass-addons` repo) in a new issue. This thread is about
cleaning-up the `grass-addons` repo. Ma

--
Martin Landa
http://geo.fsv.cvut.cz/gwiki/Landa
http://gismentors.cz/mentors/landa
___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev


--
Nikos Alexandris | Remote Sensing & Geomatics
GPG Key Fingerprint 6F9D4506F3CA28380974D31A9053534B693C4FB3 
___

grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] grass-addons git repo clean-up

[Martin Landa]

Hi,

ne 19. 5. 2019 v 11:52 odesílatel Martin Landa  napsal:
> > * tools/ content could be moved to a new git repo,
> > `grass-maintenance-tools` (any idea for better name).

another option is to keep tools in `grass-addons` repo, just to move
them into separated branch. In summary, list of branches:

* grass7 (content of grass7/* dir) <-- default
* grass6 (content of grass6/* dir)
* tools (content of tools/* dir)

Than content of branches will be different which is not probably a
perfect approach. On the other hand we will minimize number of git
repo.

Any opinion? Ma

-- 
Martin Landa
http://geo.fsv.cvut.cz/gwiki/Landa
http://gismentors.cz/mentors/landa
___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] grass-addons git repo clean-up

[Martin Landa]

Hi,

so 18. 5. 2019 v 17:00 odesílatel Martin Landa  napsal:
> * tools/ content could be moved to a new git repo,
> `grass-maintenance-tools` (any idea for better name).

if no objections I would suggest to create a new repo under OSGeo
organization in next hours/days.

Ma

-- 
Martin Landa
http://geo.fsv.cvut.cz/gwiki/Landa
http://gismentors.cz/mentors/landa
___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] grass-addons git repo clean-up

[Martin Landa]

Hi,

so 18. 5. 2019 v 22:46 odesílatel Paulo van Breugel
 napsal:
> If add-ons are made available from personal repositories, will there still be 
> a central page with links to all manual pages 
> (https://grass.osgeo.org/grass76/manuals/addons/)? I always find this a very 
> convenient place to check what add-ons are available.

yes, should work like that. But let's discuss possible implementation
(possibly a metadata file with list of all registered personal repos
in `grass-addons` repo) in a new issue. This thread is about
cleaning-up the `grass-addons` repo. Ma

-- 
Martin Landa
http://geo.fsv.cvut.cz/gwiki/Landa
http://gismentors.cz/mentors/landa
___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] [GRASS GIS] #3471: Custom dropdown control doesn’t recognize mouse events

[GRASS GIS]

#3471: Custom dropdown control doesn’t recognize mouse events
--+
  Reporter:  cmbarton |  Owner:  grass-dev@…
  Type:  defect   | Status:  reopened
  Priority:  major|  Milestone:  7.6.2
 Component:  wxGUI|Version:  7.2.2
Resolution:   |   Keywords:  wxPython, dropdown control
   CPU:  Unspecified  |   Platform:  MacOSX
--+
Changes (by cmbarton):

 * status:  closed => reopened
 * resolution:  fixed =>
 * milestone:  7.2.4 => 7.6.2


Comment:

 Reopening. I thought these were all fixed. But I recently found more of
 these drop downs in the analytical dialogs accessible from the display
 window menu bar. These include the profiler, histogrammer, bivariate
 scatterplot tool. If this pull down is controlled by a single piece of
 code somewhere for these modules, it can be easily fixed like the other
 instances. I'll move the milestone up to the current stable version too.

-- 
Ticket URL: 
GRASS GIS 

___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev