Some suggestions

[ebullient]

First, I'm really glad you wrote this, it was very helpful!

I didn't follow what you were doing with the history: I ended up backing those changes out.

What I did was a) echo every lscm command the script uses, and b) Pause (wait for the enter key) when a non-zero return code is encountered: given I could see what commands were issued, I could then retry, or use other command line tools (or even the IDE) to figure out what the pending changes were for the workspace, and to fix them (e.g. by resolving conflicts or tossing auto-created merge changesets). The git commit then proceeds and we go back to looping through the changesets (until the next non-zero return code is found).

For some reason, I was running into trouble loading repository content, likely because I was migrating my repository from the very first changeset. I had to reload the workspace after the first changeset was accepted to have the content pulled down locally. When I read the help, it certainly implies that the accept should do that loading for you: and it did, but only if I reloaded the workspace after the first accepted changeset.

[WtfJoke]

Thanks for the feedback, I'm glad that the program was helpful for you!

About the history. The thing is the compare command works insufficient in terms of the correct order of changesets. When relying only on this order of the compare, you get unnecessary conflicts. In some cases, if you have bad luck, you get some really hard (for me sometimes even unsolvable) merge-conflicts. You can read more about it in #7 or in the wiki. This means I wont merge this part of your pull request.

About a) I was planning to actually implement that feature 😃 So thanks for implementing it 👍
About b) I really like this idea, I implemented a similar feature yesterday. Its part of a (now semi-)automatic process to accept two changesets together to avoid unnecessary manual merges. However the one I have implemented, is not as beautiful implemented as you did. Please check it out and let me know if you would change there something or if its okay like that.
About c) I didn't experienced this behaviour in my tests. But your explanation seems reasonable (still strange that rtc works that way, though). Is there some way to avoid this reload? Do you think it makes sense to configure this behaviour, cause I dislike that its necessary to load the whole workspace twice when it might be not needed.

Can you create a new pull request or adjust this one so that a) is mergeable into my current develop branch (maybe creating a new branch in top of mine?). And for b and c please see my comments (depending on your thoughts, it would be cool if you could share the code in separate pull requests).

Thanks for sharing your additions & thoughts. 😄 👍 ❗

[ebullient]

I didn't think you'd pull in my rollback of the history changes: I'd just already coded mine without requiring the history first, and then when I tried to pull in your changes, the history files were then required, and so I couldn't do anything. (My changes allowed me to work around the issues with merges, as I could just discard the merge changesets and keep going).

When I pulled your stuff in, I had worked around your retry so that it would still do the retry, and then would pause if the retry didn't work either.. (again, to allow the human to make sense of what happened and fix it so the rest can carry on happily).

(In my mind, we arrived at two ways of solving the problem: you went for getting the right history, and I went for just allowing minor course corrections in the case the sorting got it wrong).

(c) is definitely weird. I would be happy to stick that in a configuration var. Someone would have to be starting with an empty workspace (where the first migrated changes really are the first changes) to be able to confirm the weirdness.

I can try to create a new pull request. I'd half done it on top of your changes, but I couldn't find a good way to bypass the history requirement (since I wasn't interested in trying to make a history since what was already working worked almost all of the time: only two pauses required to sort something out, and then it carried merrily on.. ).

RE: the history -- can't you chase this using previous eras? Or is the problem that the current era is artificially limited?

[WtfJoke]

I thought about your inputs a while.
You're right about that we have two ways of solving the same problem. I think I am going for a two way solution. A config property called like merge-strategy or external history. If they going your way (which is probably the default), it will display a warning that they might experience more conflicts (or that the history might not be 100% accurate), so the might consider fetching the history. So they can use the program without needing to fetch the history first (cause they can live without it). I think especially in smaller streams its not needed to provide a history.

For the reloading problem (c), I found a neat solution. After first accept we can check for the return code of the diff comand to check if something has been changed (since something needs to change 💭), and if thats not the case we execute the reloading logic. So no need to have it configurable 😃.

Here is the necessary code-sample

def is_reloading_necessary():
    return shell.execute("git diff --exit-code") is 0

And about the history. Even with the externally provided history I experienced some really hard to solve merge-conflicts in the component/stream I migrated. But im not quite sure what you mean with your sentence: "RE: the history -- can't you chase this using previous eras? Or is the problem that the current era is artificially limited?"

Edit: I tried to merge most of your changes manually.

[WtfJoke]

@ebullient Just wanted to let you know that I implemented some changes
See commit 127d9ad (history) and ab0499a (log shell commands)
I think you can give it a try. Like that it should be possible for you to use the out of the box solution again. :)

[ebullient]

Great! I haven't had time to look again, so thanks for getting all this put together. I'll run it again against what I was migrating to see what comes out.
=)