danmcd: Hi Dan, seems this commit had issues that the code is into the comments, 3b2267a71a62a26

can I help to do the merge from illumos-gate upstream?

Yeah....

I was supposed to include the merge-generated commit, and instead I included the file that was in conflict.

ALSO, there's a breakage in LX because of the changes in fifofs.

I'm locally building the fix right now, and weighing whether or not to force-push a cleaner

merge.

The catch is force-push may break multiple things. I need to speak with folks who are in US/Pacific about it.

"merge-generated commit text..."

Okay, the small LX fix worked. So I haven't pushed the small LX fix upstream because, as mentioned, how destructive a force-push to illumos-joyent will be.

(The two choices are push the LX fix, maybe with some extra commit comments, or force-pushing, which cleans up the merge commit, but with an unknown-to-me cost.)

Oh @tozhu you missed my response.

So there's a source file because I mistyped the filename in "git commit -F <filename>"

Also, unrelated, LX needs an update to cope with jinni illumos#16538

So the merge is okay modulo the very confusing whole-source-file commit message (the source file that was in conflict during the merge).

My first instinct, a force-push with things cleaned, is not necessarily the right thing to do.

I'm waiting for someone in Pacific Time to contemplate what a force-push might break.

danmcd: okay, got it, thank you very much

If you build locally, the patch to LX's lx_splice.c is quite small.

/* Update vnode update access time */

- fnp->fn_atime = fnp->fn_dest->fn_atime = gethrestime_sec();

+ gethrestime(&fnp->fn_dest->fn_atime);

+ fnp->fn_atime = fnp->fn_dest->fn_atime;

okay, I’ll try it later today

@tozhu I hope to have a full fix upstream before 12noon US/Eastern.

(one or the other)

danmcd: Thank you very much, I’ll wait for the fix, than you :-)

@tozhu might be later than 12noonET.

danmcd: no problem, if I can help, please feel free to let me know, thank you very much

I mostly need to consult with bahamat about pros/cons of force-push to correct illumos-joyent or not.

And tozhu has left again...

one of the things you can do prior to a force-push to confirm that it contains what you expect (confirm that a merge+fixup commits is the same as a rebase) is to compare the git tree-hash - a hash of the tree contents (file & directory contents), ignoring the history. "git rev-parse HEAD:" shows the tree hash of the root of the tree at HEAD; you can also do a git rev-parse HEAD:usr/src/uts if you want to look at the tree-hash of subtrees.

I was less worried about that (already did that via brute-force diff(1) of no-gitfiles usr/src) than I was about lots of auto-down-stream-pulls that would trainwreck over a force-push upstream.

(e.g. our own Jenkins)

We also have some bots that interface with github and our jira, and a source code search/browser, which would all need to manually be corrected. Then there's the matter of getting everyone in the wild to roll back history correctly.