Re: Antw: Re: non-smooth progress indication for git fsck and git gc

[Ulrich Windl]

>>> Jeff King  schrieb am 21.08.2018 um 03:07 in Nachricht
<20180821010712.ga32...@sigill.intra.peff.net>:
> On Mon, Aug 20, 2018 at 10:57:13AM +0200, Ævar Arnfjörð Bjarmason wrote:
> 
[...]
> So it really should just be a simple:
> 
>   progress = start_delayed_progress("Hashing packfile", 0);
> 
> That said, counting bytes would probably be ugly (just because the
> numbers get really big). We'd probably prefer to show a throughput or

Hi!

With big numbers you could apply scaling (the usual ISO suffixes), but after
having read GBs, there wouldn't be much change visible unless you add
significant fractional digits.
So scaling seems good for absolute numbers, but not for growing numbers. Of
course one could recursively scale the fractional parts again, but then the
result will be lengthy again, then.

Regards,
Ulrich

> something. And as you noted, there's some refactoring to be done with
> pack-check for it to show multiple progress meters.
> 
> (I still think in the long run we would want to scrap that code, but
> that's a much bigger job; I'm fine if somebody wants to do incremental
> improvements in the meantime).
> 
> -Peff

Re: Antw: Re: non-smooth progress indication for git fsck and git gc

[Ulrich Windl]

Hi!

Here are some stats from the repository. First the fast import ones (which had
good performance, but probably all cached, also):

% git fast-import <../git-stream
/usr/lib/git/git-fast-import statistics:
-
Alloc'd objects:  55000
Total objects:51959 (56 duplicates  )
  blobs  :47991 ( 0 duplicates  0 deltas of   
  0 attempts)
  trees  : 3946 (56 duplicates994 deltas of  
3929 attempts)
  commits:   22 ( 0 duplicates  0 deltas of   
  0 attempts)
  tags   :0 ( 0 duplicates  0 deltas of   
  0 attempts)
Total branches:  15 (15 loads )
  marks:1048576 ( 48013 unique)
  atoms:  43335
Memory total:  9611 KiB
   pools:  7033 KiB
 objects:  2578 KiB
-
pack_report: getpagesize()=   4096
pack_report: core.packedGitWindowSize = 1073741824
pack_report: core.packedGitLimit  = 8589934592
pack_report: pack_used_ctr=   1780
pack_report: pack_mmap_calls  = 23
pack_report: pack_open_windows=  1 /  1
pack_report: pack_mapped  =2905751 /2905751
-

Then the output from git-sizer:

Processing blobs: 47991
Processing trees: 3946
Processing commits: 22
Matching commits to trees: 22
Processing annotated tags: 0
Processing references: 15
| Name | Value | Level of concern   |
|  | - | -- |
| Overall repository size  |   ||
| * Blobs  |   ||
|   * Total size   |  13.7 GiB | *  |
|  |   ||
| Biggest objects  |   ||
| * Trees  |   ||
|   * Maximum entries  [1] |  13.4 k   | *  |
| * Blobs  |   ||
|   * Maximum size [2] |   279 MiB | *  |
|  |   ||
| Biggest checkouts|   ||
| * Maximum path depth [3] |10 | *  |
| * Maximum path length[3] |   130 B   | *  |
| * Total size of files[3] |  8.63 GiB | *  |

[1]  b701345cbd4317276568b9d9890fd77f38933bdc
(refs/heads/master:Resources/default/CIFP)
[2]  19f54c4a7595667329c1be23200234f0fe50ac56
(refs/heads/master:Resources/default/apt.dat)
[3]  b0e3d3a2b7f2504117408f13486c905a8eb8fb1e (refs/heads/master^{tree})

Some notes:
[1] is a directory with many short (typically < 1kB) text files
[2] is a very large text file with many changes
[3] Yes, some paths are long

Regards,
Ulrich


>>> Ævar Arnfjörð Bjarmason  schrieb am 20.08.2018 um 10:57
in
Nachricht <87woslpg9i@evledraar.gmail.com>:

> On Mon, Aug 20 2018, Ulrich Windl wrote:
> 
>>>>> Jeff King  schrieb am 16.08.2018 um 22:55 in Nachricht
>> <20180816205556.ga8...@sigill.intra.peff.net>:
>>> On Thu, Aug 16, 2018 at 10:35:53PM +0200, Ævar Arnfjörð Bjarmason wrote:
>>>
>>>> This is all interesting, but I think unrelated to what Ulrich is talking
>>>> about. Quote:
>>>>
>>>> Between the two phases of "git fsck" (checking directories and
>>>> checking objects) there was a break of several seconds where no
>>>> progress was indicated
>>>>
>>>> I.e. it's not about the pause you get with your testcase (which is
>>>> certainly another issue) but the break between the two progress bars.
>>>
>>> I think he's talking about both. What I said responds to this:
>>
>> Hi guys!
>>
>> Yes, I was wondering what git does between the two visible phases, and 
> between
>> the lines I was suggesting another progress message between those phases.
At
>> least the maximum unspecific three-dot-message "Thinking..." could be 
> displayed
>> ;-) Of course anything more appropriate would be welcome.
>> Also that message should only

Antw: Re: non-smooth progress indication for git fsck and git gc

[Ulrich Windl]

>>> Jeff King  schrieb am 16.08.2018 um 22:55 in Nachricht
<20180816205556.ga8...@sigill.intra.peff.net>:
> On Thu, Aug 16, 2018 at 10:35:53PM +0200, Ævar Arnfjörð Bjarmason wrote:
> 
>> This is all interesting, but I think unrelated to what Ulrich is talking
>> about. Quote:
>> 
>> Between the two phases of "git fsck" (checking directories and
>> checking objects) there was a break of several seconds where no
>> progress was indicated
>> 
>> I.e. it's not about the pause you get with your testcase (which is
>> certainly another issue) but the break between the two progress bars.
> 
> I think he's talking about both. What I said responds to this:

