What about Git support?

Are you missing a feature? Request it's implementation here.
sorin_carbunaru
Site Admin
Posts: 269
Joined: Mon May 09, 2016 9:37 am

Re: What about Git support?

Post by sorin_carbunaru » Wed Oct 02, 2019 3:29 pm

I'm glad to hear your colleagues love the Git integration :D ! It feels good when the clients are happy with your work.

chrispitude
Posts: 93
Joined: Thu May 02, 2019 2:32 pm

Re: What about Git support?

Post by chrispitude » Fri Nov 01, 2019 4:48 pm

I just installed the latest v2.0.0 update of the Git plugin. There is support for rebase-pulling - I'm excited to try it out!!

A quick question to everyone... We have our *.xpr Oxygen project file stored in our Git repository, so that (1) pulling the Git repository down creates a ready-to-use project, and (2) we can share project-wide settings like hotkeys and transformations.

However, we're finding that some day-to-day actions cause a user's *.xpr file to get modified. For example, let's say I change the map context in the DITA Maps Manager:
git_xpr1.PNG
git_xpr1.PNG (21.23 KiB) Viewed 530 times
This causes the project file to show up as a changed file:
git_xpr2.PNG
git_xpr2.PNG (16.64 KiB) Viewed 530 times
And when I look at the differences, the only change is the map context setting:
git_xpr3.PNG
git_xpr3.PNG (37.87 KiB) Viewed 530 times
How are others handling modifications to shared *.xpr project files in a Git flow?

Radu
Posts: 6642
Joined: Fri Jul 09, 2004 5:18 pm

Re: What about Git support?

Post by Radu » Mon Nov 04, 2019 11:50 am

Hi Chris,

Indeed Oxygen auto-saves various settings at project level. Besides the root map setting another setting we auto save at project level is the association between an opened map and a publishing scenario and we have users having problems also with this.
Honestly I'm not sure how to best handle this on our side. I mean, saving the root map setting at project level is useful, if you give the XPR to somebody new they just need to open the XPR and they will have the root map properly set.
At some point we wanted to add a special setting for the XPR project, something like "[ ] Lock project settings". This setting would be checked by you (the admin) before committing the XPR on GitHub. And for anybody opening the XPR, Oxygen would no longer save settings at XPR level. But what would happen if they change the root map? Would the setting get auto saved to Oxygen's global options?
Or if you are never interested in imposing the root map, maybe we could have particular settings like "[ ]Save Root map settings at project level" or "[ ]Save scenario associations at project level". And you could uncheck both these checkboxes (which would add some flags inside the XPR), then share the XPR with others...

Regards,
Radu
Radu Coravu
<oXygen/> XML Editor
http://www.oxygenxml.com

chrispitude
Posts: 93
Joined: Thu May 02, 2019 2:32 pm

Re: What about Git support?

Post by chrispitude » Tue Nov 05, 2019 5:48 pm

Hi Radu,

For smaller projects, it's definitely useful to store the root map and scenario associations in the project file. Like you say, any user can obtain and open the project, and they will have sensible default behaviors ready for them.

I believe this becomes less ideal when there are multiple users or multiple root maps (or both).

Let me think out loud here...

Multiple root maps

When I work with multiple root maps simultaneously, for me the concept of a global root map setting becomes more hindering than helpful. It would be nice if each editing window remembered the context in which it was opened. There are various places where the filename is shown (main window bar, bottom status bar, tooltip for editor tab) and these could display the root context in a suffix for clarity.

For example, let's say I have a shared topic S in books A and B. If I open S from A's map and S from B's map, each of these editing windows should remember its root context and resolve references accordingly. If I copy a figure from the S-from-A or S-from-B window then paste-special as a keyref link into another topic editing window T, the reference should be constructed using the keydef/scope information from either bookmap A or bookmap B, respectively.

Would this editing window root-context completely subsume the need for the simpler global root context? I am not sure, because I don't know what non-editing features the global root map setting affects.

Multiple scenario associations

The situation is less clear to me when there are multiple users and multiple writers. Perhaps it would be useful for two levels of association:
  • The project administrator sets up all associations that might be useful when working in the project, and
  • The users can select their own associations within the set configured by the administrator.
This would work in conjunction with my other filed feature request, for the "Apply Transformation Scenario(s)" button to be a drop-down that lets you run a single transformation from the associated set, thus preventing the need to change the associated net.

----

For both the root maps and scenario associations, I am just thinking out loud. These ideas are more complicated than having an option to lock the project file and push any varying settings to the user's global file. They might have usability or technical issues I haven't considered.

