Pavel Cahyna <pavel.cah...@matfyz.cz> writes: >> However, I don't think they should be sutured; mtn should recognize >> them as the _same_ file; they have the same node id in the database. > > Can it? I thought that files added by "pluck" are as if added > independently.
That's apparently how it works now, but I think it should be smarter. > Are you sure they have the same node id in the database? Before 'pluck' is executed, there is only one 'f' file; it is given a new node id when created, and maintains that node id when modified. However, 'pluck' apparently gives it a new node id, twice. I think 'pluck' should simply add the original node id to the current revision. Maybe that model would break other things; it depends on why you are using pluck. There is this comment in the implementation of pluck in cmd_merging.cc: // To perform the merge, we use the real from roster, and the real working // roster, but synthesize a temporary 'to' roster. This ensures that the // 'from', 'working' and 'base' rosters all use the same nid namespace, // while any additions that happened between 'from' and 'to' should be // considered as new nodes, even if the file that was added is in fact in // 'working' already -- so 'to' needs its own namespace. (Among other // things, it is impossible with our merge formalism to have the above // graph with a node that exists in 'to' and 'working', but not 'from'.) This states that the current behavior (adding new nodes for 'f') is deliberate, but I don't think it justifies it. >> On the other hand, 'pluck' is a somewhat dangerous command in the >> first place. Can you give a high level description of why you are >> using it? In particular, using it twice? > > Well, if you cherrypick a selected change from one branch to another and > this change creates new file(s), it is likely that later you will need > other changes/fixes to them so you will pluck again a changeset which > patches those newly created file(s). This is normally handled by branches, and merging the _whole_ branch. You are implying that there are other changes in the source branch that you _don't_ want. So the general solution is to design your branches better, so pluck is not necessary. If you don't have sufficient control over the branching policies, I can see how pluck might be part of a useful workflow. > There are already two tests for the directory variant of the bug: > pluck_directory_bug_1 and pluck_directory_bug_2. The first has a commit > between the plucks so is closer to a realistic situation, while the second > does not have any commits between just like the one I showed here. The current pluck implementation builds three rosters, does a merge, computes a changeset from the 'from' revision to the merged, and applies that changeset to the working tree. I don't understand why it doesn't just apply the 'from to to' changeset to the current working directory, as the description of the command implies. The description goes on to say using a merge allows pluck to "intelligently handles renames, conflicts and so on"; this case demonstrates otherwise :). It would be interesting to test the none-merge approach and see if it solves this current problem and those tests. Interestingly, the existing test "pluck_basics" demonstrates the same conflict, but implies it is the correct/desired behavior. I suspect there isn't a way to make 'pluck' do what everyone wants of it. -- -- Stephe _______________________________________________ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel