On 20/08/2016, at 11:51 PM, Ryan Schmidt wrote: > > On Aug 19, 2016, at 10:24 PM, Lawrence Velázquez wrote: > >> Any documentation we write should be written specifically for developers >> >> 1. who are accustomed to using Subversion, and >> 2. want to translate *their MacPorts workflow* to Git. >> >> We shouldn't expend effort rewriting a sloppier version of every generic >> "this is how version control works" Git tutorial on the Web. There's quite >> enough of that. > > Maybe what we really need is documentation for MacPorts developers that just > covers how to do whatever they need to do, using git. (I don't know if we had > such a document for Subversion.) Things like... When first starting to > contribute, fork the repo, clone the fork to your Mac; if you already have a > fork, update it with the latest changes (how?). Create a branch for your > changes. Make your changes in your text editor. Use "git diff" to see the > changes. Use "git commit" to commit them. Use "git push" something to push > them to GitHub. Submit a pull request on GitHub. When the pull request is > accepted, delete your branch.
Fork the repo?? The command for first use is just "git clone". This gets you a local working copy of the entire repository and its change history at the current time. For small changes, edit, test and "git commit -a" (all) or "git commit filename(s)" --- locally. For large changes, start a local branch and later merge it with your local master branch. The commands "git status", "git log" and "git diff" help you keep track of changes in progress and what is committed or uncommitted. To publish your local commits, first use "git pull --rebase origin master" to fetch the latest central changes and merge them into your local repository, then use "git push origin master". The --rebase option gets your changes and the central ones into a reasonably logical and readable sequence. Use "git pull --rebase origin master" on its own if you just wish to get up to date with changes to the central repo. And that is (almost) all the "gittery" I have needed and used on KDE development work in the last 4 years. The one exception is that, during the run-up to a KDE Applications release, the release guy makes a branch on the central repository for the new release and development can then continue on the master branch. If you are going to fix a bug, you need to retrieve the new branch from central and make the same fix in two branches. I can never remember exactly how to do that… ;-) … but I have the recipe in an email somewhere... Cheers, Ian W. > At various step along the way, we could add "historical note" boxes showing > how those step were done with Subversion. At some point in the future we'll > probably want to remove the Subversion historical information, but still have > the git instructions. > > _______________________________________________ macports-dev mailing list [email protected] https://lists.macosforge.org/mailman/listinfo/macports-dev
