Re: [Gnu-arch-users] Whitespace cleanups

[Tom Lord]

No.  Don't try to modify or study the intermediate directory during a
commit, at least not at this stage.  You'll most likely create a
disaster for yourself.   Seek a different solution to the problem you
want to solve.

Thanks,
-t





    > X-42-Pre-Check: Attempted
    > Date: Thu, 23 Sep 2004 17:29:24 -0400
    > From: Milan Cvetkovic <address@hidden>
    > User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.3.1) 
Gecko/20030425
    > X-Accept-Language: en
    > CC: address@hidden
    > Content-Type: text/plain; charset=us-ascii; format=flowed
    > X-BeenThere: address@hidden
    > X-Mailman-Version: 2.1.5
    > Precedence: list
    > List-Id: a discussion list for all things arch-ish 
<gnu-arch-users.gnu.org>
    > List-Unsubscribe: <http://lists.gnu.org/mailman/listinfo/gnu-arch-users>,
    >   <mailto:address@hidden>
    > List-Archive: <http://lists.gnu.org/pipermail/gnu-arch-users>
    > List-Post: <mailto:address@hidden>
    > List-Help: <mailto:address@hidden>
    > List-Subscribe: <http://lists.gnu.org/mailman/listinfo/gnu-arch-users>,
    >   <mailto:address@hidden>
    > Sender: address@hidden
    > X-Spam-Checker-Version: SpamAssassin 2.64-42mail (2004-01-11) on 
    >   mail.42inc.com
    > X-Spam-DCC: neonova: mail 1127; Body=1 Fuz1=1 Fuz2=1
    > X-Spam-Status: No, hits=-4.8 required=4.5 tests=BAYES_00,RCVD_IN_RFCI 
    >   autolearn=no version=2.64-42mail
    > X-42email-MailScanner-Information: Please contact 
http://www.42inc.com/support.html for more information.
    > X-42email-MailScanner: Found to be clean
    > X-UIDL: cb6fd4ee67a5e8f2b8d1d1ec7ceaf74c
    > 
    > 
    > Tom Lord wrote:
    > > 
    > >         3) I would like the idea of adding "--ignore-whitespace"
    > >            support to be explored before any such large change.
    > >            Perhaps even better would be a patch option that not only
    > >            ignores whitespace, but also rewrites the whitespace of
    > >            added and changed lines to conform to a convention.  Or
    > >            perhaps not.  Regardless, ti seems to deserve some thought
    > >            to me.
    > 
    > I was thinking about introducing hook which would do something similar:
    > rewrite the whitespace before commiting the file, but only in modified 
    > lines.
    > 
    > In theory, it would be possible to make a single patch on all branches, 
    > where all whitespaces are "cleaned up", and then introduce the precommit 
    > hook on all branches.
    > 
    > And only after that, you would not have conflicts on merges, only 
    > because of whitespace changes.
    > 
    > After I spent some time on this, I figured it was too much work for the 
    > payoff.
    > 
    > One of the problems that I came across is the location of patches while 
    > "tla commit" is being executed. Obviously, "tla commit" has to calculate 
    >   the patchset, and it actually stores it in one of the "junk" 
    > directories in the $ARCH_TREE_ROOT. However, I could not figure out what 
    > was the name of this directory. Or, more precisely, it kept changing 
    > every time precommit hook is invoked. It did have a consistent form:
    > 
    > ,,commit.C--B--V--patch-NN--archivename--archiveversion.*
    > or
    > ,,commit.$ARCH_REVISION--$ARCH_ARCHIVE.*
    > 
    > So the questions are:
    > - Is it safe enogh to asume that this directory always has the above
    >    form, and the youngest one is the current patchset:
    >    (ls -rt ,,commit.$ARCH_REVISION--patch-*--$ARCH_ARCHIVE.* | tail -1)
    > - If this patchset is modified,
    >      # would it be applied to the commited patch?
    >      # would it be apllied to the current tree?
    > 
    > Thanks, Milan.
    > 
    > 
    > 
    > _______________________________________________
    > Gnu-arch-users mailing list
    > address@hidden
    > http://lists.gnu.org/mailman/listinfo/gnu-arch-users
    > 
    > GNU arch home page:
    > http://savannah.gnu.org/projects/gnu-arch/
    > 
    >