From: Martin Schlemmer <azarah@nosferatu.za.org>
To: Petr Baudis <pasky@ucw.cz>
Cc: GIT Mailing Lists <git@vger.kernel.org>
Subject: Re: fix various issues in gitapply.sh (basically did not handle add/del/cm at all)
Date: Fri, 15 Apr 2005 22:30:11 +0200 [thread overview]
Message-ID: <1113597012.8582.10.camel@nosferatu.lan> (raw)
In-Reply-To: <20050415181526.GA7417@pasky.ji.cz>
[-- Attachment #1: Type: text/plain, Size: 2059 bytes --]
On Fri, 2005-04-15 at 20:15 +0200, Petr Baudis wrote:
> Dear diary, on Fri, Apr 15, 2005 at 11:28:38AM CEST, I got a letter
> where Martin Schlemmer <azarah@nosferatu.za.org> told me that...
> > Hi,
> >
> > The egrep regex should not escape the '{' and '}', and also add a check
> > for ' \t' so that we do not pickup stuff like '+----', etc. Fix typo in
> > assignment. Check if file exists in new tree before adding/removing
> > (might add support for this lowlevel to increase speed?). Fix typo in
> > line removing temp files.
> >
> > Signed-off-by: Martin Schlemmer <azarah@gentoo.org>
>
> Thanks for the merge and typo fixes. I can't imagine how, but it really
> appeared to work for me that time!
>
> I'm confused however what does the exits_in_cache() (what exits? exists?)
> gives us, apart of horribly-looking code. What bug does it fix?
>
My typo it seems - should be exists. Basically (especially for
gittrack.sh) it will add all files changed between the trees to either
the add or remove queue if this is not done. This is because it will
just add (say git track linus; git track pasky) the git*.sh files that
is missing in the linus tree (or gitrm.sh if in reverse) although they
are already present there. So we need to check if the file exists in
the destination tree before we git{add,rm}.sh it - if it do exists, then
its ok to gitrm.sh it, if it does not, it is ok to gitadd.sh it.
The other problem is also that if you keep switching, it will add each
file multiple times to the add/rm queue. This is a bug with
git{add,rm}.sh which do not check the queue if the file is already
there, and it also add a file even if it is already in the cache - so it
probably need the same type of fix. I will send a patch when we get how
we check if a file is already in the cache resolved.
Like I said in the patch, it might be better to add support low-level
side (don't know if we can have ls-tree return true/false on file basis,
else add a new tool?).
Thanks,
--
Martin Schlemmer
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
prev parent reply other threads:[~2005-04-15 20:25 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-04-15 9:28 [patch pasky 1/2] fix various issues in gitapply.sh (basically did not handle add/del/cm at all) Martin Schlemmer
2005-04-15 9:31 ` Martin Schlemmer
2005-04-15 18:15 ` Petr Baudis
2005-04-15 20:30 ` Martin Schlemmer [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1113597012.8582.10.camel@nosferatu.lan \
--to=azarah@nosferatu.za.org \
--cc=git@vger.kernel.org \
--cc=pasky@ucw.cz \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox