* Re: [PATCH] index-pack: correctly initialize appended objects
From: Johannes Schindelin @ 2008-07-26 3:04 UTC (permalink / raw)
To: Björn Steinbrink; +Cc: Junio C Hamano, Nicolas Pitre, spearce, git
In-Reply-To: <20080725171315.GA27285@atjola.homenet>
[-- Attachment #1: Type: TEXT/PLAIN, Size: 213 bytes --]
Hi,
On Fri, 25 Jul 2008, Björn Steinbrink wrote:
> + // This object comes from outside the thin pack, so we need to
> + // initialize the size and type fields
Do not use C++ comments in Git. Ever.
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH 1/2] Move launch_editor() from builtin-tag.c to editor.c
From: Johannes Schindelin @ 2008-07-26 3:00 UTC (permalink / raw)
To: Stephan Beyer; +Cc: git, Junio C Hamano
In-Reply-To: <1217003322-10291-1-git-send-email-s-beyer@gmx.net>
Hi,
On Fri, 25 Jul 2008, Stephan Beyer wrote:
> To be kind to the maintainer, I've also run the test suite again, all
> tests passed except t4116*.sh, but this is not my fault. It's the fault
> of 9a885fac.
You do understand that you cost everybody, who actually cared to take a
look for herself, a few minutes?
Just to see that the change you referenced (but did not describe at all)
is "tar -> $TAR".
And now, everybody who cared will be just puzzled. In the best case, he
will reply to you that your hint left to be wished for. I do not have to
describe the worst case, do I?
Ciao,
Dscho "who thinks that so many mails would be better if the posters would
read the mails themselves and try to imagine how readers would perceive
them"
^ permalink raw reply
* Re: git-scm.com
From: Stephan Beyer @ 2008-07-26 2:54 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Scott Chacon, git
In-Reply-To: <alpine.DEB.1.00.0807260422250.11976@eeepc-johanness>
Johannes Schindelin wrote:
> I do not like the implication that Git eats trees.
Eridius said on IRC:
"it's a Git", "he's a Blob that's Committed to storing Trees"
I still like the picture, though it can hurt environmentalists.
Regards,
Stephan
--
Stephan Beyer <s-beyer@gmx.net>, PGP 0x6EDDD207FCC5040F
^ permalink raw reply
* Re: [PATCH] Avoid warning when From: is encoded
From: Johannes Schindelin @ 2008-07-26 2:53 UTC (permalink / raw)
To: Jon Loeliger; +Cc: sverre, Abhijit Menon-Sen, Peter Valdemar Mørch, git
In-Reply-To: <488A01B8.2010405@freescale.com>
Hi,
On Fri, 25 Jul 2008, Jon Loeliger wrote:
> Sverre Rabbelier wrote:
>
> > Acked-by is reserved for people who are "owners" of the area the patch
> > touches.
>
> I love pronouncements like this. While that may be exactly true
> for the Git project, it is not, in general, always true.
It may not be true in general, but from what I heard of the Kernel
community, even there it is considered rude if you just step in and say
ACK, when you clearly have no idea what you are talking about (which is
normally determined by your being involved in that area).
So you can love (or not) pronouncements like that, but the fact still
stands true: how can your ACK be of any value (or for that matter, how can
your ACK be taken seriously) when you haven't proven -- in code! -- that
you understand the code?
Hthab,
Dscho
^ permalink raw reply
* Re: how about removing --exec-path?
From: Johannes Schindelin @ 2008-07-26 2:49 UTC (permalink / raw)
To: Alex Riesen; +Cc: git
In-Reply-To: <20080725094015.GA22077@blimp.local>
Hi,
On Fri, 25 Jul 2008, Alex Riesen wrote:
> The thing has at least this problem: is not passed to upload-pack when
> running fetch.
It should be added to PATH, and so it is passed to upload-pack, amongst
others, in a sense.
Ciao,
Dscho
^ permalink raw reply
* Re: git-scm.com
From: david @ 2008-07-26 2:47 UTC (permalink / raw)
To: Petr Baudis; +Cc: Scott Chacon, Patrick Aljord, git list
In-Reply-To: <20080726023707.GX32184@machine.or.cz>
On Sat, 26 Jul 2008, Petr Baudis wrote:
> Hi,
>
> On Fri, Jul 25, 2008 at 07:28:32PM -0700, Scott Chacon wrote:
>> I am more concerned about the logo at the bottom, and Petr and I are
>> discussing this - I can remove the logo, but then I'd have to pay for
>> this out of my pocket instead of having a small logo on the page.
>
> I actually think that this is *one* reference to GitHub that is
> perfectly and 100% okay; if it is sponsoring the hosting, it deserves
> the logo, and it is fairly non-intrusive. I _am_ watching out warily
> for excessive GitHub references within the rest of the site - if only
> because I have kind of personal interest in a competitor of GitHub and
> thus don't want GitHub to get unwarranted free advertising. :-)
>
> Petr "Pasky" Baudis
since this is a Ruby on Rails site, could the 'five links' that have been
bothering people be randomly selected? if every time you go to the site
you get a different list of projects it show how broadly git is used. it's
not as 'in your face' as managing to select five that cause people to say
"wow, they're using this", but different people will react to different
sites.
if this table gets populated by GitHub, kernel.org, and a couple other
sources it should be vendor independant enough (and we need a table like
this anyway for the 'list of projects that use git', so it serves two
purposes)
David Lang
^ permalink raw reply
* Re: git-scm.com
From: Johannes Schindelin @ 2008-07-26 2:45 UTC (permalink / raw)
To: Scott Chacon; +Cc: Patrick Aljord, git list
In-Reply-To: <d411cc4a0807251928g75744b78vac2ce77bf07fbd81@mail.gmail.com>
Hi,
On Fri, 25 Jul 2008, Scott Chacon wrote:
> 5 links in the middle?
What 5 links in the middle?
*scrolls down*
Ah, the top-posting syndrome.
Old quote, but more valid than ever:
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet and in e-mail?
I find it almost comical that people do not realize how unnaturally they
behave, and how hard they make it on their recipients, when they top-post.
Oh, and usually, I take top-posting as a clear sign that the poster is not
worth replying to. Take this mail as a sign that I take care of what you
said, _in spite of_ your top-posting.
Ciao,
Dscho
^ permalink raw reply
* Re: git-scm.com
From: Petr Baudis @ 2008-07-26 2:37 UTC (permalink / raw)
To: Scott Chacon; +Cc: Patrick Aljord, git list
In-Reply-To: <d411cc4a0807251928g75744b78vac2ce77bf07fbd81@mail.gmail.com>
Hi,
On Fri, Jul 25, 2008 at 07:28:32PM -0700, Scott Chacon wrote:
> I am more concerned about the logo at the bottom, and Petr and I are
> discussing this - I can remove the logo, but then I'd have to pay for
> this out of my pocket instead of having a small logo on the page.
I actually think that this is *one* reference to GitHub that is
perfectly and 100% okay; if it is sponsoring the hosting, it deserves
the logo, and it is fairly non-intrusive. I _am_ watching out warily
for excessive GitHub references within the rest of the site - if only
because I have kind of personal interest in a competitor of GitHub and
thus don't want GitHub to get unwarranted free advertising. :-)
Petr "Pasky" Baudis
^ permalink raw reply
* Re: [RFC] custom strategies in builtin-merge
From: Johannes Schindelin @ 2008-07-26 2:37 UTC (permalink / raw)
To: Junio C Hamano; +Cc: sverre, Miklos Vajna, git
In-Reply-To: <7vvdyto3da.fsf@gitster.siamese.dyndns.org>
Hi,
On Fri, 25 Jul 2008, Junio C Hamano wrote:
> Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
>
> > ... especially since I hope that we have them builtin soon, and not
> > only that, but have builtin-merge call them as C functions, not with
> > fork() and exec().
>
> Because builtin-merge.c does not directly use fork/exec but uses
> run_command() interface, non POSIX platforms can spawn subprocesses just
> fine, can't they?
Yes, they can. Slowly, but they do.
But why should they? Efficient merging is such a prominent feature of
Git; I do not agree to let it remain a second-class feature.
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH] git-reset: Let -q hush "locally modified" messages
From: Johannes Schindelin @ 2008-07-26 2:34 UTC (permalink / raw)
To: Stephan Beyer; +Cc: Junio C Hamano, Carlos Rica, git
In-Reply-To: <20080725213853.GD13539@leksak.fem-net>
Hi,
On Fri, 25 Jul 2008, Stephan Beyer wrote:
> Junio C Hamano wrote:
> > Stephan Beyer <s-beyer@gmx.net> writes:
> >
> > > git reset -q makes reset more quiet, but "locally modified" messages
> > > are still shown. This patch makes them disappear, too.
> >
> > Files being "locally modified" is not and error, so I think it is in
> > line with the spirit of what -q is meant to do.
> >
> > It is an interface change, though.
>
> Yes, as "needs update" -> "locally modified" was.
But that is not about scripts. Scripts have no business calling pure
porcelain, so they still get "needs update" if done properly.
Hth,
Dscho
^ permalink raw reply
* Re: git-scm.com
From: Petr Baudis @ 2008-07-26 2:33 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Scott Chacon, git
In-Reply-To: <alpine.DEB.1.00.0807260422250.11976@eeepc-johanness>
Hi,
On Sat, Jul 26, 2008 at 04:25:16AM +0200, Johannes Schindelin wrote:
> On Fri, 25 Jul 2008, Scott Chacon wrote:
>
> > A followup on the post I did a few days ago about Git documentation.
> > I forked Petr's git.or.cz site and put up a version that I think is a
> > bit more accessible and newbie-friendly at git-scm.com.
>
> I do not like the implication that Git eats trees.
yes, I keep wondering about the logo as well. On one side it is rather
amusing, on the other side... somehow it didn't win my heart over and it
*does* look somewhat unprofessional.
> I also do not like that the link to "Documentation" looks more like a
> too-short cheat-sheet.
I personally don't find the idea of having direct links to the most
used commands bad, though I'm not sure how useful will it be in
practice.
> But then, I think that git.or.cz looks more professional (read: more
> respectful, less geekish), so I think there is not much harm in that.
Note that I tried to fix up a lot of bits that I felt were a little
too colloquial in my patch series I linked in a previous mail.
--
Petr "Pasky" Baudis
As in certain cults it is possible to kill a process if you know
its true name. -- Ken Thompson and Dennis M. Ritchie
^ permalink raw reply
* Re: git-scm.com
From: Scott Chacon @ 2008-07-26 2:28 UTC (permalink / raw)
To: Patrick Aljord; +Cc: git list
In-Reply-To: <6b6419750807251838h12ea4f19gdff107694e3797c4@mail.gmail.com>
5 links in the middle? You mean to the project links? I just choose
the biggest, most well known projects I could think of and stuck them
up there - many of them are at GitHub. If you have a list you like
better, I would be happy to add them, or discuss the final list, but I
hardly think that's an advertisement for GitHub. As for the link in
the footer, that's where I'm hosting my repo for the page, and it's at
the bottom of the page and tiny.
I am more concerned about the logo at the bottom, and Petr and I are
discussing this - I can remove the logo, but then I'd have to pay for
this out of my pocket instead of having a small logo on the page.
It's not bad to host a few webpages, but this will eventually have
diagrams and screencasts and whatever else I can do for comprehensive
documentation, which can add up in brandwidth costs (especially the
screencasts). The Githubbers have offered to pay for that and host
media and whatnot for the project, backed by a real team of sysadmins.
That seems like a pretty good deal for a small logo at the bottom of
the page. For newbies, that is likely even a good thing - makes them
see that there is some corporate interest in it - that it's not just
an obscure tool for the hard core.
I am open to discussion on that, but I can't change where Ruby on
Rails has decided to host their repo.
Scott
On Fri, Jul 25, 2008 at 6:38 PM, Patrick Aljord <patcito@gmail.com> wrote:
> Looks fine but this page looks like a big advertising for Github with
> five links on the middle of the front page + one big logo at the
> bottom.
> --
> To unsubscribe from this list: send the line "unsubscribe git" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
^ permalink raw reply
* Re: git-scm.com
From: Johannes Schindelin @ 2008-07-26 2:25 UTC (permalink / raw)
To: Scott Chacon; +Cc: git
In-Reply-To: <d411cc4a0807251035i7aed2ec9wef7e8f1b3ae4c585@mail.gmail.com>
Hi,
On Fri, 25 Jul 2008, Scott Chacon wrote:
> A followup on the post I did a few days ago about Git documentation.
> I forked Petr's git.or.cz site and put up a version that I think is a
> bit more accessible and newbie-friendly at git-scm.com.
I do not like the implication that Git eats trees.
I also do not like that the link to "Documentation" looks more like a
too-short cheat-sheet.
> I had meant to discuss this with Petr before posting it to you all, but
> I published a blog post that got a bit more attention than I expected,
> and I didn't want you all to think I didn't care about your opinion, as
> some have already accused me of.
My first reaction was: he could have given Pasky a little more time to
react.
But then, I think that git.or.cz looks more professional (read: more
respectful, less geekish), so I think there is not much harm in that.
Ciao,
Dscho
^ permalink raw reply
* Re: Official Git Homepage change? Re: git-scm.com
From: Petr Baudis @ 2008-07-26 2:09 UTC (permalink / raw)
To: Scott Chacon; +Cc: git
In-Reply-To: <20080726015314.GU32184@machine.or.cz>
Hi,
oops, so I decided to unbundle this question from the previous post,
but forgot to modify the subject line...
When the git-scm.com site gets refined a bit further, it might make a
lot of sense to make http://git.or.cz/index.html a redirect to
http://git-scm.com/ and thus delegate the new site to the official Git
homepage. Of course, I would be transferring the control of the homepage
from my hands so I would like to poll the community about how do people
feel about this - opinion of core Git contributors would be especially
welcome; I find myself rather happy with the new site, so I will
implicitly take silence as an agreement.
Here is a breakdown of possible pros and cons that come on my mind:
+ The new site has much nicer and more catchy design.
+ The new site seems to have a lot of potential to grow to a rather
comprehensive resource.
+ The new site would probably have much more active maintainer. ;-)
- The new site is affiliated with a commercial entity - GitHub.
The website maintainer also has commercial interest in some published
Git learning materials, which might generate certain conflict of
interests; we must trust them that they handle this well.
- Both GitHub and Scott seem to be rather distanced from the "core"
Git development community. This might or might not be an issue.
- The new site is implemented in much more complicated way than the
old one, having a full-fledged Ruby on Rails machinery behind it and
linking to bunch of obfuscated JavaScript code; I don't think it's that
big a deal, though.
The negatives section writeup is longer, but in fact I think the
positives win here; I also have a bit of bad conscience about not giving
git.or.cz the amount of time it would deserve...
P.S.: To simplify matters, I talk only about index.html, but of course
it would make sense to transfer both the SVN Crash Course _AND_ the Git
Wiki along; we might keep the Cogito homepage for purely historical
interest too, I don't know.
--
Petr "Pasky" Baudis
As in certain cults it is possible to kill a process if you know
its true name. -- Ken Thompson and Dennis M. Ritchie
^ permalink raw reply
* Re: [PATCH] Respect crlf attribute even if core.autocrlf has not been set
From: Johannes Schindelin @ 2008-07-26 2:09 UTC (permalink / raw)
To: Eyvind Bernhardsen
Cc: Dmitry Potapov, Avery Pennarun, Joshua Jensen, Junio C Hamano,
git
In-Reply-To: <42C252B2-85B9-4D05-B3A2-2A0250D7F5D6@orakel.ntnu.no>
Hi,
On Fri, 25 Jul 2008, Eyvind Bernhardsen wrote:
> That is an excellent argument for why setting "autocrlf=true" by default
> on Windows was a bad idea. Thanks! :)
Well, these days, I tend to give a flying nothing to opinions that are not
backed up by any effort toward the project.
In other words, if you have not participated in the community process to
find what is best for Git, you could just as well say that you want the
moon to be green, and I could not care less (in both cases).
Ciao,
Dscho
^ permalink raw reply
* Official Git Homepage change? Re: git-scm.com
From: Petr Baudis @ 2008-07-26 1:53 UTC (permalink / raw)
To: Scott Chacon; +Cc: git
In-Reply-To: <d411cc4a0807251035i7aed2ec9wef7e8f1b3ae4c585@mail.gmail.com>
Hi,
On Fri, Jul 25, 2008 at 10:35:43AM -0700, Scott Chacon wrote:
> Anyhow, I'm discussing with Petr about where we want to go from here -
> what changes he'd like to make, etc, but I obviously value your
> opinion as well, so please let me know what you think. The content
> has barely changed, it's really just a usability overhaul. I want to
> make sure that whatever someone is looking for (especially someone
> new), they can find in a few clicks and a few seconds.
when the initial NIH reaction passes, I have to admit that I do rather
like it - and it's not only because you keep mentioning how awesome I am
in your blog post. ;-)
I wonder if all the Git users find the heading rather funny as I did,
instead of unprofessional - but maybe we don't care about users without
a particular sense of humor. I'm also not overly fond of the color theme
but I'm perhaps just too heavy of a blue fan.
Plenty of minor fixes are available for pull at
git://github.com/pasky/learn-github.git
(http://github.com/pasky/learn-github/tree/master)
(Note that I didn't test whether the pages still look ok with my changes
since I have no Ruby on Rails setup; hopefully they should, though.)
Other non-trivial nits:
* I'm feeling a bit uneasy about listing so many projects using Git;
I haven't heard about quite a few of these and I'm not sure on what
merit should we list projects. "Prototype" or "Liftweb" and probably
even "Rubinius", is that going to ring a bell for major part of visitors
so that they say "oh, even _those_ guys are using Git"?
* Cut the contributors list at 4 or 5 commits? Below that, the list
is getting fairly useless anyway and you have trouble with keeping the
names reasonably well-formed.
* Reusing captions from command manpages in the Documentation page
shows nicely how awful they sometimes are. :-) This is probably something
to fix upstream, though.
* Is "Git for the lazy" really unique in some regard to deserve to be
listed among the other resources? I think we should minimalize
redundancy at the documentation page, the amount of material is already
overwhelming and it should be obvious for the visitor which document to
choose based on his needs. I have similar doubts about the 37signals
resources.
In other words, "let's keep the resources orthogonal!"
* There is no reference to the Wiki in the documentation, only to the
[GitDocumentation] page; I think there should be a reference to the
[GitFaq] page too - a lot of important points that are not obvious
to newcomers are covered there. I'm just not sure where exactly to put
the link.
* I would go as far as put the link to the Wiki itself to the
navigation bar, simply since it is such a crucial resource.
* A guide on maintaining third-party patches is currently missing.
* The development page is not referenced anywhere; the missing
information are mailing list details (how to subscribe) and a link to
SubmittingPatches. Also, I have recently talked with Junio about adding
a link to the Note from the Maintainer, but we didn't yet figure out
where to stabilize the location of that page.
> Next, I will be working on the larger end-user documentation project,
> which will linked to from the documentation page of this site, and
> probably the main page too. I'll keep this list updated as I go,
> since people tend to think I don't care about the community when I try
> not to waste your time. :)
How does that compare with the Git user manual? Have you considered
collaborating on that one, or what are your reasons not to? Or are you
trying to do something different?
--
Petr "Pasky" Baudis
As in certain cults it is possible to kill a process if you know
its true name. -- Ken Thompson and Dennis M. Ritchie
^ permalink raw reply
* Re: git-scm.com
From: Patrick Aljord @ 2008-07-26 1:38 UTC (permalink / raw)
To: git list
In-Reply-To: <d411cc4a0807251035i7aed2ec9wef7e8f1b3ae4c585@mail.gmail.com>
Looks fine but this page looks like a big advertising for Github with
five links on the middle of the front page + one big logo at the
bottom.
^ permalink raw reply
* Re: [RFC] custom strategies in builtin-merge
From: Junio C Hamano @ 2008-07-26 1:12 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: sverre, Miklos Vajna, git
In-Reply-To: <alpine.DEB.1.00.0807260250480.11976@eeepc-johanness>
Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> ... especially since I hope that we have them builtin soon, and not only
> that, but have builtin-merge call them as C functions, not with fork() and
> exec().
Because builtin-merge.c does not directly use fork/exec but uses
run_command() interface, non POSIX platforms can spawn subprocesses just
fine, can't they?
I do not think at this point it is of any high priority to call strategies
internally, avoiding fork/exec. We may apply hundreds of patches per
minute, but would fork/exec overhead matter for merges?
Especially because some strategies (recursive and perhaps the rumored
"blame" even more so) are quite data intensive operations, libifying them
is not worth it, compared to the nice isolation between processes we get
from running them as a separate program. We get the necessary clean-up
after strategy did its thing for almost free (well, "at the cost of
fork/exec").
^ permalink raw reply
* Re: git-scm.com
From: Scott Chacon @ 2008-07-26 0:59 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7v3alxr0fd.fsf@gitster.siamese.dyndns.org>
Thanks Junio,
I fixed the things you mentioned here, except for the list ordering,
only because I kinda think you big contributors should be at the top
there, and also because it's slightly more difficult to populate an
html table that way :) If everyone feels strongly about that, though,
I will change it.
Scott
On Fri, Jul 25, 2008 at 4:47 PM, Junio C Hamano <gitster@pobox.com> wrote:
> I think counting merges in "The Authors of Git" statistics give quite
> skewed numbers. If you are generating it with "shortlog", you probably
> would want to give --no-merges to the command line as well. Also it
> appears that you are not using .mailmap to avoid counting the same person
> as different people.
>
> I find a tabular list like this list easier to read if it were sorted like
> this:
>
> A D G
> B E H
> C F
>
> i.e. not like this:
>
> A B C
> D E F
> G H
>
>
^ permalink raw reply
* Re: [PATCH] Build configuration to skip ctime for modification test
From: Johannes Schindelin @ 2008-07-26 0:57 UTC (permalink / raw)
To: Alex Riesen; +Cc: Linus Torvalds, Junio C Hamano, Johannes Sixt, git
In-Reply-To: <20080725055547.GA3699@blimp.local>
Hi,
On Fri, 25 Jul 2008, Alex Riesen wrote:
> But, given the fact, that somewhere sometimes its very-very annoying to
> have even one (un)changed file, something must be done about it. Maybe
> just direct
>
> [...]
> trustctime = false
... which is all Junio and I were asking all along: a separate way to ask
for ignoring ctime; not just DWIM it on top of the executable bit.
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH 6/9] builtin-init-db.c: use parse_options()
From: Johannes Schindelin @ 2008-07-26 0:55 UTC (permalink / raw)
To: Olivier Marin; +Cc: Michele Ballabio, git, gitster
In-Reply-To: <4889EF3A.6040605@free.fr>
[-- Attachment #1: Type: TEXT/PLAIN, Size: 452 bytes --]
Hi,
On Fri, 25 Jul 2008, Olivier Marin wrote:
> Johannes Schindelin a écrit :
>
> > We rely on shared_repository == 0 for non-shared repositories _almost
> > everywhere_.
>
> I think we rely on the fact that PERM_UMASK == 0 and not on the value of
> shared_repository. Not the same thing.
Just look at all the cases where we ask for "if (shared_repository)".
And then look where PERM_UMASK is assigned to. It _is_ the same thing.
Hth,
Dscho
^ permalink raw reply
* Re: [PATCH 1/9] builtin-verify-tag.c: use parse_options()
From: Johannes Schindelin @ 2008-07-26 0:53 UTC (permalink / raw)
To: Olivier Marin; +Cc: Michele Ballabio, git, gitster
In-Reply-To: <4889EF22.6020604@free.fr>
[-- Attachment #1: Type: TEXT/PLAIN, Size: 321 bytes --]
Hi,
On Fri, 25 Jul 2008, Olivier Marin wrote:
> Johannes Schindelin a écrit :
> >
> > That would be a bugfix. As such, it belongs into a different commit.
>
> I thought, for that kind of trivial bug that probably never hit anyone,
> a line in the commit message was enough.
So bisectability goes down the gutter?
^ permalink raw reply
* Re: [RFC] custom strategies in builtin-merge
From: Johannes Schindelin @ 2008-07-26 0:51 UTC (permalink / raw)
To: Junio C Hamano; +Cc: sverre, Miklos Vajna, git
In-Reply-To: <7viqutpjqq.fsf@gitster.siamese.dyndns.org>
Hi,
On Fri, 25 Jul 2008, Junio C Hamano wrote:
> "Sverre Rabbelier" <alturin@gmail.com> writes:
>
> > On Fri, Jul 25, 2008 at 13:33, Miklos Vajna <vmiklos@frugalware.org> wrote:
> >> 1) Maintain a list of commands that has a git-merge- prefix, but not a
> >> strategy. This list would currently contain "base, file, index,
> >> one-file and tree".
> >
> > Sounds a bit error prone, and could lead to unexpected results if/when
> > someone creates a new command ('git merge status' anyone?) which is
> > then suddenly treated as a merge strategy.
> >
> >> 2) Require custom strategies to have a different naming scheme, like
> >> if "foo" is a custom strategy, then it would have to be named
> >> git-merge-custom-foo, _not_ git-merge-foo.
> >
> > I think this is cleaner, what would be even nicer is to change the
> > current names too, so name them all "git-merge-stragegy-foo".
>
> I think you could retroactively impose "git-merge-strategy-" prefix rule
> and grandfather the existing ones by maintaining a list of them that by
> definition will not grow anymore.
... especially since I hope that we have them builtin soon, and not only
that, but have builtin-merge call them as C functions, not with fork() and
exec().
Ciao,
Dscho
^ permalink raw reply
* Re: [RFC] custom strategies in builtin-merge
From: Junio C Hamano @ 2008-07-26 0:33 UTC (permalink / raw)
To: sverre; +Cc: Miklos Vajna, git, Johannes Schindelin
In-Reply-To: <bd6139dc0807250450m25a932b8h68fcee13f8c343dc@mail.gmail.com>
"Sverre Rabbelier" <alturin@gmail.com> writes:
> On Fri, Jul 25, 2008 at 13:33, Miklos Vajna <vmiklos@frugalware.org> wrote:
>> 1) Maintain a list of commands that has a git-merge- prefix, but not a
>> strategy. This list would currently contain "base, file, index,
>> one-file and tree".
>
> Sounds a bit error prone, and could lead to unexpected results if/when
> someone creates a new command ('git merge status' anyone?) which is
> then suddenly treated as a merge strategy.
>
>> 2) Require custom strategies to have a different naming scheme, like
>> if "foo" is a custom strategy, then it would have to be named
>> git-merge-custom-foo, _not_ git-merge-foo.
>
> I think this is cleaner, what would be even nicer is to change the
> current names too, so name them all "git-merge-stragegy-foo".
I think you could retroactively impose "git-merge-strategy-" prefix rule
and grandfather the existing ones by maintaining a list of them that by
definition will not grow anymore.
^ permalink raw reply
* Re: [PATCH 5/6] archive: allow --exec and --remote without equal sign
From: Junio C Hamano @ 2008-07-26 0:31 UTC (permalink / raw)
To: Rene Scharfe; +Cc: git
In-Reply-To: <1216982486-5887-6-git-send-email-rene.scharfe@lsrfire.ath.cx>
Rene Scharfe <rene.scharfe@lsrfire.ath.cx> writes:
> Convert git archive to parse_options(). The parameters --remote and --exec
> are still handled by their special parser. Define them anyway in order for
> them to show up in the usage notice.
>
> Note: in a command like "git archive --prefix --remote=a/ HEAD", the string
> "--remote=a/" will be interpreted as a remote option, not a prefix, because
> that special parser sees it first. If one needs such a strange prefix, it
> needs to be specified like this: "git archive --prefix=--remote=a/ HEAD"
> (with an equal sign).
>
> Signed-off-by: Rene Scharfe <rene.scharfe@lsrfire.ath.cx>
> ---
> archive.c | 110 +++++++++++++++++++++++++++++++++++++-----------------------
> 1 files changed, 68 insertions(+), 42 deletions(-)
Hmph, somewhat dubious.
The real point of parse-options was to make the code smaller, easier to
maintain and command line handling more consistent. At least this patch
seems to fail on the two out of three counts.
All of the other patches made obvious sense to me and are queued for -rc1
but I'd like to backburner this one.
^ 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