Hi guys!

Yes, I was wondering what git does between the two visible phases, and between
the lines I was suggesting another progress message between those phases. At
least the maximum unspecific three-dot-message "Thinking..." could be displayed
;-) Of course anything more appropriate would be welcome.
Also that message should only be displayed if it's foreseeable that the
operation will take significant time. In my case (I just repeated it a few
minutes ago) the delay is significant (at least 10 seconds). As noted earlier I
was hoping to capture the timing in a screencast, but it seems all the delays
were just optimized away in the recording.

> 
>> >> During "git gc" the writing objects phase did not update for some
>> >> seconds, but then the percentage counter jumped like from 15% to 42%.
> 
> But yeah, I missed that the fsck thing was specifically about a break
> between two meters. That's a separate problem, but also worth
> discussing (and hopefully much easier to address).
> 
>> If you fsck this repository it'll take around (on my spinning rust
>> server) 30 seconds between 100% of "Checking object directories" before
>> you get any output from "Checking objects".
>> 
>> The breakdown of that is (this is from approximate eyeballing):
>> 
>>  * We spend 1-3 seconds just on this:
>>
>
https://github.com/git/git/blob/63749b2dea5d1501ff85bab7b8a7f64911d21dea/pack

> -check.c#L181
> 
> OK, so that's checking the sha1 over the .idx file. We could put a meter
> on that. I wouldn't expect it to generally be all that slow outside of
> pathological cases, since it scales with the number of objects (and 1s
> is our minimum update anyway, so that might be OK as-is). Your case has
> 13M objects, which is quite large.

Sometimes an oldish CPU could bring performance surprises, maybe. Anyway my
CPU is question is an AMD Phenom2 quad-core with 3.2GHz nominal, and there is a
classic spinning disk with 5400RPM built in...

> 
>>  * We spend the majority of the ~30s on this:
>>
>
https://github.com/git/git/blob/63749b2dea5d1501ff85bab7b8a7f64911d21dea/pack

> -check.c#L70-L79
> 
> This is hashing the actual packfile. This is potentially quite long,
> especially if you have a ton of big objects.

That seems to apply. BTW: Is there a way go get some repository statistics
like a histogram of object sizes (or whatever that might be useful to help
making decisions)?

> 
> I wonder if we need to do this as a separate step anyway, though. Our
> verification is based on index-pack these days, which means it's going
> to walk over the whole content as part of the "Indexing objects" step to
> expand base objects and mark deltas for later. Could we feed this hash
> as part of that walk over the data? It's not going to save us 30s, but
> it's likely to be more efficient. And it would fold the effort naturally
> into the existing progress meter.
> 
>>  * Wes spend another 3-5 seconds on this QSORT:
>>
>
https://github.com/git/git/blob/63749b2dea5d1501ff85bab7b8a7f64911d21dea/pack

> -check.c#L105
> 
> That's a tough one. I'm not sure how we'd count it (how many compares we
> do?). And each item is doing so little work that hitting the progress
> code may make things noticeably slower.

If it's sorting, maybe add some code like (wild guess):

if (objects_to_sort > magic_number)
   message("Sorting something...");

> 
> Again, your case is pretty big. Just based on the number of objects,
> linux.git should be 1.5-2.5 seconds on your machine for the same
> operation. Which I think may be small enough to ignore (or even just
> print a generic before/after). It's really the 30s packfile hash that's
> making the whole thing so terrible.
> 
> -Peff

Antw: Re: non-smooth progress indication for git fsck and git gc

[Ulrich Windl]

>>> Duy Nguyen  schrieb am 16.08.2018 um 17:18 in Nachricht
:
> On Thu, Aug 16, 2018 at 1:10 PM Ulrich Windl
>  wrote:
>>
>> Hi!
>>
>> I'd like to point out some minor issue observed while processing some 
> 5-object repository with many binary objects, but most are rather small:
>>
>> Between the two phases of "git fsck" (checking directories and checking 
> objects) there was a break of several seconds where no progress was 
> indicated.
>>
>> During "git gc" the writing objects phase did not update for some seconds, 
> but then the percentage counter jumped like from 15% to 42%.
>>
>> I understand that updating the progress output too often can be a 
> performance bottleneck, while upating it too rarely might only bore the 
> user... ;-)
>>
>> But maybe something can be done. My git version is 2.13.7 (openSUSE 42.3).
> 
> Is it possible to make this repository public? You can also use "git
> fast-export --anonymize" to make a repo with same structure but no
> real content (but read the man page about that option first)

Hi!

Actually I tried that locally, but with the resulting repository both, fsck and 
gc are very fast. So I guess it won't be very useful. Also the original .git 
directory uses 5.3G, while the anonymous .git just used 4.3M...

I tried to capture the behavior as screencast, but it seems the screencast 
optimized the little cahnges away, and in the result git almost had no delay on 
any operation 8-(

Regards,
Ulrich

> 
>> Regards,
>> Ulrich
>>
>>
> 
> 
> -- 
> Duy

non-smooth progress indication for git fsck and git gc

[Ulrich Windl]

Hi!

I'd like to point out some minor issue observed while processing some 
5-object repository with many binary objects, but most are rather small:

Between the two phases of "git fsck" (checking directories and checking 
objects) there was a break of several seconds where no progress was indicated.

During "git gc" the writing objects phase did not update for some seconds, but 
then the percentage counter jumped like from 15% to 42%.

I understand that updating the progress output too often can be a performance 
bottleneck, while upating it too rarely might only bore the user... ;-)

But maybe something can be done. My git version is 2.13.7 (openSUSE 42.3).

Regards,
Ulrich

Antw: Re: Q: Ignore ./foo, but not script/foo

[Ulrich Windl]

