From mboxrd@z Thu Jan 1 00:00:00 1970 From: Yann Dirson Subject: Bulk move and some of its close relatives Date: Tue, 26 Oct 2010 20:13:14 +0200 Message-ID: <20101026181314.GA5695@home.lan> References: <1287868022-24872-1-git-send-email-ydirson@altern.org> <1287868022-24872-2-git-send-email-ydirson@altern.org> <7veibeitip.fsf@alter.siamese.dyndns.org> <20101025201227.GB3347@home.lan> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii To: git@vger.kernel.org X-From: git-owner@vger.kernel.org Tue Oct 26 20:30:42 2010 Return-path: Envelope-to: gcvg-git-2@lo.gmane.org Received: from vger.kernel.org ([209.132.180.67]) by lo.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1PAoIB-0003Zp-IU for gcvg-git-2@lo.gmane.org; Tue, 26 Oct 2010 20:30:39 +0200 Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S933503Ab0JZSa3 (ORCPT ); Tue, 26 Oct 2010 14:30:29 -0400 Received: from smtp5-g21.free.fr ([212.27.42.5]:59765 "EHLO smtp5-g21.free.fr" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1756909Ab0JZSa1 (ORCPT ); Tue, 26 Oct 2010 14:30:27 -0400 Received: from home.lan (unknown [81.57.214.146]) by smtp5-g21.free.fr (Postfix) with ESMTP id 65B63D4811D for ; Tue, 26 Oct 2010 20:30:20 +0200 (CEST) Received: from yann by home.lan with local (Exim 4.72) (envelope-from ) id 1PAo1K-0001nU-5L for git@vger.kernel.org; Tue, 26 Oct 2010 20:13:14 +0200 Content-Disposition: inline In-Reply-To: <20101025201227.GB3347@home.lan> User-Agent: Mutt/1.5.20 (2009-06-14) Sender: git-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: git@vger.kernel.org Archived-At: On Mon, Oct 25, 2010 at 10:12:27PM +0200, Yann Dirson wrote: > It is only later that I realized that the larger picture was about > bulk moves, and directory renames were only a subset of those. I had a couple of thoughts about this dir-rename -> bulk-moves shift today while riding to/from work. So here are some of the fresh air I got... Is a bulk-move finally so special ? There is a close relative to it which may be of interest too: bulk deletion. If we implement detection of bulk deletion, we can build on it to get: * detection of a new type of conflict: addition in a branch of a new file in a dir which is deleted in the other branch (quite similar to the one we were talking about, of a new file in a dir that got moved in other branch) * split a good part of the current bulk-move patch in a standalone patch, which is something I wondered how to do * probably a much better base for directory-split detection Then, since a bulk-move is made of a bulk deletion, and addition somewhere else of those deleted files, it became tempting to contemplate the concept of "bulk addition". At first sight it seems awkward, I confess, especially "bulk addition into a preexisting dir", which is a bit hard to define with precision. OTOH, "bulk addition of a brand new dir" could bring goodies as well: * new conflict type: creation in both branches of a new directory with same name That confict type made me think of another one. Some of you may have noticed in the v7 commit message a suggestion for future developments labelled "support other types of bluk-grouping, like prefixes, and maybe config-specified patterns". Now if we get the capability of specifying how we define a "group of files" with something other than the directory hierarchy (let's say eg. that in t/ every "t[0-9]{4}-" is a prefix), the "bulk-add/bulk-add" conflict generated by 2 tests with same numeric ID would be detected as a conflict. Another grouping example would be by file suffix - source-code reorgs eg. bulk-moving header files into their own dir are not rare either. Does that sound sane ? -- Yann