Fork or branch?

Fork or branch?

[adam_kb]

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.

RE: Fork or branch?

[Peter Jönsson P]

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

Re: Fork or branch?

[Jakub Narebski]

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

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

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
-- 
Jakub Narebski
Poland
ShadeHawk on #git

Re: Fork or branch?

[Dmitry Potapov]

On Thu, Apr 21, 2011 at 06:03:19AM -0700, adam_kb wrote:
> 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? 

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

Re: Fork or branch?

[Jonathan Nieder]

Hi,

adam_kb wrote:

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

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