Paul Burba wrote on 2012-01-11: > A random thought about your patch: The skip/stop logic kicks in when > performing a cherry pick merge. It might be better if it only applies > when doing sync merges. Reasoning: If a user explicitly states the > revisions she wants to merge, I think we should assume she knows what > she wants.
That could make sense, but your reasoning should apply in general and not just to this patch. It's not the UI or API semantics we currently have for cherry-picks. Currently, we prune already-merged revisions from a cherry-pick revision range just the same as from a sync merge range. Nowhere in the code do we codify the difference between a cherry-pick and a sync merge, beyond where we parse the command-line arguments. From that point on, we simply pass around a list of revision ranges to consider for merging. The sync-merge UI populates the list with one range; the cherry-pick UI populates the list with one or more ranges. I'm open to changing that. > Also, if our detection method isn't foolproof we need a > way for the user to merge a revision we want to skip [...] Agreed in principle, but I intend the detection to be precise. - Julian
