Marc Weber writes: > > > Probably this is so much work that nobody will ever implement it. > > That was the consensus regarding a "smart" replace operation. > > See also "structured editing".
I disagree. I think within five years you'll see this happening. > I asked at #git now. Git can't find out on which commits a commit > depends. So if you get conflicts you can start searching those commits. git currently can't do that, but it wouldn't be hard to implement. You start with "git log --numstat <commit>" which will give you a list of changed files. For each file pipe "git log -p ..<commit> <file>" into a Python or Perl script that keeps a database of touched lines. This would presumbly be rather slower (multipass, for one thing) than Darcs which keeps the necessary information in the patches. > So if you have to move many patches consider using darcs. > If you expect to have a very linear history only git may be the better > choice. I would say the opposite, except that maybe we have different definitions of "linear". I would say that a history which always reconverges rapidly to the mainline is linear, even though there may be a lot of concurrent development going on at any given time. Darcs is good at this. A history with multiple long-lived branches is nonlinear, even if each branch is locally perfectly linear. git is good at that. _______________________________________________ darcs-users mailing list [email protected] http://lists.osuosl.org/mailman/listinfo/darcs-users