>>> Sebastian Staudt  schrieb am 19.07.2018 um 09:55 in
Nachricht
:
> Hello Ulrich,
> 
> if you want to ignore a file in the root of the repository (and only
> there) this is the correct syntax:
> 
> /foo

Hi!

Thanks, you are perfectly right: It works, and actually, when read carefully 
enough, the last item in "PATTERN FORMAT" explains that.

Maybe the EXAMPLES could have an example for each item (5 cases) described ;-)

Regards,
Ulrich

> 
> Best regards,
> Sebastian
> Am Do., 19. Juli 2018 um 09:45 Uhr schrieb Ulrich Windl
> :
>>
>> Hi!
>>
>> I have a (simple) question I could not answer elegantly from the 
> gitignore(5) manual page:
>>
>> A project produces a "foo" binary in the root directory that I want to 
> ignore (So I put "foo" into .gitignore)
>> Unfortunately I found out taht I cannot have a "script/foo" added while 
> "foo" is in .gitignore.
>> So I changed "foo" to "./foo" in .gitignore. I can could add "script/foo", 
> but now "foo" is not ignored any more!
>>
>> Is there as solution other than:?
>> --
>> foo
>> !script/foo
>> !bla/foo
>> #etc.
>> --
>>
>> If "foo" is one exception to generally using foo elsewhere, it seems to be 
> counterproductive to have to add exceptions for all the cases that are not 
> exceptions, while "foo" is the only exception...
>>
>> Did I miss something? If so, maybe add it to a future manual page.
>>
>> Regards,
>> Ulrich
>>
>>

Q: Ignore ./foo, but not script/foo

[Ulrich Windl]

Hi!

I have a (simple) question I could not answer elegantly from the gitignore(5) 
manual page:

A project produces a "foo" binary in the root directory that I want to ignore 
(So I put "foo" into .gitignore)
Unfortunately I found out taht I cannot have a "script/foo" added while "foo" 
is in .gitignore.
So I changed "foo" to "./foo" in .gitignore. I can could add "script/foo", but 
now "foo" is not ignored any more!

Is there as solution other than:?
--
foo
!script/foo
!bla/foo
#etc.
--

If "foo" is one exception to generally using foo elsewhere, it seems to be 
counterproductive to have to add exceptions for all the cases that are not 
exceptions, while "foo" is the only exception...

Did I miss something? If so, maybe add it to a future manual page.

Regards,
Ulrich

Antw: Re: java diffs show no method context

[Ulrich Windl]

Hi!

Thanks for that. It sounds plausible, but I wonder why it works automagically
for C, but not for Java (Politcal reasons put aside): Using ".c" for C is about
as common as using ".java" for Java ;-)

Regards,
Ulrich

>>> Alban Gruin <alban.gr...@gmail.com> schrieb am 25.04.2018 um 17:05 in
Nachricht
<aae8d748-101d-1eb2-f8e8-9da2e53e2...@gmail.com>:
> Le 25/04/2018 à 14:53, Ulrich Windl a écrit :
>> Hi!
>> 
>> This is for git 2.13.6, and it may be an FAQ or frequent feature request. 
> Anyway:
>> I'm new to Java, and writing my first project using Git, I found that "git

> diff" only reports the class in the diff context, but not the method (as
seen 
> for C, for example).
>> I'd wish to have the method where the diff is located.
> 
> Hi,
> 
> to achieve this behaviour, you have to create a file named
> ".gitattributes" at the root of your project, containing this line:
> 
> *.java diff=java
> 
> .gitattributes allows you to configure other things, as described in the
> documentation[1].
> 
> I hope it helps.
> 
> [1] https://www.git-scm.com/docs/gitattributes 
> 
> Cheers,
> Alban

java diffs show no method context

[Ulrich Windl]

Hi!

This is for git 2.13.6, and it may be an FAQ or frequent feature request. 
Anyway:
I'm new to Java, and writing my first project using Git, I found that "git 
diff" only reports the class in the diff context, but not the method (as seen 
for C, for example).
I'd wish to have the method where the diff is located. Here is an example chunk:


