git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Christian Couder <chriscool@tuxfamily.org>
To: Martin von Zweigbergk <martin.von.zweigbergk@gmail.com>
Cc: git@vger.kernel.org, Johannes.Schindelin@gmx.de,
	christian.couder@gmail.com, trast@student.ethz.ch
Subject: Re: Refactoring git-rebase.sh and git-rebase--interactive.sh
Date: Wed, 3 Nov 2010 04:24:32 +0100	[thread overview]
Message-ID: <201011030424.33093.chriscool@tuxfamily.org> (raw)
In-Reply-To: <AANLkTimeWDbJPor9PnKgW5sD7DLjqrm-vTzEtnARvP3M@mail.gmail.com>

On Tuesday 02 November 2010 13:33:07 Martin von Zweigbergk wrote:
> (Resending as plain text. Sorry about the spam to the guys on the CC list.)
> 
> Hi,
> 
> I have now been using Git for something like 18 months, and I think it's
> about time that I try to contribute.

Great!

> So, after adding some features to git-rebase.sh (which I will send
> separate mails about), I realized I would have to add them to
> git-rebase--interactive.sh as well. Rather than doing that, I would
> prefer to first extract the common parts of these scripts and add the
> features in only one place. Since this is the first time I do anything
> on Git, I will need a lot of advice.
> 
> My main goal is to extract the commonalities in command line parsing and
> interpretation as well as validation (of command line and repository
> state, and running the pre-rebase hook).
> 
> First of all, do you agree that this should be done and is now a good
> time to do it (I'm thinking mostly about conflicts with other ongoing
> efforts)? While at GitTogether, I talked briefly to Thomas Rast about
> doing this, and he mentioned that resurrecting the git sequencer might
> be a better idea. However, I *think* much of what I was thinking about
> doing involves code that is run before the git sequencer is called. I
> wouldn't mind working on the git sequencer afterwards, unless Christian
> Couder or someone else is currently working on it.

Now that GTAC (http://www.gtac.biz) is over, I plan to work on options 
--continue, --abort and --skip for git cherry-pick/revert. After that I hope 
to be able to refactor the code so that in the end common code is used by 
cherry-pick/revert and rebase.

And I agree that what you want to do does not conflict with my plan. On the 
contrary it might help in the end. Go for it!

Thanks,
Christian.

  parent reply	other threads:[~2010-11-03  3:24 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-11-02 12:33 Refactoring git-rebase.sh and git-rebase--interactive.sh Martin von Zweigbergk
2010-11-02 12:46 ` Johannes Sixt
2010-11-03  3:24 ` Christian Couder [this message]
2010-11-03 12:22   ` Martin von Zweigbergk
2010-11-04 21:15   ` Yann Dirson
2010-11-04 21:49     ` Pat Notz
2010-11-05  8:58     ` Christian Couder
2010-11-06  2:03 ` Martin von Zweigbergk
2010-11-07  1:57   ` Martin von Zweigbergk

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=201011030424.33093.chriscool@tuxfamily.org \
    --to=chriscool@tuxfamily.org \
    --cc=Johannes.Schindelin@gmx.de \
    --cc=christian.couder@gmail.com \
    --cc=git@vger.kernel.org \
    --cc=martin.von.zweigbergk@gmail.com \
    --cc=trast@student.ethz.ch \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).