[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Gnu-arch-users] Whitespace cleanups

From: Milan Cvetkovic
Subject: Re: [Gnu-arch-users] Whitespace cleanups
Date: Fri, 24 Sep 2004 09:46:25 -0400
User-agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.3.1) Gecko/20030425

Tom Lord wrote:
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.


Just to clarify, if I wanted to see what it is that wants to be commited during the "precommit hook", I should use "tla delta `tla logs -f | tail -1`" and then investigate what the content of "the proposed changes" is.

Or I am missing something.

Thanks, Milan.

    > 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) 
    > 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 
    > List-Unsubscribe: <>,
    >        <mailto:address@hidden>
    > List-Archive: <>
    > List-Post: <mailto:address@hidden>
    > List-Help: <mailto:address@hidden>
    > List-Subscribe: <>,
    >        <mailto:address@hidden>
    > Sender: address@hidden
> X-Spam-Checker-Version: SpamAssassin 2.64-42mail (2004-01-11) on >
    > 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 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
> > GNU arch home page:
> >

Gnu-arch-users mailing list

GNU arch home page:

reply via email to

[Prev in Thread] Current Thread [Next in Thread]