Junio C Hamano <gitster@xxxxxxxxx> writes: > What is missing in the series is an end-user facing documentation, > it seems? Don't take this as a complaint; an RFC is expected to be > incomplete and one of the reasons asking for comment responses is > to fill the gaps. Yes, I'm aware that was missing, but I didn't want to spend too much time on this if the general idea would be discarded anyway. > How is the "most recent modification" defined in a history with > forks and merges? For example, in this topology: > > A---B---B---B---B---B > \ / > C---D > > where each letter denotes the contents in the path we are interested > in (and as usual, time flows from left to right), is it the child of > commit A that made the last modification from A to B? Or was it the > merge commit that compared B and D and decided that the path should > have B? Something else? Does it change the story if the sides of > the merge were swapped, i.e. if the branch that kept B all the way > were not the mainline but the side branch that got merged? > > A---B---B---C---D---B---B > \ / > B-------B > > The same question applies if the path we are interested in is a > tree, not a leaf file. > > I do not seem to see such a case that involves "ours" merge in the > tests, either. Those are good scenarios to think about. I'll try to include them in test cases for the next version. I think it's easier to argue about it then. -- Toon
