* Re: git-subtree: directory mismatch
From: Avery Pennarun @ 2009-11-25 23:20 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Junio C Hamano, Nanako Shiraishi, Marc Fournier, git
In-Reply-To: <alpine.DEB.1.00.0911260013550.4985@pacific.mpi-cbg.de>
On Wed, Nov 25, 2009 at 6:17 PM, Johannes Schindelin
<Johannes.Schindelin@gmx.de> wrote:
> On Wed, 25 Nov 2009, Junio C Hamano wrote:
>> I do remember some people didn't like -X<option> syntax but I don't
>> think there was any solid counterproposal to achieve a similar goal to
>> satisfy the need to pass arbitrary parameters to the merge strategy
>> backends.
>
> I took exception to the awkward way to specify the option. A strong hint
> just how awkward -X<option> is: it is hard to implement using
> parse-options.
I read the earlier thread and I still don't quite understand this
point. What makes it difficult? X seems just like any other option
that takes a string parameter (which is easily supported by getopt at
least; I haven't played with parse_options but I certainly hope it's
as good as getopt).
The string parameter (say, $x) is translated directly into "--$x" and
passed as exactly one argument of the argv array to the subprogram.
Easy, right? Plus Junio already wrote a patch to do it (which I'm in
the process of forward-porting) and it seems pretty straightforward.
Perhaps I'm missing something.
Thanks,
Avery
^ permalink raw reply
* Re: [PATCH] grep: --full-tree
From: Jeff King @ 2009-11-25 23:22 UTC (permalink / raw)
To: A Large Angry SCM; +Cc: Junio C Hamano, git
In-Reply-To: <4B0DB894.7010800@gmail.com>
On Wed, Nov 25, 2009 at 06:07:00PM -0500, A Large Angry SCM wrote:
> <semi rhetorical>
> So, what's the solution?
>
> Have every command command take a list of configuration options to
> ignore/respect?
>
> Have every command take an option to ignore/respect _all_
> configuration options?
>
> Have inconsistency between commands, like we have now
>
> Have commands have all kinds of hidden/undocumented default settings?
> </semi rhetorical>
I don't know. All of those options suck. ;
Probably we would want something flexible, but with sane defaults. Like
an environment variable to ignore all (or most) config options, but then
the ability to opt into specific ones. Something like:
GIT_PLUMBING=1; export GIT_PLUMBING
git log ;# does not respect any non-plumbing config
git --respect='log.showroot' ;# respect just the one variable
git --respect='color.*' log ;# you get all color
But there are two big obstacles (besides the obvious issue that
introducing this in itself needs a gentle transition plan):
1. We need to annotate every config option with whether it is
potentially problematic. For example, core.filemode should probably
be respected no matter what (but I'm not sure if it is simply true
for core.*).
2. Script writers need to actually use the system, which is somewhat
more verbose and annoying than what they have to do now. But at
least it defaults to safety when they are lazy, and then they can
re-add options. Of course, they are stuck on an upgrade treadmill
of analyzing and approving each new option that appears in git.
-Peff
^ permalink raw reply
* Re: [PATCH] grep: --full-tree
From: Johannes Schindelin @ 2009-11-25 23:31 UTC (permalink / raw)
To: Sverre Rabbelier; +Cc: Junio C Hamano, git
In-Reply-To: <fabb9a1e0911251246l4684f357pb5f379b191aaa64a@mail.gmail.com>
Hi,
On Wed, 25 Nov 2009, Sverre Rabbelier wrote:
> On Wed, Nov 25, 2009 at 21:23, Junio C Hamano <gitster@pobox.com> wrote:
> > But then you can alias "gr 'grep --full-tree'" with the same ease and
> > there is no reason to change the default.
>
> I agree, but then again I'm somewhat biased, as I want the current
> behavior :P.
You mean like the many people who wanted to keep the dashed commands, but
unlike who you do speak up _before_ your expectations are broken?
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH] gitweb.js: Harden setting blamed commit info in incremental blame
From: Jakub Narebski @ 2009-11-25 23:28 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Stephen Boyd, git
In-Reply-To: <7vd436s2r8.fsf@alter.siamese.dyndns.org>
On Wed, środa 25. listopada 2009 22:39, Junio C Hamano napisał:
> Jakub Narebski <jnareb@gmail.com> writes:
>
> > It was 'Unspecified error.' shown in xhr watch. Accessing xhr.status
> > causes an error.
>
> As to the topic, it does not seem to break _existing_ features; if that is
> not the case, please let me know.
With the single exception of "Create links leading to 'blame_incremental'
using JavaScript" all commits are about opt-in features: either need to
be enabled in gitweb config ('timed' feature), or you need to handcraft
URL ('blame_incremental' as action parameter).
The commit that makes 'blame' links to use 'blame_incremental' view if
JavaScript is enabled might break 'blame' view for IE8 users.
> Otherwise I'm inclined to merge the entire series to 'master' by 1.6.6-rc1.
>
> 6821dee gitweb.js: fix padLeftStr() and its usage
> 6aa2de5 gitweb.js: Harden setting blamed commit info in incremental blame
> e42a05f gitweb.js: fix null object exception in initials calculation
> 63267de gitweb: Minify gitweb.js if JSMIN is defined
> c4ccf61 gitweb: Create links leading to 'blame_incremental' using JavaScript
> e206d62 gitweb: Colorize 'blame_incremental' view during processing
> 4af819d gitweb: Incremental blame (using JavaScript)
> aa7dd05 gitweb: Add optional "time to generate page" info in footer
> -aef3768 gitweb: Use light/dark for class names also in 'blame' view
>
> and treat it as a new feature with known breakages, to give it wider
> audience. That way you will hopefully get more people who are willing to
> help debug/fix things for you.
Perhaps then it would be better to put commit that creates links to
'blame_incremental' action last, and have it in 'next' and not in master?
Below there is request-pull with reordered series, unless you want me
to resend this series as a set of patches, as reply to this email.
-- >8 --
The following changes since commit b073b7a990deb1cb3425db45642fa18c8b3cb65c:
Benjamin Kramer (1):
Explicitly truncate bswap operand to uint32_t
are available in the git repository at:
git://repo.or.cz/git/jnareb-git.git gitweb/web
7bc7e38 gitweb: Create links leading to 'blame_incremental' using JavaScript
aa1ff3d gitweb.js: Harden setting blamed commit info in incremental blame
da51a3c gitweb.js: fix padLeftStr() and its usage
a253a2c gitweb.js: fix null object exception in initials calculation
fbebd29 gitweb: Minify gitweb.js if JSMIN is defined
8ba6343 gitweb: Colorize 'blame_incremental' view during processing
0e14278 gitweb: Incremental blame (using JavaScript)
c4c6645 gitweb: Add optional "time to generate page" info in foot
Jakub Narebski (6):
gitweb: Add optional "time to generate page" info in footer
gitweb: Incremental blame (using JavaScript)
gitweb: Colorize 'blame_incremental' view during processing
gitweb: Minify gitweb.js if JSMIN is defined
gitweb.js: Harden setting blamed commit info in incremental blame
gitweb: Create links leading to 'blame_incremental' using JavaScript
Stephen Boyd (2):
gitweb.js: fix null object exception in initials calculation
gitweb.js: fix padLeftStr() and its usage
Makefile | 26 ++-
git-instaweb.sh | 7 +
gitweb/README | 5 +
gitweb/gitweb.css | 25 ++
gitweb/gitweb.js | 870 ++++++++++++++++++++++++++++++++++++++++++++++++++++
gitweb/gitweb.perl | 311 ++++++++++++++-----
6 files changed, 1157 insertions(+), 87 deletions(-)
create mode 100644 gitweb/gitweb.js
--
Jakub Narebski
Poland
^ permalink raw reply
* Re: [PATCH] grep: --full-tree
From: Sverre Rabbelier @ 2009-11-25 23:29 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Junio C Hamano, git
In-Reply-To: <alpine.DEB.1.00.0911260030130.4985@pacific.mpi-cbg.de>
Heya,
On Thu, Nov 26, 2009 at 00:31, Johannes Schindelin
<Johannes.Schindelin@gmx.de> wrote:
> You mean like the many people who wanted to keep the dashed commands, but
> unlike who you do speak up _before_ your expectations are broken?
Yes, kinda like that, but with the note that I do think we should not
lock down the UI in favor or not breaking expectations. I mean, if
people want to retain a specific behavior forever, maybe they should
just keep using that version of git forever? Nah, that doens't work of
course, but I do think a balance is needed between the two (improving
the UI and not breaking people's expectations).
--
Cheers,
Sverre Rabbelier
^ permalink raw reply
* Re: [PATCH] grep: --full-tree
From: Johannes Schindelin @ 2009-11-25 23:34 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Jeff King, git
In-Reply-To: <7vmy2as319.fsf@alter.siamese.dyndns.org>
Hi,
On Wed, 25 Nov 2009, Junio C Hamano wrote:
> Jeff King <peff@peff.net> writes:
>
> > On Wed, Nov 25, 2009 at 12:52:11PM -0800, Junio C Hamano wrote:
> >
> >> So I think the posted patch alone without changing anything else would be
> >> the approach to give the most benefit with the least impact to existing
> >> users, at least for now.
> >
> > Yes, I meant to say in my original message but forgot to: I think
> > --full-tree is an important first step, no matter what happens next. It
> > gives people a way to do what they want without typing the right number
> > of ".."s, and it opens up --no-full-tree if the default changes later.
> >
> > But I do worry about it being a command-line option. You are asking the
> > user to remember to type --full-tree every time.
>
> We could redefine get_pathspec() to treat a pathspec that begins with a
> slash to be anchored at the top,
This would break spectacularly in MSys. And this is just one reason not
to do this "magic".
Clearly, a command line option is the only unambiguous way to do what you
want to do (and not changing the default all of a sudden).
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH] grep: --full-tree
From: Junio C Hamano @ 2009-11-25 23:41 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Junio C Hamano, Jeff King, git
In-Reply-To: <alpine.DEB.1.00.0911260032410.4985@pacific.mpi-cbg.de>
Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> This would break spectacularly in MSys.
How? If that is the case wouldn't --full-tree break Msys the same way?
^ permalink raw reply
* Re: git-subtree: directory mismatch
From: Björn Steinbrink @ 2009-11-25 23:41 UTC (permalink / raw)
To: Avery Pennarun
Cc: Johannes Schindelin, Junio C Hamano, Nanako Shiraishi,
Marc Fournier, git
In-Reply-To: <32541b130911251520l7a84554bxab9cf59ff9d8fc1@mail.gmail.com>
On 2009.11.25 18:20:45 -0500, Avery Pennarun wrote:
> On Wed, Nov 25, 2009 at 6:17 PM, Johannes Schindelin
> <Johannes.Schindelin@gmx.de> wrote:
> > On Wed, 25 Nov 2009, Junio C Hamano wrote:
> >> I do remember some people didn't like -X<option> syntax but I don't
> >> think there was any solid counterproposal to achieve a similar goal to
> >> satisfy the need to pass arbitrary parameters to the merge strategy
> >> backends.
> >
> > I took exception to the awkward way to specify the option. A strong hint
> > just how awkward -X<option> is: it is hard to implement using
> > parse-options.
>
> I read the earlier thread and I still don't quite understand this
> point. What makes it difficult?
I guess it's -Xfoo vs. -X foo (note the space). Same deal with log
-S<string>. "git log -S foo" would look for an empty string (I guess)
being added/removed in some commit in foo's history, while "git log
-Sfoo" looks for "foo" being added/remove in HEAD's history.
Björn
^ permalink raw reply
* Re: Commiting changes onto more than one branch
From: Daniel Barkalow @ 2009-11-25 23:41 UTC (permalink / raw)
To: Mike Jarmy; +Cc: Junio C Hamano, Eugene Sajine, git
In-Reply-To: <6b4a562b0911251143s63f09f7bwe4b67d6871d8a1b2@mail.gmail.com>
[-- Attachment #1: Type: TEXT/PLAIN, Size: 2869 bytes --]
On Wed, 25 Nov 2009, Mike Jarmy wrote:
> Junio C Hamano wrote:
> > I take it to mean that even though v[345] have diverged, the area that the
> > particular change you have in mind has to touch haven't changed since they
> > forked.
>
> Correct. Sometimes, there might be unrelated changes to a given file
> or files, in which case conflict resolution will be done manually.
> But generally speaking, bugfixes will tend to go on quite cleanly.
>
> > Instead, you can fork such a topic from the latest common.
> >
> > o--o--o--o--o--o--o--o v4
> > /
> > --o--x--x--x--x--x--x--x v3
> > \
> > Y---Y
> > your change(s)
> >
> > and merging this to v3 and v4 will have the desired effect.
> >
> > o--o--o--o--o--o--o--o---------M v4
> > / /
> > --o--x--x--x--x--x--x--x---M v3 /
> > \ / /
> > Y---Y----------------.-----.
> > your change(s)
> >
> > The merges will incorporate this particular change alone without dragging
> > anything else. When you merge it to v4, none of the unrelated 'x' will be
> > merged into it.
>
> That sounds a whole lot like what I need.
>
> Right now I'm thinking that the right approach is that once we have
> released v3, and started working on v4 heavily, we will probably not
> want to check any commits directly into v3. Bugfixes will have their
> own branch. If there is a whole new project or whatever being done
> on top of v3, it will have its own branch as well.
>
> So once v3 is in beta or whatever and we declare a code freeze, we
> could have a rule that all commits must be merge-commits coming from
> dedicated branches with descriptive, intelligible names. For each
> dedicated branch, some thought will have to be given as to just where
> off of v3 to branch it from (not just carelessly off the latest tip).
> Meanwhile, new development will continue on v4, with lots of commits
> going right into the branch (or into v4 sub-branches with occasional
> merge-commits into v4).
It's worth noting that you don't have to have any general visibility to
the dedicated branch. If you look at Junio's graph, there are only two
branches marked: v3 and v4. The stuff in the bottom line only appears as
the second parent in the merge commits. Git's data model doesn't require a
branch for a commit to be "on" like many other VCSes, so it's perfectly
reasonable for a developer to make a temporary branch, create the fix in
some private repository, merge it to each applicable official branch, and
then discard the temporary branch. (The temporary branch is only needed at
all so that the developer has some way to refer to the fix while merging
it, and the name only matters in that humans will see it in the merge
commit message.)
-Daniel
*This .sig left intentionally blank*
^ permalink raw reply
* Re: git-subtree: directory mismatch
From: Avery Pennarun @ 2009-11-25 23:45 UTC (permalink / raw)
To: Björn Steinbrink
Cc: Johannes Schindelin, Junio C Hamano, Nanako Shiraishi,
Marc Fournier, git
In-Reply-To: <20091125234122.GA31422@atjola.homenet>
2009/11/25 Björn Steinbrink <B.Steinbrink@gmx.de>:
> On 2009.11.25 18:20:45 -0500, Avery Pennarun wrote:
>> I read the earlier thread and I still don't quite understand this
>> point. What makes it difficult?
>
> I guess it's -Xfoo vs. -X foo (note the space). Same deal with log
> -S<string>. "git log -S foo" would look for an empty string (I guess)
> being added/removed in some commit in foo's history, while "git log
> -Sfoo" looks for "foo" being added/remove in HEAD's history.
Oh. Ouch. Isn't it standard for options-that-take-string-parameters
to always *require* that parameter? This seems to be how getopt
works. Basically "-X foo" is the same as "-Xfoo" in that system.
If parse_options doesn't already do this, should I try to add it somehow?
Avery
^ permalink raw reply
* Re: Commiting changes onto more than one branch
From: Andreas Schwab @ 2009-11-25 23:56 UTC (permalink / raw)
To: Daniel Barkalow; +Cc: Mike Jarmy, Junio C Hamano, Eugene Sajine, git
In-Reply-To: <alpine.LNX.2.00.0911251752330.14365@iabervon.org>
Daniel Barkalow <barkalow@iabervon.org> writes:
> (The temporary branch is only needed at all so that the developer has
> some way to refer to the fix while merging it, and the name only
> matters in that humans will see it in the merge commit message.)
If you merge by commit-ish the branch name does not even appear in the
commit message.
Andreas.
--
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5
"And now for something completely different."
^ permalink raw reply
* Re: [PATCH] grep: --full-tree
From: Johannes Schindelin @ 2009-11-26 0:04 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Jeff King, git
In-Reply-To: <7vvdgyp3zn.fsf@alter.siamese.dyndns.org>
Hi,
On Wed, 25 Nov 2009, Junio C Hamano wrote:
> Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
>
> > This would break spectacularly in MSys.
>
> How? If that is the case wouldn't --full-tree break Msys the same way?
If you want to specify an argument on MSys that starts with a slash, you
have to provide double slashes, otherwise it gets expanded to the Windows
path (prefixing with the absolute path of the MSys root).
But this introduces yet another inconcistency: using double slashes
everywhere else does not work.
Hopefully you see the real reason why it breaks down? The reason is that
you try to re-interpret something in a special way that means something
different. A path starting with a slash simply does not mean "the root of
the project". It means "the root of the file system".
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH] grep: --full-tree
From: Junio C Hamano @ 2009-11-26 0:00 UTC (permalink / raw)
To: Wincent Colaiuta; +Cc: James Pickens, Jeff King, git
In-Reply-To: <60F92BD7-6FFF-4D9A-B2F0-0858F4E90B59@wincent.com>
Wincent Colaiuta <win@wincent.com> writes:
> Oh, I wouldn't like that at all. I think it would be a very ugly UI
> wart, because it would basically make Git behave differently than
> every other command line tool that accepts paths. If it is to deviate
> from the extremely widespread convention that paths starting with /
> refer to absolute paths rooted at the root of the filesystem, then the
> justification for it would need to be very strong indeed.
There are at least two flaws in that argument.
- git does not accept paths (it lets you specify patterns that match,
e.g. t/ to name ptahs under t/ directory).
- "/pathspec" does follow the widespread convention that a string that
begin with a "/" refer to a path rooted at the root _in the context_;
the definition of root may or may not match the filesystem root.
Think of things like <a href="/$path">Top</a>. Does "/$path" mean at
the root of filesystem? No.
I am not married to the "git grep -e frotz /Documentation" notation, by
the way. I just didn't think of a different notation that is equally
short, sweet and logical. We could do //Documentation if it makes it more
distinct, but I do think it is worse than a single slash.
^ permalink raw reply
* Re: [PATCH] grep: --full-tree
From: Junio C Hamano @ 2009-11-26 0:02 UTC (permalink / raw)
To: Jeff King; +Cc: git
In-Reply-To: <20091125222625.GB2861@coredump.intra.peff.net>
Jeff King <peff@peff.net> writes:
> On Wed, Nov 25, 2009 at 02:19:35PM -0800, Junio C Hamano wrote:
>
>> Jeff King <peff@peff.net> writes:
>>
>> > ... That is, I don't want to have to remember "git grep
>> > --full-tree" or "git grep /" every time
>>
>> But that cuts both ways. If you change the default to full-tree,
>> people will forget to put "." every time when asking to limit to the
>> current directory.
>
> I know. Which is why I am arguing for a configuration option.
Yeah; what is your take on tr/reset-checkout-patch topic, by the way? I
do not particularly like a configuration that changes the behaviour of a
command in a drastic way---it will make helping others much harder, but I
guess it should be Ok?
This may sound like an OffTopic, but because we _are_ discussing
consistency, it matters.
^ permalink raw reply
* Re: [PATCH] grep: --full-tree
From: Junio C Hamano @ 2009-11-26 0:13 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Junio C Hamano, Jeff King, git
In-Reply-To: <alpine.DEB.1.00.0911260059040.4985@pacific.mpi-cbg.de>
Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> If you want to specify an argument on MSys that starts with a slash, you
> have to provide double slashes, otherwise it gets expanded to the Windows
> path (prefixing with the absolute path of the MSys root).
How well does the command line hack handle things like
$ git archive --output=/var/tmp/foo.tar
I have to wonder.
> Hopefully you see the real reason why it breaks down?
Yes, Windows' braindamage. It doesn't invalidate anything I said so far,
but only proves that emulation can go only so far. I hope msys port can
grok real "path from root" notation on Windows, e.g.
$ git diff --no-index "C:\My Documents/hello.txt" "D:\goodbye.txt"
(or perhaps "//c/my documents/...", but I do not care about the details).
^ permalink raw reply
* Re: [PATCH] grep: --full-tree
From: A Large Angry SCM @ 2009-11-26 0:16 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Wincent Colaiuta, James Pickens, Jeff King, git
In-Reply-To: <7vd436p339.fsf@alter.siamese.dyndns.org>
Junio C Hamano wrote:
> - git does not accept paths (it lets you specify patterns that match,
> e.g. t/ to name ptahs under t/ directory).
Here is where it get interesting!
Our users, new and old alike, are wanting consistency. Consistency
amongst the git commands. Consistency with their platform of choice.
Consistency with what they are familiar with, Consistency with their
expectations.
Declaring that git commands (all?!) do not take paths but patterns does
not help the situation; however technically correct it may be.
> - "/pathspec" does follow the widespread convention that a string that
> begin with a "/" refer to a path rooted at the root _in the context_;
> the definition of root may or may not match the filesystem root.
But the users are almost always dealing with things (objects) that
started as files, act like files and may be files again. Why should they
not expect filesystem semantics.
^ permalink raw reply
* Re: [PATCH] grep: --full-tree
From: Junio C Hamano @ 2009-11-26 0:20 UTC (permalink / raw)
To: gitzilla; +Cc: Junio C Hamano, Wincent Colaiuta, James Pickens, Jeff King, git
In-Reply-To: <4B0DC8F7.1000509@gmail.com>
A Large Angry SCM <gitzilla@gmail.com> writes:
> But the users are almost always dealing with things (objects) that
> started as files, act like files and may be files again. Why should
> they not expect filesystem semantics.
Do you truly want to see this?
diff --git a/var/tmp/git/Makefile b/var/tmp/git/Makefile
index 5a0b3d4..e9b03a8 100644
--- a/var/tmp/git/Makefile
+++ b/var/tmp/git/Makefile
@@ -1985,3 +1985,4 @@ coverage-report:
...
As long as you are talking about paths you communicate with git, your
root _is_ the root of the work tree, and it shouldn't matter where you
have your work tree.
That is what I meant by "the root _in the context_".
^ permalink raw reply
* Re: [PATCH] grep: --full-tree
From: A Large Angry SCM @ 2009-11-26 0:30 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Wincent Colaiuta, James Pickens, Jeff King, git
In-Reply-To: <7v4ooinnkx.fsf@alter.siamese.dyndns.org>
Junio C Hamano wrote:
> A Large Angry SCM <gitzilla@gmail.com> writes:
>
>> But the users are almost always dealing with things (objects) that
>> started as files, act like files and may be files again. Why should
>> they not expect filesystem semantics.
>
> Do you truly want to see this?
>
> diff --git a/var/tmp/git/Makefile b/var/tmp/git/Makefile
> index 5a0b3d4..e9b03a8 100644
> --- a/var/tmp/git/Makefile
> +++ b/var/tmp/git/Makefile
> @@ -1985,3 +1985,4 @@ coverage-report:
> ...
>
> As long as you are talking about paths you communicate with git, your
> root _is_ the root of the work tree, and it shouldn't matter where you
> have your work tree.
>
> That is what I meant by "the root _in the context_".
>
Nice example for a command output. But what did the user specify on the
command line?
^ permalink raw reply
* Re: [PATCH] gitweb.js: Harden setting blamed commit info in incremental blame
From: Junio C Hamano @ 2009-11-26 0:34 UTC (permalink / raw)
To: Jakub Narebski; +Cc: Junio C Hamano, Stephen Boyd, git
In-Reply-To: <200911260028.19383.jnareb@gmail.com>
Jakub Narebski <jnareb@gmail.com> writes:
> Below there is request-pull with reordered series, unless you want me
> to resend this series as a set of patches, as reply to this email.
It is too late for that, as they are already in 'next'. I do not think it
is necessary nor desirable, either.
With the "Create links" commit, you are _adding_ a new link that leads to
a new feature with known breakage, not _replacing_ a link that leads to an
existing working implementation with one that does not work for some
people, no?
Merging everything else but not merging that commit does not make any
sense. It won't give any wider exposure to the feature, and is no better
than carrying the entire thing in 'next' (or 'pu') post 1.6.6.
A follow-up patch to add a gitweb configuration switch that disables the
non-working view by default but allows site owners to enable it in order
to help improving the feature would be a sensible thing to do. As long as
that patch is solidly done we can merge the whole thing to 'master' in the
upcoming release.
^ permalink raw reply
* Re: [PATCH] grep: --full-tree
From: Junio C Hamano @ 2009-11-26 0:36 UTC (permalink / raw)
To: gitzilla; +Cc: Junio C Hamano, Wincent Colaiuta, James Pickens, Jeff King, git
In-Reply-To: <4B0DCC27.4030702@gmail.com>
A Large Angry SCM <gitzilla@gmail.com> writes:
> Junio C Hamano wrote:
>> A Large Angry SCM <gitzilla@gmail.com> writes:
>>
>>> But the users are almost always dealing with things (objects) that
>>> started as files, act like files and may be files again. Why should
>>> they not expect filesystem semantics.
>>
>> Do you truly want to see this?
>>
>> diff --git a/var/tmp/git/Makefile b/var/tmp/git/Makefile
>> index 5a0b3d4..e9b03a8 100644
>> --- a/var/tmp/git/Makefile
>> +++ b/var/tmp/git/Makefile
>> @@ -1985,3 +1985,4 @@ coverage-report:
>> ...
>>
>> As long as you are talking about paths you communicate with git, your
>> root _is_ the root of the work tree, and it shouldn't matter where you
>> have your work tree.
>>
>> That is what I meant by "the root _in the context_".
>
> Nice example for a command output. But what did the user specify on
> the command line?
Either relative path from $(cwd) or full pathname from the root of the
filesystem in your world (because you do not understand the value of the
context), and ralative path from $(cwd) or full pathname from the root of
the work tree in my world.
^ permalink raw reply
* [PATCH/RFC 00/11] daemon-win32
From: Erik Faye-Lund @ 2009-11-26 0:39 UTC (permalink / raw)
To: msysgit; +Cc: git, dotzenlabs, Erik Faye-Lund
This is my stab at cleaning up Mike Pape's patches for git-daemon
on Windows for submission, plus some of my own.
* Patch 1-4 originate from Mike Pape, but have been cleaned up quite
a lot by me. I hope Mike won't hate me. Credit have been retained,
as all important code here were written by Mike. The commit
messages were written mostly by me.
* Patch 5 is a trivial old-style function declaration fix.
* Patch 6 introduces two new functions to the run-command API,
kill_async() and is_async_alive().
* Patch 7-8 removes the stdin/stdout redirection for the service
functions, as redirecting won't work for the threaded version.
* Patch 9 converts the daemon-code to use the run-command API. This
is the patch I expect to be the most controversial.
* Patch 10 is about using line-buffered mode instead of full-buffered
mode for stderr.
* Patch 11 finally enables compilation of git-daemon on MinGW.
Let the flames begin!
Erik Faye-Lund (7):
inet_ntop: fix a couple of old-style decls
run-command: add kill_async() and is_async_alive()
run-command: support input-fd
daemon: use explicit file descriptor
daemon: use run-command api for async serving
daemon: use full buffered mode for stderr
mingw: compile git-daemon
Mike Pape (4):
mingw: add network-wrappers for daemon
strbuf: add non-variadic function strbuf_vaddf()
mingw: implement syslog
compat: add inet_pton and inet_ntop prototypes
Makefile | 8 ++-
compat/inet_ntop.c | 22 ++------
compat/inet_pton.c | 8 ++-
compat/mingw.c | 111 +++++++++++++++++++++++++++++++++++++++++--
compat/mingw.h | 32 ++++++++++++
daemon.c | 134 ++++++++++++++++++++++++++--------------------------
git-compat-util.h | 9 ++++
run-command.c | 32 ++++++++++++-
run-command.h | 2 +
strbuf.c | 15 ++++--
strbuf.h | 1 +
11 files changed, 274 insertions(+), 100 deletions(-)
^ permalink raw reply
* [PATCH/RFC 01/11] mingw: add network-wrappers for daemon
From: Erik Faye-Lund @ 2009-11-26 0:39 UTC (permalink / raw)
To: msysgit; +Cc: git, dotzenlabs, Erik Faye-Lund
In-Reply-To: <1259195958-2372-1-git-send-email-kusmabite@gmail.com>
From: Mike Pape <dotzenlabs@gmail.com>
git-daemon requires some socket-functionality that is not yet
supported in the Windows-port. This patch adds said functionality,
and makes sure WSAStartup gets called by socket(), since it is the
first network-call in git-daemon. In addition, a check is added to
prevent WSAStartup (and WSACleanup, though atexit) from being
called more than once, since git-daemon calls both socket() and
gethostbyname().
Signed-off-by: Mike Pape <dotzenlabs@gmail.com>
Signed-off-by: Erik Faye-Lund <kusmabite@gmail.com>
---
compat/mingw.c | 60 ++++++++++++++++++++++++++++++++++++++++++++++++++++---
compat/mingw.h | 16 ++++++++++++++
2 files changed, 72 insertions(+), 4 deletions(-)
diff --git a/compat/mingw.c b/compat/mingw.c
index 10d6796..458021b 100644
--- a/compat/mingw.c
+++ b/compat/mingw.c
@@ -983,23 +983,37 @@ char **make_augmented_environ(const char *const *vars)
return env;
}
-/* this is the first function to call into WS_32; initialize it */
-#undef gethostbyname
-struct hostent *mingw_gethostbyname(const char *host)
+static void wsa_init(void)
{
+ static int initialized = 0;
WSADATA wsa;
+ if (initialized)
+ return;
+
if (WSAStartup(MAKEWORD(2,2), &wsa))
die("unable to initialize winsock subsystem, error %d",
WSAGetLastError());
atexit((void(*)(void)) WSACleanup);
+ initialized = 1;
+}
+
+/* this can be the first function to call into WS_32; initialize it */
+#undef gethostbyname
+struct hostent *mingw_gethostbyname(const char *host)
+{
+ wsa_init();
return gethostbyname(host);
}
+/* this can be the first function to call into WS_32; initialize it */
int mingw_socket(int domain, int type, int protocol)
{
+ SOCKET s;
int sockfd;
- SOCKET s = WSASocket(domain, type, protocol, NULL, 0, 0);
+
+ wsa_init();
+ s = WSASocket(domain, type, protocol, NULL, 0, 0);
if (s == INVALID_SOCKET) {
/*
* WSAGetLastError() values are regular BSD error codes
@@ -1029,6 +1043,44 @@ int mingw_connect(int sockfd, struct sockaddr *sa, size_t sz)
return connect(s, sa, sz);
}
+#undef bind
+int mingw_bind(int sockfd, struct sockaddr *sa, size_t sz)
+{
+ SOCKET s = (SOCKET)_get_osfhandle(sockfd);
+ return bind(s, sa, sz);
+}
+
+#undef setsockopt
+int mingw_setsockopt(int sockfd, int lvl, int optname, void *optval, int optlen)
+{
+ SOCKET s = (SOCKET)_get_osfhandle(sockfd);
+ return setsockopt(s, lvl, optname, (const char*)optval, optlen);
+}
+
+#undef listen
+int mingw_listen(int sockfd, int backlog)
+{
+ SOCKET s = (SOCKET)_get_osfhandle(sockfd);
+ return listen(s, backlog);
+}
+
+#undef accept
+int mingw_accept(int sockfd1, struct sockaddr *sa, socklen_t *sz)
+{
+ int sockfd2;
+
+ SOCKET s1 = (SOCKET)_get_osfhandle(sockfd1);
+ SOCKET s2 = accept(s1, sa, sz);
+
+ /* convert into a file descriptor */
+ if ((sockfd2 = _open_osfhandle(s2, O_RDWR|O_BINARY)) < 0) {
+ closesocket(s2);
+ return error("unable to make a socket file descriptor: %s",
+ strerror(errno));
+ }
+ return sockfd2;
+}
+
#undef rename
int mingw_rename(const char *pold, const char *pnew)
{
diff --git a/compat/mingw.h b/compat/mingw.h
index 1978f8a..f362f61 100644
--- a/compat/mingw.h
+++ b/compat/mingw.h
@@ -5,6 +5,7 @@
*/
typedef int pid_t;
+typedef int socklen_t;
#define hstrerror strerror
#define S_IFLNK 0120000 /* Symbolic link */
@@ -33,6 +34,9 @@ typedef int pid_t;
#define F_SETFD 2
#define FD_CLOEXEC 0x1
+#define EAFNOSUPPORT WSAEAFNOSUPPORT
+#define ECONNABORTED WSAECONNABORTED
+
struct passwd {
char *pw_name;
char *pw_gecos;
@@ -182,6 +186,18 @@ int mingw_socket(int domain, int type, int protocol);
int mingw_connect(int sockfd, struct sockaddr *sa, size_t sz);
#define connect mingw_connect
+int mingw_bind(int sockfd, struct sockaddr *sa, size_t sz);
+#define bind mingw_bind
+
+int mingw_setsockopt(int sockfd, int lvl, int optname, void *optval, int optlen);
+#define setsockopt mingw_setsockopt
+
+int mingw_listen(int sockfd, int backlog);
+#define listen mingw_listen
+
+int mingw_accept(int sockfd, struct sockaddr *sa, socklen_t *sz);
+#define accept mingw_accept
+
int mingw_rename(const char*, const char*);
#define rename mingw_rename
--
1.6.5.rc2.7.g4f8d3
^ permalink raw reply related
* [PATCH/RFC 02/11] strbuf: add non-variadic function strbuf_vaddf()
From: Erik Faye-Lund @ 2009-11-26 0:39 UTC (permalink / raw)
To: msysgit; +Cc: git, dotzenlabs, Erik Faye-Lund
In-Reply-To: <1259195958-2372-2-git-send-email-kusmabite@gmail.com>
From: Mike Pape <dotzenlabs@gmail.com>
This patch adds strbuf_vaddf, which takes a va_list as input
instead of the variadic input that strbuf_addf takes. This
is useful for fowarding varargs to strbuf_addf.
Signed-off-by: Mike Pape <dotzenlabs@gmail.com>
Signed-off-by: Erik Faye-Lund <kusmabite@gmail.com>
---
strbuf.c | 15 +++++++++------
strbuf.h | 1 +
2 files changed, 10 insertions(+), 6 deletions(-)
diff --git a/strbuf.c b/strbuf.c
index a6153dc..e1833fb 100644
--- a/strbuf.c
+++ b/strbuf.c
@@ -190,23 +190,18 @@ void strbuf_adddup(struct strbuf *sb, size_t pos, size_t len)
strbuf_setlen(sb, sb->len + len);
}
-void strbuf_addf(struct strbuf *sb, const char *fmt, ...)
+void strbuf_vaddf(struct strbuf *sb, const char *fmt, va_list ap)
{
int len;
- va_list ap;
if (!strbuf_avail(sb))
strbuf_grow(sb, 64);
- va_start(ap, fmt);
len = vsnprintf(sb->buf + sb->len, sb->alloc - sb->len, fmt, ap);
- va_end(ap);
if (len < 0)
die("your vsnprintf is broken");
if (len > strbuf_avail(sb)) {
strbuf_grow(sb, len);
- va_start(ap, fmt);
len = vsnprintf(sb->buf + sb->len, sb->alloc - sb->len, fmt, ap);
- va_end(ap);
if (len > strbuf_avail(sb)) {
die("this should not happen, your snprintf is broken");
}
@@ -214,6 +209,14 @@ void strbuf_addf(struct strbuf *sb, const char *fmt, ...)
strbuf_setlen(sb, sb->len + len);
}
+void strbuf_addf(struct strbuf *sb, const char *fmt, ...)
+{
+ va_list va;
+ va_start(va, fmt);
+ strbuf_vaddf(sb, fmt, va);
+ va_end(va);
+}
+
void strbuf_expand(struct strbuf *sb, const char *format, expand_fn_t fn,
void *context)
{
diff --git a/strbuf.h b/strbuf.h
index d05e056..8686bcb 100644
--- a/strbuf.h
+++ b/strbuf.h
@@ -119,6 +119,7 @@ extern size_t strbuf_expand_dict_cb(struct strbuf *sb, const char *placeholder,
__attribute__((format(printf,2,3)))
extern void strbuf_addf(struct strbuf *sb, const char *fmt, ...);
+extern void strbuf_vaddf(struct strbuf *sb, const char *fmt, va_list ap);
extern size_t strbuf_fread(struct strbuf *, size_t, FILE *);
/* XXX: if read fails, any partial read is undone */
--
1.6.5.rc2.7.g4f8d3
^ permalink raw reply related
* [PATCH/RFC 03/11] mingw: implement syslog
From: Erik Faye-Lund @ 2009-11-26 0:39 UTC (permalink / raw)
To: msysgit; +Cc: git, dotzenlabs, Erik Faye-Lund
In-Reply-To: <1259195958-2372-3-git-send-email-kusmabite@gmail.com>
From: Mike Pape <dotzenlabs@gmail.com>
Syslog does not usually exist on Windows, so we implement our own
using Window's ReportEvent mechanism.
Signed-off-by: Mike Pape <dotzenlabs@gmail.com>
Signed-off-by: Erik Faye-Lund <kusmabite@gmail.com>
---
compat/mingw.c | 51 +++++++++++++++++++++++++++++++++++++++++++++++++++
compat/mingw.h | 15 +++++++++++++++
daemon.c | 2 --
git-compat-util.h | 1 +
4 files changed, 67 insertions(+), 2 deletions(-)
diff --git a/compat/mingw.c b/compat/mingw.c
index 458021b..68116ac 100644
--- a/compat/mingw.c
+++ b/compat/mingw.c
@@ -1255,6 +1255,57 @@ int sigaction(int sig, struct sigaction *in, struct sigaction *out)
return 0;
}
+static HANDLE ms_eventlog;
+
+void openlog(const char *ident, int logopt, int facility) {
+ if (ms_eventlog)
+ return;
+ ms_eventlog = RegisterEventSourceA(NULL, ident);
+}
+
+void syslog(int priority, const char *fmt, ...) {
+ struct strbuf msg;
+ va_list va;
+ WORD logtype;
+
+ strbuf_init(&msg, 0);
+ va_start(va, fmt);
+ strbuf_vaddf(&msg, fmt, va);
+ va_end(va);
+
+ switch (priority) {
+ case LOG_EMERG:
+ case LOG_ALERT:
+ case LOG_CRIT:
+ case LOG_ERR:
+ logtype = EVENTLOG_ERROR_TYPE;
+ break;
+
+ case LOG_WARNING:
+ logtype = EVENTLOG_WARNING_TYPE;
+ break;
+
+ case LOG_NOTICE:
+ case LOG_INFO:
+ case LOG_DEBUG:
+ default:
+ logtype = EVENTLOG_INFORMATION_TYPE;
+ break;
+ }
+
+ ReportEventA(ms_eventlog,
+ logtype,
+ (WORD)NULL,
+ (DWORD)NULL,
+ NULL,
+ 1,
+ 0,
+ (const char **)&msg.buf,
+ NULL);
+
+ strbuf_release(&msg);
+}
+
#undef signal
sig_handler_t mingw_signal(int sig, sig_handler_t handler)
{
diff --git a/compat/mingw.h b/compat/mingw.h
index f362f61..576b1a1 100644
--- a/compat/mingw.h
+++ b/compat/mingw.h
@@ -37,6 +37,19 @@ typedef int socklen_t;
#define EAFNOSUPPORT WSAEAFNOSUPPORT
#define ECONNABORTED WSAECONNABORTED
+#define LOG_PID 0x01
+
+#define LOG_EMERG 0
+#define LOG_ALERT 1
+#define LOG_CRIT 2
+#define LOG_ERR 3
+#define LOG_WARNING 4
+#define LOG_NOTICE 5
+#define LOG_INFO 6
+#define LOG_DEBUG 7
+
+#define LOG_DAEMON (3<<3)
+
struct passwd {
char *pw_name;
char *pw_gecos;
@@ -157,6 +170,8 @@ int sigaction(int sig, struct sigaction *in, struct sigaction *out);
int link(const char *oldpath, const char *newpath);
int symlink(const char *oldpath, const char *newpath);
int readlink(const char *path, char *buf, size_t bufsiz);
+void openlog(const char *ident, int logopt, int facility);
+void syslog(int priority, const char *fmt, ...);
/*
* replacements of existing functions
diff --git a/daemon.c b/daemon.c
index 1b5ada6..07d7356 100644
--- a/daemon.c
+++ b/daemon.c
@@ -4,8 +4,6 @@
#include "run-command.h"
#include "strbuf.h"
-#include <syslog.h>
-
#ifndef HOST_NAME_MAX
#define HOST_NAME_MAX 256
#endif
diff --git a/git-compat-util.h b/git-compat-util.h
index ef60803..33a8e33 100644
--- a/git-compat-util.h
+++ b/git-compat-util.h
@@ -105,6 +105,7 @@
#include <netdb.h>
#include <pwd.h>
#include <inttypes.h>
+#include <syslog.h>
#if defined(__CYGWIN__)
#undef _XOPEN_SOURCE
#include <grp.h>
--
1.6.5.rc2.7.g4f8d3
^ permalink raw reply related
* [PATCH/RFC 04/11] compat: add inet_pton and inet_ntop prototypes
From: Erik Faye-Lund @ 2009-11-26 0:39 UTC (permalink / raw)
To: msysgit; +Cc: git, dotzenlabs, Erik Faye-Lund
In-Reply-To: <1259195958-2372-4-git-send-email-kusmabite@gmail.com>
From: Mike Pape <dotzenlabs@gmail.com>
Windows doesn't have inet_pton and inet_ntop, so
add prototypes in git-compat-util.h for them.
At the same time include git-compat-util.h in
the sources for these functions, so they use the
network-wrappers from there on Windows.
Signed-off-by: Mike Pape <dotzenlabs@gmail.com>
Signed-off-by: Erik Faye-Lund <kusmabite@gmail.com>
---
Makefile | 2 ++
compat/inet_ntop.c | 6 +++---
compat/inet_pton.c | 8 +++++---
git-compat-util.h | 8 ++++++++
4 files changed, 18 insertions(+), 6 deletions(-)
diff --git a/Makefile b/Makefile
index 70cee6d..3b01694 100644
--- a/Makefile
+++ b/Makefile
@@ -1227,9 +1227,11 @@ endif
endif
ifdef NO_INET_NTOP
LIB_OBJS += compat/inet_ntop.o
+ BASIC_CFLAGS += -DNO_INET_NTOP
endif
ifdef NO_INET_PTON
LIB_OBJS += compat/inet_pton.o
+ BASIC_CFLAGS += -DNO_INET_PTON
endif
ifdef NO_ICONV
diff --git a/compat/inet_ntop.c b/compat/inet_ntop.c
index f444982..e5b46a0 100644
--- a/compat/inet_ntop.c
+++ b/compat/inet_ntop.c
@@ -17,9 +17,9 @@
#include <errno.h>
#include <sys/types.h>
-#include <sys/socket.h>
-#include <netinet/in.h>
-#include <arpa/inet.h>
+
+#include "../git-compat-util.h"
+
#include <stdio.h>
#include <string.h>
diff --git a/compat/inet_pton.c b/compat/inet_pton.c
index 4078fc0..2ec995e 100644
--- a/compat/inet_pton.c
+++ b/compat/inet_pton.c
@@ -17,9 +17,9 @@
#include <errno.h>
#include <sys/types.h>
-#include <sys/socket.h>
-#include <netinet/in.h>
-#include <arpa/inet.h>
+
+#include "../git-compat-util.h"
+
#include <stdio.h>
#include <string.h>
@@ -41,7 +41,9 @@
*/
static int inet_pton4(const char *src, unsigned char *dst);
+#ifndef NO_IPV6
static int inet_pton6(const char *src, unsigned char *dst);
+#endif
/* int
* inet_pton4(src, dst)
diff --git a/git-compat-util.h b/git-compat-util.h
index 33a8e33..27fa601 100644
--- a/git-compat-util.h
+++ b/git-compat-util.h
@@ -340,6 +340,14 @@ static inline char *gitstrchrnul(const char *s, int c)
}
#endif
+#ifdef NO_INET_PTON
+int inet_pton(int af, const char *src, void *dst);
+#endif
+
+#ifdef NO_INET_NTOP
+const char *inet_ntop(int af, const void *src, char *dst, size_t size);
+#endif
+
extern void release_pack_memory(size_t, int);
extern char *xstrdup(const char *str);
--
1.6.5.rc2.7.g4f8d3
^ permalink raw reply related
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