(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. 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. While I did put 'refactoring' in the subject line, this is not strictly true for I would like to do. There are currently quite some functional differences between 'git rebase' and 'git rebase -i' (not just the obvious one). While refactoring the code, it would be natural to remove some of these differences, because I would guess that most of them are not intentional. The following are some of the differences I have found so far. 1. Several different error messages. For example, 'cannot rebase: you have unstaged changes' versus 'Working tree is dirty'. 2. Different order of validation of command line and current state. For example, if the working tree is dirty and the upstream is invalid, interactive rebase will report the dirty working tree, while non- interactive rebase will report the invalid upstream. 3. Different set of supported flags. For example, interactive rebase does not support the '--stat' flag (and rebase.stat configuration) and various versions of '--strategy'. The above are just some examples, and it is probably most efficient to decide which behavior to pick in each case while reviewing patches (provided, of course, that you think it is worthwhile to extract the shared functionality). /Martin -- 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