@@ -100,6 +119,8 @@ public class PdfParser {
PdfObject obj, value;
PdfObjectName name;
for ( int pos = startIndex; pos < endIndex; pos += 2 ) {
+   if ( (obj = objects.get(pos)).type != PdfObject.Type.Name )
+   exception("Name expected");
name = (PdfObjectName) obj;
if ( pos + 1 == endIndex )
exception("missing value");

The corrsponding definition of the method is like this:

/**
 * Populate Dictionary with parsed objects
 * @param dict Dictionary to fill
 * @param startIndex Position of first item to add
 * @param endIndex Position of first item not to add
 */
private void populateDictionary(PdfObjectDictionary dict, int startIndex, in
t endIndex)
{
...

Regards,
Ulrich

Antw: Re: Re: bug deleting "unmerged" branch (2.12.3)

[Ulrich Windl]

Hi!

Sorry for the late response:
On a somewhat not-up-to date manual:

   -d, --delete
   Delete a branch. The branch must be fully merged in its upstream
   branch, or in HEAD if no upstream was set with --track or
   --set-upstream.


Maybe the topic of multiple branches pointing to the same commit could be 
mentioned (regarding the status of each such branch being considered to be 
merged or not). Also "fully merged" could be made a bit more precise, maybe.

Maybe gitglossary could have definitions for "merged" and "fully merged" with 
manual pages referring to it.

Regards,
Ulrich


>>> "Philip Oakley" <philipoak...@iee.org> schrieb am 08.12.2017 um 21:26 in
Nachricht <582105F8768F4DA6AF4EC82888F0BFBE@PhilipOakley>:
> From: "Ulrich Windl" <ulrich.wi...@rz.uni-regensburg.de>
>> Hi Philip!
>>
>> I'm unsure what you are asking for...
>>
>> Ulrich
> 
> Hi Ulrich,
> 
> I was doing a retrospective follow up (of the second kind [1]).
> 
> In your initial email
> https://public-inbox.org/git/5a1d70fd02a100029...@gwsmtp1.uni-regensburg.d
>  
> e/
> you said
> 
> "I wanted to delete the temporary branch (which is of no use now), I got a
> message that the branch is unmerged.
> I think if more than one branches are pointing to the same commit, one
> should be allowed to delete all but the last one without warning."
> 
> My retrospectives question was to find what what part of the documentation
> could be improved to assist fellow coders and Git users in gaining a better
> understanding here. I think it's an easy mistake [2] to make and that we
> should try to make the man pages more assistive.
> 
> I suspect that the description for the `git branch -d` needs a few more
> words to clarify the 'merged/unmerged' issue for those who recieve the
> warning message. Or maybe the git-glossary, etc. I tend to believe that most
> users will read some of the man pages, and would continue to do so if they
> are useful.
> 
> I'd welcome any feedback or suggestions you could provide.
> --
> Philip
> 
>> >>> "Philip Oakley" <philipoak...@iee.org> 04.12.17 0.30 Uhr >>>
>> From: "Junio C Hamano" <gits...@pobox.com>
>> > "Philip Oakley" <philipoak...@iee.org> writes:
>> >
>> >> I think it was that currently you are on M, and neither A nor B are
>> >> ancestors (i.e. merged) of M.
>> >>
>> >> As Junio said:- "branch -d" protects branches that are yet to be
>> >> merged to the **current branch**.
>> >
>> > Actually, I think people loosened this over time and removal of
>> > branch X is not rejected even if the range HEAD..X is not empty, as
>> > long as X is marked to integrate with/build on something else with
>> > branch.X.{remote,merge} and the range X@{upstream}..X is empty.
>> >
>> > So the stress of "current branch" above you added is a bit of a
>> > white lie.
>>
>> Ah, thanks. [I haven't had chance to check the code]
>>
>> The man page does say:
>> .-d
>> .Delete a branch. The branch must be fully merged in its upstream
>> .branch, or in HEAD if no upstream was set with --track
>> .or --set-upstream.
>>
>> It's whether or not Ulrich had joined the two aspects together, and if the
>> doc was sufficient to help recognise the 'unmerged' issue. Ulrich?
>> --
>> Philip
>>
>>
> 
> [1] Retrospective Second Directive, section 3.4.2 of (15th Ed) Agile
> Processes in software engineering and extreme programming. ISBN 1628251042
> (for the perspective of the retrospective..)
> [2] 'mistake' colloquial part of the error categories of slips lapses and
> mistakes : Human Error, by Reason (James, prof) ISBN 0521314194 (worthwhile)

Antw: Re: bug deleting "unmerged" branch (2.12.3)

[Ulrich Windl]

Hi Philip!

I'm unsure what you are asking for...

Ulrich
>>> "Philip Oakley"  04.12.17 0.30 Uhr >>>
From: "Junio C Hamano" 
> "Philip Oakley"  writes:
>
>> I think it was that currently you are on M, and neither A nor B are
>> ancestors (i.e. merged) of M.
>>
>> As Junio said:- "branch -d" protects branches that are yet to be
>> merged to the **current branch**.
>
> Actually, I think people loosened this over time and removal of
> branch X is not rejected even if the range HEAD..X is not empty, as
> long as X is marked to integrate with/build on something else with
> branch.X.{remote,merge} and the range X@{upstream}..X is empty.
>
> So the stress of "current branch" above you added is a bit of a
> white lie.

Ah, thanks. [I haven't had chance to check the code]

The man page does say:
.-d
.Delete a branch. The branch must be fully merged in its upstream
.branch, or in HEAD if no upstream was set with --track 
.or --set-upstream.

It's whether or not Ulrich had joined the two aspects together, and if the
doc was sufficient to help recognise the 'unmerged' issue. Ulrich?
--
Philip

Antw: Re: bug deleting "unmerged" branch (2.12.3)

[Ulrich Windl]

> "Ulrich Windl" <ulrich.wi...@rz.uni-regensburg.de> writes:
> 
>> I think if more than one branches are pointing to the same commit,
>> one should be allowed to delete all but the last one without
>> warning. Do you agree?
> 
> That comes from a viewpoint that the only purpose "branch -d" exists
> in addition to "branch -D" is to protect objects from "gc".  Those
> who added the safety feature may have shared that view originally,
> but it turns out that it protects another important thing you are
> forgetting.
> 
> Imagine that two topics, 'topicA' and 'topicB', were independently
> forked from 'master', and then later we wanted to add a feature that
> depends on these two topics.  Since the 'feature' forked, there may
> have been other developments, and we ended up in this topology:
> 
> ---o---o---o---o---o---M
> \   \  
>  \   o---A---o---F
>   \ /  
>o---o---o---o---B
> 
> where A, B and F are the tips of 'topicA', 'topicB' and 'feature'
> branches right now [*1*].
> 
> Now imagine we are on 'master' and just made 'topicB' graduate.  We
> would have this topology.
> 
> ---o---o---o---o---o---o---M
> \   \ /
>  \   o---A---o---F   /
>   \ /   /
>o---o---o---o---B
> 
> While we do have 'topicA' and 'feature' branches still in flight,
> we are done with 'topicB'.  Even though the tip of 'topicA' is
> reachable from the tip of 'feature', the fact that the branch points
> at 'A' is still relevant.  If we lose that information right now,
> we'd have to go find it when we (1) want to further enhance the
> topic by checking out and building on 'topicA', and (2) want to
> finally get 'topicA' graduate to 'master'.
> 
> Because removal of a topic (in this case 'topicB') is often done
> after a merge of that topic is made into an integration branch,
> "branch -d" that protects branches that are yet to be merged to the
> current branch catches you if you said "branch -d topic{A,B}" (or
> other equivalent forms, most likely you'd have a script that spits
> out list of branches and feed it to "xargs branch -d").
> 
> So, no, I do not agree.

Hi!

I can follow your argumentation, but I fail to see that your branches A and B 
point to the same commit (which is what I was talking about). So my situation 
would be:

o---oA,B

I still think I could safely remove either A or B, even when the branch 
(identified by the commit, not by the name) is unmerged. What did I miss?

Regards,
Ulrich

> 
> 
> [Footnotes]
> 
> *1* Since the 'feature' started developing, there were a few commits
> added to 'topicB' but because the feature does not depend on
> these enhancements to that topic, B is ahead of the commit that
> was originally merged with the tip of 'topicA' to form the
> 'feature' branch.

Antw: Re: bug deleting "unmerged" branch (2.12.3)

[Ulrich Windl]

> Hi Ulrich,
> 
> On Tue, 28 Nov 2017, Ulrich Windl wrote:
> 
>> During a rebase that turned out to be heavier than expected 8-( I
>> decided to keep the old branch by creating a temporary branch name to
>> the commit of the branch to rebase (which was still the old commit ID at
>> that time).
>>
>> When done rebasing, I attached a new name to the new (rebased) branch,
>> deleted the old name (pointing at the same rebase commit), then
>> recreated the old branch from the temporary branch name (created to
>> remember the commit id).
>>
>> When I wanted to delete the temporary branch (which is of no use now), I
>> got a message that the branch is unmerged.
> 
> This is actually as designed, at least for performance reasons (it is not
> exactly cheap to figure out whether a given commit is contained in any
> other branch).
> 
>> I think if more than one branches are pointing to the same commit, one
>> should be allowed to delete all but the last one without warning. Do you
>> agree?
> 
> No, respectfully disagree, because I have found myself with branches
> pointing to the same commit, even if the branches served different
> purposes. I really like the current behavior where you can delete a
> branch with `git branch -d` as long as it is contained in its upstream
> branch.

Hi!

I'm not talking about the intention of a branch, but of the state of a branch: 
If multiple branches point (not "contain") the same commit, they are equivalent 
(besides the name) at that moment. As no program can predict the future or the 
intentions of the user, it should be safe to delete the branch, because it can 
easily be recreated (from the remaining branches pointing to the same commit).

It shouldn't need a lot of computational power to find out when multiple 
branches point to the same commit.

Regards,
Ulrich

bug deleting "unmerged" branch (2.12.3)

[Ulrich Windl]

Hi!

During a rebase that turned out to be heavier than expected 8-( I decided to 
keep the old branch by creating a temporary branch name to the commit of the 
branch to rebase (which was still the old commit ID at that time).
When done rebasing, I attached a new name to the new (rebased) branch, deleted 
the old name (pointing at the same rebase commit), then recreated the old 
branch from the temporary branch name (created to remember the commit id).
When I wanted to delete the temporary branch (which is of no use now), I got a 
message that the branch is unmerged.
I think if more than one branches are pointing to the same commit, one should 
be allowed to delete all but the last one without warning. Do you agree?

Regards,
Ulrich

Problems in Default merge message

[Ulrich Windl]

Hi!

I'd like to report an old-time bug in git, regarding the default message 
visible for a "git merge --no-commit" (at the later commit, of course):

* When merging a branch, the first name is put in single quotes, while the 
second is not.

* There is no blank line after the first one

* there are two blank lines further down

I'll attach a sample default merge file as found in the editor.

I suggest to put both branches in single quotes, and to either remove the two 
blank lines, or make them comment lines (for visual separation)

Regards,
Ulrich





merge-message
Description: Binary data

Antw: Re: Terrible bad performance for it blame --date=iso -C -C master --

[Ulrich Windl]

>>> Samuel Lijin  schrieb am 03.05.2017 um 09:12 in Nachricht

Antw: Re: Terrible bad performance for it blame --date=iso -C

[Ulrich Windl]

>>> Jakub Narebski <jna...@gmail.com> schrieb am 03.04.2017 um 17:16 in
Nachricht
<0ccc5cab-26b7-4b02-b964-452b61e92...@gmail.com>:
> W dniu 03.04.2017 o 12:56, SZEDER Gábor pisze:
>> Ulrich Windl wrote:
> 
>>> In the other case (for the user bored of waiting seeking for some
>>> entertainment ;-)) a "-v (verbose) option could be useful.  Or at the
>>> very least: If git is expecting that some operation will take (or
>>> already did take) a lot of time, give some message explaining why it
>>> is taking a lot of time, and maybe how to avoid that.
>> 
>> It already does so by default since v2.8.0, see aba37f495 (blame: add
>> support for --[no-]progress option, 2015-12-12).
>> 
>>   $ time git blame sha1_file.c |wc -l
>>   4026
>>   
>>   real0m1.744s
>>   user0m1.672s
>>   sys 0m0.068s
>>   $ time git blame -C -C sha1_file.c |wc -l
>>   Blaming lines: 100% (4026/4026), done.
>>   4026
>>   
>>   real0m3.832s
>>   user0m3.716s
>>   sys 0m0.112s
>> 
>> However, after a short peek at that commit, it only displays progress
>> by default when stderr is a terminal, which might not be the case when
>> invoked from emacs.
> 
> Emacs (magit?) should use `git blame --porcelain`, and do its own
> progress report, just like 'git gui blame' and incremental blame mode
> of gitweb.

I was thinking similar: The pain vc-annotate obviously should work without
those "-C" options, and with prefix argument (C-u  in Emacs) it could
start looking for copied stuff. HMO...

Worse than no progress reporting is the inability to kill the process (if you
run out of patience) with C-g (that stops most commands in Emacs).

> 
> Actually... there already is git-blamed - Minor mode for incremental
> blame for Git, and mo-git-blame - An interactive, iterative 'git blame'
> mode for Emacs, both available on ELPA (Emacs Lisp Package Archive).

I confess taht is still use RCS from time to time, and I prefer the
higher-level Emacs commands ;-)

Regards,
Ulrich

Antw: Re: Terrible bad performance for it blame --date=iso -C -C master --

[Ulrich Windl]

Junio,

thanks for explaining! So if there are at least two commits, blame is fast, but 
with only one commit blame tries hard to find another commit that might have 
contributed to the one file?
I verified that without those "-C" options the result is very quick.
In the other case (for the user bored of waiting seeking for some entertainment 
;-)) a "-v (verbose) option could be useful.
Or at the very least: If git is expecting that some operation will take (or 
already did take) a lot of time, give some message explaining why it is taking 
a lot of time, and maybe how to avoid that.

Regards,
Ulrich


>>> Junio C Hamano <gits...@pobox.com> schrieb am 31.03.2017 um 17:52 in 
>>> Nachricht
<xmqq60ip1m0f....@gitster.mtv.corp.google.com>:
> "Ulrich Windl" <ulrich.wi...@rz.uni-regensburg.de> writes:
> 
>> I was running "vc-annotate" in Emacs for a file from a large
>> repository (>4 files, a big percentage being binary, about 10
>> commits). For the first file the result was presented rather soon, but
>> for a second file the command did not finish even after about 10
>> minutes!
>>
>> The file in question is a rather short text file (124 kB), and
>> according to git log it has one commit.
>>
>> While being bored, I did an strace of the command to find out that a
>> huge number of files is inspected.
> 
> With -C -C the user (vc-annotate?) is asking to inspect huge number
> of files, to find if the contents of the file (except for the part
> that came from its own previous version) came from other existing
> files.  So this is very much expected.
> 
> It might not be a bad idea to teach "blame" not to pay attention to
> any path that is marked as "-diff" (e.g. binary files) when trying
> to see if remaining contents appeared by borrowing from them.  We do
> not have that heuristics (yet).

Terrible bad performance for it blame --date=iso -C -C master --

[Ulrich Windl]

Hi!

I was running "vc-annotate" in Emacs for a file from a large repository (>4 
files, a big percentage being binary, about 10 commits). For the first file the 
result was presented rather soon, but for a second file the command did not 
finish even after about 10 minutes!

The file in question is a rather short text file (124 kB), and according to git 
log it has one commit.

While being bored, I did an strace of the command to find out that a huge 
number of files is inspected.

I'm using git of openSUSE LEap 42.2 (git-2.10.2-3.1.x86_64).

Here's the stat of the process:

% cat /proc/6307/stat
6307 (git) R 6189 6307 6307 0 -1 4194304 30514692 0 1860 0 142035 6333 0 0 20 0 
1 0 14519800 5850595328 391884 18446744073709551615 4194304 6038988 
140726752300720 140726752293728 5549816 0 0 67108864 0 0 0 0 17 2 0 0 28211 0 0 
8138160 8173100 9625600 140726752306005 140726752306072 140726752306072 
140726752309227 0

Regards,
Ulrich

Antw: Re: Enhancement Request: locale git option

[Ulrich Windl]

 Ralf Thielow ralf.thie...@gmail.com schrieb am 04.12.2014 um 20:02 in
Nachricht
CAN0XMOL5ZZgEJ3zaXOAcxyX47iTM-DQv=+pnsdvrjd4awwx...@mail.gmail.com:
 Hi Ulrich,
 
 2014-12-04 8:32 GMT+01:00 Ulrich Windl ulrich.wi...@rz.uni-regensburg.de:
 Hi!

 I'm native German, but German git messages confuse me (yopu'll have to 
 correlate them with the man pages). At the moment git uses the
 
 What in particular makes the German git messages confusing you? What
 `git version` do you use?
 Maybe we can find something to improve in the translation.

The problem is (as others found out already) that all documentation I have use 
english Git messages, and lots of documentation is in English.

You could compare it to C++ (for example): If you read the language reference 
in English, you can only be confused by German compiler messages, and if you 
have a German book on C++, the phrases the book uses are quite likely not the 
ones the compiler uses...

Back to Git: Assuming (pure Science Fiction) that you participate in several 
projects using Git: One from a French maintainer expects that Git messages are 
in French, one Project uses English, another Project uses German... The a 
per-project locale setting would make sense (despite of the fact that I believe 
that every international project should use English for communication (just 
because it's a kind of industry standard, not giving any personal preference).

Regards,
Ulrich

 
 Thanks,
 Ralf




--
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

Antw: Re: Enhancement Request: locale git option

[Ulrich Windl]

 Ralf Thielow ralf.thie...@gmail.com schrieb am 06.12.2014 um 20:28 in
Nachricht
CAN0XMO+hn0cYrd=gvpuad_mqcvknwdfzfln0vo7045-m_0g...@mail.gmail.com:
 2014-12-05 16:45 GMT+01:00 Torsten Bögershausen tbo...@web.de:

 I do not know who was first, and who came later, but
 

http://git-scm.com/book/de/v1/Git-Grundlagen-%C3%84nderungen-am-Repository-na

 chverfolgen

 uses versioniert as tracked


 LANG=de_DE.UTF-8 git status
 gives:
 nichts zum Commit vorgemerkt, aber es gibt unbeobachtete Dateien (benutzen

 Sie git add zum Beobachten)


 Does it make sense to replace beobachten with versionieren ?

 
 I think it makes sense. versionieren describes the concept of tracking
 better than beobachten, IMO. I'll send a patch for that.

Isolated from usage, versionieren and tracking have no common translation;
what about verfolgen (~follow) for tracking?

 
 Thanks



--
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

Antw: Re: Enhancement Request: locale git option

[Ulrich Windl]

 Torsten Bögershausen tbo...@web.de schrieb am 04.12.2014 um 09:29 in
Nachricht 54801b50.4080...@web.de:
 On 12/04/2014 08:32 AM, Ulrich Windl wrote:
 Hi!

 I'm native German, but German git messages confuse me (yopu'll have to 
 correlate them with the man pages). At the moment git uses the locale 
 settings from the environment, so you can only change git's locale settings

 by changing the environment (like LANG= git ...).
 OTOH Git has a flexible hierachical option setting mechanism. Why not allow

 a Git language (locale) setting system-wde, user-wide, or
repository-specific.

 Regards,
 Ulrich
 How about
 alias git='LANGUAGE=de_DE.UTF-8 git'
 in your ~/.profile ?
 (Of course you need to change de to the language you want )

That way no program ever needs configuration files ;-)





--
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

Enhancement Request: locale git option

[Ulrich Windl]

Hi!

I'm native German, but German git messages confuse me (yopu'll have to 
correlate them with the man pages). At the moment git uses the locale settings 
from the environment, so you can only change git's locale settings by changing 
the environment (like LANG= git ...).
OTOH Git has a flexible hierachical option setting mechanism. Why not allow a 
Git language (locale) setting system-wde, user-wide, or repository-specific.

Regards,
Ulrich


--
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

Antw: Re: Extended splitting for git add --interactive

[Ulrich Windl]

I probably forgot to mention the obvious: My enhancement request was for cases 
where git would reject so split a junk. I don't want to change the default 
split (if it finds a point to split).
So maybe call it a 2nd-level-split. Only if split refuses to split, you could 
avoid using edit to manually split.
Iknow that in gerneral such things can't be right, but you can eith reject the 
new junks or use edit. I just guessed the feature could save some time on the 
average.

 Junio C Hamano gits...@pobox.com schrieb am 26.11.2014 um 19:57 in 
 Nachricht
xmqq3895rdr1@gitster.dls.corp.google.com:
 Ulrich Windl ulrich.wi...@rz.uni-regensburg.de writes:
 
 This is for git-1.7.12 (an older version from the SLES11 SP3 SDK). If
 the issue is solved meanwhile, I'll be happy, and I apologize for
 being too lazy to find out.
 
 The answer is no ;-).
 
 Currently Git cannot split a block of changes like

 -AAA
 -BBB
 +CCC
 +DDD

 Into
 -AAA
 +CCC
 and
 -BBB
 +DDD
 
 And it is unlikely to do so ever, because it is a wrong thing to do.
 
 What makes the user happy to see above split when the user is
 expecting this instead?
 
 -AAA
 and
 -BBB
 +CCC
 +DDD
 
 Another split that is not possible is a split across an empty line, like:

 +AAA
 + empty line (in reality)
 +BBB
 
 Likewise.  An empty line is not that special.  AAA may be adding one
 block of lines if (condition) { ... } and BBB may be another, and
 it often happens that you would want to separate these into two
 changes, with or without an empty line in between.
 
+if (foo) {
+  do foo thing
+}
+if (bar) {
+  do bar thing
+}

 Having said all that, I am not opposed to a usable idea to allow the
 user to specify where in a contiguous block of -*+* to break a hunk
 and how.




--
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

Extended splitting for git add --interactive

[Ulrich Windl]

Hi!

This is for git-1.7.12 (an older version from the SLES11 SP3 SDK). If the issue 
is solved meanwhile, I'll be happy, and I apologize for being too lazy to find 
out.

Currently Git cannot split a block of changes like

-AAA
-BBB
+CCC
+DDD

Into
-AAA
+CCC
and
-BBB
+DDD

So you'll have to edit it and waste me extra time (People probably use split if 
they know what they are doing, so maybe allow that).

