> "Bradley M. Kuhn" <bkuhn@xxxxxxxxxxxxxxxxx> writes: > > I wasn't sure what I should be doing with the patch set once it was already > > in 'seen'. Junio C Hamano wrote: > Being 'seen' is an indication that it has been seen and does not mean > anything more than that. Documentation/SubmittingPatches says: > >>> `git pull --rebase` will automatically skip already-applied patches, and > >>> will let you know. This works only if you rebase on top of the branch in > >>> which your patch has been merged (i.e. it will not tell you if your patch > >>> is merged in `seen` if you rebase on top of master). > This is talking about a fairly mature topic that has already been in 'next' > and was on the course to graduate to 'master'. The topic would eventually > be in 'master', and at that point "pull --rebase" would notice that the > patches are no longer needed (or were merged in a different form). But > that does not apply to topics that are not in 'master' yet. Junio, thanks for your detailed reply. I have a couple ideas of some minor changes to SubmittingPatches that would have made what you said clearer to me when I was doing my first patch. I'll think about it some and send something along, but probably won't get to it until next month (but it doesn't seem urgent). Taylor wrote: >>> Since 'seen' is a convenience branch that contains the current state >>> of the in-flight topics, it is subject to be changed and rebuilt >>> multiple times (c.f., link:howto/maintain-git) so the presence of your >>> patches in 'seen' (but not 'next' or 'master') should not affect your >>> workflow. I'll hold on to this text as a possibility, to start from when I dig into the proposals above. Thanks! -- Bradley M. Kuhn - he/him Policy Fellow & Hacker-in-Residence at Software Freedom Conservancy ======================================================================== Become a Conservancy Supporter today: https://sfconservancy.org/supporter
