git/list[1] front-page[2] threads[3] people[4] search[5] about
 

Re: [PATCH 3/4] rebase: test ack

From
Junio C Hamano <gitster@pobox.com>
Date
May 21, 2014, 16:54 UTC
Message-ID
<xmqqioozqdgo.fsf@gitster.dls.corp.google.com>
In-Reply-To
<20140521125246.GA21476@redhat.com>
"Michael S. Tsirkin" <mst@redhat.com> writes:
Show 16 quoted lines
> On Tue, May 20, 2014 at 08:13:27AM -0700, Junio C Hamano wrote:
>> "Michael S. Tsirkin" <mst@redhat.com> writes:
>> 
>> > Just to clarify I can post v2 of 4/4 without reposting 1-3 since they
>> > are queued?
>> 
>> If you need to update anything queued only on 'pu' but not yet in
>> 'next', it is customary to resend the whole for everybody to see
>> (what is already in 'next' should only be built upon incrementally
>> and not updated with replacement patches), while noting which ones
>> are the same as before.  Christian Couder has been doing it nicely
>> in his recent rerolls (if the series were not in 'next', that is).
>> 
>> Thanks.
>
> Actually I don't see anything like it in pu.

The way I usually work is to apply a non-fix (i.e. enhancement) series on a topic branch forked from 'master' (or the last tagged version contained in its tip) and see if it makes sense, and then try-merge the result to 'next' to see if it is free of potential funny interactions with other topics that are already in flight. After that happens, the topic branch is merged to somewhere in 'pu'.

It is possible that I did not have time to go through all the steps above (after all, I had to make another -rc release and there was an unexpected last-minute change of plans in the morning that blew a few hours of work). Or there may have been some merge conflicts that I didn't feel like resolving for various reasons (e.g. if I knew the series would be rerolled anyway, it can wait; if the other topic that interacts with your series has been cooking sufficiently long in 'next' and if it is very close to the final release of this cycle, it may be easier to wait for the other topic to graduate to 'master', which would happen soon after this cycle finishes, and ask you to rebase your series).

I don't remember which ;-)
Previous: Michael S. TsirkinNext: Michael S. Tsirkin
Message 11 of 17 in “ack recoding in commit log”
  1. 0/4 ack recoding in commit logMichael S. Tsirkin, May 18, 2014
  2. 1/4 rebase -i: add ack actionMichael S. Tsirkin, May 18, 2014
  3. 2/4 git-rebase: document ackMichael S. Tsirkin, May 18, 2014
  4. Eric SunshineMay 18, 2014
  5. 3/4 rebase: test ackMichael S. Tsirkin, May 18, 2014
  6. Junio C HamanoMay 19, 2014
  7. Michael S. TsirkinMay 19, 2014
  8. Michael S. TsirkinMay 20, 2014
  9. Junio C HamanoMay 20, 2014
  10. Michael S. TsirkinMay 21, 2014
  11. Junio C HamanoMay 21, 2014
  12. Michael S. TsirkinMay 21, 2014
  13. Junio C HamanoMay 21, 2014
  14. 4/4 git-ack: record an ackMichael S. Tsirkin, May 18, 2014
  15. Fabian RuchJun 3, 2014
  16. Fabian RuchJun 11, 2014
  17. Michael S. TsirkinJun 11, 2014

Read the whole thread, see it on lore, or plain text.

$ cat FOOTERMessages come from the public archive at lore.kernel.org/git, fetched every hour. The front page is chosen and written each morning by an AI editor and can be wrong; the threads themselves are the record. About and API. For agents: an MCP server at https://gitlist.dev/mcp, and any thread, story or person page as Markdown by adding .md to its URL (or sending Accept: text/markdown). Details in /llms.txt.