On Wed, 2017-06-21 at 23:30 +0200, Daniel A. Wagenaar wrote: The patch can be applied directly to the git repository and there are two options. One is to join the inkscape project group on GitLab, allowing you to commit directly to master branch. The other is to fork the project on GitLab, commit your patch to your fork and then click the propose merge (pull request) button, that'll run the CI builder and allows others to review your code. Best Regards, Martin Owens

On Tue, 2017-06-27 at 13:31 -0700, alvinpenner wrote: There are some functions on the internet gitlab.com website which allows you to in-place edit a file, it creates a commit for your modifications. Once edited, you can use the merge request / pull request button to ask for review. The other option is to git clone, modify the file, commit, push and thn create a pull request using the url returned to your when you do a push. Good luck! Best Regards, Martin Owens

IMHO the best way to be an occasional contributor to a git repo like inkscape is to create a new branch and then request a merge. This makes making changes easier and is more robust. Specifically I use this procedure: (once you've got it cloned to your system) 1. Fetch an uptodate version of the remotes - Type ```git remote update``` - This will fetch (and update) your origin and the original project's remote. - Note that ```git remote -v``` will find and inform you of all remotes but do nothing so is useful for seeing shape of this. - This combines fetch commands for each possible remote into one command. 2. Check you understand code organisation. - Type ```git branch -a``` - Will show you the names of all branches in local and remotes. (Using different colors probably depending on your git shell setup.) - You should see the original project's remote and your origin as well as your local master and any branches you have made. - This command is useful to see what shape the code is in. 3. Merge your master to agree with the remote - Type ```git merge ``` Now you're up-to-date and ready to work. You should do new work in a newly made branch to avoid contaminating someone else's work (unless you coordinate with a team). Its also easy to delete your branch once its accepted and cleanup ready for your next contribution. One per branch, well named and described. 4. Get into the right branch to do the action required. - To make a new branch so we can begin work: - Type ```git checkout -b newbranchname``` - This will create a branch labelled "newbranchname" and check it out (make it current) in one step. - To get into a branch to do work on it: - Type ```git checkout branchname``` - To get your master uptodate and in-sync with the remote - Type ```git checkout master``` to get into your local master - Type ```git merge remotename master``` to get the original project's master into your local master - Type ```git push origin master``` to update your remote master to agree. Your files in the project have now been changed to reflect them as they are in that branch. So you can work on them, making changes so you can commit them and store them as a named entity for easy review, management, changes. 5. To commit changes (record them for later use) - ```git commit -am "the message"``` - This combined command commits all changes (including new files and deletions) as well as any content changes and - adds a commit message. 6. Check status of local branch - Type ```git status``` - This shows you what the system thinks you intended to do and is generally useful to see what's up. - Use it often to see what the git system understands. - You can also use "git lg" (if you added it as described below) 7. Push your changes up to your remote (origin) so you can then push it to the original project: - Type ```git push origin branchname``` - The "branchname" is the branch you are working in 8. Push suggested branch to the original project. - On the github/gitlab website - refresh the page and you will see your new commit shows as a branch. - The website may/will offer to push this to the original project. Accept this and type a comment explaining what the branch is for. 9. Pay attention to what the original project's leader tell you to do in terms of changes. - make these, commit, push as above(4..8) and the results should go through to the original website automatically and be added to the commit. - Be sure to be in the correct branch (yours) when you make changes This doc has not gone into rebasing or squashing commits. get help from someone on your project or read more elsewhere. Lastly add this command to git so you can see the status of commits to the remotes in a simple yet clear format. This line only needs to be entered once at commandline prompt. It adds the alias "git lg" to your list of possible git commands. It will remain across system reboots. ```git config --global alias.lg "log --color --graph --pretty=format:'%Cred%h%Creset -%C(yellow)%d%Creset %s %Cgreen(%cr) %C(bold blue)<%an>%Creset' --abbrev-commit --"``` Once added you can see the log of actions by typing: ```git lg ``` Cheers... On 6/28/2017 9:16 AM, alvinpenner wrote:

Yes - good point. - "git add -A" is a better way before "git commit -am" to ensure all newly removed and added files are ready for the commit. On 6/28/2017 2:23 PM, Ken Moffat wrote: