Ok, so if I have this straight… the simple answer is “no”. Fossil is, by design, not going to let me modify a checkin once it has gone into the DB, fair enough..
I’m not aware of this reparent fork…are you saying that is a fork of fossil itself that lets us cheat a little? I’m not really rejecting anything…but generally…its not going to be worth it to me to move the checkin to a branch which will be closed and left hanging around forever with the unmerged change in it every time this mistake happens. At that points its just better to leave the two file changes in one checkin…even though I am associating the checkin with a ticket and one of the file changes has nothing to do with that ticket, etc. Kind of annoying, but once its in…its in…and on the surface, unless I’m misunderstanding, it might be possible to use this fork of fossil to reverse out the checkin so its not left dangling in an orphaned branch…though…generally….I would probably rather stick to vanilla fossil. And no I have no desire to tamper with artifacts. I was just asking if fossil has any way to correct this kind of mistake. I think the simple asnwer is “no, be more careful” On May 22, 2016, at 6:43 PM, Andy Goth <andrew.m.g...@gmail.com> wrote: > On 5/22/2016 3:52 PM, Steve Schow wrote: >> Let’s say I have added file A…then never commit it… >> >> a couple days later I add file B and hit commit >> >> Suddenly I realize that two files were committed. I want them both >> commited, but I want them committed as seperate checkins. >> >> I can move the one checkin to a branch, but how can I *easily” split >> the checkin into two checkins, file A on one checkin and file B on the >> other checkin? > > In Fossil, committing creates a check-in which captures the entire state > of the source tree at a moment in time. This check-in is defined by a > manifest artifact which in turn references file artifacts. > > You seem to be asking how to edit that manifest artifact to reference an > older version of one of the files, the one you didn't mean to check in > at the same time as the other. > > Fossil is specifically designed to prevent this sort of history > tampering. Instead, it provides the ability to push the unwanted > manifest out of the way onto a branch (which can be hidden) then redo > the commits as intended. > > But all the above is me describing in greater detail an approach you > already rejected. > > So if you insist on something else, you might try experimenting with the > "reparent" branch which provides a reparent command used to revise the > predecessor version of a commit. > > In the following, BADVER is the check-in version where you mistakenly > committed changes to both A and B. BASELINE is its predecessor. > > 1. Build and install the "reparent" version of Fossil. > > 2. Run "f up BASELINE" to go back before changes to A and B. > > 3. Run "f revert -r BADVER A" to put in the change to A. > > 4. Run "f commit -allow-fork -date-override DATE" where DATE is the > version you intended to do the commit to A. This will create a fork. > > 5. Run "f reparent BADVER current" to make the current version be the > predecessor of BADVER. > > I don't like this approach. It isn't how I'd go about things. The > reparent command is for fixing a damaged repository or for incorporating > old history that wasn't available when the project was started. But > hey, it's an option. Plus it would be nice for reparent to get some > more testing. > > When I try the above procedure, I wind up with two versions showing as > leaf, just like when the fork occurred. This is something that needs to > be fixed in the reparent command. Previously I found that this stays > broken until a new branch is created. > > -- > Andy Goth | <andrew.m.goth/at/gmail/dot/com> > > _______________________________________________ > fossil-users mailing list > fossil-users@lists.fossil-scm.org > http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users _______________________________________________ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
