<div dir="ltr">While I like the general workflow very much, I am totally against committing automatically to the snapshot branch. If you do so, you are actually committing (1) without any message that explains something and (2) something that you do not know yet whether it works or not. Moreover, merging is going to be ... interesting.<div>
<br></div><div>So, I would update the proposal to:</div><div> - have the equivalent of a reflog, that is a list of snapshots that are *local* to the current user (i.e. not part of any public repository) so that *the developer who remembers what he did in the last days* has the ability to go back to any state he has seen before in its current repository. This is updated automatically by autoproj each time 'autoproj update' is executed and can be re-bootstrapped by pointing to the source repository while bootstrapping (e.g. autoproj bootstrap --snapshot /path/to/original:snapshot_id)</div>
<div> - add an "autoproj commit" command that commits the current state with a commit message *as a tag* in the repository. This way, there is no branch and therefore no problem with merging. Pushing all snapshots means doing git push --tags. Of course, autoproj commit would have the ability to store any state from the reflog.</div>
<div> - add an "autoproj snapshots" command that presents these tags in historical order with commit messages (kind of a git log of history tags)</div><div> - bootstrapping the right snapshot would be as easy as adding a tag=<tagname> to the bootstrap line. The script could be easily generated by using the "current" bootstrap.sh as a template.</div>
<div><br></div><div>Sylvain<br><div class="gmail_extra"><br></div><div class="gmail_extra"><br></div></div></div>