Hi Christian, Christian Couder writes: > On Monday 11 April 2011 06:49:05 Ramkumar Ramachandra wrote: > > > > 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. You're right -- no point obscuring things. I can't help thinking that there must be a more elegant representation. I'll think about it for a while, and try to come up with something. > > 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. Hm. I originally wanted this so that each commit in the instruction sheet isn't polluted with the same command-line options, but this doesn't seem to be a good solution. -- Ram -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html