LISTSERV 16.5 - QSERV-L Archives

On Wed, May 21, 2014 at 12:08 AM, Kian-Tat Lim <[log in to unmask]> wrote:

Can someone please define for me exactly what "clean history"
means? I see at least four different components that people have
mentioned:

1) commit (on master) == feature or commit == bugfix (i.e. squashing)
2) commit messages are written and formatted correctly
3) avoidance of "messy merges" (define, please?)
4) avoidance of parallel branches other than at the tip (i.e. rebasing)

I think the first two are fine. But in the ideal case, wouldn't
feature == ticket and bug == ticket, so commit (on master) == ticket merge?

For many small tickets, I think we would want to squash commits such that there is only a single commit for the ticket, and in that case I think it might make more sense to rebase them onto master and hence have no merge commit. To tie the commit to the ticket we could add the ticket number to the log message instead.

For larger tickets that touch multiple code components or are done in multiple stages, it makes more sense to have multiple commits for a ticket, and in this case I'd still like to have an explicit merge-to-master commit.

I think the third is quite avoidable but does not *require* the fourth.

I'm not personally pushing for option 4 either - I think there are good arguments to be made for both that and having explicit merge commits for tickets, and I'm ambivalent about which is better. But I'd definitely like to avoid merging master to a ticket branch; when that operation is necessary it's better to rebase.

So I guess maybe I'm saying the problem really starts earlier,
with too much being done on each ticket.

I partially agree: a lot of the messiness does happen earlier, but I think we should let it happen then, and only demand that it be cleaned up (i.e. via rebase -i) before we merge it to master.

Jim