Martin Waitz <tali@xxxxxxxxxxxxxx> wrote: > hoi :) > > On Mon, May 29, 2006 at 05:35:43PM -0400, Shawn Pearce wrote: > > Now that diff+apply is probably faster than a 3 way merge in > > read-tree precisely because it doesn't need to run merge-recursive > > I'm starting to look at how we can use apply to do partial > > application of a patch and use RCS' diff3 or just drop a reject > > file out when a hunk doesn't apply cleanly. > > but when applying patches, we have to be careful not to overwrite > any changes in the working tree which have not yet been committed. > With read-tree it should operate entirely in its temporary index without > touching the working tree. Agreed. But that's not always what you want. There's two cases of applying a patch: 1) Apply this patch but only affect my working tree if everything is going to patch clean. If anything goes wrong fail without touching anything. git-apply already does this. 2) I know that not all hunks in this patch will apply cleanly. So do the best you can by applying what you can and leave me the remainder for manual merging. git-merge-recursive does this through RCS' diff3. But I think I want #2 built into git-apply where it can handle add/rename/delete cases without the expense of git-merge-recursive. I also want it to apply what it can and leave me reject files _NOT_ a messy RCS style conflict in the file. Some people just prefer reject files. I know someone has asked about this in the past as Emacs has a good merge tool based on reject files. But in the case of #2 we get a mess in our working directory and in our index as the patch didn't go in cleanly. That's OK. I want the unmerged stages in the index and I want the working directory to contain the conflicts as I want to fix that all up before commit. > > > But then an operation as important as commit has to be bullet-proof > > > and I don't like to do anything complex in there. > > > > I agree. But I'd like to see some sort of functionality to > > automatically handle some common topic branche cases in commit. > > Of course I consider the current commit tool to already be too > > complex (like being able to pull the commit message from any > > random commit). > > And I really feel guilt for trying to add even more. > Is there some other way to add such a feature? Not really. Short of adding a new command which is a variant of git-commit specialized for this type of work. Which may be what I wind up doing to get what I want. > I have been dreaming of such a system for years now, and with GIT > it really feels feasible at last. > Graphics programs could compose an image out of different layers for > ages, now it is time for version control software to do the same :-) Heh. Its not quite as simple as it is in an image editor. But yes, I agree. Darcs can sort of do this I believe. StGIT and pg both attempt to do some basic operations but don't really get everything right. -- Shawn. - : send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html