Help us name a new Mercurial feature

Jun Wu of Facebook is proposing a new hg feature which helps editing a commit stack. Basically, it looks through your recent draft commits (commits which haven’t been pushed to a public repo) your working directory, and automatically updates the right draft commits with the changes in your working directory that best correspond according to hg annotate/blame information. The intent, of course, is to make it easier and automatic to clean up a series of WIP commits.

What should this be called? Current proposals are stuff like hg amend --ancestors or hg histedit --smart. Jun Wu called it hg smartfixup. I don’t really like “smart” myself as I don’t find it very descriptive, and we already use “amend” essentially as a synonym for “fixup”.

We take naming things kind of seriously, as they are our UI. Like the Master said, “If language is not correct, then what is said is not what is meant; if what is said is not what is meant, then what must be done remains undone; if this remains undone, morals and art will deteriorate; if justice goes astray, the people will stand about in helpless confusion. Hence there must be no arbitrariness in what is said. This matters above everything.” ;-)

ahal edited 2 years ago | link

Imagine an immigrant moving to a new country. She doesn’t speak the language and will have a difficult time adjusting at first. To ease the transition, she decides to move to an area that already has a decent population of people who share her culture. However, the culture in the new country is still dominant, so she still has to adopt it to some degree.

In this analogy:

immigrant == a hunk from working directory changes
new country == commit series
area with similar culture == commit hunk gets amended to

Thinking of terminology along this vein leads to stuff like:

hg amend --assimilate
hg amend --intermix
hg amend --mingle
hg amend --blend
etc

paluche 2 years ago | link

If I understand the feature correctly, it sounds like it will distribute the changes you’ve made in your working directory across one or more amend actions performed upon one or more draft commits, mapping changes to draft commits in an intelligent way. hg amend --distributed is the best that I could come up with. Maybe it will inspire something better.

stsp 2 years ago | link

It sounds neat. But I don’t think I fully understand the use case which provided motivation for this.

Is the working tree based on a public commit (already pushed to a published repository)? Which the draft commit series should now be “rebased” on top of?

Where would the local changes in the working tree typically come from? And are these changes conceptually based on the top of the stack of draft commits, or are they based on a public commit? Perhaps that does not matter?

Could you provide an example?

2

JordiGH 2 years ago | link

Is the working tree based on a public commit (already pushed to a published repository)?

No, if the working directory is on a public commit, this command does a no-op.

Which the draft commit series should now be “rebased” on top of?

This command does no rebasing at all, not in the sense of “changing the base”. (Git uses “rebase” to refer to all commit rewriting. This command only rewrites, doesn’t rebase.)

Where would the local changes in the working tree typically come from?

From the working directory. You’ve modified your files but the commits you really want to amend are back in your draft history.

Could you provide an example?

You have P -> X -> Y -> Z and you check out Z. Here P is a public base commit, while X, Y, and Z are drafts based on P. X modified file x, Y modified file y, and Z modified file z. In your working directory you make further modifications to the same lines as modified in files x, y, and z. When you run this new hg command, the changes in your working directory will be distributed to commit X for file x, to commit Y for file y, and to commit Z for file z.
1. 2
  
  trousers 2 years ago | link
  
  Your description makes me think of history (obviously) and absorbing (for some reason).
  Maybe hg absorb or hg soak?
2. 2
  
  stsp edited 2 years ago | link
  
  Does this have to be a new subcommand, or could it be an option for ‘hg commit’?
  
  Since “hg commit –amend” will modifiy commit Z, having a UI tweak which modifies X, Y, and Z might make sense. Also, ‘draft’ is very clearly defined here: https://selenic.com/hg/help/phases
  
  So perhaps something like “hg commit –amend-drafts” or “hg commit –amend –draft” would do?
  1. 2
    
    JordiGH edited 2 years ago | link
    
    It can be either. But generally we don’t like a ton of options for the same command. Ideally, hg help $command should fit in a screenful, and git checkout doing four different things depending on flags is our go-to example of worst case scenario. We already have hg amend as a proposed deprecation path for hg commit --amend (deprecation in hg just means removing it from the docs; all functionality stays forever).
    
    If you had to pick a single verb or short phrase to describe this command, what you would you pick?
    1. 5
      
      seschwar 2 years ago | link
      
      Then how about hg amend-drafts. The fact that the command allows you to amend multiple draft-phase changesets is all in the name.
      
      hg amend-drafts ^ ^ ^ | | | amend | | draft-phase | changesets | multiple
      
      And while not a single word I find it more descriptive then hg smartfixup (Smart? Fix up what?) or something like hg absorb (Absorb? What into where?).
      
      I also like the hg revise suggestion by stsp.
    2. 4
      
      stsp 2 years ago | link
      
      It’s not easy. Some things that come to mind (not sure if they’re any good):
      
      hg revise
      
      hg refine
      
      hg rewrite
      
      hg patchup
      
      hg refit
      
      hg gulp
      
      I would also consider ‘hg absorb’ as suggested by trousers.
    3. 1
      
      stijlist 2 years ago | link
      
      Maybe “decompose”? This doesn’t give the user any hints about what is being decomposed or where the decomposed pieces are going for discoverability, but once you know the command, it’s memorable. I’m thinking of “problem decomposition” and hoping that connotation dominates “biological composition” :)
3. 1
  
  lmm 2 years ago | link
  
  Ok, so it’s about distributing this commit over previous draft commits, or putting this commit into the points in history where it fits.
  
  How about hg retcon? That sounds like the closest analogy to what you want to do - pretend that these changes were always at the appropriate point in draft history where they should have been.

Xorlev 2 years ago | link

How about hg amend --collate? I’m thinking of a Xerox copier taking a 20-page document and printing all of the first page, then second… etc.

apg 2 years ago | link

I don’t know hg at all anymore, or the conventions, but, this seems to be a sort of tidying, or maybe restacking. But when I think of tidying up, I can’t help but think of stackenblocken.

dwc 2 years ago | link

[Comment removed by author]

1

JordiGH 2 years ago | link

Is it obvious? What’s manual or unautomatic about hg amend?

wambotron 2 years ago | link

smartfixup is a terrible name. It really doesn’t say anything about what it does. But this use case is kind of odd, IMO. I understand why someone may want to do it, I’ve just never really felt the need for it myself. Maybe my commit history is too messy :P or maybe I just don’t commit often enough.

I think hg amend --by-lines or maybe hg collapse / hg contract would be good.