From: Junio C Hamano <hidden> Date: 2016-06-15 22:43:13
Again, 'next' is getting quite lightweight compared to 'master'.
Good time to do "war on whitespace" Marco suggested myself.
'pu' has Shawn's 'pu' from git-gui, to help people experiment
with the proposed blame viewer improvements more easily. I
personally like it quite a bit.
----------------------------------------------------------------
Here are the topics that have been cooking. Commits prefixed
with '-' are only in 'pu' while commits prefixed with '+' are
in 'next'. The topics list the commits in reverse chronological
order.
* lh/submodules (Sat Jun 2 03:27:42 2007 +0200) 2 commits
+ Add basic test-script for git-submodule
+ Add git-submodule command
I find this a 'master' material already. Will merge soon.
* gb/idx (Fri Jun 1 15:18:05 2007 -0400) 1 commit
+ Unify write_index_file functions
Should graduate to 'master' by mid next week.
* pb/am (Thu May 24 19:25:25 2007 -0700) 2 commits
+ Remove git-applypatch
+ git-applymbox: Remove command
Will push out to 'master' soon to see if anybody screams.
* dh/repack (Fri May 25 14:40:24 2007 -0700) 1 commit
- Enhance unpack-objects for live repo and large objects
I saw nobody other than Dana jump up and down and say we must
have this, so I still parked this in 'pu' without merging it to
'next'. Maybe a time for a quick poll?
* jc/blame (Fri Apr 20 16:25:50 2007 -0700) 4 commits
- blame: show log as it goes
- git-blame: optimize get_origin() from linear search to hash-
lookup.
- git-blame: pass "struct scoreboard *" pointers around.
- blame: lift structure definitions up
* jc/diff (Mon Dec 25 01:08:50 2006 -0800) 2 commits
- test-para: combined diff between HEAD, index and working tree.
- para-walk: walk n trees, index and working tree in parallel
Backburnered. Further work on the latter, or something like
that, or something based on (disused) git-merge-tree, is needed
to exonerate Linus from having lied in the following part of his
talk (there is a transcript at http://git.or.cz/gitwiki of his
talk by the way):
The source code may sometimes look complicated because we
are very performance centric, I am. I really care, and
sometimes to make things go really fast, you have to use
more complicated algorithms than just checking one file at a
time. When you are doing 22,000 file merges, you do not
want to check one file at a time, you want to check the
whole tree in one go and say, "Ah they are the same, I do
not have to do anything".
as we _DO_ currently merge one path at a time.
You _could_ interpret "merge" in his message as applying
millions of patches from Andrew, in which case it is true ---
the cache-tree optimization in the index does help us skipping
the unchanged tree recomputation. But that does not apply to a
true merge, even when it is a trivial tree-level merge.
From: Johannes Schindelin <hidden> Date: 2016-06-15 22:43:13
Hi,
On Sat, 2 Jun 2007, Junio C Hamano wrote:
* lh/submodules (Sat Jun 2 03:27:42 2007 +0200) 2 commits
+ Add basic test-script for git-submodule
+ Add git-submodule command
I find this a 'master' material already. Will merge soon.
I agree. Even if I had not time to review it closely, from a cursory look
it is clean enough. I don't expect any regressions from that.
* pb/am (Thu May 24 19:25:25 2007 -0700) 2 commits
+ Remove git-applypatch
+ git-applymbox: Remove command
Will push out to 'master' soon to see if anybody screams.
Ack.
* jc/diff (Mon Dec 25 01:08:50 2006 -0800) 2 commits
- test-para: combined diff between HEAD, index and working tree.
- para-walk: walk n trees, index and working tree in parallel
Backburnered.
I actually like those two commits, and I always wanted to work on top of
these, but my new boss keeps me away from Git :-(
Will review, and try to work some more on them in the next three weeks.
Don't drop them!
As for the complicated source code: I cannot agree. If you have _any_ idea
about what data structures are about, you will readily recognize what it
is about. We _could_ be more explicit, but by a huge margin.
(IMHO too many people try to chime in without _any_ clue about the
difference of hash tables and binary search, and no notion of Landau's
symbol. We should not necessarily try to accomodate people who are _that_
unwilling to work up their theory.)
Ciao,
Dscho
From: Shawn O. Pearce <hidden> Date: 2016-06-15 22:43:13
Junio C Hamano [off-list ref] wrote:
'pu' has Shawn's 'pu' from git-gui, to help people experiment
with the proposed blame viewer improvements more easily. I
personally like it quite a bit.
For what its worth, my 'pu' has the same policy as Junio's; it
rebases freely and topics can come and go from it at any time.
But that said, it is certainly suitable for Junio's 'pu'. :-)
I just pushed an even newer version out a couple of minutes ago.
Now I'm running two passes of git-blame:
*) Pass 1: git-blame --incremental
*) Pass 2: git-blame -M -C -C --incremental
and the viewer shows them in two columns. This gives you pretty
quick information about why a change exists, as you get both who
moved the block to where it is, and who originally wrote it. ;-)
Lots of things still to be worked on in blame, like having it
keep track of what line(s) you are at or are trying to jump to.
I'll try to get to that stuff tonight or tomorrow.
--
Shawn.
From: Nicolas Pitre <hidden> Date: 2016-06-15 22:43:14
On Sat, 2 Jun 2007, Junio C Hamano wrote:
* dh/repack (Fri May 25 14:40:24 2007 -0700) 1 commit
- Enhance unpack-objects for live repo and large objects
I saw nobody other than Dana jump up and down and say we must
have this, so I still parked this in 'pu' without merging it to
'next'. Maybe a time for a quick poll?
I did provide a followup comment to this patch. If the concerns I
raised are addressed then I won't be against such a patch.
Nicolas
* dh/repack (Fri May 25 14:40:24 2007 -0700) 1 commit
- Enhance unpack-objects for live repo and large objects
I saw nobody other than Dana jump up and down and say we must
have this, so I still parked this in 'pu' without merging it to
'next'. Maybe a time for a quick poll?
I did provide a followup comment to this patch. If the concerns I
raised are addressed then I won't be against such a patch.
Hmm, I thought only your comments about incoherency were
still unaddressed and they applied only to the degunking patch,
but in any case I was planning to improve both patches in similar ways.
I won't be able to do this for a week or two (crunch time here).
I will first review the discussion for each patch in case my memory is wrong.
Thanks,
--
Dana L. How danahow@gmail.com +1 650 804 5991 cell