From: Christian Couder <chriscool@tuxfamily.org>
To: Johannes Schindelin <Johannes.Schindelin@gmx.de>
Cc: Junio C Hamano <gitster@pobox.com>,
git@vger.kernel.org, Stephan Beyer <s-beyer@gmx.net>,
Daniel Barkalow <barkalow@iabervon.org>
Subject: Re: [PATCH 2/2] rebase -i: use some kind of config file to save author information
Date: Tue, 23 Jun 2009 07:30:01 +0200 [thread overview]
Message-ID: <200906230730.01456.chriscool@tuxfamily.org> (raw)
In-Reply-To: <alpine.DEB.1.00.0906221117270.4168@intel-tinevez-2-302>
On Monday 22 June 2009, Johannes Schindelin wrote:
> Hi,
>
> On Sun, 21 Jun 2009, Junio C Hamano wrote:
> > Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> > > On Sat, 20 Jun 2009, Christian Couder wrote:
> > >> This is better than saving in a shell script, because it will make
> > >> it much easier to port "rebase -i" to C. This also removes some sed
> > >> regexps and some "eval"s.
> > >
> > > It will not make it easier to port "rebase -i" to C, as this is an
> > > internal file. The user is not supposed to touch it at all. Only
> > > "rebase -i". So it would be very easy to just use a different
> > > on-disk format when turning "rebase -i" into a builtin.
> >
> > "This is an internal file" is just a declaration you are making, and
> > the file is observable by anybody after "rebase -i" relinquishes the
> > control to let the user sort out the mess.
>
> It is an observation I am making. Sure, the file is observable by the
> user. But it is hidden deep inside .git/ and users who change things
> inside .git/ (with the exception of config) are asking for trouble.
>
> I really do not see the point of changing the file format _before_
> turning rebase -i into C.
>
> Oh, and I do not see the point of turning rebase -i into C before finally
> polishing sequencer so it can go into git.git's master.
The problem with this is that it will take a lot of time to implement the
features that have been added to rebase -i since the sequencer stalled,
then to polish it, and to get it reviewed and so on, and during that time
other features or changes may be implemented by other people.
So I prefer to use code from the current sequencer (at
http://repo.or.cz/w/git/sbeyer.git) to start porting step by step rebase -i
to C.
Regards,
Christian.
next prev parent reply other threads:[~2009-06-23 5:29 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-06-20 2:34 [PATCH 2/2] rebase -i: use some kind of config file to save author information Christian Couder
2009-06-20 9:27 ` Jakub Narebski
2009-06-21 5:15 ` Christian Couder
2009-06-21 21:55 ` Johannes Schindelin
2009-06-21 23:15 ` Junio C Hamano
2009-06-22 4:50 ` Christian Couder
2009-06-22 9:19 ` Johannes Schindelin
2009-06-23 5:30 ` Christian Couder [this message]
2009-06-23 9:40 ` Johannes Schindelin
2009-06-24 4:36 ` Christian Couder
2009-06-23 4:57 ` Christian Couder
2009-06-23 5:25 ` Junio C Hamano
2009-06-24 4:29 ` Christian Couder
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=200906230730.01456.chriscool@tuxfamily.org \
--to=chriscool@tuxfamily.org \
--cc=Johannes.Schindelin@gmx.de \
--cc=barkalow@iabervon.org \
--cc=git@vger.kernel.org \
--cc=gitster@pobox.com \
--cc=s-beyer@gmx.net \
/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).