Re: [BUG] git rev-parse :/ "regex" syntax not really regex?
On Sun, Apr 17, 2016 at 04:10:28PM +0200, Andreas Schwab wrote:
> Andreas Mohr <a...@lisas.de> writes:
>
> > Unless I happened to misunderstand git's regex flavour, or something else...
> > (hmm, perhaps it's a try-match-single-line vs. multi-line content issue,
> > which perhaps does not work by specifying the trailing $)
>
> This is exactly the difference. git log --grep matches individual lines
> (like grep), whereas :/ matches against the whole commit message
> including embedded (and trailing) newlines, and $ doesn't match an
> embedded newline. Thus to address the second commit in your example you
> have to use $':/^My commit\n' (using bash's ANSI-C quoting feature).
At first I thought "no way, I already did try trailing \n",
but then I realized that
it's exactly use of that ANSI-C quoting feature
which makes that \n newline be (non-)interpreted correctly here,
and it truly works.
Thank you for a fast and well-inform{ed|ing} response!
Now there's only one question remaining:
do we simply take this as a documentation-supplied-by-mailing-list item ;-),
or should certain parts of the parse-rev :/ documentation
be improved in a certain manner?
No, there's another one:
this syntax seems to be (as indicated) indeed bash-specific,
since a short dash test script (POSIX):
#!/usr/bin/dash
git rev-parse $':/^My commit\n'
simply prints a
$:/^My commit\n
result,
and no amount of syntax fiddling
succeeded in getting the correct commit result on dash.
Well, since that \n simply *is* a newline
(see also
http://unix.stackexchange.com/questions/155367/when-to-use-bash-ansi-c-style-escape-e-g-n
),
a successful way to encode it in dash (all non-bash shells?) is:
git rev-parse :/'^My commit
'
i.e. with an *actual* newline.
BTW, as a (albeit weak) former m68k architecture user,
thank you for your efforts!
Andreas Mohr
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[BUG] git rev-parse :/ "regex" syntax not really regex?
Hello all, I just wanted to shortly mention that to me it seems that while git help rev-parse says :/, e.g. :/fix nasty bug A colon, followed by a slash, followed by a text, names a commit whose commit message matches the specified regular expression. This name returns the youngest matching commit which is reachable from any ref. If the commit message starts with a ! you have to repeat that; the special sequence :/!, followed by something else than !, is reserved for now. The regular expression can match any part of the commit message. To match messages starting with a string, one can use e.g. :/^foo. , the supported syntax seems to be decidedly not really regex, as opposed to git log --grep Creating a minimal reproducing repo sample with e.g. a dummy commit series of the following commit titles: My commit last My commit My commit first and doing searches via git rev-parse :/'^My commi\w' git rev-parse :/'^My commit$' git rev-parse :/'^My commit' git log --grep='^My commit$' --format=%H < that one seems to work fully reliably will yield surprising results (returning most recent commit rather than commit title exact-match one), and no amount of fiddling with various regex flavour syntax deviations managed to fix it for me. Unless I happened to misunderstand git's regex flavour, or something else... (hmm, perhaps it's a try-match-single-line vs. multi-line content issue, which perhaps does not work by specifying the trailing $) $ git --version git version 2.5.5 (same irritating behaviour also encountered on some older version, perhaps 2.0/2.1 range) If this bug is confirmed, then I could suggest two variants: - fix rev-parse's handling of :/ to actually do the correct thing, if easily possible - simply fix rev-parse's docs to correctly indicate that unfortunately it is NOT fully regex capable, and ensure also having added a reference to the (much?) more reliably working git log --grep. If this bug is not confirmed, then the question would be what kind of potential documentation / usability weaknesses successfully managed to lead me astray and thus would need to be fixed. Thanks, Andreas Mohr -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Issue: repack semi-frequently fails on Windows (msysgit) - suspecting file descriptor issues
Hi all, over the years I've had the same phenomenon with various versions of msysgit (now at 1.9.5.msysgit.0, on Windows 7 64bit), so I'm now sufficiently confident of it being a long-standing, longer-term issue and thus I'm reporting it now. Since I'm doing development in a sufficiently rebase-heavy manner, I seem to aggregate a lot of objects. Thus, when fetching content I'm sufficiently frequently greeted with a git gc run. This, however, does not work fully reliably: Auto packing the repository for optimum performance. You may also run git gc manually. See git help gc for more information. Counting objects: 206527, done. Delta compression using up to 4 threads. Compressing objects: 100% (27430/27430), done. Writing objects: 100% (206527/206527), done. Total 206527 (delta 178632), reused 206527 (delta 178632) Unlink of file '.git/objects/pack/pack-ab1712db0a94b5c55538d3b4cb3660cedc264c3c.pack' failed. Should I try again? (y/n) n Unlink of file '.git/objects/pack/pack-ab1712db0a94b5c55538d3b4cb3660cedc264c3c.idx' failed. Should I try again? (y/n) n Checking connectivity: 206527, done. A workable workaround for this recurring issue (such a fetch will fail repeatedly, thereby hampering my ability to update properly) is to manually do a git gc --auto prior to the fetch (which will then succeed). -- ¿umop apisdn upside down? (by daniweb.com user Bench) -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Issue: repack semi-frequently fails on Windows (msysgit) - suspecting file descriptor issues
Hi, On Thu, Apr 16, 2015 at 01:31:02PM +0200, Johannes Schindelin wrote: Hi, On 2015-04-16 13:10, Thomas Braun wrote: I've never had this issue. The error message from unlinking the file means that someone is still accessing the file and thus it can not be deleted (due to the implicit file locking on windows). Best guess is that an antivirus is still accessing it. There is a tool called `WhoUses.exe` in msysGit (I do not remember if I included it into Git for Windows 1.x for end users) which could be used to figure out which process accesses a given file still: https://github.com/msysgit/msysgit/blob/master/mingw/bin/WhoUses.exe (maybe that would help you identify the cause of the problem). Oh my. Botched mail conversation... I tried to f'up on this messy start ASAP, so I even managed to omit this final *pre-existing* part: Please note that this system is hampered by a crappy virus scanner dependency (F-Secure), which could be the culprit for this issue (e.g. by keeping files busy for longer than expected), however I really don't think that it takes part in this issue. The reason that I suspect that it's not virus scanner related is: - standalone git gc --auto works immediately (hmm but this might also point at the opposite - namely virus scanner still accessing files of a prior operation only in case there *was* a prior operation) - file descriptor scope handling issue in git source code is very easily imaginable - only a very rebase-heavy workflow of a sufficiently large repo is likely to have this issue turn up in a frequently enough manner, thus it's quite likely that it's not observed (or reported) all too often Thanks, Andreas Mohr -- GNU/Linux. It's not the software that's free, it's you. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Issue: repack semi-frequently fails on Windows (msysgit) - suspecting file descriptor issues
On Thu, Apr 16, 2015 at 01:48:46PM +0200, Andreas Mohr wrote: OK, at this point in time it's my turn to actually verify that indeed it's NOT the virus scanner: - generate rebase-heavy activity - update - hit issue - unload virus (~ scanner?? I'm unsure on exact terminology to be used ;-) - update - profit!? Despite trying hard (generating a lot of activity, with different repo projects even) I cannot reproduce it in a timely manner, thus I'll have to wait until repo state has degraded in a sufficient manner for such a larger repack with that issue to occur again (probably a matter of weeks). Once it happens, I will: - ensure keeping a copy of the entire (problematic-state) repo, and verify reproducibility of its (copied/preserved) breakage - unload virus and do other tests - report back Andreas Mohr -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Issue: repack semi-frequently fails on Windows (msysgit) - suspecting file descriptor issues
Hi,
sorry, I had sent the prior mail prematurely (hit wrong key)
and have been busy working on the resubmission...
On Thu, Apr 16, 2015 at 01:10:36PM +0200, Thomas Braun wrote:
Am 16.04.2015 um 12:03 schrieb Andreas Mohr:
Hi all,
over the years I've had the same phenomenon with various versions of msysgit
(now at 1.9.5.msysgit.0, on Windows 7 64bit), so I'm now sufficiently
confident of it being a long-standing, longer-term issue and thus I'm
reporting it now.
(I've had experience with this issue as early as 1.7.x, I believe).
(CC'ing msysgit)
Hi Andreas,
Since I'm doing development in a sufficiently rebase-heavy manner,
I seem to aggregate a lot of objects.
Thus, when fetching content I'm sufficiently frequently greeted with
a git gc run.
This, however, does not work fully reliably:
Auto packing the repository for optimum performance. You may also
run git gc manually. See git help gc for more information.
Counting objects: 206527, done.
Delta compression using up to 4 threads.
Compressing objects: 100% (27430/27430), done.
Writing objects: 100% (206527/206527), done.
Total 206527 (delta 178632), reused 206527 (delta 178632)
Unlink of file
'.git/objects/pack/pack-ab1712db0a94b5c55538d3b4cb3660cedc264c3c.pack'
failed. Should I try again? (y/n) n
Unlink of file
'.git/objects/pack/pack-ab1712db0a94b5c55538d3b4cb3660cedc264c3c.idx'
failed. Should I try again? (y/n) n
Checking connectivity: 206527, done.
A workable workaround for this recurring issue
(such a fetch will fail repeatedly,
thereby hampering my ability to update properly)
is to manually do a git gc --auto
prior to the fetch (which will then succeed).
I've never had this issue. The error message from unlinking the file
means that someone is still accessing the file and thus it can not be
deleted (due to the implicit file locking on windows).
Can you reproduce the error reliably?
It seems to be reproducible pretty reliably,
at least once git thinks it needs to repack (initiated by a fetch operation, I
think),
*and* then the unlink issue successfully turned up
(which may happen perhaps every 20 fetches of a *very* rebase-heavy workflow).
Interim mail content:
I strongly suspect that git's repacking implementation
(probably unrelated to msysgit-specific deviations,
IOW, git *core* handling)
simply is buggy
in that it may keep certain file descriptors open
at least a certain time (depending on scope of implementation/objects!?)
beyond having finished its operation (rename?).
As a related note, in an unrelated application of mine
I also encountered issues on Windows
where renaming of in-use files and further use of these files/names
then failed (error code was EACCES I believe).
IOW, this seems to be an issue specific to
Windows' special (and sometimes quirky) filesystem handling
which probably does not turn up on many other platforms,
thus a historic existing implementation weakness in git's repack handling
could not be nailed down in a sufficiently easy manner.
I think I may have the order wrong, however:
Handling seems to be:
- repack needed
- counting objects
- compressing
- writing
- unlink (delete) of all prior non-repacked objects (which fails)
I have to admit that at this point in time I'm actually unsure
which higher-level operation it actually is
that gets carried out where eventually a repack *implicitly* gets triggered
(I've got a shell script here which implements clean branch updating,
where I eventually hit the problem during its daily use).
Since a standalone git gc --auto *immediately* appears to work
(after many repeated attempts of failing full-update),
this is a strong hint that (in the failure case)
it's the *PRIOR* (non-repack) operation
which has kept these objects open beyond its actual operation scope.
Suspected implementation sample code:
if (operation_needed)
{
operation_workingset set;
set.DoStuff();
if (repack_needed)
{
repack_handler repack;
repack.DoStuff();
}
}
[NOTE the very prominent scope issues in this example,
which might be the exact reason for hitting such unlink failures -
simply due to having kept file descriptors open within the working set]
I have not had a look at git source though
to actually determine whether there do exist
such severe operation scope issues
that I'm strongly contemplating.
Andreas Mohr
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Issue: repack semi-frequently fails on Windows (msysgit) - suspecting file descriptor issues
On Thu, Apr 16, 2015 at 01:42:35PM +0200, Andreas Mohr wrote: Hi, On Thu, Apr 16, 2015 at 01:31:02PM +0200, Johannes Schindelin wrote: Hi, On 2015-04-16 13:10, Thomas Braun wrote: I've never had this issue. The error message from unlinking the file means that someone is still accessing the file and thus it can not be deleted (due to the implicit file locking on windows). Best guess is that an antivirus is still accessing it. There is a tool called `WhoUses.exe` in msysGit (I do not remember if I included it into Git for Windows 1.x for end users) which could be used to figure out which process accesses a given file still: https://github.com/msysgit/msysgit/blob/master/mingw/bin/WhoUses.exe (maybe that would help you identify the cause of the problem). Oh my. Botched mail conversation... I tried to f'up on this messy start ASAP, so I even managed to omit this final *pre-existing* part: Please note that this system is hampered by a crappy virus scanner dependency (F-Secure), which could be the culprit for this issue (e.g. by keeping files busy for longer than expected), however I really don't think that it takes part in this issue. The reason that I suspect that it's not virus scanner related is: - standalone git gc --auto works immediately (hmm but this might also point at the opposite - namely virus scanner still accessing files of a prior operation only in case there *was* a prior operation) - file descriptor scope handling issue in git source code is very easily imaginable - only a very rebase-heavy workflow of a sufficiently large repo is likely to have this issue turn up in a frequently enough manner, thus it's quite likely that it's not observed (or reported) all too often OK, at this point in time it's my turn to actually verify that indeed it's NOT the virus scanner: - generate rebase-heavy activity - update - hit issue - unload virus (~ scanner?? I'm unsure on exact terminology to be used ;-) - update - profit!? (and possibly have a try at WhoUses.exe there, too - thanks for the hint!) Andreas Mohr -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Issue: repack semi-frequently fails on Windows (msysgit) - suspecting file descriptor issues
[git-owner CC dutifully removed] On Thu, Apr 16, 2015 at 05:48:42PM +0200, Johannes Schindelin wrote: Hi Peff, On 2015-04-16 17:28, Jeff King wrote: On Thu, Apr 16, 2015 at 01:35:05PM +0200, Andreas Mohr wrote: I strongly suspect that git's repacking implementation (probably unrelated to msysgit-specific deviations, IOW, git *core* handling) simply is buggy in that it may keep certain file descriptors open at least a certain time (depending on scope of implementation/objects!?) beyond having finished its operation (rename?). Hrm. [... detailed analysis, including a Minimal, Complete Verifiable Example ...] Thank you so much! I will definitely test this (at the moment, I have to recreate my build environment in a different VM than I used so far, that takes quite some time...) Your hash-object script successfully and with ease managed to provoke the issue again, thanks a lot! (syntax issue though: missed a '|' pipe). And I then did some unload tests (force-unloaded, via End Process Tree) of the virus, and the unlink issue persisted (but to be truly certain, I would have to rename away the entire virus installation tree). Not to mention that it already looks anyway like we seem to be on the way of nailing a genuine git handling bug... Also, I have a very hard time remembering that the retry unlink? EVER finally ended up successful (despite virus file activity surely being a very temporary thing!). So much for some related observations that I can contribute currently - I had no time left to actually work on it today but I'll try to do some testing given the very detailed (and gratifyingly matching :) analysis of Jeff King (thanks a lot, too!). Andreas Mohr -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Wishlist: git help bisect should mention stop keyword
Hi, the man page (git version 1.7.10.4) is a bit non-symmetric since git bisect has the start param, but when searching for stop (nothing more obvious than that, right?), one comes up empty -- usability issue. The appropriate action complementary to start appears to be git bisect reset, thus its description definitely ought to include a stop keyword. Description as of 1.7.10.4 is After a bisect session, to clean up the bisection state and return to the original HEAD, issue the following command: $ git bisect reset which could be changed into After a bisect session, to clean up the bisection state and return to the original HEAD (in other words, to stop bisect), issue the following command: $ git bisect reset Andreas Mohr -- GNU/Linux. It's not the software that's free, it's you. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] git-bisect.txt: clarify that reset finishes bisect
Hi, On Sat, Feb 09, 2013 at 01:53:04PM -0800, Junio C Hamano wrote: Michael J Gruber g...@drmicha.warpmail.net writes: After a bisect session, to clean up the bisection state and return to -the original HEAD, issue the following command: +the original HEAD (i.e., to finish bisect), issue the following command: Makes sense. Doesn't ;) [aww, very sorry for this blunt reply] The main point of my mail was to stretch the (whether actually intended) *perceived* start - stop symmetry (which a *user* quite likely would end up searching for in the document, and fail to find any stop keyword, thus not getting to the relevant reset parameter section in time). Quite likely I failed to properly word things to make that obvious, in my quickly carved mail. To clarify intent behind these docs, I would thus propose to have the sentence improved to something quite similar to the original HEAD (i.e., to finish - stop a started - bisect), issue the following command: Thanks a ton for your immediate handling of my wishlist item! Andreas Mohr -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] git-bisect.txt: clarify that reset finishes bisect
On Sat, Feb 09, 2013 at 03:35:35PM -0800, Junio C Hamano wrote: Andreas Mohr a...@lisas.de writes: The main point of my mail was to stretch the (whether actually intended) *perceived* start - stop symmetry Actually, in that sense, I do no think finish is exactly a good wording. The majority of use case would be to finish up after you found the sole culprit, so in that sense finish is not too bad, but in general, when you reset, there is not necessarily any symmmetry with start. We should definitely not be giving you an illusion that there is one by using stop [*1*]. Yeah, of course, but the whole point was that the *user* will *directly* and *immediately* mentally go from a bisect start parameter to stop, and end up failing to find it. Thus the stop *KEYWORD* *has* to be mentioned in the man page (even if only to then expressly state that reset is not quite about stopiing things). *1* another reason to avoid stop is that it could mean I stop here for now, to later come back and start digging again from there, which is not reset is about at all. Such reasons for not listing stop might even be stronger than the reason of users being required to successfully look up the symmetric stop keyword. If that was decided to be the case, then stop would indeed have to be omitted in the man page - to the detriments of usability. Thanks, Andreas Mohr -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
