git@vger.kernel.org mailing list mirror (one of many)
 help / color / mirror / code / Atom feed
From: Stephan Beyer <s-beyer@gmx.net>
To: Junio C Hamano <gitster@pobox.com>
Cc: git@vger.kernel.org,
	Johannes Schindelin <Johannes.Schindelin@gmx.de>,
	Joerg Sommer <joerg@alea.gnuu.de>,
	Daniel Barkalow <barkalow@iabervon.org>,
	Christian Couder <chriscool@tuxfamily.org>
Subject: Re: squashing patches
Date: Tue, 10 Jun 2008 02:38:16 +0200	[thread overview]
Message-ID: <20080610003816.GH8079@leksak.fem-net> (raw)
In-Reply-To: <7vskvmfhjj.fsf@gitster.siamese.dyndns.org>

Hi,

> > Example:
> > 	pick ea7beef
> > 	edit		# or "pause" as you suggested
> > After a little discussion this became:
> > 	pick --edit ea7beef
> >
> > And I can't objectively say what's better
> 
> Me neither.  My "expectation" came primarily from what I understood,
> namely you seemt to prefer atomism, and not from "I want things to be this
> way".

Yes I prefer atomism, because it helps to keep things simple and stupid.

> If we think any proposed and future instruction would be reasonable to
> have --edit option, then all insn implementation would need to support
> "edit" option anyway, and the users do not have to remember which insn
> does and does not support --edit

Currently every insn where it makes sense (indeed, this may be
subjective) does support --edit.  So currently "file" (or "patch"),
"pick", "merge" and "squash" do, because they commit something.

But you are right (and I think Peff meant the same), that the separate
insn is more generic and thus it's more flexible.

So would you prefer a)"pause" or b)"edit"?
Or as text:
a)
edit [<commit>]::
	Pauses the sequencer process to let you manually make changes.
+
After you have finished your changes and added them to the index,
invoke `git-sequencer --continue`.
If you only want to edit the last commit message with an editor,
run `git commit --amend` (see linkgit:git-commit[1]) before.
+
If `<commit>` is given, pick `<commit>` first. This is a short form for
`pick <commit>` and `edit` on separate lines.)

b)
edit <commit>::
	Picks a commit and pauses the sequencer process to let you
	make changes.
+
This is a short form for `pick <commit> and `pause` on separate lines.

pause::		# (perhaps options may occur later, if they make sense)
	Pauses the sequencer process to let you manually make changes.
+
After you have finished your changes and added them to the index, 
invoke `git-sequencer --continue`.
If you only want to edit the last commit message with an editor,
run `git commit --amend` (see linkgit:git-commit[1]) before.


More flexible and modular seems to be the approach b).
But I want your opinion to go sure. ;-)

> I see.  Not using count but setting an explicit mark and using that commit
> sounds more robust, considering that use case.

So I take the --up-to syntax from Paolo?
Seemed right to me.

> >>  - The "tag" command looked a little out of place;
> >
> > Eh, why?
> 
> Why not?

Because it's practical.
The marks are only available during sequencer process and it's just
useful to tag something that you can reach by that name afterwards
(or during sequencing, too).
The user could use tag instead of mark if he wants to keep the ref
after sequencing.
I also can imagine sequencer-using scripts, that want to tag a version
release or something.

> I just wondered why there was a support only for lightweight tag there.

Basically because it's in next :)
And then I thought "Ok, nice. Let's keep it.".

> You do not have "branch" command, and your "tag" command does not seem to
> support things like -a, -s, -m<msg>, etc.

Hmmm, -a, -s and -m could even be useful.

Regards,
  Stephan

-- 
Stephan Beyer <s-beyer@gmx.net>, PGP 0x6EDDD207FCC5040F

  reply	other threads:[~2008-06-10  0:39 UTC|newest]

Thread overview: 41+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-06-07 22:01 [RFC] git-sequencer.txt Stephan Beyer
2008-06-09 11:45 ` squashing patches (was: Re: [RFC] git-sequencer.txt) Stephan Beyer
2008-06-09 14:04   ` Johannes Schindelin
2008-06-09 15:10   ` squashing patches Paolo Bonzini
2008-06-09 15:43     ` Paolo Bonzini
2008-06-09 16:29     ` Stephan Beyer
2008-06-09 16:37       ` Paolo Bonzini
2008-06-09 20:29     ` [RFC/PATCH] Add git-squash tool and tests Stephan Beyer
2008-06-09 20:34       ` Johannes Schindelin
2008-06-09 20:53         ` Paolo Bonzini
2008-06-09 21:34           ` Johannes Schindelin
2008-06-09 23:42             ` Stephan Beyer
2008-06-10  0:26               ` Johannes Schindelin
2008-06-09 23:46         ` Stephan Beyer
2008-06-09 19:34   ` squashing patches Junio C Hamano
2008-06-09 20:43     ` Stephan Beyer
2008-06-09 20:53       ` Jeff King
2008-06-09 23:57         ` Stephan Beyer
2008-06-10  1:00           ` Jeff King
2008-06-09 21:02       ` Junio C Hamano
2008-06-10  0:38         ` Stephan Beyer [this message]
2008-06-09 16:49 ` [RFC] git-sequencer.txt Jakub Narebski
2008-06-10  1:21   ` Stephan Beyer
2008-06-10  4:46     ` Christian Couder
2008-06-10  8:59       ` Stephan Beyer
2008-06-11  4:10         ` Christian Couder
2008-06-11 17:07       ` Daniel Barkalow
2008-06-10  6:17     ` Jakub Narebski
2008-06-12  0:22 ` [RFCv2/FYI] git-sequencer.txt Stephan Beyer
2008-06-12  1:31   ` Paolo Bonzini
2008-06-12 15:29     ` Stephan Beyer
2008-06-12 15:38       ` [RFC/PATCH] git-commit: Change --reuse-message to --reuse-commit Stephan Beyer
2008-06-12 15:56       ` [RFCv2/FYI] git-sequencer.txt Paolo Bonzini
2008-06-12  5:16   ` Junio C Hamano
2008-06-12 17:07     ` Stephan Beyer
2008-06-13  5:04       ` Paolo Bonzini
2008-06-13 12:16         ` Stephan Beyer
2008-06-13 14:42           ` Paolo Bonzini
2008-06-13 19:24       ` Olivier Marin
2008-06-12 14:10   ` Jakub Narebski
2008-06-12 17:20     ` Stephan Beyer

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

  List information: http://vger.kernel.org/majordomo-info.html

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

  git send-email \
    --in-reply-to=20080610003816.GH8079@leksak.fem-net \
    --to=s-beyer@gmx.net \
    --cc=Johannes.Schindelin@gmx.de \
    --cc=barkalow@iabervon.org \
    --cc=chriscool@tuxfamily.org \
    --cc=git@vger.kernel.org \
    --cc=gitster@pobox.com \
    --cc=joerg@alea.gnuu.de \
    /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.
Code repositories for project(s) associated with this public inbox

	https://80x24.org/mirrors/git.git

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 read-only IMAP folder(s) and NNTP newsgroup(s).