Fork or branch?

I 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?

-- View this message in context: http://git.661346.n2.nabble.com/Fork-or-branch-tp6293910p6293910.html Sent from the git mailing list archive at Nabble.com.

Hi!

Will 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.

repo.git:
 - <python based>
 - <c based>
 - ... 
 - <some other language based>
 - shared_data

Just 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.

Good luck!

// Peter

-----Original Message-----
From: git-owner@vger.kernel.org [mailto:git-owner@vger.kernel.org] On Behalf Of adam_kb
Sent: den 21 april 2011 15:03
To: git@vger.kernel.org
Subject: Fork or branch?

I 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? 

-- View this message in context: http://git.661346.n2.nabble.com/Fork-or-branch-tp6293910p6293910.html Sent from the git mailing list archive at Nabble.com. -- To 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

adam_kb <a-kyle@hotmail.com> writes:

If you do not plan to merge your changes / your rewrite into project X, then it is a fork (like e.g. LibreOffice.org is a fork of OpenOffice.org).

Branch is in-repository line of development, e.g. 'stable' and 'unstable', or 'maint', 'master' and 'next' branches.

HTH

On Thu, Apr 21, 2011 at 06:03:19AM -0700, adam_kb wrote:

It depends whether you want to have separate repositories (with separate working tree) or you want to have in the same repository. Actually, it does not matter all that much what decision you make now, you can always change that later -- it is very easy to unite two repositories in one, and, on contrary, it is always possible to split branches. Obviously, if you split branches having some common commits, each clone will have them.

Personally, if I re-wrote some Python code in C or C++, I would probably make a separate clone just to have two working tree. If necessary, it is possible to merge changes between them using 'git pull'.

Dmitry

Hi,

adam_kb wrote:

It depends what you would like the resulting history to look like ("gitk --all" can help a lot here).

In practice, rewriting a project in another language tends to be a big step, almost as big as starting a new project. None of the original code gets kept. It can take a long time before the rewrite gains all the functionality of the original.

So let's imagine a few different scenarios.

1. Replacing pieces of the Python project with C++ incrementally
----------------------------------------------------------------

Perhaps I am writing an extension module or a standalone helper that the Python code calls. When finished, I'll be able to discard the Python skeleton.

In this case, it is a perfect opportunity to use a topic branch (see gitworkflows(7) for what this means). To start out, I make a new branch:

	git checkout -b go-faster

Now I hack as usual, telling git about my changes as I go:

	... hack hack hack ...
	git add .
	git add -u
	git diff --cached;	# looks good?
	make
	... test test test ...
	git commit;	# all right, commit the first change.

	... hack hack hack ...

Suppose I notice a bug that already existed in the original Python implementation. I fix it there first, since the C++ changes are up in the air:

	git checkout master
	... fix fix fix ...
	git add -A
	make test
	git diff --cached;	# looks good?
	git commit;	# ok, describe the fix.
	... test test test ...;	# one final test.

But I want to make sure the bugfix works well with the C++ changes, too:

	git checkout go-faster
	git merge master;	# merge in the bugfix

The code the bugfix touched might overlap with my changes, in which case I should look at the conflicts with "git diff" and figure out how to resolve them (see the user manual and git-merge(1) for details on this process). Hopefully the result works well. If it does not, I might go back to "master" and rethink the fix or use "git commit --amend" to tweak the merge resolution.

When all looks good, I run

	git push

to publish my changes. This does not automatically push the go-faster branch, which has not been made public yet; once I have announced it, I might use

	git push origin go-faster

to make it public, and then plain "git push" will push it from that point on.

2. Reimplementing with the Python code as an inspiration
--------------------------------------------------------

Now suppose I instead want to start the C version from scratch, adding features one at a time from the Python version.

In this case, it is probably simplest to start a new repository.

	git init project-x-c
	cd project-x-c

Eventually it is time to tell users of project-x that project-x-c is working as well or better and that project-x will be abandoned. Git does not care.

3. Reimplementing in the context of a larger project
----------------------------------------------------

Lastly, suppose I want to reimplement the Python version in C in one go, but this is just one file of many in a larger project.

This is conceptually very similar to case (2). It can make sense to at first treat the reimplementation as a new and separate feature (maintaining both side-by-side within the same tree), and only once the reimplementation is finished eliminating the old version. This is how the migration from the old ide_* to the new libata_* drivers in Linux has been proceeding, for example.

Another alternative is to do the reimplementation in one commit, replacing the old command at the same time.

Both methods have happened in the history of git itself a few times. Various commands written in Python or Perl were rewritten in C; one can find some examples with

	git log --diff-filter=D -- 'git-*.sh' 'git-*.perl' 'git-*.py'

using git 1.7.5.

Hope that helps. Jonathan