* Re: git merge and cherry-pick and duplicated commits?
From: skillzero @ 2009-01-14 7:33 UTC (permalink / raw)
To: git
In-Reply-To: <5EA96780-EF4C-4B31-9C60-6ABAF21663FA@silverinsanity.com>
I guess maybe a better question is how do people normally handle
situations like mine where I did some work on branch X and I later
realize I need only a portion of that work on branch Y? I'm not sure
how I can change my workflow to completely eliminate these situations.
For example, I often start a branch to add a new feature and I end up
fixing bug A on that branch. Then other people on my team decide they
need the fix for bug A immediately and can't wait for me to finish my
feature branch and do a full merge.
Is there some way I can change my workflow such that I can fix bug A
(maybe on a separate branch?) and somehow apply it to both both
branches in a way that won't result in duplicate commits?
Does this kind of thing ever happen with the Linux kernel or git
itself: somebody does a fix as part of their topic branch and the
Linux kernel or git master wants that particular fix now, but is not
ready for the full topic branch? Would they just suggest the fix be
separated into its own topic branch and that merged? If so, how would
that new topic branch merge into the original topic branch without
resulting in a duplicate commit when it's later merged into master?
^ permalink raw reply
* Re: git merge and cherry-pick and duplicated commits?
From: Johannes Sixt @ 2009-01-14 7:34 UTC (permalink / raw)
To: skillzero; +Cc: git
In-Reply-To: <2729632a0901132221r746144a1y9628615be1c6ad04@mail.gmail.com>
skillzero@gmail.com schrieb:
> Is there any way to apply a commit to 2 different branches (which have
> diverged) in a way that git will remember so that when the 2 branches
> merge later, it won't result in duplicate commits? I find that I often
> make changes that days or weeks later find out that some other branch
> needs that change and by then, there have been lots of commits to both
> branches after the commit I want.
Well, the way to do it is "careful planning".
If you have a *slight* suspicion that some change *might* be needed on a
different branch, then:
1. you commit the change on a branch of its own that forks off of the
merge-base of *all* the branches that *might* need it;
2. next, you merge this fix-up branch into the branch where you need it
first, which is very likely your current topic-under-development.
3. Later you can merge the branch into the other branches if you find that
it is really needed.
If you don't have the slight suspicion, then you have to take the
second-best route, namely to cherry-pick the commit onto a branch just
like in 1. above, and continue with 2. and 3. In this case you have the
commit twice, but not more than that.
-- Hannes
^ permalink raw reply
* git Thunderbird Synching
From: Nicholas LaRoche @ 2009-01-14 7:52 UTC (permalink / raw)
To: git
Has anyone tried to synch a Thunderbird profile between two computers
with git?
I want to do something like this with my main profile, but I'm concerned
that if I send/receive email on either machine independently that there
will be corruption in some of the files when I push back to my main box.
Regards,
Nick
^ permalink raw reply
* jgit merge question
From: David Birchfield @ 2009-01-14 7:55 UTC (permalink / raw)
To: git
In-Reply-To: <S1760244AbZANHqN/20090114074613Z+1959@vger.kernel.org>
Hi all,
My apologies in advance for the newbie question, and I hope this is
the correct forum - please let me know if there is a better place.
I have been working with the JGit library and with the pgm files and
other documentation I have been able to implement most of the basic
functions that I need for my testing application - including fetch.
This is great! However, I have not been able to successfully
implement the merge function with JGit. There is some reference to
this in the mail archive, but I cannot find any of the merge code that
is referenced in the distribution. I have tried to pull from
pgm.MergeBase.java, but that hasn't been successful.
My question:
Is there any sort of tutorial or reference code snippet that
implements merge? Or is there a trick to getting the MergeBase code
to achieve a basic merge?
Thanks in advance!
Best,
David
^ permalink raw reply
* Re: git merge and cherry-pick and duplicated commits?
From: skillzero @ 2009-01-14 8:08 UTC (permalink / raw)
To: git
In-Reply-To: <496D9572.2090303@viscovery.net>
On Tue, Jan 13, 2009 at 11:34 PM, Johannes Sixt <j.sixt@viscovery.net> wrote:
> Well, the way to do it is "careful planning".
>
> If you have a *slight* suspicion that some change *might* be needed on a
> different branch, then:
>
> 1. you commit the change on a branch of its own that forks off of the
> merge-base of *all* the branches that *might* need it;
>
> 2. next, you merge this fix-up branch into the branch where you need it
> first, which is very likely your current topic-under-development.
>
> 3. Later you can merge the branch into the other branches if you find that
> it is really needed.
If I create a separate bug-fix-only branch X that forks from the
latest common commit of all the branches that might need it and some
of those branches already have commits after that merge base (e.g.
branch Z is 5 commits after the common merge base by the time I fix
the bug), will git be able to merge the new branch X into Z in a way
that will allow me to also merge branch X into my original feature
branch A and then later merge A into Z without duplicating the commit
that is now in both branch X and Z?
It seems like I'd run into my original duplicate commit problem
because even though branch X was originally based off the same parent
commit, it will have a different parent when it is merged into Z
because Z is no longer at that common merge commit (it's 5 commits
beyond it).
^ permalink raw reply
* Re: [BUG PATCH RFC] mailinfo: correctly handle multiline 'Subject:' header
From: Kirill Smelkov @ 2009-01-14 8:19 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Alexander Potashev, git
In-Reply-To: <20090113093916.GA25471@landau.phys.spbu.ru>
On Tue, Jan 13, 2009 at 12:39:16PM +0300, Kirill Smelkov wrote:
> On Mon, Jan 12, 2009 at 03:27:44PM -0800, Junio C Hamano wrote:
> > Kirill Smelkov <kirr@landau.phys.spbu.ru> writes:
[...]
> > But doesn't this
> >
> > > From nobody Mon Sep 17 00:00:00 2001
> > > -From: A
> > > +From: A (zzz)
> > > U
> > > Thor
> > > - <a.u.thor@example.com>
> > > + <a.u.thor@example.com> (Comment)
> >
> > regress for people who spell their names like this?
> >
> > From: john.doe@email.xz (John Doe)
>
> I think everything is ok:
[...]
Just in case it got spam-detected again:
http://marc.info/?l=git&m=123183962105146&w=2
Thanks,
Kirill
^ permalink raw reply
* Re: git merge and cherry-pick and duplicated commits?
From: Nanako Shiraishi @ 2009-01-14 8:31 UTC (permalink / raw)
To: skillzero; +Cc: git
In-Reply-To: <2729632a0901132221r746144a1y9628615be1c6ad04@mail.gmail.com>
Quoting skillzero@gmail.com:
> The problem is, by the time I wanted to do the cherry-pick, I had
> already committed other stuff to the branch. I tried doing 'git rebase
> master branch' when on master and it just applied all the stuff from
> master to branch.
>
> Is there any way to apply a commit to 2 different branches (which have
> diverged) in a way that git will remember so that when the 2 branches
> merge later, it won't result in duplicate commits? I find that I often
> make changes that days or weeks later find out that some other branch
> needs that change and by then, there have been lots of commits to both
> branches after the commit I want.
Johennes Sixt gave a good answer. You need to think before making your commits while you are developing to separate what change belongs to common code base and what change belongs to a specific feature.
I was reading gitster's blog (he has several "git tutorial" articles recently) and he talks about how to commit a change to a branch different from what you originally developed it on in today's entry. You may find it instructive, but the procedure is after you think about it and decide what change goes where.
--
Nanako Shiraishi
http://ivory.ap.teacup.com/nanako3/
^ permalink raw reply
* Re: git-svn fails to fetch repository
From: Vladimir Pouzanov @ 2009-01-14 8:32 UTC (permalink / raw)
To: git
In-Reply-To: <76718490901131658l108852f2y9a25eb9133d6e96d@mail.gmail.com>
Jay Soffian <jaysoffian <at> gmail.com> writes:
> So you're adding the "use Carp..." and "warn..." lines.
>
> Then try the import again. That should at least show why the svn_delta
> temp file is being acquired twice.
Output is pretty long so I've put in on pastebin:
http://pastebin.com/m210be905
^ permalink raw reply
* Re: git merge and cherry-pick and duplicated commits?
From: Johannes Sixt @ 2009-01-14 8:34 UTC (permalink / raw)
To: skillzero; +Cc: git
In-Reply-To: <2729632a0901140008r59e429aeq3ce367e1bc7df71@mail.gmail.com>
[Please reply-to-all on this list, to keep Cc: list]
skillzero@gmail.com schrieb:
> On Tue, Jan 13, 2009 at 11:34 PM, Johannes Sixt <j.sixt@viscovery.net> wrote:
>
>> Well, the way to do it is "careful planning".
>>
>> If you have a *slight* suspicion that some change *might* be needed on a
>> different branch, then:
>>
>> 1. you commit the change on a branch of its own that forks off of the
>> merge-base of *all* the branches that *might* need it;
>>
>> 2. next, you merge this fix-up branch into the branch where you need it
>> first, which is very likely your current topic-under-development.
>>
>> 3. Later you can merge the branch into the other branches if you find that
>> it is really needed.
>
> If I create a separate bug-fix-only branch X that forks from the
> latest common commit of all the branches that might need it and some
> of those branches already have commits after that merge base (e.g.
> branch Z is 5 commits after the common merge base by the time I fix
> the bug), will git be able to merge the new branch X into Z in a way
> that will allow me to also merge branch X into my original feature
> branch A and then later merge A into Z without duplicating the commit
> that is now in both branch X and Z?
>
> It seems like I'd run into my original duplicate commit problem
> because even though branch X was originally based off the same parent
> commit, it will have a different parent when it is merged into Z
> because Z is no longer at that common merge commit (it's 5 commits
> beyond it).
After you created the fixup, you have this situation:
o--o--o <- A (feature branch)
/
--o--x <- X (the fix-up branch)
\
o--o--o <- Z (probably your master)
You merge the fix-up into the feature branch and continue developing the
feature:
o--o--o--M--o--o <- A
/ /
--o--x-----' <- X
\
o--o--o <- Z
Other people need the fix in Z right now, so you merge it into Z as well:
o--o--o--M--o--o <- A
/ /
--o--x-----< <- X
\ \
o--o--o--N <- Z
You complete your feature and merge it into Z:
o--o--o--M--o--o <- A
/ / \
--o--x-----< \ <- X
\ \ \
o--o--o--N---------O <- Z
The fix-up commit is only once in your history.
-- Hannes
^ permalink raw reply
* Re: git merge and cherry-pick and duplicated commits?
From: Boaz Harrosh @ 2009-01-14 8:38 UTC (permalink / raw)
To: skillzero; +Cc: git
In-Reply-To: <2729632a0901140008r59e429aeq3ce367e1bc7df71@mail.gmail.com>
skillzero@gmail.com wrote:
> On Tue, Jan 13, 2009 at 11:34 PM, Johannes Sixt <j.sixt@viscovery.net> wrote:
>
>> Well, the way to do it is "careful planning".
>>
>> If you have a *slight* suspicion that some change *might* be needed on a
>> different branch, then:
>>
>> 1. you commit the change on a branch of its own that forks off of the
>> merge-base of *all* the branches that *might* need it;
>>
>> 2. next, you merge this fix-up branch into the branch where you need it
>> first, which is very likely your current topic-under-development.
>>
>> 3. Later you can merge the branch into the other branches if you find that
>> it is really needed.
>
> If I create a separate bug-fix-only branch X that forks from the
> latest common commit of all the branches that might need it and some
> of those branches already have commits after that merge base (e.g.
> branch Z is 5 commits after the common merge base by the time I fix
> the bug), will git be able to merge the new branch X into Z in a way
> that will allow me to also merge branch X into my original feature
> branch A and then later merge A into Z without duplicating the commit
> that is now in both branch X and Z?
>
> It seems like I'd run into my original duplicate commit problem
> because even though branch X was originally based off the same parent
> commit, it will have a different parent when it is merged into Z
> because Z is no longer at that common merge commit (it's 5 commits
> beyond it).
> --
No, if you use merges it will not duplicate. It will know exactly what
to do because it is the same commit in all branches.
Only git-cherry-pick will duplicate the same patch, but as a different
new commit. Then when merging the merge sees a merge conflict but since
it is exactly the same change it will accept it. The same happens if
two different patches have exact same hunk, the merge is smart to accept
the same change from two sources. What happen with cherry-pick is that all
the hunks match.
Boaz
^ permalink raw reply
* Re: git merge and cherry-pick and duplicated commits?
From: Thomas Rast @ 2009-01-14 8:41 UTC (permalink / raw)
To: skillzero; +Cc: git
In-Reply-To: <2729632a0901132221r746144a1y9628615be1c6ad04@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 1442 bytes --]
skillzero@gmail.com wrote:
> I thought git would realize that master already had those 2 commits
> and not add them again when merging?
[later]
> That's what I was somewhat disappointed by. Even though the result of
> the commit had a different hash, I assumed git would keep some kind of
> internal per-commit hash so it could tell later that two commits were
> the same and not re-apply them.
I think there's an important misunderstanding here: merging A into B
does *not* have anything to do with commits, or history for that
matter, beyond the differences from $(git merge-base A B) to A and
B.[*]
Along the same lines, nothing is ever re-applied during merging.
git-merge just figures out that you made the same change on both
sides, so it must have been a good change, so it must go into the end
result. *How* you arrived at the same change---say, by
cherry-picking, or by getting the same result in that region from
otherwise different commits, or even from several commits---does *not*
matter in any way.
You can use 'git cherry', 'git log --left-right --cherry-pick', and
similar tools to find commits that are cherry-picked "duplicates", but
unless you rewrite history, they are there to stay.
[*] This is a simplification since as soon as the merge-base is not
unique, merge-recursive will actually start looking into history
further back.
--
Thomas Rast
trast@{inf,student}.ethz.ch
[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* Re: git-patches list?
From: Felipe Contreras @ 2009-01-14 8:44 UTC (permalink / raw)
To: Akira Kitada; +Cc: Junio C Hamano, git
In-Reply-To: <90bb445a0901130755t6ea98bcco6b6663d806dcc2e6@mail.gmail.com>
On Tue, Jan 13, 2009 at 5:55 PM, Akira Kitada <akitada@gmail.com> wrote:
> This list seems to be used as a bug tracker, discussing git development,
> user questions, announcement etc.
> I thought this is so unusual list that something should be wrong here,
> but it turned out that it looks working right in mysteryous way.
> I take that back now.
> Hmm, interesting...
Yes, it's definitely not the norm on other projects, but perhaps it should be.
That's how the linux kernel mailing list works. There are other
mailing lists for the different sub-systems, but there's no separation
between bugs, discussion and patches, which makes sense, because quite
often bugs and patches trigger discussions, and bug discussions
trigger patches.
Following this approach perhaps it would make sense to create a
separate mailing list for jgit and similar stuff.
--
Felipe Contreras
^ permalink raw reply
* Re: question about COMMIT_EDITMSG crlf
From: Juanma Barranquero @ 2009-01-14 9:01 UTC (permalink / raw)
To: Johannes Sixt; +Cc: Frank Li, git
In-Reply-To: <496D91CE.1000504@viscovery.net>
On Wed, Jan 14, 2009 at 08:18, Johannes Sixt <j.sixt@viscovery.net> wrote:
> No, there isn't. But perhaps you can use WordPad instead of Notepad? There
> are reports that this worked.
Or Notepad2:
http://www.flos-freeware.ch/notepad2.html
Juanma
^ permalink raw reply
* Re: .ft tag in man
From: Michael J Gruber @ 2009-01-14 10:11 UTC (permalink / raw)
To: Todd Zullinger; +Cc: Junio C Hamano, bill lam, git
In-Reply-To: <20090114064510.GZ18365@inocybe.teonanacatl.org>
Todd Zullinger venit, vidit, dixit 14.01.2009 07:45:
...
> I began seeing this on Fedora 10. Defining DOCBOOK_XSL_172 fixed
> that issue, but seems to have caused another. :/
>
> For example, in git-diff.1, without DOCBOOK_XSL_172, I see:
>
> .ft C
> $ git diff (1)
> $ git diff --cached (2)
> $ git diff HEAD (3)
> .ft
>
> With DOCBOOK_XSL_172, I get this:
>
> $ git diff ▓fB(3)▓fR
> $ git diff --cached ▓fB(2)▓fR
> $ git diff HEAD ▓fB(3)▓fR
>
> The '.ft' problem is gone, but '\fB' and '\fR' are replaced by '▓fB'
> and '▓fR', respectively. The paragraphs that follow such a list of
> commands show more ugliness:
>
> ⌂sp ▓fB1. ▓fRChanges in the working tree not yet staged for the
> next commit. ⌂br ▓fB2. ▓fRChanges between the index and your
> last commit; what you would be committing if you run "git commit"
> without "-a" option. ⌂br ▓fB3. ▓fRChanges in the working tree
> since your last commit; what you would be committing if you run
> "git commit -a" ⌂br
>
> Defining ASCIIDOC8 seems to have no effect on this problem.
>
>> Perhaps you are using different version of asciidoc/docbook/xmlto
>> toolchain?
>
> On Fedora 10, these are the versions:
>
> asciidoc-8.2.5-2.fc9
> docbook-dtds-1.0-41.fc10
> docbook-style-xsl-1.74.0-4.fc10
> xmlto-0.0.21-2.fc10
>
> Fedora 9 has:
>
> asciidoc-8.2.5-2.fc9
> docbook-dtds-1.0-38.fc9
> docbook-style-xsl-1.73.2-10.fc9
> xmlto-0.0.20-3.fc9
The problem can be seen even in the F10 release packages for git. Shame
on them ;)
When I get back to my F9 box I'll try upgrading those packages one by
one to their F10 versions (hoping dependencies don't connect all of them).
Michael
^ permalink raw reply
* Re: [PATCH next] git-notes: fix printing of multi-line notes
From: Johannes Schindelin @ 2009-01-14 10:14 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Tor Arne Vestbø, git
In-Reply-To: <7v3afm758u.fsf@gitster.siamese.dyndns.org>
[-- Attachment #1: Type: TEXT/PLAIN, Size: 875 bytes --]
Hi,
On Tue, 13 Jan 2009, Junio C Hamano wrote:
> Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
>
> > On Tue, 13 Jan 2009, Tor Arne Vestbø wrote:
> >
> >> The line length was read from the same position every time,
> >> causing mangled output when printing notes with multiple lines.
> >>
> >> Also, adding new-line manually for each line ensures that we
> >> get a new-line between commits, matching git-log for commits
> >> without notes.
> >>
> >> Signed-off-by: Tor Arne Vestbø <tavestbo@trolltech.com>
> >> ---
> >
> > Patch looks good, so
> >
> > Acked-by: Johannes Schindelin <johannes.schindelin@gmx.de>
> >
> > For extra browny points, you could add a test with multi-line notes.
>
> Yeah, not just "extra", having tests is a good way to make sure a new
> feature like this evolves healthily.
Oh, and of course I meant "brownie"...
Ducks,
Dscho
^ permalink raw reply
* Re: jgit merge question
From: Johannes Schindelin @ 2009-01-14 10:26 UTC (permalink / raw)
To: David Birchfield; +Cc: git
In-Reply-To: <4EDE3D74-CEA3-473C-ADD1-03B79AAB9EDF@asu.edu>
Hi,
On Wed, 14 Jan 2009, David Birchfield wrote:
> I have been working with the JGit library and with the pgm files and
> other documentation I have been able to implement most of the basic
> functions that I need for my testing application - including fetch.
> This is great! However, I have not been able to successfully implement
> the merge function with JGit. There is some reference to this in the
> mail archive, but I cannot find any of the merge code that is referenced
> in the distribution.
You mean
http://thread.gmane.org/gmane.comp.version-control.git/100524/focus=100589
?
Yes, it has not been implemented, basically because it needs a diff
implementation, and I constantly run out of time working on it. I have
something that works, but needs lots of improvements to be usable
(basically, it has to avoid deep recursion depths).
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH] Noted that vi is the final choice of editor in git help commit
From: Adeodato Simó @ 2009-01-14 9:55 UTC (permalink / raw)
To: Craig Fratrik; +Cc: git
In-Reply-To: <1231886016-31675-1-git-send-email-cfratrik@gmail.com>
* Craig Fratrik [Tue, 13 Jan 2009 14:33:36 -0800]:
> The editor used to edit the commit log message will be chosen from the
> GIT_EDITOR environment variable, the core.editor configuration variable, the
> -VISUAL environment variable, or the EDITOR environment variable (in that
> -order).
> +VISUAL environment variable, the EDITOR environment variable, or finally 'vi'
> +(in that order).
May I suggest:
The editor used to edit the commit log message will be chosen from the
GIT_EDITOR environment variable, the core.editor configuration variable, the
VISUAL environment variable, or the EDITOR environment variable (in that
-order).
+order). If none of those are set, "vi" will be used.
--
Adeodato Simó dato at net.com.org.es
Debian Developer adeodato at debian.org
A lie can go round the world before the truth has got its boots on.
-- Terry Pratchett
^ permalink raw reply
* Re: [RFC/PATCH] gitweb: Fix nested links problem with ref markers
From: Jakub Narebski @ 2009-01-14 10:39 UTC (permalink / raw)
To: Giuseppe Bilotta; +Cc: git
In-Reply-To: <cb7bb73a0901131956s7f441c38o3a0b1e5f456a3cd3@mail.gmail.com>
On Wed, 14 Jan 2009, Giuseppe Bilotta wrote:
> On Tue, Jan 13, 2009 at 7:17 PM, Jakub Narebski <jnareb@gmail.com> wrote:
>> On Tue, 13 Jan 2009, Giuseppe Bilotta wrote:
[...]
>>> The float thing was the second suggestion I was given on www-style.
>>
>> What was the first suggestion? And what is www-style?
>
> The first suggestion was to just leave things as they are. www-style
> is www-style@w3c.org, the CSS mailing list of the W3C
Thanks.
>>> Can you provide a patch I can apply to my tree for testing to see how
>>> it comes up?
>>
>> Here it is. Note that CSS could be I think reduced. The size of
>> gitweb.perl changes is affected by changing calling convention for
>> git_print_header_html subroutine.
>
> It's funny, I was working on a very similar patch myself a couple of
> days ago, but couldn't get the horizontal filler after the link to
> work properly, which is why I asked on www-style.
>
> I'll test your patch and let you know.
I am checking 'log' view of git repository; it should have enough
ref markers to test this issue.
It works also in Konqueror 3.5.3-0.2.fc4...
>> There is also strange artifact at least in Mozilla 1.17.2: if I hover
>> over ref marker, the subject (title) gets darker background. Curious...
>
> Might be some kind of bug with the capturing vs bubbling phase.
...but the same artifact can be seen too. Also I am not entirely
pleased with the way things behave on mouseover. It is a pity that
you cannot style element using CSS2.1 based on the pseudo-class :hover
of descendant element, or/and pseudo-class of sibling element, which
nevertheless overlays given element.
--
Jakub Narebski
Poland
^ permalink raw reply
* [PATCH 1/3] git-daemon: single-line logs
From: Jan Engelhardt @ 2009-01-14 10:48 UTC (permalink / raw)
To: git
parent v1.6.1
git-daemon: single-line logs
Having just a single line per connection attempt, much like Apache
httpd2 access logs, makes log parsing much easier, especially when
just glancing over it non-automated.
Signed-off-by: Jan Engelhardt <jengelh@medozas.de>
---
daemon.c | 15 ++++++---------
1 file changed, 6 insertions(+), 9 deletions(-)
Index: git-1.6.1/daemon.c
===================================================================
--- git-1.6.1.orig/daemon.c
+++ git-1.6.1/daemon.c
@@ -295,12 +295,13 @@ static int git_daemon_config(const char
return 0;
}
-static int run_service(char *dir, struct daemon_service *service)
+static int run_service(char *dir, struct daemon_service *service,
+ const char *origin, const char *vhost)
{
const char *path;
int enabled = service->enabled;
- loginfo("Request %s for '%s'", service->name, dir);
+ loginfo("%s->%s %s \"%s\"\n", origin, vhost, service->name, dir);
if (!enabled && !service->overridable) {
logerror("'%s': service not enabled.", service->name);
@@ -507,10 +508,10 @@ static void parse_extra_args(char *extra
static int execute(struct sockaddr *addr)
{
static char line[1000];
+ char addrbuf[256] = "";
int pktlen, len, i;
if (addr) {
- char addrbuf[256] = "";
int port = -1;
if (addr->sa_family == AF_INET) {
@@ -529,7 +530,6 @@ static int execute(struct sockaddr *addr
port = ntohs(sin6_addr->sin6_port);
#endif
}
- loginfo("Connection from %s:%d", addrbuf, port);
setenv("REMOTE_ADDR", addrbuf, 1);
}
else {
@@ -541,10 +541,6 @@ static int execute(struct sockaddr *addr
alarm(0);
len = strlen(line);
- if (pktlen != len)
- loginfo("Extended attributes (%d bytes) exist <%.*s>",
- (int) pktlen - len,
- (int) pktlen - len, line + len + 1);
if (len && line[len-1] == '\n') {
line[--len] = 0;
pktlen--;
@@ -569,7 +565,8 @@ static int execute(struct sockaddr *addr
* Note: The directory here is probably context sensitive,
* and might depend on the actual service being performed.
*/
- return run_service(line + namelen + 5, s);
+ return run_service(line + namelen + 5, s,
+ addrbuf, hostname);
}
}
^ permalink raw reply
* [PATCH 2/3] git-daemon: use getnameinfo to resolve hostname
From: Jan Engelhardt @ 2009-01-14 10:48 UTC (permalink / raw)
To: git
In-Reply-To: <alpine.LSU.2.00.0901141147120.16109@fbirervta.pbzchgretzou.qr>
parent v1.6.1
git-daemon: use getnameinfo to resolve hostname
This is much shorter than inet_ntop'ing, and also translated
unresolvable addresses into a string.
Signed-off-by: Jan Engelhardt <jengelh@medozas.de>
---
daemon.c | 26 +++++++-------------------
1 file changed, 7 insertions(+), 19 deletions(-)
Index: git-1.6.1/daemon.c
===================================================================
--- git-1.6.1.orig/daemon.c
+++ git-1.6.1/daemon.c
@@ -512,25 +512,13 @@ static int execute(struct sockaddr *addr
int pktlen, len, i;
if (addr) {
- int port = -1;
-
- if (addr->sa_family == AF_INET) {
- struct sockaddr_in *sin_addr = (void *) addr;
- inet_ntop(addr->sa_family, &sin_addr->sin_addr, addrbuf, sizeof(addrbuf));
- port = ntohs(sin_addr->sin_port);
-#ifndef NO_IPV6
- } else if (addr && addr->sa_family == AF_INET6) {
- struct sockaddr_in6 *sin6_addr = (void *) addr;
-
- char *buf = addrbuf;
- *buf++ = '['; *buf = '\0'; /* stpcpy() is cool */
- inet_ntop(AF_INET6, &sin6_addr->sin6_addr, buf, sizeof(addrbuf) - 1);
- strcat(buf, "]");
-
- port = ntohs(sin6_addr->sin6_port);
-#endif
- }
- setenv("REMOTE_ADDR", addrbuf, 1);
+ i = getnameinfo(addr, (addr->sa_family == AF_INET6) ?
+ sizeof(struct sockaddr_in6) : sizeof(struct sockaddr_in),
+ addrbuf, sizeof(addrbuf), NULL, 0, 0);
+ if (i == 0)
+ setenv("REMOTE_ADDR", addrbuf, 1);
+ else
+ unsetenv("REMOTE_ADDR");
}
else {
unsetenv("REMOTE_ADDR");
^ permalink raw reply
* [PATCH 3/3] git-daemon: vhost support
From: Jan Engelhardt @ 2009-01-14 10:49 UTC (permalink / raw)
To: git
In-Reply-To: <alpine.LSU.2.00.0901141148130.16109@fbirervta.pbzchgretzou.qr>
parent v1.6.1
git-daemon: support vhosts
Since git clients usually send the target hostname in the request
similar to the "Host:" HTTP header, one can do virtual hosting.
Signed-off-by: Jan Engelhardt <jengelh@medozas.de>
---
daemon.c | 22 +++++++++++++++++++---
1 file changed, 19 insertions(+), 3 deletions(-)
Index: git-1.6.1/daemon.c
===================================================================
--- git-1.6.1.orig/daemon.c
+++ git-1.6.1/daemon.c
@@ -2,6 +2,7 @@
#include "pkt-line.h"
#include "exec_cmd.h"
+#include <stdbool.h>
#include <syslog.h>
#ifndef HOST_NAME_MAX
@@ -21,7 +22,7 @@ static const char daemon_usage[] =
" [--timeout=n] [--init-timeout=n] [--max-connections=n]\n"
" [--strict-paths] [--base-path=path] [--base-path-relaxed]\n"
" [--user-path | --user-path=path]\n"
-" [--interpolated-path=path]\n"
+" [--interpolated-path=path] [--vhost]\n"
" [--reuseaddr] [--detach] [--pid-file=file]\n"
" [--[enable|disable|allow-override|forbid-override]=service]\n"
" [--inetd | [--listen=host_or_ipaddr] [--port=n]\n"
@@ -36,6 +37,7 @@ static int strict_paths;
static int export_all_trees;
/* Take all paths relative to this one if non-NULL */
+static bool enable_vhosting;
static char *base_path;
static char *interpolated_path;
static int base_path_relaxed;
@@ -309,8 +311,18 @@ static int run_service(char *dir, struct
return -1;
}
- if (!(path = path_ok(dir)))
- return -1;
+ if (enable_vhosting) {
+ char vdir[256];
+
+ if (avoid_alias(dir) != 0)
+ return -1;
+ snprintf(vdir, sizeof(vdir), "/%s%s", hostname, dir);
+ if ((path = path_ok(vdir)) == NULL)
+ return -1;
+ } else {
+ if ((path = path_ok(dir)) == NULL)
+ return -1;
+ }
/*
* Security on the cheap.
@@ -1046,6 +1058,10 @@ int main(int argc, char **argv)
make_service_overridable(arg + 18, 0);
continue;
}
+ if (strcmp(arg, "--vhost") == 0) {
+ enable_vhosting = true;
+ continue;
+ }
if (!strcmp(arg, "--")) {
ok_paths = &argv[i+1];
break;
^ permalink raw reply
* Re: [PATCH] Noted that vi is the final choice of editor in git help commit
From: Michael J Gruber @ 2009-01-14 11:14 UTC (permalink / raw)
To: Adeodato Simó; +Cc: Craig Fratrik, git
In-Reply-To: <20090114095512.GA29927@chistera.yi.org>
Adeodato Simó venit, vidit, dixit 14.01.2009 10:55:
> * Craig Fratrik [Tue, 13 Jan 2009 14:33:36 -0800]:
>
>> The editor used to edit the commit log message will be chosen from the
>> GIT_EDITOR environment variable, the core.editor configuration variable, the
>> -VISUAL environment variable, or the EDITOR environment variable (in that
>> -order).
>> +VISUAL environment variable, the EDITOR environment variable, or finally 'vi'
>> +(in that order).
>
> May I suggest:
>
> The editor used to edit the commit log message will be chosen from the
> GIT_EDITOR environment variable, the core.editor configuration variable, the
> VISUAL environment variable, or the EDITOR environment variable (in that
> -order).
> +order). If none of those are set, "vi" will be used.
>
+order). If none of those are set, "vi" will be used unless TERM is
+unset or set to "dumb".
There is also some special parsing of the value but I don't think it
needs to be advertised. The terminal-less case, on the other hand, may
be relevant for scripters and ssh'ers.
Cheers,
Michael
^ permalink raw reply
* What's cooking in git.git (Jan 2009, #03; Wed, 14)
From: Junio C Hamano @ 2009-01-14 11:32 UTC (permalink / raw)
To: git
Here are the topics that have been cooking. Commits prefixed
with '-' are only in 'pu' while commits prefixed with '+' are
in 'next'. The ones marked with '.' do not appear in any of
the branches, but I am still holding onto them.
The topics list the commits in reverse chronological order. The
topics meant to be merged to the maintenance series have "maint-"
in their names.
----------------------------------------------------------------
[New Topics]
* kb/am-directory (Sun Jan 11 22:21:48 2009 -0800) 1 commit
+ git-am: add --directory=<dir> option
This is "third-time-lucky, perhaps?" resurrection. I do not think I'd be
using this very often, but it originated from a real user request.
* jk/signal-cleanup (Sun Jan 11 06:36:49 2009 -0500) 3 commits
- pager: do wait_for_pager on signal death
- refactor signal handling for cleanup functions
- chain kill signals for cleanup functions
* kb/lstat-cache (Tue Jan 13 13:29:08 2009 +0100) 5 commits
- lstat_cache(): introduce clear_lstat_cache() function
- lstat_cache(): introduce invalidate_lstat_cache() function
- lstat_cache(): introduce has_dirs_only_path() function
- lstat_cache(): introduce has_symlink_or_noent_leading_path()
function
- lstat_cache(): more cache effective symlink/directory detection
This is the seventh round; although the author asked me not to bother, I
couldn't resist. I renamed one helper function while reading the patches
and made minor adjustments on styles, but it looked reasonable.
* lh/submodule-tree-traversal (Mon Jan 12 00:45:55 2009 +0100) 3 commits
- builtin-ls-tree: enable traversal of submodules
- archive.c: enable traversal of submodules
- tree.c: add support for traversal of submodules
* jc/maint-format-patch-o-relative (Mon Jan 12 15:18:02 2009 -0800) 1 commit
- Teach format-patch to handle output directory relative to cwd
This was my lunchtime "this may fix it" response to a breakage report. I
haven't really thought things through but my gut feeling is this might
break things for minorities who are accustomed to the existing behaviour,
especially wrt the filenames reported on the standard output.
* lt/maint-wrap-zlib (Wed Jan 7 19:54:47 2009 -0800) 1 commit
+ Wrap inflate and other zlib routines for better error reporting
Needs the "free our memory upon seeing Z_MEM_ERROR and try again" bits
extracted from Shawn's patch on top of this one.
* js/diff-color-words (Sun Jan 11 21:00:58 2009 +0100) 4 commits
- color-words: take an optional regular expression describing words
- color-words: refactor to allow for 0-character word boundaries
- color-words: refactor word splitting and use ALLOC_GROW()
- Add color_fwrite(), a function coloring each line individually
Dscho's series that was done in response to Thomas's original; two agreed
to work together on this codebase.
* db/foreign-scm (Sun Jan 11 15:12:10 2009 -0500) 3 commits
- Support fetching from foreign VCSes
- Add specification of git-vcs helpers
- Add "vcs" config option in remotes
----------------------------------------------------------------
[Stalled and may need help and prodding to go forward]
* ds/uintmax-config (Mon Nov 3 09:14:28 2008 -0900) 1 commit
. autoconf: Enable threaded delta search when pthreads are supported
I haven't heard neither positive nor negative comments from minority
platforms that might be harmed, but this feels like the right thing to do,
so perhaps the best course of action is to merge this down to 'master' and
see if anybody screams.
* jc/blame (Wed Jun 4 22:58:40 2008 -0700) 2 commits
+ blame: show "previous" information in --porcelain/--incremental
format
+ git-blame: refactor code to emit "porcelain format" output
This gives Porcelains (like gitweb) the information on the commit _before_
the one that the final blame is laid on, which should save them one
rev-parse to dig further. The line number in the "previous" information
may need refining, and sanity checking code for reference counting may
need to be resurrected before this can move forward.
----------------------------------------------------------------
[Actively cooking]
* gb/gitweb-opml (Fri Jan 2 13:49:30 2009 +0100) 2 commits
+ gitweb: suggest name for OPML view
+ gitweb: don't use pathinfo for global actions
* ks/maint-mailinfo-folded (Mon Jan 12 15:22:11 2009 -0800) 2 commits
- mailinfo: 'From:' header should be unfold as well
- mailinfo: correctly handle multiline 'Subject:' header
The author seems to have more updates, but I couldn't extract them from
the e-mail.
* js/patience-diff (Thu Jan 1 17:39:37 2009 +0100) 3 commits
+ bash completions: Add the --patience option
+ Introduce the diff option '--patience'
+ Implement the patience diff algorithm
* mv/apply-parse-opt (Fri Jan 9 22:21:36 2009 -0800) 2 commits
+ Resurrect "git apply --flags -" to read from the standard input
+ parse-opt: migrate builtin-apply.
* tr/rebase-root (Fri Jan 2 23:28:29 2009 +0100) 4 commits
+ rebase: update documentation for --root
+ rebase -i: learn to rebase root commit
+ rebase: learn to rebase root commit
+ rebase -i: execute hook only after argument checking
Looked reasonable.
* js/notes (Tue Jan 13 20:57:16 2009 +0100) 6 commits
+ git-notes: fix printing of multi-line notes
+ notes: fix core.notesRef documentation
+ Add an expensive test for git-notes
+ Speed up git notes lookup
+ Add a script to edit/inspect notes
+ Introduce commit notes
* sc/gitweb-category (Fri Dec 12 00:45:12 2008 +0100) 3 commits
- gitweb: Optional grouping of projects by category
- gitweb: Split git_project_list_body in two functions
- gitweb: Modularized git_get_project_description to be more generic
----------------------------------------------------------------
[Graduated to "master"]
* nd/grep-assume-unchanged (Sat Dec 27 15:21:03 2008 +0700) 2 commits
+ grep: grep cache entries if they are "assume unchanged"
+ grep: support --no-ext-grep to test builtin grep
* as/maint-shortlog-cleanup (Tue Dec 30 22:01:44 2008 +0100) 1 commit
+ builtin-shortlog.c: use string_list_append(), and don't strdup
unnecessarily
* jc/maint-ls-tree (Wed Dec 31 19:00:50 2008 +0900) 2 commits
+ Document git-ls-tree --full-tree
+ ls-tree: add --full-tree option
* js/bundle-tags (Fri Jan 2 19:08:46 2009 +0100) 1 commit
+ bundle: allow rev-list options to exclude annotated tags
* js/add-not-submodule (Fri Jan 2 19:08:40 2009 +0100) 1 commit
+ git add: do not add files from a submodule
* pb/maint-git-pm-false-dir (Mon Dec 29 01:25:00 2008 +0100) 1 commit
+ Git.pm: correctly handle directory name that evaluates to "false"
* pj/maint-ldflags (Sun Jan 4 21:27:41 2009 -0500) 1 commit
+ configure clobbers LDFLAGS
* fe/cvsserver (Fri Jan 2 16:40:14 2009 +0100) 2 commits
+ cvsserver: change generation of CVS author names
+ cvsserver: add option to configure commit message
* js/maint-bisect-gitk (Fri Jan 2 19:08:00 2009 +0100) 1 commit
+ bisect view: call gitk if Cygwin's SESSIONNAME variable is set
* np/no-loosen-prune-expire-now (Tue Dec 30 14:45:11 2008 -0500) 1 commit
+ objects to be pruned immediately don't have to be loosened
* cb/maint-unpack-trees-absense (Thu Jan 1 21:54:33 2009 +0100) 3 commits
+ unpack-trees: remove redundant path search in verify_absent
+ unpack-trees: fix path search bug in verify_absent
+ unpack-trees: handle failure in verify_absent
* mc/cd-p-pwd (Tue Dec 30 07:10:24 2008 -0800) 1 commit
+ git-sh-setup: Fix scripts whose PWD is a symlink to a work-dir on
OS X
* mh/cherry-default (Thu Jan 1 22:56:29 2009 +0100) 2 commits
+ Documentation: clarify which parameters are optional to git-cherry
+ git-cherry: make <upstream> parameter optional
Some of the above will still need to be downmerged to respective
maintenance branches after they are widely used on 'master'.
----------------------------------------------------------------
[Will merge to "master" soon]
* mh/maint-commit-color-status (Thu Jan 8 19:53:05 2009 +0100) 2 commits
+ git-status -v: color diff output when color.ui is set
+ git-commit: color status output when color.ui is set
* rs/maint-shortlog-foldline (Tue Jan 6 21:41:06 2009 +0100) 1 commit
+ shortlog: handle multi-line subjects like log --pretty=oneline et.
al. do
* rs/fgrep (Sat Jan 10 00:18:34 2009 +0100) 2 commits
+ grep: don't call regexec() for fixed strings
+ grep -w: forward to next possible position after rejected match
* as/autocorrect-alias (Sun Jan 4 18:16:01 2009 +0100) 1 commit
+ git.c: make autocorrected aliases work
* tr/maint-no-index-fixes (Wed Jan 7 12:15:30 2009 +0100) 3 commits
+ diff --no-index -q: fix endless loop
+ diff --no-index: test for pager after option parsing
+ diff: accept -- when using --no-index
* jc/maint-format-patch (Sat Jan 10 12:41:33 2009 -0800) 1 commit
+ format-patch: show patch text for the root commit
* ap/clone-into-empty (Sun Jan 11 15:19:12 2009 +0300) 2 commits
+ Allow cloning to an existing empty directory
+ add is_dot_or_dotdot inline function
* gb/gitweb-patch (Thu Dec 18 08:13:19 2008 +0100) 4 commits
+ gitweb: link to patch(es) view in commit(diff) and (short)log view
+ gitweb: add patches view
+ gitweb: change call pattern for git_commitdiff
+ gitweb: add patch view
----------------------------------------------------------------
[On Hold]
* jk/renamelimit (Sat May 3 13:58:42 2008 -0700) 1 commit
. diff: enable "too large a rename" warning when -M/-C is explicitly
asked for
* jc/stripspace (Sun Mar 9 00:30:35 2008 -0800) 6 commits
. git-am --forge: add Signed-off-by: line for the author
. git-am: clean-up Signed-off-by: lines
. stripspace: add --log-clean option to clean up signed-off-by:
lines
. stripspace: use parse_options()
. Add "git am -s" test
. git-am: refactor code to add signed-off-by line for the committer
^ permalink raw reply
* What's in git.git (Jan 2009, #01; Wed, 14)
From: Junio C Hamano @ 2009-01-14 11:32 UTC (permalink / raw)
To: git
Many topics graduated to 'master' and I updated the draft release notes
for 1.6.2.
* The 'maint' branch has these fixes since the last announcement.
Clemens Buchacher (1):
modify/delete conflict resolution overwrites untracked file
Felipe Contreras (1):
fast-import: Cleanup mode setting.
Henrik Austad (2):
Use capitalized names where appropriate
Be consistent in switch usage for tar
Jay Soffian (1):
Git.pm: call Error::Simple() properly
Joey Hess (1):
README: tutorial.txt is now called gittutorial.txt
Johannes Schindelin (1):
merge-recursive: mark rename/delete conflict as unmerged
Junio C Hamano (3):
merge-recursive: do not clobber untracked working tree garbage
builtin-apply: prevent non-explicit permission changes
git checkout: do not allow switching to a tree-ish that is not a commit
Kirill A. Korinskiy (1):
http-push: support full URI in handle_remote_ls_ctx()
Markus Heidelberg (1):
doc/git-send-email: mention sendemail.cc config variable
Miklos Vajna (1):
fast-export: print usage when no options specified
Pierre Habouzit (1):
Avoid spurious error messages on error mistakes.
jidanni@jidanni.org (3):
Documentation/git-tag.txt: minor typo and grammar fix
Documentation/git-push.txt: minor: compress one option
contrib/examples/README: give an explanation of the status of these files
* The 'master' branch has these since the last announcement
in addition to the above.
Adeodato Simó (2):
builtin-shortlog.c: use string_list_append(), and don't strdup
unnecessarily
t7501-commit.sh: explicitly check that -F prevents invoking the editor
Alexander Potashev (1):
remove trailing LF in die() messages
Charles Bailey (4):
Fix some tab/space inconsistencies in git-mergetool.sh
Add -y/--no-prompt option to mergetool
mergetool: Add prompt to continue after failing to merge a file
mergetool: Don't keep temporary merge files unless told to
Christian Couder (1):
sha1_file: make "read_object" static
Clemens Buchacher (3):
unpack-trees: handle failure in verify_absent
unpack-trees: fix path search bug in verify_absent
unpack-trees: remove redundant path search in verify_absent
Eric Wong (1):
git-svn: add --authors-file test
Fabian Emmes (2):
cvsserver: add option to configure commit message
cvsserver: change generation of CVS author names
Giuseppe Bilotta (1):
gitweb: use href() when generating URLs in OPML
Jakub Narebski (3):
gitweb: Move 'lineno' id from link to row element in git_blame
gitweb: A bit of code cleanup in git_blame()
gitweb: cache $parent_commit info in git_blame()
Jeff King (1):
Makefile: clean up TEST_PROGRAMS definition
Johannes Schindelin (5):
git wrapper: Make while loop more reader-friendly
bisect view: call gitk if Cygwin's SESSIONNAME variable is set
bundle: allow rev-list options to exclude annotated tags
git add: do not add files from a submodule
show <tag>: reuse pp_user_info() instead of duplicating code
Jon Loeliger (1):
Fix Documentation typos surrounding the word 'handful'.
Junio C Hamano (2):
ls-tree: add --full-tree option
Update 1.6.2 draft release notes
Kjetil Barvik (1):
Cleanup of unused symcache variable inside diff-lib.c
Lee Marlow (2):
bash completion: Add '--intent-to-add' long option for 'git add'
bash completion: Use 'git add' completions for 'git stage'
Marcel M. Cary (1):
git-sh-setup: Fix scripts whose PWD is a symlink to a work-dir on OS X
Markus Heidelberg (3):
git-cherry: make <upstream> parameter optional
Documentation: clarify which parameters are optional to git-cherry
contrib/vim: change URL to point to the latest syntax files
Matt Kraai (1):
gitweb: unify boolean feature subroutines
Miklos Vajna (1):
Add support for a pdf version of the user manual
Nanako Shiraishi (1):
Document git-ls-tree --full-tree
Nguyễn Thái Ngọc Duy (2):
grep: support --no-ext-grep to test builtin grep
grep: grep cache entries if they are "assume unchanged"
Nicolas Pitre (1):
objects to be pruned immediately don't have to be loosened
Paul Jarc (1):
configure clobbers LDFLAGS
Philippe Bruhat (1):
Git.pm: correctly handle directory name that evaluates to "false"
Pierre Habouzit (1):
filter-branch: add git_commit_non_empty_tree and --prune-empty.
René Scharfe (2):
diff: add option to show context between close hunks
strbuf: instate cleanup rule in case of non-memory errors
SZEDER Gábor (1):
bash: add '--merge' to 'git reset'
William Pursell (2):
Add subroutine to display one-line summary of hunks
Add 'g' command to go to a hunk
^ permalink raw reply
* Re: [PATCH 1/3] git-daemon: single-line logs
From: Junio C Hamano @ 2009-01-14 11:33 UTC (permalink / raw)
To: Jan Engelhardt; +Cc: git
In-Reply-To: <alpine.LSU.2.00.0901141147120.16109@fbirervta.pbzchgretzou.qr>
Jan Engelhardt <jengelh@medozas.de> writes:
> parent v1.6.1
>
> git-daemon: single-line logs
Please drop these two needless lines when/if you are submitting patches
for inclusion..
> Having just a single line per connection attempt, much like Apache
> httpd2 access logs, makes log parsing much easier, especially when
> just glancing over it non-automated.
While I like the motivation, and I wish the log were as terse as possible
from the day one, I think changing the output format unconditionally like
this patch does is a horrible idea. I'd expect there are many people who
already have their infrastructure set up to parse the current output; this
patch actively breaks things for them, doesn't it?
> @@ -295,12 +295,13 @@ static int git_daemon_config(const char
> return 0;
> }
>
> -static int run_service(char *dir, struct daemon_service *service)
> +static int run_service(char *dir, struct daemon_service *service,
> + const char *origin, const char *vhost)
> {
> const char *path;
> int enabled = service->enabled;
>
> - loginfo("Request %s for '%s'", service->name, dir);
> + loginfo("%s->%s %s \"%s\"\n", origin, vhost, service->name, dir);
Mental note. You are adding origin and vhost probably because you are
losing them from elsewhere..
> @@ -507,10 +508,10 @@ static void parse_extra_args(char *extra
> static int execute(struct sockaddr *addr)
> {
> static char line[1000];
> + char addrbuf[256] = "";
> int pktlen, len, i;
>
> if (addr) {
> - char addrbuf[256] = "";
> int port = -1;
>
> if (addr->sa_family == AF_INET) {
> @@ -529,7 +530,6 @@ static int execute(struct sockaddr *addr
> port = ntohs(sin6_addr->sin6_port);
> #endif
> }
> - loginfo("Connection from %s:%d", addrbuf, port);
Mental note. Port is not logged anymore here.
> @@ -541,10 +541,6 @@ static int execute(struct sockaddr *addr
> alarm(0);
>
> len = strlen(line);
> - if (pktlen != len)
> - loginfo("Extended attributes (%d bytes) exist <%.*s>",
> - (int) pktlen - len,
> - (int) pktlen - len, line + len + 1);
Mental note. XA are not logged here anymore.
> @@ -569,7 +565,8 @@ static int execute(struct sockaddr *addr
> * Note: The directory here is probably context sensitive,
> * and might depend on the actual service being performed.
> */
> - return run_service(line + namelen + 5, s);
> + return run_service(line + namelen + 5, s,
> + addrbuf, hostname);
> }
> }
So not just you are changing the format, but you are losing information as
well.
By the way, I think hostname has already been freed and NULLed at this
call site. Aren't you getting entries like:
192.168.0.1->(null) upload-pack "/pub/git.git"
in your log?
^ 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