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

Re: [PATCH v2 0/8] Fix atomicity and avoid fd exhaustion in ref transactions

From
Michael Haggerty <mhagger@alum.mit.edu>
Date
May 11, 2015, 06:52 UTC
Message-ID
<555051C9.7040204@alum.mit.edu>
In-Reply-To
<xmqqr3qng2h4.fsf@gitster.dls.corp.google.com>
On 05/11/2015 06:30 AM, Junio C Hamano wrote:
Show 38 quoted lines
> Michael Haggerty <mhagger@alum.mit.edu> writes:
> 
>> The following other branches, also from my GitHub repo, might be
>> useful:
>>
>> * 'write-refs-sooner-2.3' -- suggested merge of the change to 'maint'.
>>
>> * 'write-refs-sooner-master' -- suggested merge of the change to
>>   'master'.
>>
>> * 'write-refs-sooner-rebased-2.3' and
>>   'write-refs-sooner-rebased-master' -- rebases of 'write-refs-sooner'
>>   onto 'maint' and 'master' respectively, in case anybody is
>>   interested to see how the individual patches would look if
>>   implemented natively on these branches.
> 
> Thanks, that indeed is very helpful and instructive.
> 
> A mechanical merge of sooner-2.2 to maint trivially gave sooner-2.3,
> so I am happy with that one.
> 
> Even though I manually resolved it and the resulting tree pretty
> much matched with your suggested merge, I am hesitant to record the
> change of sooner-2.3 as a single large merge to master.  I am
> tempted to record this as somewhat a wicked merge, e.g.
> 
>  - apply posted patches on maint-2.2, which is your sooner-2.2;
> 
>  - branch sooner-2.3 from maint, merge sooner-2.2;
> 
>  - branch sooner-master from v2.4.0, apply the patches in your
>    sooner-rebased-master on top, and then merge sooner-2.3, possibly
>    with "-s ours"
> 
> And then sooner-master would record both "if built naturally on 2.4"
> progression, which would explain what was done much better than a
> huge merge of sooner-2.3 into 'master', and "what is to be done on
> older codebase".

This is exactly the kind of case that "rebase with history" [1] was meant to address. But given that our tooling doesn't support such complicated histories very well, your plan sounds reasonable.

Michael

[1] http://softwareswirl.blogspot.de/2009/04/truce-in-merge-vs-rebase-war.html

-- 
Michael Haggerty
mhagger@alum.mit.edu
Previous: Junio C HamanoNext: Stefan Beller
Message 13 of 16 in “Fix atomicity and avoid fd exhaustion in ref transactions”
  1. 0/8 Fix atomicity and avoid fd exhaustion in ref transactionsMichael Haggerty, May 10, 2015
  2. 1/8 update-ref: test handling large transactions properlyMichael Haggerty, May 10, 2015
  3. 2/8 t7004: rename ULIMIT test prerequisite to ULIMIT_STACK_SIZEMichael Haggerty, May 10, 2015
  4. Stefan BellerMay 11, 2015
  5. Junio C HamanoMay 12, 2015
  6. 3/8 write_ref_to_lockfile(): new function, extracted from write_ref_sha1()Michael Haggerty, May 10, 2015
  7. 4/8 commit_ref_update(): new function, extracted from write_ref_sha1()Michael Haggerty, May 10, 2015
  8. 5/8 rename_ref(): inline calls to write_ref_sha1() from this functionMichael Haggerty, May 10, 2015
  9. 6/8 ref_transaction_commit(): inline call to write_ref_sha1()Michael Haggerty, May 10, 2015
  10. 7/8 ref_transaction_commit(): remove the local flags variableMichael Haggerty, May 10, 2015
  11. 8/8 ref_transaction_commit(): fix atomicity and avoid fd exhaustionMichael Haggerty, May 10, 2015
  12. Junio C HamanoMay 11, 2015
  13. Michael HaggertyMay 11, 2015
  14. Stefan BellerMay 11, 2015
  15. Christian CouderMay 12, 2015
  16. Stefan BellerMay 11, 2015

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.