I hope other users can share their thinking too!

chrispitude
Posts: 93
Joined: Thu May 02, 2019 2:32 pm

Re: What about Git support?

Post by chrispitude » Tue Nov 12, 2019 4:12 pm

The situation with our shared project file became unworkable. Despite telling everyone not to include it in commits, it still accidentally got staged/committed/conflicted.

For now, we have a MASTER project file in the repo, then each writer copies it to their own working copy. I added the following lines to our .gitignore, which ignores any project file except our master file:

Code: Select all

*.xpr
!our_books_MASTER.xpr
This means that writers don't get updates to the project file automatically, but we can work with that for now.

Radu
Posts: 6642
Joined: Fri Jul 09, 2004 5:18 pm

Re: What about Git support?

Post by Radu » Tue Nov 19, 2019 12:28 pm

Hi Chris,

For your feedback about remembering from what DITA Map context the topic was opened, we have issue with ID EXM-43179 registered. I do not have a timeline estimate for it.
For the problem with the XPR being often modified, I think right now your approach of having a master XPR is the right one. I registered issue EXM-44587 for it and in this case we are starting to better understand what we need to do in order to allow you the flexibility to choose if certain settings should be saved at project level or not. If we manage to fix it we'll update this forum thread but I cannot guarantee a fix in the Oxygen 22 release, maybe in the minor 22.1 release which will be in Spring 2020.

Regards,
Radu
Radu Coravu
<oXygen/> XML Editor
http://www.oxygenxml.com

Radu
Posts: 6642
Joined: Fri Jul 09, 2004 5:18 pm

Re: What about Git support?

Post by Radu » Thu Nov 21, 2019 9:19 am

Hi Chris,

As an idea related to the changed XPR, we have an end user who created a script which is run every time someone pulls and which updates the tech writer's XPR from the master XPR:

viewtopic.php?p=56230#p56230

Regards,
Radu
Radu Coravu
<oXygen/> XML Editor
http://www.oxygenxml.com

havip
Posts: 1
Joined: Fri Dec 20, 2019 10:24 am
Contact:

Re: What about Git support?

Post by havip » Fri Dec 20, 2019 10:28 am

Still no plan for Git support?
havip

alex_jitianu
Posts: 721
Joined: Wed Nov 16, 2005 11:11 am

Re: What about Git support?

Post by alex_jitianu » Mon Dec 30, 2019 9:54 am

Hi,

Well, there is actually Git support for awhile now. It comes in the form af an add-on and to install it you need to:
1. Go to Help->Install new add-ons...
2. If you are running Oxygen version 21.1 just select Default Update Site from the top combo. If not, paste this URL: https://raw.githubusercontent.com/oxyge ... /addon.xml
3. Check the Git Support add-on and follow the install procedure

Best regards,
Alex

chrispitude
Posts: 93
Joined: Thu May 02, 2019 2:32 pm

Re: What about Git support?

Post by chrispitude » Mon Dec 30, 2019 9:05 pm

havip, this Git plugin has become one of the most-loved features of Oxygen in our team. Give it a try!!

GHogarth
Posts: 16
Joined: Tue Aug 27, 2019 10:55 pm

Re: What about Git support?

Post by GHogarth » Thu Jan 09, 2020 6:07 pm

Important note: (thanks to alex_jitianu)
The Oxygen's Git plugin is based on the JGit library, which supports at least the precommit Git hooks.
If you are running on Windows, you need to:
1. Install Cygwin. You'll need to nstall the Git packages in Cygwin too, because the hook scripts want to execute git command.
2. Add the Cygwin bin folder (e.g. cygwin64\system\bin) to the Windows PATH environment variable.

chrispitude
Posts: 93
Joined: Thu May 02, 2019 2:32 pm

Re: What about Git support?

Post by chrispitude » Sun Jan 12, 2020 2:37 pm

GHogarth wrote:
Thu Jan 09, 2020 6:07 pm
Important note: (thanks to alex_jitianu)
The Oxygen's Git plugin is based on the JGit library, which supports at least the precommit Git hooks.
If you are running on Windows, you need to:
1. Install Cygwin. You'll need to nstall the Git packages in Cygwin too, because the hook scripts want to execute git command.
2. Add the Cygwin bin folder (e.g. cygwin64\system\bin) to the Windows PATH environment variable.
Hmm, interesting. Has anyone tried making precommit hooks with WSL (Windows Subsystem for Linux) in Windows 10?

Post Reply