On Tue, Apr 12, 2016 at 09:07:30AM -0700, Junio C Hamano wrote: > Matthieu Moy <matthieu....@grenoble-inp.fr> writes: > > > "Michael S. Tsirkin" <m...@redhat.com> writes: > > > >> Interesting. An empty commit would be rather easy to create on any > >> branch, not just the current one, using git-commit-tree. > > > > This "modify a branch without checking-it out" makes me think of "git > > notes". It may make sense to teach "git rebase -i" to look for notes in > > rebased commits and append them to the commit message when applying. > > Just an idea, not necessarily a good one ;-). > > Yeah that may actually fly well, as a note is designed to attach to > an exact commit, not to a branch, so that feels more natural.
We'd have to invent a way to show that in the rebase -i output though. > As to the "use commit-tree", well, personally I am not interested in > a solution that can work well in my workflow ONLY if I further script > it. That's half-solution and unless that half is done very well, > I'd rather do a full solution better. Absolutely. But that's not what I meant. I will add a flag to git-ack to select a branch and use commit-tree to put the ack commit there *internally*. Would this do everything you need? How do you select a branch? Automatically or do you remember the mapping from topic to branch name? > Note: this is a continuation of "I personally would not use > it, even though other people might" discussion. > > I was also wondering if I should just script around filter-branch, > if all I am futzing with is the data in the trailer block, doing the > munging of the trailer block with interpret-trailers, naturally. > > In any case, a recent occasion that I had to do something related to > this topic may illustrate the boundary of requirements: > > Two developers, Michael and David, are involved. David sends a > 24-patch series, some of which were written by Michael and > others by David. The in-body "From:" lines are set right and > the resulting patches record authorship correctly. > > Michael reminds David that patches authored by Michael still > need to be signed-off by David. David sends a single message > "those by Michael in this series are signed off by me". > > Michael also says that he reviewed all patches authored by > David, i.e. "Add Acked-by Michael to all patches in this series > authored by David". > > Now this is an extreme case where a simple "OK I received an > e-mailed Ack, so I can rely on the subject line matching to mark it > to be squashed" approach will never work (i.e. if we were automating > it I'd expect that the script in DSL to the automation machinery to > take at last as many (conceptual) bits as the above problem > description). So here's how I solve the second part for now - that is very common: I expect Michael to write something like For series: Acked-by: Michael S. Tsirkin <m...@redhat.com> then I run git ack -s to put the signature in a file .git/ACKS. (git ack -s is just writing acks into .git/ACKS so if the email format is wrong I just edit it manually). And then I tag the series in email and run git ack -r to add the ack tag. For first part, that is less common but also happens (for example I get "for patches 1,7 and 23 in series: ACK") - I would do git ack -s to store David's signoff, then tag just messages by David (probably just using limit ~b From:\ David in mutt) and pipe them to git ack -r. Does this sound user-friendly enough? What would you do differently? -- MST -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
