On Thu, 28 Jan 2016 09:25:51 -0600
John McKown <john.archie.mck...@gmail.com> wrote:

> OK, I admit it, I want to abuse git. I cloned a library which
> implements some functionality. The library is written in Python. I
> want to "port" this functionality to Google's Go language.

Congrats with this from another gopher! ;-)

> Now, what is probably the correct thing to do is to simply create a
> "Go" branch and develop there, leaving the Python code alone. Perhaps
> merging the Go branch back into "master" once the port is working.
> But I'd really like to create the "Go" branch with none of the Python
> files in it and with no "footprints" of the Python code in the "Go"
> branch. I know that I could simply create the "Go" branch, then git
> rm all the Python code. But I don't really like "cluttering up" the
> commit log in the "Go" branch that way.

That's what `git checkout --orphan <branchname>` is for.

Basically you do:

  $ git checkout --orphan go
  $ git rm -rf --cached .
  ... also maybe remove most of the files in the work tree as well
  ...
  $ git add whatever
  $ git commit # Will be the first commit on "go"
  
> Perhaps what I need to do is create a separate repository with the
> "Go" code. And then, later, somehow "merge" (not git merge) the two
> repositories together. Perhaps something like:
> 
> cd ~/Library
> git fetch file://~/Library-Go/.git Go

^^^ JFTR, this is an anti-pattern: most Git operations on
locally-accessible repositories (same filesystem) are faster when you
just use plain pathnames, like in `git fetch ~/Library-Go` (there's no
need to tuck "/.git" onto its end BTW) -- because Git "short-circuits"
certain operations then.

> git checkout FETCH_HEAD
> git checkout -b Go
> git checkout -- master .gitignore
> # remove files in directory which were in .gitignore from master
> # branch

In my eyes, what these commands appear to do would amount to

  git fetch ~/Library/Go Go:Go
  git checkout -- master .gitignore

> Or am I totally off-base with this idea of keeping functionally
> identical libraries implemented in different language in different
> branches?

The end result of that "separate repo + fetch a single branch" approach
would result in absolutely the same end result, right?

So I'd personally would Go with a from-scratch branch in the original
repo.

-- 
You received this message because you are subscribed to the Google Groups "Git 
for human beings" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to git-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Reply via email to