* Re: [PATCH] Move all dashed form git commands to libexecdir
From: A Large Angry SCM @ 2007-11-30 2:17 UTC (permalink / raw)
To: Nicolas Pitre
Cc: Junio C Hamano, Linus Torvalds, Jeff King, Johannes Schindelin,
Nguyen Thai Ngoc Duy, Jan Hudec, git
In-Reply-To: <alpine.LFD.0.99999.0711291959510.9605@xanadu.home>
Nicolas Pitre wrote:
> On Thu, 29 Nov 2007, A Large Angry SCM wrote:
>
>> Again, there needs to remain support in the Makefile to install the "dashed"
>> versions of the commands for those that want it; and be able to set
>> gitexecdir=$(binder) without editing the Makefile.
>
> Well, if you want a "non standard" installation, maybe you just can edit
> a line or two in the Makefile?
Why do you object to a "install-dashed" Makefile target?
^ permalink raw reply
* Re: [PATCH] Move all dashed form git commands to libexecdir
From: A Large Angry SCM @ 2007-11-30 2:03 UTC (permalink / raw)
To: Johannes Schindelin
Cc: Junio C Hamano, Linus Torvalds, Jeff King, Nguyen Thai Ngoc Duy,
Jan Hudec, git
In-Reply-To: <Pine.LNX.4.64.0711300053260.27959@racer.site>
Johannes Schindelin wrote:
> Hi,
>
> On Thu, 29 Nov 2007, A Large Angry SCM wrote:
[...]
>> Again, there needs to remain support in the Makefile to install the "dashed"
>> versions of the commands for those that want it; and be able to set
>> gitexecdir=$(binder) without editing the Makefile.
>
> Umm. Why? If there is no compelling reason (and you named none, but
> there were quite a few reasons against it), why should the Makefile
> support the dash form after 1.5.6?
Not all shells support customized command completion (check the
archives); "bang" history (check the archives); etc.
^ permalink raw reply
* Re: [RFC] use typechange as rename source
From: Jeff King @ 2007-11-30 1:57 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vmyswsfl6.fsf@gitster.siamese.dyndns.org>
On Thu, Nov 29, 2007 at 05:10:45PM -0800, Junio C Hamano wrote:
> > OK. What next? Did the patch I sent make sense? Do you want a cleaned up
> > version with a commit message and signoff, or does it need work?
>
> It just hit me that breaking (as in diffcore-break) a filepair that is a
> typechange may yield the same result, and if it works, that would be
> conceptually cleaner. After all, a typechange is the ultimate form of
> total rewriting (the similarity between the preimage and the postimage
> is very low -- even their types are different, let alone contents).
>
> Compared to that, the rename_used++ in that codepath you touched feels
> more magic to me.
I have always been a bit confused about diffcore-break, so I am probably
misunderstanding what you mean. But are you saying that
diffcore-break.c:should_break should return 1 for typechanges? If so,
that does not have the desired effect.
-Peff
^ permalink raw reply
* Re: Adding Git to Better SCM Initiative : Comparison
From: Jakub Narebski @ 2007-11-30 1:53 UTC (permalink / raw)
To: Johan Herland; +Cc: git, Alex Riesen, Robin Rosenberg
In-Reply-To: <200711300226.54338.johan@herland.net>
On Fri, 30 Nov 2007, Johan Herland wrote:
> On Friday 30 November 2007, Jakub Narebski wrote:
>> On Thu, 29 Nov 2007, Alex Riesen wrote:
>>> Jakub Narebski, Thu, Nov 29, 2007 03:26:12 +0100:
>>
>>>> + <s id="git">
>>>> + Medium. There's Git User's Manual, manpages, some
>>>> + technical documentation and some howtos. All
>>>> + documentation is also available online in HTML format;
>>>> + there is additional information (including beginnings
>>>> + of FAQ) on git wiki.
>>>> + Nevertheles one of complaints in surveys is insufficient
>>>
>>> "Nevertheless" (two "s").
>>>
>>> BTW, I wouldn't call the level of documentation "Medium" when compared
>>> to any commercial SCM. How can they earn more than "a little", when
>>> compared to any opensource program?
>>
>> Source code is not [user level] documentation.
>>
>> But perhaps it should be "Good" instead of "Medium", although I think
>> not "Excellent".
>
> If we try to compare ourselves to what's closest, i.e. Mercurial, I would
> say that Git's documentation is probably on par with what Mercurial has to
> offer. Their "Documentation" entry in the comparison is as follows:
>
> "Very good. There's an overview and tutorial on the web site, and integrated
> help for every command."
>
> I say we go for something similar.
Well, at least according to surveys results people perceive
"The Mercurial Book" (hgbook) as better documentation than
"Git User's Manual" + tutorials. See for example frequent requests
for "The Git Book" patterned after hgbook and/or svnbook.
BTW. the list was meant to be updated by contributors who added
SCMs, but it doesn't liik lik it is...
--
Jakub Narebski
Poland
^ permalink raw reply
* Re: [PATCH] Move all dashed form git commands to libexecdir
From: Jeff King @ 2007-11-30 1:53 UTC (permalink / raw)
To: Nicolas Pitre
Cc: Junio C Hamano, Linus Torvalds, Johannes Schindelin,
Nguyen Thai Ngoc Duy, Jan Hudec, git
In-Reply-To: <alpine.LFD.0.99999.0711292029420.9605@xanadu.home>
On Thu, Nov 29, 2007 at 08:33:39PM -0500, Nicolas Pitre wrote:
> So what you want is for the dashed hardlinks to exist _inside_ the
> libexec directory, even if most people won't "see" them due to that
> libexec directory not being in the shell path, right?
>
> If that is what you mean then I personally don't care at all.
That is exactly what I mean.
-Peff
^ permalink raw reply
* Re: [PATCH] Move all dashed form git commands to libexecdir
From: Nicolas Pitre @ 2007-11-30 1:33 UTC (permalink / raw)
To: Jeff King
Cc: Junio C Hamano, Linus Torvalds, Johannes Schindelin,
Nguyen Thai Ngoc Duy, Jan Hudec, git
In-Reply-To: <20071130012536.GA12615@coredump.intra.peff.net>
On Thu, 29 Nov 2007, Jeff King wrote:
> On Thu, Nov 29, 2007 at 08:19:38PM -0500, Nicolas Pitre wrote:
>
> > > In principle, yes, though one man's porcelain is another man's plumbing,
> > > so determining the correct set is hard (and why bother if they are all
> > > hidden from mere mortals, anyway?).
> >
> > That would be a good reason not to bother determining which set to
> > preserve and remove them all then.
>
> It clearly argues for putting all in the same boat, yes (but obviously
> we disagree on which boat).
>
> > Sure you'll miss the dashed form for, say, one week? After that your
> > fingers should be retrained.
>
> Perhaps, although that doesn't address my other point, about non-bash
> program in the world which already does filename completion (in my case,
> I am specifically thinking about vim's ":r!", but surely emacs users
> must have a similar issue).
>
> But that is just talking about the disadvantages; you can argue that
> they are small, but they are clearly non-zero. More importantly, what
> are the _advantages_ of removing the hardlinks (and if you haven't read
> the other message I just sent you, I am talking not about putting
> hardlinks into a non-PATH directory, but about removing them entirely
> once they are already in that alternate directory)? If there aren't any
> advantages, or they are also small, then it makes sense to keep the
> hardlinks.
So what you want is for the dashed hardlinks to exist _inside_ the
libexec directory, even if most people won't "see" them due to that
libexec directory not being in the shell path, right?
If that is what you mean then I personally don't care at all.
Nicolas
^ permalink raw reply
* Re: Adding Git to Better SCM Initiative : Comparison
From: Johan Herland @ 2007-11-30 1:26 UTC (permalink / raw)
To: git; +Cc: Jakub Narebski, Alex Riesen, Robin Rosenberg
In-Reply-To: <200711300118.28145.jnareb@gmail.com>
On Friday 30 November 2007, Jakub Narebski wrote:
> On Thu, 29 Nov 2007, Alex Riesen wrote:
> > Jakub Narebski, Thu, Nov 29, 2007 03:26:12 +0100:
>
> >> + <s id="git">
> >> + Medium. There's Git User's Manual, manpages, some
> >> + technical documentation and some howtos. All
> >> + documentation is also available online in HTML format;
> >> + there is additional information (including beginnings
> >> + of FAQ) on git wiki.
> >> + Nevertheles one of complaints in surveys is insufficient
> >
> > "Nevertheless" (two "s").
> >
> > BTW, I wouldn't call the level of documentation "Medium" when compared
> > to any commercial SCM. How can they earn more than "a little", when
> > compared to any opensource program?
>
> Source code is not [user level] documentation.
>
> But perhaps it should be "Good" instead of "Medium", although I think
> not "Excellent".
If we try to compare ourselves to what's closest, i.e. Mercurial, I would
say that Git's documentation is probably on par with what Mercurial has to
offer. Their "Documentation" entry in the comparison is as follows:
"Very good. There's an overview and tutorial on the web site, and integrated
help for every command."
I say we go for something similar.
Have fun!
...Johan
--
Johan Herland, <johan@herland.net>
www.herland.net
^ permalink raw reply
* Re: [PATCH] Move all dashed form git commands to libexecdir
From: Jeff King @ 2007-11-30 1:25 UTC (permalink / raw)
To: Nicolas Pitre
Cc: Junio C Hamano, Linus Torvalds, Johannes Schindelin,
Nguyen Thai Ngoc Duy, Jan Hudec, git
In-Reply-To: <alpine.LFD.0.99999.0711292013580.9605@xanadu.home>
On Thu, Nov 29, 2007 at 08:19:38PM -0500, Nicolas Pitre wrote:
> > In principle, yes, though one man's porcelain is another man's plumbing,
> > so determining the correct set is hard (and why bother if they are all
> > hidden from mere mortals, anyway?).
>
> That would be a good reason not to bother determining which set to
> preserve and remove them all then.
It clearly argues for putting all in the same boat, yes (but obviously
we disagree on which boat).
> Sure you'll miss the dashed form for, say, one week? After that your
> fingers should be retrained.
Perhaps, although that doesn't address my other point, about non-bash
program in the world which already does filename completion (in my case,
I am specifically thinking about vim's ":r!", but surely emacs users
must have a similar issue).
But that is just talking about the disadvantages; you can argue that
they are small, but they are clearly non-zero. More importantly, what
are the _advantages_ of removing the hardlinks (and if you haven't read
the other message I just sent you, I am talking not about putting
hardlinks into a non-PATH directory, but about removing them entirely
once they are already in that alternate directory)? If there aren't any
advantages, or they are also small, then it makes sense to keep the
hardlinks.
-Peff
^ permalink raw reply
* Re: [PATCH] Move all dashed form git commands to libexecdir
From: Nicolas Pitre @ 2007-11-30 1:19 UTC (permalink / raw)
To: Jeff King
Cc: Junio C Hamano, Linus Torvalds, Johannes Schindelin,
Nguyen Thai Ngoc Duy, Jan Hudec, git
In-Reply-To: <20071130010055.GB12224@coredump.intra.peff.net>
On Thu, 29 Nov 2007, Jeff King wrote:
> On Thu, Nov 29, 2007 at 07:52:01PM -0500, Nicolas Pitre wrote:
>
> > > I am still against this step, for the reasons mentioned in the mails
> > > leading up to the one you just quoted. I am fine with "does not install
> > > hardlinks for builtin-commands on systems that don't support hardlinks"
> > > (and of course all such hardlinks are in $(libexecdir)/git-core at this
> > > point).
> >
> > But only for porcelain, right? You certainly don't need the dashed form
> > of plumbing commands?
>
> In principle, yes, though one man's porcelain is another man's plumbing,
> so determining the correct set is hard (and why bother if they are all
> hidden from mere mortals, anyway?).
That would be a good reason not to bother determining which set to
preserve and remove them all then.
Sure you'll miss the dashed form for, say, one week? After that your
fingers should be retrained.
Nicolas
^ permalink raw reply
* Re: Fix a pathological case in git detecting proper renames
From: Kumar Gala @ 2007-11-30 1:18 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Jeff King, Junio C Hamano, Git Mailing List
In-Reply-To: <alpine.LFD.0.9999.0711291625580.8458@woody.linux-foundation.org>
On Nov 29, 2007, at 6:41 PM, Linus Torvalds wrote:
>
>
> On Thu, 29 Nov 2007, Jeff King wrote:
>>
>> I think it will get worse, because you are simultaneously calculating
>> all of the similarity scores bit by bit rather than doing a loop.
>> Though
>> perhaps you mean at the end you will end up with a list of src/dst
>> pairs
>> sorted by score, and you can loop over that.
>
> Well, after thinking about this a bit, I think there's a solution
> that may
> work well with the current thing too: instead of looping just *once*
> over
> the list of rename pairs, loop twice - and simply refuse to do
> copies on
> the first loop.
>
> This trivial patch does that, and turns Kumar's test-case into a
> perfect
> rename list.
Glad I can be of use for something :)
> It's not pretty, it's not smart, but it seems to work. There's
> something
> to be said for keeping it simple and stupid.
>
> And it should not be nearly as expensive as it may _look_. Yes, the
> loop
> is "(i = 0; i < num_create * num_src; i++)", but the important part is
> that the whole array is sorted by rename score, and we have a
>
> if (mx[i].score < minimum_score)
> break;
>
> in it, so uthe loop actually would tend to terminate rather quickly.
>
> Anyway, Kumar, the thing to take away from this is:
>
> - git really doesn't even *care* about the whole "rename detection"
> internally, and any commits you have done with renames are totally
> independent of the heuristics we then use to *show* the renames.
>
> - the rename detection really is for just two reasons: (a) keep humans
> happy, and keep the diffs small and (b) help automatic merging
> across
> renames. So getting renames right is certainly good, but it's more
> of a
> "politeness" issue than a "correctness" issue, although the merge
> portion of it does matter a lot sometimes.
Yeah both of these dawned on me after my brain started working and
thinking about what you were talking about when you say git manages
'content' and thinking about how the content management correlates to
the diffs we generate.
> - the important thing here is that you can commit your changes and not
> worry about them being somehow "corrupted" by lack of rename
> detection,
> even if you commit them with a version of git that doesn't do rename
> detection the way you expected it. The rename detection is an
> "after-the-fact" thing, not something that actually gets saved in
> the
> repository, which is why we can change the heuristics _after_ seeing
> examples, and the examples magically correct themselves!
>
> - try out the two patches I've posted, and see if they work for you.
> They
> pass the test-suite, and the output for your example commit looks
> sane,
> but hey, if you have other test-cases, try them out.
Only started using -M when a co-worker informed me about it. But if I
see other cases in the future I'll let you guys know.
> Here's Kumar's pretty diffstat with both my patches:
>
> Makefile | 6 +++---
> board/{cds => freescale}/common/cadmus.c | 0
> board/{cds => freescale}/common/cadmus.h | 0
> board/{cds => freescale}/common/eeprom.c | 0
> board/{cds => freescale}/common/eeprom.h | 0
> board/{cds => freescale}/common/ft_board.c | 0
> board/{cds => freescale}/common/via.c | 0
> board/{cds => freescale}/common/via.h | 0
> board/{cds => freescale}/mpc8541cds/Makefile | 0
> board/{cds => freescale}/mpc8541cds/config.mk | 0
> board/{cds => freescale}/mpc8541cds/init.S | 0
> board/{cds => freescale}/mpc8541cds/mpc8541cds.c | 0
> board/{cds => freescale}/mpc8541cds/u-boot.lds | 4 ++--
> board/{cds => freescale}/mpc8548cds/Makefile | 0
> board/{cds => freescale}/mpc8548cds/config.mk | 0
> board/{cds => freescale}/mpc8548cds/init.S | 0
> board/{cds => freescale}/mpc8548cds/mpc8548cds.c | 0
> board/{cds => freescale}/mpc8548cds/u-boot.lds | 4 ++--
> board/{cds => freescale}/mpc8555cds/Makefile | 0
> board/{cds => freescale}/mpc8555cds/config.mk | 0
> board/{cds => freescale}/mpc8555cds/init.S | 0
> board/{cds => freescale}/mpc8555cds/mpc8555cds.c | 0
> board/{cds => freescale}/mpc8555cds/u-boot.lds | 4 ++--
> 23 files changed, 9 insertions(+), 9 deletions(-)
>
> and here it is before:
>
> Makefile | 6 +-
> board/cds/mpc8548cds/Makefile | 60 -----
> board/cds/mpc8555cds/Makefile | 60 -----
> board/cds/mpc8555cds/init.S | 255
> --------------------
> board/cds/mpc8555cds/u-boot.lds | 150
> ------------
> board/{cds => freescale}/common/cadmus.c | 0
> board/{cds => freescale}/common/cadmus.h | 0
> board/{cds => freescale}/common/eeprom.c | 0
> board/{cds => freescale}/common/eeprom.h | 0
> board/{cds => freescale}/common/ft_board.c | 0
> board/{cds => freescale}/common/via.c | 0
> board/{cds => freescale}/common/via.h | 0
> board/{cds => freescale}/mpc8541cds/Makefile | 0
> board/{cds => freescale}/mpc8541cds/config.mk | 0
> board/{cds => freescale}/mpc8541cds/init.S | 0
> board/{cds => freescale}/mpc8541cds/mpc8541cds.c | 0
> board/{cds => freescale}/mpc8541cds/u-boot.lds | 4 +-
> .../mpc8541cds => freescale/mpc8548cds}/Makefile | 0
> board/{cds => freescale}/mpc8548cds/config.mk | 0
> board/{cds => freescale}/mpc8548cds/init.S | 0
> board/{cds => freescale}/mpc8548cds/mpc8548cds.c | 0
> board/{cds => freescale}/mpc8548cds/u-boot.lds | 4 +-
> .../mpc8541cds => freescale/mpc8555cds}/Makefile | 0
> board/{cds => freescale}/mpc8555cds/config.mk | 0
> .../mpc8541cds => freescale/mpc8555cds}/init.S | 0
> board/{cds => freescale}/mpc8555cds/mpc8555cds.c | 0
> .../mpc8541cds => freescale/mpc8555cds}/u-boot.lds | 4 +-
> 27 files changed, 9 insertions(+), 534 deletions(-)
>
> so it certainly makes the diffs prettier.
Much better. I love with open source development works.
- k
^ permalink raw reply
* Re: [PATCH] Move all dashed form git commands to libexecdir
From: Jeff King @ 2007-11-30 1:17 UTC (permalink / raw)
To: Nicolas Pitre
Cc: Junio C Hamano, Linus Torvalds, Johannes Schindelin,
Nguyen Thai Ngoc Duy, Jan Hudec, git
In-Reply-To: <alpine.LFD.0.99999.0711292004340.9605@xanadu.home>
On Thu, Nov 29, 2007 at 08:13:04PM -0500, Nicolas Pitre wrote:
> > My point is that (2) is already implemented for every program (shell or
> > no) which understands filename completion, and there is a proposal for
> > taking it away. I would consider that, except I haven't see any claimed
> > advantages except that the hardlinks are awful under Windows.
>
> Weren't enough complaints about Git having waaaaaaaaaaay too many
> commands? Didn't those complaints come about often enough already?
>
> $ git-[tab]
> Display all 135 possibilities? (y or n)
Go back and read the thread to which you are responding. I am _not_
arguing against moving those commands to $(libexecdir) where no sane
user will ever see them. That change addresses the issue you are talking
about.
I _am_ arguing against removing them entirely, for those of us who want
to go to the trouble of enabling this (by putting a non-standard entry
into our PATH). Because the issue you are talking about will already
have been dealt with, it is no longer a compelling reason to remove the
hardlinks entirely.
The only reason I have heard to remove them entirely is that Windows
doesn't properly support hardlinks, which I addressed in my other mails
(and to which I have seen no rebuttal).
-Peff
^ permalink raw reply
* Re: [PATCH] Move all dashed form git commands to libexecdir
From: Nicolas Pitre @ 2007-11-30 1:13 UTC (permalink / raw)
To: Jeff King
Cc: Junio C Hamano, Linus Torvalds, Johannes Schindelin,
Nguyen Thai Ngoc Duy, Jan Hudec, git
In-Reply-To: <20071130005852.GA12224@coredump.intra.peff.net>
On Thu, 29 Nov 2007, Jeff King wrote:
> On Thu, Nov 29, 2007 at 04:49:26PM -0800, Junio C Hamano wrote:
>
> > I understand your point was primarily "git-a<tab>". I think it has been
> > solved for bash and zsh but not for other shells. I think possible and
> > sensible avenues are (1) punt -- cvs, svn nor hg people do not seem to
> > have problem with it, or (2) implement completion in your other favorite
> > shells.
>
> My point is that (2) is already implemented for every program (shell or
> no) which understands filename completion, and there is a proposal for
> taking it away. I would consider that, except I haven't see any claimed
> advantages except that the hardlinks are awful under Windows.
Weren't enough complaints about Git having waaaaaaaaaaay too many
commands? Didn't those complaints come about often enough already?
$ git-[tab]
Display all 135 possibilities? (y or n)
Nicolas
^ permalink raw reply
* Re: [RFC] use typechange as rename source
From: Junio C Hamano @ 2007-11-30 1:10 UTC (permalink / raw)
To: Jeff King; +Cc: git
In-Reply-To: <20071129141452.GA32670@coredump.intra.peff.net>
Jeff King <peff@peff.net> writes:
> OK. What next? Did the patch I sent make sense? Do you want a cleaned up
> version with a commit message and signoff, or does it need work?
It just hit me that breaking (as in diffcore-break) a filepair that is a
typechange may yield the same result, and if it works, that would be
conceptually cleaner. After all, a typechange is the ultimate form of
total rewriting (the similarity between the preimage and the postimage
is very low -- even their types are different, let alone contents).
Compared to that, the rename_used++ in that codepath you touched feels
more magic to me.
^ permalink raw reply
* Re: [PATCH v3] Allow update hooks to update refs on their own
From: Junio C Hamano @ 2007-11-30 1:06 UTC (permalink / raw)
To: Steven Grimm; +Cc: Jeff King, git
In-Reply-To: <35C5BEA0-0D6C-4D2E-85E7-1B78FB0BEADA@midwinter.com>
Steven Grimm <koreth@midwinter.com> writes:
> If any one of #1-5 wasn't true or was solvable in a different way,
> then #6 wouldn't be needed. For example, if git-svn kept its mapping
> of git revisions to svn revisions somewhere else it could leave the
> commit messages untouched, meaning the SHA1s wouldn't change.
That does sound like an unfortunate design problem with how git-svn
keeps track of the correlation between two systems.
But after thinking about this issue a bit more, I think I agree that
allowing to munge what was pushed inside update hook may make sense even
outside of git-svn context (iow, if this were an ugly workaround for
git-svn deficiency then I would be unhappy but I think there are valid
use cases). "You push A, I inspect it and may rewrite it to A' but only
if A' is reasonable -- otherwise I reject your pushing of A" could be a
valid thing to do in other contexts. A stupid example would be an update
hook that tries to cleanse what you pushed for whitespace breakage and
commit a cleaned-up result only if the result passes the testsuite.
^ permalink raw reply
* Re: [PATCH] Move all dashed form git commands to libexecdir
From: Nicolas Pitre @ 2007-11-30 1:01 UTC (permalink / raw)
To: A Large Angry SCM
Cc: Junio C Hamano, Linus Torvalds, Jeff King, Johannes Schindelin,
Nguyen Thai Ngoc Duy, Jan Hudec, git
In-Reply-To: <474F5E90.9040505@gmail.com>
On Thu, 29 Nov 2007, A Large Angry SCM wrote:
> Again, there needs to remain support in the Makefile to install the "dashed"
> versions of the commands for those that want it; and be able to set
> gitexecdir=$(binder) without editing the Makefile.
Well, if you want a "non standard" installation, maybe you just can edit
a line or two in the Makefile?
Nicolas
^ permalink raw reply
* Re: [PATCH] Move all dashed form git commands to libexecdir
From: Jeff King @ 2007-11-30 1:00 UTC (permalink / raw)
To: Nicolas Pitre
Cc: Junio C Hamano, Linus Torvalds, Johannes Schindelin,
Nguyen Thai Ngoc Duy, Jan Hudec, git
In-Reply-To: <alpine.LFD.0.99999.0711291950590.9605@xanadu.home>
On Thu, Nov 29, 2007 at 07:52:01PM -0500, Nicolas Pitre wrote:
> > I am still against this step, for the reasons mentioned in the mails
> > leading up to the one you just quoted. I am fine with "does not install
> > hardlinks for builtin-commands on systems that don't support hardlinks"
> > (and of course all such hardlinks are in $(libexecdir)/git-core at this
> > point).
>
> But only for porcelain, right? You certainly don't need the dashed form
> of plumbing commands?
In principle, yes, though one man's porcelain is another man's plumbing,
so determining the correct set is hard (and why bother if they are all
hidden from mere mortals, anyway?).
Perhaps because I am actively working on git, I tend to use a fair
number of plumbing commands for under-the-hood inspection and
experimentation.
-Peff
^ permalink raw reply
* Re: Some git performance measurements..
From: Jakub Narebski @ 2007-11-30 0:54 UTC (permalink / raw)
To: git
In-Reply-To: <alpine.LFD.0.99999.0711291208060.9605@xanadu.home>
<opublikowany i wysłany>
[Cc: git@vger.kernel.org, Nicolas Pitre <nico@cam.org>,
Linus Torvalds <torvalds@linux-foundation.org>]
Nicolas Pitre wrote:
> Well, see below for the patch that actually split the pack data into
> objects of the same type. Doing that "git checkout" on the kernel tree
> did improve things for me although not spectacularly.
> +static int sort_by_type(const void *_a, const void *_b)
> +{
> + const struct object_entry *a = *(struct object_entry **)_a;
> + const struct object_entry *b = *(struct object_entry **)_b;
> +
> + /*
> + * Preserve recency order for objects of the same type and reused deltas.
> + */
> + if(a->type == OBJ_REF_DELTA || a->type == OBJ_OFS_DELTA ||
> + b->type == OBJ_REF_DELTA || b->type == OBJ_OFS_DELTA ||
> + a->type == b->type)
> + return (a < b) ? -1 : 1;
> + return a->type - b->type;
> +}
> + qsort(sorted_by_type, nr_objects, sizeof(*sorted_by_type), sort_by_type);
Isn't there a better way to do this sorting? What is needed here is
(stable) _bucket_ sort / _pigeonhole_ sort (or counting sort), which
is O(n); quicksort is perhaps simpler to use, but I'm not sure if
faster in this situation.
--
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git
^ permalink raw reply
* Re: [PATCH] Move all dashed form git commands to libexecdir
From: Jeff King @ 2007-11-30 0:58 UTC (permalink / raw)
To: Junio C Hamano
Cc: Linus Torvalds, Johannes Schindelin, Nguyen Thai Ngoc Duy,
Jan Hudec, git
In-Reply-To: <7vzlwwsgkp.fsf@gitster.siamese.dyndns.org>
On Thu, Nov 29, 2007 at 04:49:26PM -0800, Junio C Hamano wrote:
> I understand your point was primarily "git-a<tab>". I think it has been
> solved for bash and zsh but not for other shells. I think possible and
> sensible avenues are (1) punt -- cvs, svn nor hg people do not seem to
> have problem with it, or (2) implement completion in your other favorite
> shells.
My point is that (2) is already implemented for every program (shell or
no) which understands filename completion, and there is a proposal for
taking it away. I would consider that, except I haven't see any claimed
advantages except that the hardlinks are awful under Windows.
I am proposing to have those dashed forms on platforms where it makes
sense, but to treat them as second-class citizens (by putting them in
$(libexecdir), which will address consistency problems.
> And I think the following from Linus makes sense.
>
> > And from a consistency standpoint, that would be a *good* thing. There are
> > many reasons why the git-xyz format *cannot* be the "consistent" form
> > (ranging from the flags like --bare and -p to just aliases), so
> > encouraging people to move to "git xyz" is just a good idea.
> >
> > Yeah, yeah, the man-pages need the "git-xyz" form, but on the other hand,
> > rather than "man git-xyz", you can just do "git help xyz" instead, and now
> > you're consistently avoiding the dash again!
>
> but I am feeling quite feverish today so I may be missing something
> obvious.
I thought Linus' point was that moving the subcommands was sufficient
for dealing with the consistency issue (i.e., all scripts would move to
"git foo" and only those people who really wanted to would put the
dashed forms in their path). From the same email you quoted, but just
above:
> On Thu, 29 Nov 2007, Jeff King wrote:
> >
> > Yes, I am fine with the user having to go to extra lengths to use the
> > dash forms (like adding $(libexecdir) to their path), which I think
> > should address your consistency concern.
>
> I agree. If we actually start moving the subcommands into a separate
> directory, I suspect scripts will be fixed up soon enough. Of course
> people *can* do it by just adding the path, but more likely, we'll just
> see people start doign "git xyz" instead of "git-xyz".
But now we are arguing about what Linus meant like it is scripture. ;)
-Peff
^ permalink raw reply
* Re: [PATCH] Move all dashed form git commands to libexecdir
From: Johannes Schindelin @ 2007-11-30 0:54 UTC (permalink / raw)
To: A Large Angry SCM
Cc: Junio C Hamano, Linus Torvalds, Jeff King, Nguyen Thai Ngoc Duy,
Jan Hudec, git
In-Reply-To: <474F5E90.9040505@gmail.com>
Hi,
On Thu, 29 Nov 2007, A Large Angry SCM wrote:
> Junio C Hamano wrote:
> [...]
> > Ok. So here is a revised roadmap that a panda brain (that is not so
> > well working today due to fever) came up.
> >
> > - v1.5.4 will ship with gitexecdir=$(bindir) in Makefile. But the
> > release notes for the version will warn users that:
> >
> > (1) using git-foo from the command line, and
> >
> > (2) using git-foo from your scripts without first prepending the
> > return value of "git --exec-path" to the PATH
> >
> > is now officially deprecated (it has been deprecated for a long time
> > since January 2006, v1.2.0~149) and upcoming v1.5.5 will ship with
> > the default configuration that does not install git-foo form in
> > user's PATH.
> >
> > If further will warn users that git-foo form will be removed in
> > v1.5.6 for many commands and it will be merely an accident if some of
> > them still work after that.
> >
> > - Post v1.5.4, start cooking gitexecdir=$(libexecdir)/git-core, aiming
> > for inclusion in v1.5.5, perhaps in Feb-Mar 2008 timeframe. This
> > will also affect the sample RPM spec and resulting RPM binary
> > packages I will place on k.org, and I'll ask Gerrit to do the same on
> > Debian side. The official binary packaging of individual distros are
> > not under my control, but if there is a handy list of people I can
> > send this notice to for other distros, that would help this process.
> >
> > - The release notes for v1.5.5 will warn users again that git-foo will
> > be removed in v1.5.6 for many commands and it will be merely an
> > accident if some of them still work.
> >
> > - Post v1.5.5, start cooking the change that does not install hardlinks
> > for built-in commands, aiming for inclusion in v1.5.6, in May-Jun
> > 2008 timeframe.
>
> Again, there needs to remain support in the Makefile to install the "dashed"
> versions of the commands for those that want it; and be able to set
> gitexecdir=$(binder) without editing the Makefile.
Umm. Why? If there is no compelling reason (and you named none, but
there were quite a few reasons against it), why should the Makefile
support the dash form after 1.5.6?
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH] Move all dashed form git commands to libexecdir
From: Nicolas Pitre @ 2007-11-30 0:52 UTC (permalink / raw)
To: Jeff King
Cc: Junio C Hamano, Linus Torvalds, Johannes Schindelin,
Nguyen Thai Ngoc Duy, Jan Hudec, git
In-Reply-To: <20071130003512.GB11683@coredump.intra.peff.net>
On Thu, 29 Nov 2007, Jeff King wrote:
> On Thu, Nov 29, 2007 at 04:13:29PM -0800, Junio C Hamano wrote:
>
> > - Post v1.5.5, start cooking the change that does not install hardlinks
> > for built-in commands, aiming for inclusion in v1.5.6, in May-Jun
> > 2008 timeframe.
>
> I am still against this step, for the reasons mentioned in the mails
> leading up to the one you just quoted. I am fine with "does not install
> hardlinks for builtin-commands on systems that don't support hardlinks"
> (and of course all such hardlinks are in $(libexecdir)/git-core at this
> point).
But only for porcelain, right? You certainly don't need the dashed form
of plumbing commands?
Nicolas
^ permalink raw reply
* Re: [PATCH] Move all dashed form git commands to libexecdir
From: A Large Angry SCM @ 2007-11-30 0:51 UTC (permalink / raw)
To: Junio C Hamano
Cc: Linus Torvalds, Jeff King, Johannes Schindelin,
Nguyen Thai Ngoc Duy, Jan Hudec, git
In-Reply-To: <7veje8twt2.fsf@gitster.siamese.dyndns.org>
Junio C Hamano wrote:
[...]
> Ok. So here is a revised roadmap that a panda brain (that is not so
> well working today due to fever) came up.
>
> - v1.5.4 will ship with gitexecdir=$(bindir) in Makefile. But the
> release notes for the version will warn users that:
>
> (1) using git-foo from the command line, and
>
> (2) using git-foo from your scripts without first prepending the
> return value of "git --exec-path" to the PATH
>
> is now officially deprecated (it has been deprecated for a long time
> since January 2006, v1.2.0~149) and upcoming v1.5.5 will ship with
> the default configuration that does not install git-foo form in
> user's PATH.
>
> If further will warn users that git-foo form will be removed in
> v1.5.6 for many commands and it will be merely an accident if some of
> them still work after that.
>
> - Post v1.5.4, start cooking gitexecdir=$(libexecdir)/git-core, aiming
> for inclusion in v1.5.5, perhaps in Feb-Mar 2008 timeframe. This
> will also affect the sample RPM spec and resulting RPM binary
> packages I will place on k.org, and I'll ask Gerrit to do the same on
> Debian side. The official binary packaging of individual distros are
> not under my control, but if there is a handy list of people I can
> send this notice to for other distros, that would help this process.
>
> - The release notes for v1.5.5 will warn users again that git-foo will
> be removed in v1.5.6 for many commands and it will be merely an
> accident if some of them still work.
>
> - Post v1.5.5, start cooking the change that does not install hardlinks
> for built-in commands, aiming for inclusion in v1.5.6, in May-Jun
> 2008 timeframe.
Again, there needs to remain support in the Makefile to install the
"dashed" versions of the commands for those that want it; and be able to
set gitexecdir=$(binder) without editing the Makefile.
^ permalink raw reply
* Re: [PATCH] Move all dashed form git commands to libexecdir
From: Junio C Hamano @ 2007-11-30 0:49 UTC (permalink / raw)
To: Jeff King
Cc: Linus Torvalds, Johannes Schindelin, Nguyen Thai Ngoc Duy,
Jan Hudec, git
In-Reply-To: <20071130003512.GB11683@coredump.intra.peff.net>
Jeff King <peff@peff.net> writes:
> On Thu, Nov 29, 2007 at 04:13:29PM -0800, Junio C Hamano wrote:
>
>> - Post v1.5.5, start cooking the change that does not install hardlinks
>> for built-in commands, aiming for inclusion in v1.5.6, in May-Jun
>> 2008 timeframe.
>
> I am still against this step, for the reasons mentioned in the mails
> leading up to the one you just quoted. I am fine with "does not install
> hardlinks for builtin-commands on systems that don't support hardlinks"
> (and of course all such hardlinks are in $(libexecdir)/git-core at this
> point).
I understand your point was primarily "git-a<tab>". I think it has been
solved for bash and zsh but not for other shells. I think possible and
sensible avenues are (1) punt -- cvs, svn nor hg people do not seem to
have problem with it, or (2) implement completion in your other favorite
shells.
And I think the following from Linus makes sense.
> And from a consistency standpoint, that would be a *good* thing. There are
> many reasons why the git-xyz format *cannot* be the "consistent" form
> (ranging from the flags like --bare and -p to just aliases), so
> encouraging people to move to "git xyz" is just a good idea.
>
> Yeah, yeah, the man-pages need the "git-xyz" form, but on the other hand,
> rather than "man git-xyz", you can just do "git help xyz" instead, and now
> you're consistently avoiding the dash again!
but I am feeling quite feverish today so I may be missing something
obvious.
^ permalink raw reply
* Re: Fix a pathological case in git detecting proper renames
From: Jeff King @ 2007-11-30 0:48 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Kumar Gala, Junio C Hamano, Git Mailing List
In-Reply-To: <alpine.LFD.0.9999.0711291625580.8458@woody.linux-foundation.org>
On Thu, Nov 29, 2007 at 04:41:09PM -0800, Linus Torvalds wrote:
> It's not pretty, it's not smart, but it seems to work. There's something
> to be said for keeping it simple and stupid.
>
> And it should not be nearly as expensive as it may _look_. Yes, the loop
> is "(i = 0; i < num_create * num_src; i++)", but the important part is
> that the whole array is sorted by rename score, and we have a
>
> if (mx[i].score < minimum_score)
> break;
>
> in it, so uthe loop actually would tend to terminate rather quickly.
I think the slowdown is a non-issue. From the benchmarking I did in the
past, all of the time was spent _before_ even getting to the qsort of
scores. So even if you doubled the expense of that loop, it would have a
negligible impact.
But I haven't actually benchmarked this new patch, of course.
-Peff
^ permalink raw reply
* Re: Fix a pathological case in git detecting proper renames
From: Linus Torvalds @ 2007-11-30 0:41 UTC (permalink / raw)
To: Jeff King; +Cc: Kumar Gala, Junio C Hamano, Git Mailing List
In-Reply-To: <20071129235253.GA10261@coredump.intra.peff.net>
On Thu, 29 Nov 2007, Jeff King wrote:
>
> I think it will get worse, because you are simultaneously calculating
> all of the similarity scores bit by bit rather than doing a loop. Though
> perhaps you mean at the end you will end up with a list of src/dst pairs
> sorted by score, and you can loop over that.
Well, after thinking about this a bit, I think there's a solution that may
work well with the current thing too: instead of looping just *once* over
the list of rename pairs, loop twice - and simply refuse to do copies on
the first loop.
This trivial patch does that, and turns Kumar's test-case into a perfect
rename list.
It's not pretty, it's not smart, but it seems to work. There's something
to be said for keeping it simple and stupid.
And it should not be nearly as expensive as it may _look_. Yes, the loop
is "(i = 0; i < num_create * num_src; i++)", but the important part is
that the whole array is sorted by rename score, and we have a
if (mx[i].score < minimum_score)
break;
in it, so uthe loop actually would tend to terminate rather quickly.
Anyway, Kumar, the thing to take away from this is:
- git really doesn't even *care* about the whole "rename detection"
internally, and any commits you have done with renames are totally
independent of the heuristics we then use to *show* the renames.
- the rename detection really is for just two reasons: (a) keep humans
happy, and keep the diffs small and (b) help automatic merging across
renames. So getting renames right is certainly good, but it's more of a
"politeness" issue than a "correctness" issue, although the merge
portion of it does matter a lot sometimes.
- the important thing here is that you can commit your changes and not
worry about them being somehow "corrupted" by lack of rename detection,
even if you commit them with a version of git that doesn't do rename
detection the way you expected it. The rename detection is an
"after-the-fact" thing, not something that actually gets saved in the
repository, which is why we can change the heuristics _after_ seeing
examples, and the examples magically correct themselves!
- try out the two patches I've posted, and see if they work for you. They
pass the test-suite, and the output for your example commit looks sane,
but hey, if you have other test-cases, try them out.
Here's Kumar's pretty diffstat with both my patches:
Makefile | 6 +++---
board/{cds => freescale}/common/cadmus.c | 0
board/{cds => freescale}/common/cadmus.h | 0
board/{cds => freescale}/common/eeprom.c | 0
board/{cds => freescale}/common/eeprom.h | 0
board/{cds => freescale}/common/ft_board.c | 0
board/{cds => freescale}/common/via.c | 0
board/{cds => freescale}/common/via.h | 0
board/{cds => freescale}/mpc8541cds/Makefile | 0
board/{cds => freescale}/mpc8541cds/config.mk | 0
board/{cds => freescale}/mpc8541cds/init.S | 0
board/{cds => freescale}/mpc8541cds/mpc8541cds.c | 0
board/{cds => freescale}/mpc8541cds/u-boot.lds | 4 ++--
board/{cds => freescale}/mpc8548cds/Makefile | 0
board/{cds => freescale}/mpc8548cds/config.mk | 0
board/{cds => freescale}/mpc8548cds/init.S | 0
board/{cds => freescale}/mpc8548cds/mpc8548cds.c | 0
board/{cds => freescale}/mpc8548cds/u-boot.lds | 4 ++--
board/{cds => freescale}/mpc8555cds/Makefile | 0
board/{cds => freescale}/mpc8555cds/config.mk | 0
board/{cds => freescale}/mpc8555cds/init.S | 0
board/{cds => freescale}/mpc8555cds/mpc8555cds.c | 0
board/{cds => freescale}/mpc8555cds/u-boot.lds | 4 ++--
23 files changed, 9 insertions(+), 9 deletions(-)
and here it is before:
Makefile | 6 +-
board/cds/mpc8548cds/Makefile | 60 -----
board/cds/mpc8555cds/Makefile | 60 -----
board/cds/mpc8555cds/init.S | 255 --------------------
board/cds/mpc8555cds/u-boot.lds | 150 ------------
board/{cds => freescale}/common/cadmus.c | 0
board/{cds => freescale}/common/cadmus.h | 0
board/{cds => freescale}/common/eeprom.c | 0
board/{cds => freescale}/common/eeprom.h | 0
board/{cds => freescale}/common/ft_board.c | 0
board/{cds => freescale}/common/via.c | 0
board/{cds => freescale}/common/via.h | 0
board/{cds => freescale}/mpc8541cds/Makefile | 0
board/{cds => freescale}/mpc8541cds/config.mk | 0
board/{cds => freescale}/mpc8541cds/init.S | 0
board/{cds => freescale}/mpc8541cds/mpc8541cds.c | 0
board/{cds => freescale}/mpc8541cds/u-boot.lds | 4 +-
.../mpc8541cds => freescale/mpc8548cds}/Makefile | 0
board/{cds => freescale}/mpc8548cds/config.mk | 0
board/{cds => freescale}/mpc8548cds/init.S | 0
board/{cds => freescale}/mpc8548cds/mpc8548cds.c | 0
board/{cds => freescale}/mpc8548cds/u-boot.lds | 4 +-
.../mpc8541cds => freescale/mpc8555cds}/Makefile | 0
board/{cds => freescale}/mpc8555cds/config.mk | 0
.../mpc8541cds => freescale/mpc8555cds}/init.S | 0
board/{cds => freescale}/mpc8555cds/mpc8555cds.c | 0
.../mpc8541cds => freescale/mpc8555cds}/u-boot.lds | 4 +-
27 files changed, 9 insertions(+), 534 deletions(-)
so it certainly makes the diffs prettier.
Linus
---
diffcore-rename.c | 13 +++++++++++++
1 files changed, 13 insertions(+), 0 deletions(-)
diff --git a/diffcore-rename.c b/diffcore-rename.c
index f64294e..3d37725 100644
--- a/diffcore-rename.c
+++ b/diffcore-rename.c
@@ -497,6 +497,19 @@ void diffcore_rename(struct diff_options *options)
qsort(mx, num_create * num_src, sizeof(*mx), score_compare);
for (i = 0; i < num_create * num_src; i++) {
struct diff_rename_dst *dst = &rename_dst[mx[i].dst];
+ struct diff_filespec *src;
+ if (dst->pair)
+ continue; /* already done, either exact or fuzzy. */
+ if (mx[i].score < minimum_score)
+ break; /* there is no more usable pair. */
+ src = rename_src[mx[i].src].one;
+ if (src->rename_used)
+ continue;
+ record_rename_pair(mx[i].dst, mx[i].src, mx[i].score);
+ rename_count++;
+ }
+ for (i = 0; i < num_create * num_src; i++) {
+ struct diff_rename_dst *dst = &rename_dst[mx[i].dst];
if (dst->pair)
continue; /* already done, either exact or fuzzy. */
if (mx[i].score < minimum_score)
^ permalink raw reply related
* Re: [PATCH] Move all dashed form git commands to libexecdir
From: Nguyen Thai Ngoc Duy @ 2007-11-30 0:40 UTC (permalink / raw)
To: Junio C Hamano
Cc: Linus Torvalds, Jeff King, Johannes Schindelin, Jan Hudec, git
In-Reply-To: <7veje8twt2.fsf@gitster.siamese.dyndns.org>
On Nov 30, 2007 7:13 AM, Junio C Hamano <gitster@pobox.com> wrote:
> - Post v1.5.4, start cooking gitexecdir=$(libexecdir)/git-core, aiming
> for inclusion in v1.5.5, perhaps in Feb-Mar 2008 timeframe. This
> will also affect the sample RPM spec and resulting RPM binary
> packages I will place on k.org, and I'll ask Gerrit to do the same on
> Debian side. The official binary packaging of individual distros are
> not under my control, but if there is a handy list of people I can
> send this notice to for other distros, that would help this process.
You can find Gentoo maintainers here:
http://sources.gentoo.org/viewcvs.py/gentoo-x86/dev-util/git/metadata.xml?rev=1.6&view=markup
--
Duy
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox