On Sun, 16 Oct 2016 21:39:41 -0400
rhkra...@gmail.com wrote:

> I am probably using git in an unusual way.
> I want to do some development for a project that is managed by
> Mercurial (scite / scintilla), but, for the sake of learning git (and
> minimizing the need to learn anything else)  I want to use git for
> the work I do.
> I've downloaded the source code as tarballs (which are available--I
> could also have downloaded the source code using Mercurial, but, as
> long as the tarballs are available, I'd prefer to do it using
> tarballs).
> I originally downloaded version 3.66 of the source code, untarred it
> into a working directory, initialized a git repository, and then
> added and committed the source code to the git repository.
> So far, I haven't actually made any changes to the source code.
> Now version 3.70 is available, and I sort of repeated the process,
> that is, I untarred the new version into the working directory that I
> had previously created, then did a git status--it seemed to recognize
> the modified files, which I then added and committed.
> So far, so good.
> But, I'm not sure how to handle further updates after I've made local
> changes to the source code.
> The one approach I can think of is to create a patch file before I
> download the next update, then download and untar the next update,
> and then apply that patch file (while doing git adds and commits at
> the appropriate times, which I have to think about).
> But the patch file approach seems rather cumbersome and un-git (and
> un-CMS) like--is there a better approach?

Well, two points here.

The first one: why not use a Git-to-Hg "bridge" to natively work with a
remote Mercurial repository?  One such bridge is [1]; the project's
README file contains pointers to other implementations and the
comparison of them.

This approach allows you to use your CMS of choice to work on the
project while not inventing ad-hoc solutions for bringing in upstream
changes over time.

So OK, let's supposed you did know such solutions exist but consciously
decided to avoid them for whatever reason.
If we only consider your current workflow, I see two issues with it
(and that's the second point).

First, simple untarring of a new upstream tarball and running
`git add -u` on the results is not enough: this does not take care of
the files _deleted_ by upstream in the new release.

What you really need to do is:

1) Delete everything from the work tree and the index:

   git rm -rf .

2) Unpack your tarball.

3) Stage the new contents:

   git add .

4) Commit.

Second, there's no sense to use patches because commits on Git
branches represent changes in a much more convenient way than patches.
While commits are _not_ patches in Git, this is merely an
implementation detail, and each of them still constitutes a changeset.
You can easily see what changes a commit introduced (compared to its
parent commit) by running

  git show <commit_id>

Another fact is that Git was expliticly created to support certain
workflows involving patches -- namely, generating patch series and
sending them to a mailing list, and applying a patch series from a
mailbox file.

Hence, if you refuse to use a Git-to-Hg bridge for some reason I
suggest you to use normal Git branches to track your changes.

Basically, the workflow would be something like this:

1) Bring a new upstream release in -- recording a commit on some
   dedicated branch (I'd name it "upstream").

2) Fork a branch off that commit.  Let's call it "devel".

3) Implement whatever set of changes you need there.

   Record a commit for each.  Feel free to use `git rebase` to massage
   that history until you're OK with exporting it.

4) Use `git format-patch` to prepare a set of patches to send.

   Note that `git send-email` is able to mail it right away to the
   specified address.

5) Once the new upstream release comes out, repeat step (1)
   and then `git rebase` your "devel" onto the new tip of "upstream".

6) Repeat steps (3)..(5) forever ;-)

1. https://github.com/felipec/git-remote-hg

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