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
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html