On Fri, Mar 20, 2015 at 5:56 AM, Abilio Marques <abili...@gmail.com> wrote:
> Neat ideas already popped. Here I copy/paste some fragments of them: > > fossil diff --tk --partial-commit (Then, an automatic "fossil stash" is >> performed where the original modified files are stored. The files left in >> the working area only contain the selected differences) >> > > I personally would like a selective stash. Perhaps one where you can > selectively push some changes (then fossil could proceed to remove them > from the actual files), or selectively pop/apply some changes (but I > imagine this one could get things confusing, specially if used with apply). > Here is the problem with an interactive partial-commit that I see. But first some history: A couple days ago I was convinced I'd found a bug in the merge conflict code. I hadn't, but was confused by a merge conflict in a file where the exact same line was missing (correctly) from two of the three portions of the merge conflict in the source file. I experimented with some changes to try to make things more clear for future me by having the merge conflict include more history. In my one specific test case, it was helpful, but I quickly realized that: - What if the "missing context" came at the beginning of a merge conflict instead of at the end of the merge conflict? By the point fossil identifies the lines that are part of the merge conflict we've already passed up potentially deleted history and it would be quite complex to backup. Not impossible, but very complex. - What if the missing historical context at the end of the merge conflict was more than one line? How to know how much extra history is needed for this one exact file, where this file could be C source, or README, or XML, or JSON, or C++, or any other form of text file? - What if the missing historical context isn't even needed (which is probably often the case)? In that case adding even an extra line could confuse the issue just as much as the missing extra line was confusing me. Note: In my case the missing line was #endif which would have left the merge non-buildable if I only used the merge conflict info to resolve the conflict. I realized that there is no right answer to those questions. The point of the merge conflict is that there was a conflict and a human had to make a decision and all it could do is provide me what it knew about the state of the merge. It is up to the human to take whatever additional remedial tasks (such as diffing baseline against each copy and whatever other analysis is needed). Okay, sorry for that. There is a point, though. An ability to selectively commit just portions of a file implies an ability to differentiate which pieces are needed where. A human can do this. If the idea above (fossil diff --tk --partial-commit) is to allow individual blocks of changes to be selected, then it is too coarse grained for all situations. If it has checkboxes on every changed line, then it might be adequate. Nope, scratch that, it is possible that two changes could impact the same line in different ways, so even a line by line set of checkboxes would be too coarse grained. How about a word by word set of checkboxes? Character by character? These changes could be anything, source code, documentation, data files, html, css, javascript, C, etc, etc. Whatever solution is implemented needs to accommodate all of them, and others not yet mentioned or imagined. If the diff model proposed accommodates all these potential variations, what has been invented is essentially a text editor. I am sympathetic to the idea that you don't *intend* to jumble up changes in a single set of edits and only realize after the fact that you've accomplished exactly that, and thus you want a way to extract the changes into two separate commits / branches / whatever. I think the git model is only appealing at this point because it allows you to rewrite history. You can commit anything you want to a git repo without trepidation because you can always modify it, rebase it, delete it, whatever you want. This doesn't work with fossil due to the immutable history functionality, which is a feature. The fossil version of this workflow would be something along the lines of: 1. You've opened a repo into work area A. 2. You've gone along happily editing for whatever period of time only to realize "dang, I mixed up these two things, I need to separate them". 3. You make a copy of the entire work area A as work area B (perhaps with a fossil open --keep, I'm not sure as I've not tried this myself). 4. In work area A you remove the parts that should only be in work area B and test/commit. 5. In work area B you remove the parts that should only be in work area A and test/commit. Or alternatively: 3. You stash snapshot your current set of changes. 4. You remove one set of changes and test/commit. 5. You stash pop, remove the other set of changes and test/commit. As I understand it, with git you'd do something like: 3. You stage partial files, using some user interface to specify which portions are staged, and commit. 4. You stage the other set of changes and commit them elsewhere. 5. Only now that you've saved the two different sets of changes do you test / rewrite history / whatever. I personally don't see where the suggested fossil workflows are inferior to what git provides. I'm sure there are possible improvements, but I personally can't see where the git partial file commit functionality buys you anything you can't just as effectively do with a text editor and existing support from fossil, and with far less confusion or complexity. -- Scott Robison
_______________________________________________ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
