rdamazio added a comment.

  In D7630#115300 <https://phab.mercurial-scm.org/D7630#115300>, @pulkit wrote:
  
  > This results in an empty commit which is not similar to what rebase or 
evolve will generally result in after `D7631` unless `ui.allowemptycommit=True` 
is set. I think good behavior is to obsolete the absorbed changeset in favour 
of either it's parent or one of the revs in which it was absorbed.
  
  It's not *always* empty - if there had been lines that it failed absorb 
(because it couldn't find where to absorb into), those would be left in the 
commit.
  
  In D7630#117270 <https://phab.mercurial-scm.org/D7630#117270>, @marmoute 
wrote:
  
  > In D7630#115320 <https://phab.mercurial-scm.org/D7630#115320>, @pulkit 
wrote:
  >
  >>>> This results in an empty commit which is not similar to what rebase or 
evolve will generally result in after `D7631` unless `ui.allowemptycommit=True` 
is set. I think good behavior is to obsolete the absorbed changeset in favour 
of either it's parent or one of the revs in which it was absorbed.
  >>>
  >>> I made a related comment on the parent patch before I realized that this 
patch adds obsmarker handling. My suggestion there was to mark all the commits 
that got absorbed into as successors, and if there's anything left in the 
absorbed commit, that would be yet another successor. Would that work?
  >>
  >> Yep, that sounds good.
  
  I'm fine with doing this, but is there an efficient way to detect that it 
became empty?
  
  > This means generate split+fold markers. That is going to be fun to deal 
with :-). I dont' really have any much better idea however (the alternative 
seems to use simple prune markers, which is meh).
  
  I'm not following this part - why do you need markers at all?
  (you can argue whether you want them - but I don't see why you *need* them)

REPOSITORY
  rHG Mercurial

CHANGES SINCE LAST ACTION
  https://phab.mercurial-scm.org/D7630/new/

REVISION DETAIL
  https://phab.mercurial-scm.org/D7630

To: rdamazio, #hg-reviewers
Cc: marmoute, pulkit, martinvonz, mercurial-devel
_______________________________________________
Mercurial-devel mailing list
Mercurial-devel@mercurial-scm.org
https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel

Reply via email to