On Sat, Mar 12, 2011 at 10:34:08PM -0800, Junio C Hamano wrote: > I see you rebased your jk/doc-credits topic at GitHub but haven't queued > this one yet, so I won't be pulling, but give me a holler when the branch > is ready to be pulled into 'master'. I'll then push the result out after > running final "make doc" check on a few platforms I have and eyeballing > the output. It's pushed now. I rebase my topics aggressively on top of master (which you saw), but I don't always push out regularly. Since my main output is patches to the list, in general I assume nobody is actually looking at my topics directly. :) Let me know if some other strategy would be better[1]. I've done a perfunctory check over the changes, but there are a lot of them, so another set of eyeballs on the output is appreciated. -Peff [1] I have mixed feelings about the aggressive rebasing. Our 'master' is pretty stable, so I don't feel the need to build off the last tagged release. But rebasing a lot does make it hard for others to follow the topic, and it makes it hard to organize my work with you queue in pu, and then merge to 'next' and 'master'. However, I haven't found a satisfactory solution to tracking patches as they move through the workflow of local development, sent to list, and applied upstream. Git-cherry sort of does this, but patch-ids miss a lot of cases: patches tweaked in transit, patches applied on a different commit, or even patches taken partially or split up. So I rebase frequently, and as patches get picked up in master, the branches dwindle to empty. Suggestions welcome if anybody else has figured out something clever. -Peff -- 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