git/list[1] front-page[2] threads[3] people[4] search[5] about
 

Re: [RFC PATCH 00/11] Sequencer Foundations

From
Christian Couder <chriscool@tuxfamily.org>
Date
Apr 11, 2011, 06:20 UTC
Message-ID
<201104110820.20342.chriscool@tuxfamily.org>
In-Reply-To
<20110411044900.GA20939@kytes>
Hi Ram,
On Monday 11 April 2011 06:49:05 Ramkumar Ramachandra wrote:
Show 16 quoted lines
> Hi Christian,
> 
> Christian Couder writes:
> > On Sunday 10 April 2011 17:11:46 Ramkumar Ramachandra wrote:
> > > Hi,
> > > 
> > > I've started working on building a sequencer for Git.
> > 
> > So you are starting the GSoC early! Great!
> > When (or before) it really starts, just make sure you put your work on a
> > public Git repository and you send status updates regularly (weekly if
> > possible).
> 
> Ofcourse.  I've already discussed many of these issues last year [1].
> The work corresponding to this particular series can be found in the
> 'sequencer' branch on my GitHub fork [2].  
Great! Thanks!
> Since the results haven't
> been announced, and the coding period hasn't begun, this work should
> be treated like "normal work" -- I just wrote it this weekend.
Ok.
Show 27 quoted lines
> > > 3. From the format of the TODO and DONE files, one more thing should
> > > be clear- I'm trying to stick to a slight variation of the 'rebase -i'
> > > format.  This part will go into the sequencer.  Then I'll use a
> > > cherry-pick specific file to keep the command-line options.  Yes, I'm
> > > trying to work on Daniel's idea [3] from the very start.  Is this a
> > > good idea?
> > 
> > I think that the TODO and DONE file format will need at one point to
> > include options and it is simpler if this change is done early. Using a
> > cherry-pick specific file to keep the options is not very generic for a
> > sequencer that could be used for many things.
> > 
> > For example, as we have rebase --interactive, we will probably want to
> > have cherry-pick --interactive, and when editing the TODO file we might
> > want to use different cherry-pick options when picking different
> > commits.
> 
> Point noted -- I shouldn't narrow down the various things I can do
> with a single commit early on and lock us into a more restrictive
> design.  However, I'm not in favor of making it too generic; I
> certainly wouldn't like to edit an instruction sheet that looks like
> this:
> 
> cherry-pick -m 1 -s -r 83a4fe9
> revert -n 3a6fe42
> cherry-pick -x --ff dacfe41
> cherry-pick -s recursive -Xpatience b31d4e2
I wouldn't like either, but I would like it even less if it was like this:

pick 83a4fe9 # -m 1 -s -r revert 3a6fe42 # -n pick dacfe41 # -x --ff pick b31d4e2 # -s recursive -Xpatience

I mean that of course people should not use too many options for no good reason, but if they do need to use some options, it's better if they are shown like in a shell, as they will be more familiar with them this way.

There is no point of making options look different to prevent people from abusing them.

Show 15 quoted lines
> It'll become impossible to tell which options are disallowed over what
> else, and it'll become a nightmare to debug when something goes wrong.
> My idea is that we add commit-specific options in an optional
> backward-compatible manner later:
> 
> pick 83a4fe9
> revert 3a6fe42 # -n
> pick dacfe41 # -s
> pick b31d4e2
> 
> That way, there'll be two sets of options:
> 
> 1. One "global" set of command-line switches that applies
> to all the commits, which will be written to a command-specific
> location.  The sequencer itself knows nothing about this.

I don't see the point of this global set. And if the sequencer knows nothing about it, the user may not know about it too and so may not understand how things work.

Show 20 quoted lines
> 2. Optional commit-specific stuff that's passed in the
> form of a (modified) commit_list to the sequencer API to write to the
> todo/ done files.
> 
> Do you like this idea?
> 
> > This would also make the different cherry-pick options available when
> > using rebase --interactive once it uses the sequencer.
> > 
> > > [1]:
> > > http://thread.gmane.org/gmane.comp.version-control.git/170758/focus=170
> > > 908 [2]: http://thread.gmane.org/gmane.comp.version-control.git/162183
> > > [3]:
> > > http://thread.gmane.org/gmane.comp.version-control.git/170758/focus=17
> > > 0834
> > 
> > [3] is missing here.
> 
> Your email client is perhaps wrapping too aggressively? It's fine in
> my original email [3].

Yeah, sorry about that! Christian.

Previous: Ramkumar RamachandraNext: Ramkumar Ramachandra
Message 32 of 36 in “Sequencer Foundations”
  1. 00/11 Sequencer FoundationsRamkumar Ramachandra, Apr 10, 2011
  2. 01/11 revert: Avoid calling die; return error insteadRamkumar Ramachandra, Apr 10, 2011
  3. Jonathan NiederApr 10, 2011
  4. Ramkumar RamachandraMay 8, 2011
  5. Junio C HamanoApr 11, 2011
  6. 02/11 revert: Lose global variables "commit" and "me"Ramkumar Ramachandra, Apr 10, 2011
  7. Christian CouderApr 11, 2011
  8. Ramkumar RamachandraApr 11, 2011
  9. 03/11 revert: Introduce a struct to parse command-line options intoRamkumar Ramachandra, Apr 10, 2011
  10. Jonathan NiederApr 10, 2011
  11. Ramkumar RamachandraMay 8, 2011
  12. Junio C HamanoApr 11, 2011
  13. Ramkumar RamachandraMay 8, 2011
  14. 04/11 revert: Separate cmdline argument handling from the functional codeRamkumar Ramachandra, Apr 10, 2011
  15. 05/11 revert: Catch incompatible command-line options earlyRamkumar Ramachandra, Apr 10, 2011
  16. Junio C HamanoApr 11, 2011
  17. Ramkumar RamachandraMay 8, 2011
  18. 06/11 revert: Implement parsing --continue, --abort and --skipRamkumar Ramachandra, Apr 10, 2011
  19. 07/11 revert: Handle conflict resolutions more elegantlyRamkumar Ramachandra, Apr 10, 2011
  20. 08/11 usage: Introduce error_errno correspoding to die_errnoRamkumar Ramachandra, Apr 10, 2011
  21. 09/11 revert: Write head, todo, done filesRamkumar Ramachandra, Apr 10, 2011
  22. 10/11 revert: Give noop a default value while argument parsingRamkumar Ramachandra, Apr 10, 2011
  23. 11/11 revert: Implement --abort processingRamkumar Ramachandra, Apr 10, 2011
  24. Daniel BarkalowApr 10, 2011
  25. Ramkumar RamachandraApr 11, 2011
  26. Jonathan NiederApr 10, 2011
  27. Daniel BarkalowApr 11, 2011
  28. Jonathan NiederApr 11, 2011
  29. Ramkumar RamachandraApr 11, 2011
  30. Christian CouderApr 11, 2011
  31. Ramkumar RamachandraApr 11, 2011
  32. Christian CouderApr 11, 2011
  33. Ramkumar RamachandraApr 11, 2011
  34. Daniel BarkalowApr 11, 2011
  35. Jonathan NiederApr 11, 2011
  36. Daniel BarkalowApr 11, 2011

Read the whole thread, see it on lore, or plain text.

$ cat FOOTERMessages come from the public archive at lore.kernel.org/git, fetched every hour. The front page is chosen and written each morning by an AI editor and can be wrong; the threads themselves are the record. About and API. For agents: an MCP server at https://gitlist.dev/mcp, and any thread, story or person page as Markdown by adding .md to its URL (or sending Accept: text/markdown). Details in /llms.txt.