Another split that is not possible is a split across an empty line, like:

+AAA
+ empty line (in reality)
+BBB

One could split that either into two parts with the empty lines belonging to 
one of AAA or BBB, or into three parts where the empty line is just another 
junk to accept or refuse. See comment above on why I'd like that.

Regards,
Ulrich Windl


--
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

Antw: Re: Q: .git/HEAD and .git/refs/heads

[Ulrich Windl]

 Matthieu Moy matthieu@grenoble-inp.fr schrieb am 02.04.2014 um 19:54 
 in
Nachricht vpqob0jwrbb@anie.imag.fr:
 Ulrich Windl ulrich.wi...@rz.uni-regensburg.de writes:
 
 Hi!

 I have a small question: After a git gc with last commit being [shared 
 2679648] I found this:
 cat .git/HEAD
 ref: refs/heads/shared
 cat .git/refs/heads/shared
 cat: .git/refs/heads/shared: No such file or directory

 Is this intentional?
 
 Yes.
 
 commit in these files: .git/logs/HEAD .git/logs/refs/heads/shared
 .git/info/refs .git/packed-refs
 
 Yes, they are where the refs are stored. If you have many refs in your
 repository, having one file per ref is inefficient. It's more efficient
 for Git to have one big read-only file. When one ref is modified, the
 .git/refs/heads/$branch file is re-created, and the packed entry is
 ignored.
 
 if [ -d .git ]; then
 GIT_HEAD=$(.git/HEAD)
 GIT_BRANCH=${GIT_HEAD##*/}
 GIT_HEAD=Git:$GIT_BRANCH-$(cut -c1-7 .git/${GIT_HEAD##*: })
 fi
 
 Don't access the filesystem. Ask Git.
 
 GIT_FULL_BRANCH=$(git rev-parse --symbolic-full-name HEAD)
 GIT_BRANCH=${GIT_FULL_BRANCH##*/}
 GIT_HEAD=Git:$GIT_BRANCH-$(git rev-parse --short HEAD)
 
 (Perhaps there's a simpler way without $GIT_FULL_BRANCH)

Matthieu,

thanks for this (it not so abvious how to use git --rev-parse)!

Ulrich


--
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

Q: .git/HEAD and .git/refs/heads

[Ulrich Windl]

Hi!

I have a small question: After a git gc with last commit being [shared 
2679648] I found this:
 cat .git/HEAD
ref: refs/heads/shared
 cat .git/refs/heads/shared
cat: .git/refs/heads/shared: No such file or directory

Is this intentional? How does Git find the numeric commit for HEAD?
Using find, I found my commit in these files:
.git/logs/HEAD
.git/logs/refs/heads/shared
.git/info/refs
.git/packed-refs

Before git gc I found the commit ID in HEAD.

Why I'm worrying?: I tried to make a simple script that finds out the current 
HEAD-commit like this:
if [ -d .git ]; then
GIT_HEAD=$(.git/HEAD)
GIT_BRANCH=${GIT_HEAD##*/}
GIT_HEAD=Git:$GIT_BRANCH-$(cut -c1-7 .git/${GIT_HEAD##*: })
fi

Then $GIT_HEAD was something like Git:shared-863962c.

Should I use code like this:?
awk '$2 == refs/heads/shared { print $1 }' .git/info/refs

Of course I'd be most pleased if there was some git builtin to get that (I read 
the manual without success).

Using an older version of Git (git-1.7.12)...

Regards,
Ulrich Windl


--
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

Antw: Re: diff support for the Eiffel language?

[Ulrich Windl]

Hi!

I managed to have some success, although it's not perfect. Unfortunately the
Eiffel grammar does not allow a 100% solution. Example:

---
local
  x : BOOLEAN
---
declares a local variable named `x', while

---
  x : BOOLEAN
   do ... end
---

Declares a function named `x'. Formal generic parameters like `x :
ARRAY[ARRAY[STRING]]' make things more complicate. Anyway, here's my solution
(probably incomplete):
---
% git config --local -e
[diff Eiffel]
xfuncname =
!^[[:space:]]*(check|class|[Cc]reate|else|elseif|end|ensure|do|!|feature|from|indexing|inherit|is|local|loop|note|require|then|until)[[:space:]]*\n\
^[[:space:]]*(class[[:space:]]*[[:alpha:]_][[:alnum:]_]*)\n\
^[[:space:]]*([[:alpha:]_][[:alnum:]_]*[[:space:]]*\\([^(\)]+:[^(\)]+\\)[[:space:]]*:[[:space:]*[[:alpha:]_][[:alnum:]_]*[[:space:]]*[^[:space:]\]?[^\=]*)[[:space:]]*$\n\

^[[:space:]]*([[:alpha:]_][[:alnum:]_]*[[:space:]]*\\([^(\)]+:[^(\)]+\\))[[:space:]]*$\n\

^[[:space:]]*([[:alpha:]_][[:alnum:]_]*[[:space:]]*:[[:space:]*[[:alpha:]_][[:alnum:]_]*[[:space:]]*[^[:space:]\]?[^\=]*)[[:space:]]*$\n\
^[[:space:]]*([[:alpha:]_][[:alnum:]_]*)[[:space:]]*$
% cat .git/info/attributes
*.e diff=Eiffel
---

Regards,
Ulrich

 Johannes Sixt j.s...@viscovery.net schrieb am 22.10.2012 um 15:35 in
Nachricht 50854b90.50...@viscovery.net:
 Am 10/22/2012 15:06, schrieb Ævar Arnfjörð Bjarmason:
  On Mon, Oct 22, 2012 at 1:58 PM, Ulrich Windl 
  ulrich.wi...@rz.uni-regensburg.de wrote:
  However there's one little thing I noticed with git diff: The
  conte4xt lines (staring with @@) show the current function (in Perl
  and C), but they show the current feature clause in Eiffel (as
  opposed to the expected current feature). I wonder how hard it is to
  fix it (Observed in git 1.7.7 of openSUSE 12.1).
  
  See git.git's e90d065 for an example of adding a new diff pattern.
 
 It's not necessary to wait until there is built-in support for a new 
 language.
 
 For example, for Windows resource files, I have
 
 *.rcdiff=winres
 
 in .gitattributes or .git/info/attributes and
 
 [diff winres]
 xfuncname =

!^(BEGIN|END|FONT|CAPTION|STYLE)\n^[a-zA-Z_][a-zA-Z_0-9]*.*\n^[[:space:]]*(
 [[:alnum:]_]+,
 *DIALOG.*)
 
 in .git/config (the xfuncname is all on a single line). The first part
 beginning at ! up to \n tells to ignore the specified matches. The other
 parts separated by \n tell the things to put in the hunk header. You can
 have ignore parts (with exlamation mark) and take this parts (without)
 in any order that is convenient, as long as the last one is take this.
 
 -- Hannes
 

 
 
--
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

diff support for the Eiffel language?

[Ulrich Windl]

Hi!

After a longer pause, I did some programming in Eiffel again, and while doing 
so, why not use Git? It works!

However there's one little thing I noticed with git diff:
The conte4xt lines (staring with @@) show the current function (in Perl and 
C), but they show the current feature clause in Eiffel (as opposed to the 
expected current feature). I wonder how hard it is to fix it (Observed in git 
1.7.7 of openSUSE 12.1).

For the non-Eiffelists:

Eiffel has a class structure like this:
class FOO

feature {BAR} -- This is a feature clause, grouping related features 
(attributes/routines)

   baz (x,y : INTEGER) : STRING is
  -- blabla...
  do
 ...
  end -- baz

end -- class FOO

---
Now if I change something inside baz, it would be nice if the @@-contect line 
would show baz (or more) instead of feature {BAR}

Regards,
Ulrich
P.S. Apologies if the feature requested had been added already.


--
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