name it ( CAD-Cuff ) computer aided design CAD and cuff as the entry gate of fashion design
1 Like
Ok, great! What is the recommended Git client? Could someone describe the recommended procedure for becoming a contributor? I mean, shall we fork the repository, or commit directly into the main repository?
3 Likes
Hey @yannlossouarn, I think the process remains the same as it did with Mercurial & Bitbucket.
- Create a GitHub account.
- Fork the project’s GitHub repository.
- Clone your fork to your local machine.
- Add the main project repo (upstream) to your clone as a remote repo. See here.
- Commit changes to your local repo.
- Pull from upstream and resolve any merge conflicts.
- Push changes to your fork on GitHub.
- Create a pull request.
I plan to update the wiki material for contributors to reflect the move and make things clearer. Also, I take it Steve is the new project maintainer, so if you’re reading this, welcome Steve!
5 Likes
@yannlossouarn, I see your are UI designer
Note Valentina UI uses actually Qt4 API and technology like Qt Designer which are deprecated in Qt5 and imho a mess (buggy, many limitations, etc.)
But move to QML is another story … (Tape is less challenging)
1 Like
Let’s have a new thread for discussing working with the Github repo
1 Like
Is there any easy way to “pull” or print a complete copy of the supporting text and information for any specific issue documented in the repository? I can use the sledge hammer approach and make lots of screenshots. I was hoping there is something easier that I just don’t know. I am preparing for a long stretch with no internet
1 Like
thanks for the info. I have a question (probably for Steve but you might have the answer). is it reasonable for me to do another fork of the valentina-team/vpo2 repository just before i leave next week. My intent would be to capture the most current committed items including source and issues
Hey many people create multiple forks of a given project. This is not unusual. Hope everything is good with you, I’m way busy this week.
I would assume you can make as many remote forks as you want, as well as any number of local forks?
In regards to forks and commits - just to make sure I got it correct… I made a fork of the original-> develop branch and then made a local clone, then updated to most recent commits. Created a new local branch “fixes”… made fixes and built to check the fixes.
So now the question is… do I make the commits to the the fixes branch, merge to develope, then push to fork -> develope, then make a pull request to the original? Or, do I create a fixes branch on the fork, commit the changes to the local -> fixes, the push the changes to the fork -> fixes… merge fixes to develop on fork and local… then make a pull request?
In other words, do I want the local and remote fork to mirror each other? And specifically where should any pull requests be made from?
Hi @Douglas, Yes, you understand the workflow.
One thing though.
You merge your local fixes branch to your local develop branch. Then in Qt, do the steps to Build All then run and test it for how to break it. If it seems reasonably okay, push to your remote firk and make a pull request.
I think you should have a fixes branch on your fork as well, not only your local.
This way other people could take a look at your changes if you need help. Theoretically, someone could even contribute.
Also your work is saved on the repo and not only on your local machine. It might come in handy if you lose your data on your local machine for some reason.
When you’re done then you can merge your fixes branch to your develop, test everything like Slspencer said (make sure to also update your develop branch on a regular basis and that it’s up to date before the pull request) and then make a pull request to the original repo.
2 Likes
That’s kinda of what I was thinking.
That’s a given to me… I’m a stickler for details and would rather get it right the first time and not have to fix it later.
Is it best to update develop then merge to develop OR merge to develop then update develop?
Anybody good at making flow charts? This would be super for the wiki.
1 Like
Mermaid (a simple markdown-like script language for generating charts from text) could be a useful tool.
[Edit: Even better, there is a GraphViz Mediawiki plugin, so the charts can be created right on the wiki page. Take a look at the gallery for some pretty impressive examples. The source code is included in each example.]
1 Like
flow chart of the pattern creation process or flowchart of the existing functionality of the code base? or both?
1 Like
I would update develop, then make the merge, then the push. But both ways are probably ok!
1 Like
Yes it would. Plus some more thorough info on Qt and the makefile stuff…
I assume a flow chart of handling commits, merging, etc with the Github repo.
1 Like