{"thread":{"id":"27153","subject":"Fork or branch?","startedAt":"2011-04-21T13:03:19Z","lastAt":"2011-04-21T22:39:00Z","messageCount":5,"participants":["adam_kb","Peter Jönsson P","Jakub Narebski","Dmitry Potapov","Jonathan Nieder"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"166189","messageId":"1303390999618-6293910.post@n2.nabble.com","threadId":"27153","inReplyTo":null,"subject":"Fork or branch?","fromName":"adam_kb","fromEmail":"a-kyle@hotmail.com","sentAt":"2011-04-21T13:03:19Z","receivedAt":"2011-04-21T13:03:19Z","isPatch":false,"sender":{"key":"a-kyle@hotmail.com","avatar":"https://gravatar.com/avatar/b355c694c28f31b51b43be0f1c4ba58d09729c77395a10fa4f68989065db6f27?d=mp&s=160"},"body":"I am new to git and understand most of it except for merge. My question is -\nif I have project X on branch master and its coded in python but I then want\nto take that same project and code it in say C or C++ would I fork or branch\nthe project? \n\n--\nView this message in context: http://git.661346.n2.nabble.com/Fork-or-branch-tp6293910p6293910.html\nSent from the git mailing list archive at Nabble.com.\n"},{"id":"166192","messageId":"41F80411E3CC644A844E6BED6E472FD91AE14979CC@ESESSCMS0363.eemea.ericsson.se","threadId":"27153","inReplyTo":"1303390999618-6293910.post@n2.nabble.com","subject":"RE: Fork or branch?","fromName":"Peter Jönsson P","fromEmail":"peter.p.jonsson@ericsson.com","sentAt":"2011-04-21T13:23:01Z","receivedAt":"2011-04-21T13:23:01Z","isPatch":false,"sender":{"key":"peter.p.jonsson@ericsson.com","avatar":"https://gravatar.com/avatar/7c7bf60738b19f1590a3d39e021adadad713f84adf80a7a405667fe939ef16bb?d=mp&s=160"},"body":"Hi!\n\nWill you be sharing anything between the projects? If you have data that will be shared between the two different implementations it would be enough with just a simple directory structure while still inside the same git repo.\n\nrepo.git:\n - \n - \n - ... \n - \n - shared_data\n\nJust create a new branch on the current code based and start working on the C based one. Then you can merge it back to the \"main\" code line if it works out.\n\nGood luck!\n\n// Peter\n\n-----Original Message-----\nFrom: git-owner@vger.kernel.org [mailto:git-owner@vger.kernel.org] On Behalf Of adam_kb\nSent: den 21 april 2011 15:03\nTo: git@vger.kernel.org\nSubject: Fork or branch?\n\nI am new to git and understand most of it except for merge. My question is - if I have project X on branch master and its coded in python but I then want to take that same project and code it in say C or C++ would I fork or branch the project? \n\n--\nView this message in context: http://git.661346.n2.nabble.com/Fork-or-branch-tp6293910p6293910.html\nSent from the git mailing list archive at Nabble.com.\n--\nTo unsubscribe from this list: send the line \"unsubscribe git\" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html\n"},{"id":"166194","messageId":"m3sjtbwu01.fsf@localhost.localdomain","threadId":"27153","inReplyTo":"1303390999618-6293910.post@n2.nabble.com","subject":"Re: Fork or branch?","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2011-04-21T14:38:08Z","receivedAt":"2011-04-21T14:38:08Z","isPatch":false,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"adam_kb writes:\n\n> I am new to git and understand most of it except for merge. My question is -\n> if I have project X on branch master and its coded in python but I then want\n> to take that same project and code it in say C or C++ would I fork or branch\n> the project? \n\nIf you do not plan to merge your changes / your rewrite into project\nX, then it is a fork (like e.g. LibreOffice.org is a fork of\nOpenOffice.org).\n\nBranch is in-repository line of development, e.g. 'stable' and\n'unstable', or 'maint', 'master' and 'next' branches.\n\nHTH\n-- \nJakub Narebski\nPoland\nShadeHawk on #git\n"},{"id":"166198","messageId":"20110421183320.GA17298@dpotapov.dyndns.org","threadId":"27153","inReplyTo":"1303390999618-6293910.post@n2.nabble.com","subject":"Re: Fork or branch?","fromName":"Dmitry Potapov","fromEmail":"dpotapov@gmail.com","sentAt":"2011-04-21T18:33:20Z","receivedAt":"2011-04-21T18:33:20Z","isPatch":false,"sender":{"key":"dpotapov@gmail.com","avatar":"https://avatars.githubusercontent.com/u/6568595?v=4"},"body":"On Thu, Apr 21, 2011 at 06:03:19AM -0700, adam_kb wrote:\n> I am new to git and understand most of it except for merge. My question is -\n> if I have project X on branch master and its coded in python but I then want\n> to take that same project and code it in say C or C++ would I fork or branch\n> the project? \n\nIt depends whether you want to have separate repositories (with separate\nworking tree) or you want to have in the same repository. Actually, it\ndoes not matter all that much what decision you make now, you can always\nchange that later -- it is very easy to unite two repositories in one,\nand, on contrary, it is always possible to split branches. Obviously, if\nyou split branches having some common commits, each clone will have them.\n\nPersonally, if I re-wrote some Python code in C or C++, I would probably\nmake a separate clone just to have two working tree. If necessary, it\nis possible to merge changes between them using 'git pull'.\n\n\nDmitry\n"},{"id":"166211","messageId":"20110421223845.GA3993@elie","threadId":"27153","inReplyTo":"1303390999618-6293910.post@n2.nabble.com","subject":"Re: Fork or branch?","fromName":"Jonathan Nieder","fromEmail":"jrnieder@gmail.com","sentAt":"2011-04-21T22:39:00Z","receivedAt":"2011-04-21T22:39:00Z","isPatch":false,"sender":{"key":"jrnieder@gmail.com","avatar":"https://avatars.githubusercontent.com/u/281595?v=4"},"body":"Hi,\n\nadam_kb wrote:\n\n> I am new to git and understand most of it except for merge. My question is -\n> if I have project X on branch master and its coded in python but I then want\n> to take that same project and code it in say C or C++ would I fork or branch\n> the project? \n\nIt depends what you would like the resulting history to look like\n(\"gitk --all\" can help a lot here).\n\nIn practice, rewriting a project in another language tends to be a big\nstep, almost as big as starting a new project. None of the original\ncode gets kept. It can take a long time before the rewrite gains all\nthe functionality of the original.\n\nSo let's imagine a few different scenarios.\n\n1. Replacing pieces of the Python project with C++ incrementally\n----------------------------------------------------------------\n\nPerhaps I am writing an extension module or a standalone helper that the\nPython code calls. When finished, I'll be able to discard the Python\nskeleton.\n\nIn this case, it is a perfect opportunity to use a topic branch (see\ngitworkflows(7) for what this means). To start out, I make a new\nbranch:\n\n\tgit checkout -b go-faster\n\nNow I hack as usual, telling git about my changes as I go:\n\n\t... hack hack hack ...\n\tgit add .\n\tgit add -u\n\tgit diff --cached;\t# looks good?\n\tmake\n\t... test test test ...\n\tgit commit;\t# all right, commit the first change.\n\n\t... hack hack hack ...\n\nSuppose I notice a bug that already existed in the original Python\nimplementation. I fix it there first, since the C++ changes are up in\nthe air:\n\n\tgit checkout master\n\t... fix fix fix ...\n\tgit add -A\n\tmake test\n\tgit diff --cached;\t# looks good?\n\tgit commit;\t# ok, describe the fix.\n\t... test test test ...;\t# one final test.\n\nBut I want to make sure the bugfix works well with the C++ changes,\ntoo:\n\n\tgit checkout go-faster\n\tgit merge master;\t# merge in the bugfix\n\nThe code the bugfix touched might overlap with my changes, in which\ncase I should look at the conflicts with \"git diff\" and figure out\nhow to resolve them (see the user manual and git-merge(1) for details\non this process). Hopefully the result works well. If it does not,\nI might go back to \"master\" and rethink the fix or use \"git commit\n--amend\" to tweak the merge resolution.\n\nWhen all looks good, I run\n\n\tgit push\n\nto publish my changes. This does not automatically push the go-faster\nbranch, which has not been made public yet; once I have announced it, I\nmight use\n\n\tgit push origin go-faster\n\nto make it public, and then plain \"git push\" will push it from that\npoint on.\n\n2. Reimplementing with the Python code as an inspiration\n--------------------------------------------------------\n\nNow suppose I instead want to start the C version from scratch, adding\nfeatures one at a time from the Python version.\n\nIn this case, it is probably simplest to start a new repository.\n\n\tgit init project-x-c\n\tcd project-x-c\n\nEventually it is time to tell users of project-x that project-x-c is\nworking as well or better and that project-x will be abandoned. Git\ndoes not care.\n\n3. Reimplementing in the context of a larger project\n----------------------------------------------------\n\nLastly, suppose I want to reimplement the Python version in C in one\ngo, but this is just one file of many in a larger project.\n\nThis is conceptually very similar to case (2). It can make sense to\nat first treat the reimplementation as a new and separate feature\n(maintaining both side-by-side within the same tree), and only once\nthe reimplementation is finished eliminating the old version. This is\nhow the migration from the old ide_* to the new libata_* drivers in\nLinux has been proceeding, for example.\n\nAnother alternative is to do the reimplementation in one commit,\nreplacing the old command at the same time.\n\nBoth methods have happened in the history of git itself a few times.\nVarious commands written in Python or Perl were rewritten in C; one\ncan find some examples with\n\n\tgit log --diff-filter=D -- 'git-*.sh' 'git-*.perl' 'git-*.py'\n\nusing git 1.7.5.\n\nHope that helps.\nJonathan\n"}]}