All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jeff King <peff@peff.net>
To: Michael Witten <mfwitten@MIT.EDU>
Cc: git@vger.kernel.org
Subject: Re: Imports without Tariffs
Date: Sat, 13 Oct 2007 03:57:23 -0400	[thread overview]
Message-ID: <20071013075723.GA27533@coredump.intra.peff.net> (raw)
In-Reply-To: <1240801C-F4CC-4290-8C3D-2038F1957DF3@MIT.EDU>

On Sat, Oct 13, 2007 at 12:30:09AM -0400, Michael Witten wrote:

>> except that git-rebase is smart enough to realize that C == C' and skip
>> it (so it's a "safe" way of moving forward).
>
> This is good to know! The documentation should mention this case!

Yes, it probably should. Can you submit a patch describing the behavior
where you think it ought to go?

> Basically, the imported cvs history should be treated like
> a remote that's being tracked. It seems like the solution
> I proposed kind of does this and would work for other SCM
> imports too.

I think it's an interesting avenue to pursue, though I would worry a
little about robustness. I like the fact that after rebasing, the
commits have done a complete git->cvs->git loop and look identical, so I
am sure everything made it through intact. But perhaps I'm just being
paranoid.

As an alternate idea, why not try to have the CVS commit contain all
information necessary to create a particular git commit. IOW, describe
all of the data that goes into the commit hash as textual comments in
the CVS commit (committer name/time, author name/time). And then
theoretically git-cvsimport can reconstruct the exact same commits
again, and your git->cvs->git merge really _will_ be a fastforward.

> Unfortunately, they are the ones running the servers; I have to do my
> git work behind the scenes.

I've been in the same boat, and just used the rebase trick I described.
Of course it was a very tiny project, so I didn't mind losing some of
the full power of git.

-Peff

  parent reply	other threads:[~2007-10-13  7:57 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-10-13  4:01 (unknown), Michael Witten
2007-10-13  4:07 ` your mail Jeff King
     [not found]   ` <1240801C-F4CC-4290-8C3D-2038F1957DF3@MIT.EDU>
2007-10-13  4:39     ` Imports without Tariffs Michael Witten
2007-10-13  7:57     ` Jeff King [this message]
2007-10-13 23:04       ` Michael Witten
2007-10-14 16:40         ` Jeff King
2007-10-14 22:10           ` Michael Witten
  -- strict thread matches above, loose matches on Subject: below --
2007-10-12 20:36 mfwitten
2007-10-13  2:49 ` Jeff King
     [not found] ` <3B7796D6-5901-40B0-B3FC-70642AC50B08@mit.edu>
2007-10-13  4:44   ` Michael Witten

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20071013075723.GA27533@coredump.intra.peff.net \
    --to=peff@peff.net \
    --cc=git@vger.kernel.org \
    --cc=mfwitten@MIT.EDU \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.