git email From: parsing (was Re: [GIT PULL] Staging/IIO driver patches for 4.11-rc1)

[Greg KH]

On Wed, Feb 22, 2017 at 11:59:01AM -0800, Linus Torvalds wrote:
> On Wed, Feb 22, 2017 at 6:56 AM, Greg KH <gre...@linuxfoundation.org> wrote:
> >
> > =?UTF-8?q?Simon=20Sandstr=C3=B6m?= (1):
> >   staging: vt6656: Add missing identifier names
> 
> Wow, your scripts really screwed up that name.
> 
> I'm assuming this is quilt not doing proper character set handling..
> 
> Because if it's git, we need to get that fixed (but I'm pretty sure
> git gets this right - there are various tests for email header
> quoting).
> 
> Alternatively, somebody hand-edited some email and moved the From:
> header to the body without fixing up the RFC 1342 mail header quoting
> (which is very different from how quoting works in the *body* of an
> email).
> 
> Poor Simon Sandström.
> 
> Funnily enough, this only exists for one commit. You've got several
> other commits from Simon that get his name right.
> 
> What happened?

I don't know what happened, I used git for this, I don't use quilt for
"normal" patches accepted into my trees anymore, only for stable kernel
work.

So either the mail is malformed, or git couldn't figure it out, I've
attached the original message below, and cc:ed the git mailing list.

Also, Simon emailed me after this was committed saying something went
wrong, but I couldn't go back and rebase my tree.  Simon, did you ever
figure out if something was odd on your end?

Git developers, any ideas?

thanks,

greg k-h


messy_email.mbox
Description: application/mbox

Re: 0 bot for Git

[Greg KH]

On Wed, Apr 13, 2016 at 10:29:57AM -0700, Stefan Beller wrote:
> 
> At Git Merge Greg said (paraphrasing here):
> 
>   We waste developers time, because we have plenty of it. Maintainers time
>   however is precious because maintainers are the bottleneck and a scare
>   resource to come by.

s/scare/scarce/

Although some people might disagree :)

--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: 0 bot for Git

[Greg KH]

On Mon, Apr 11, 2016 at 09:29:59PM -0700, Stefan Beller wrote:
> Resending as plain text. (I need to tame my mobile)
> 
> On Mon, Apr 11, 2016 at 7:51 AM, Stefan Beller  wrote:
> > Hi Greg,
> >
> > Thanks for your talk at the Git Merge 2016!
> > The Git community uses the same workflow as the kernel. So we may be
> > interested in the 0 bot which could compile and test each patch on the list.
> > Could you put us in touch with the authors/maintainers of said tool?
> >
> > Unlike the kernel we would not need hardware testing and we're low traffic
> > compared to the kernel, which would make it easier to set it up.

We don't get much, if any, real hardware testing from the 0-day bot,
it's just lots and lots of builds and static testing tools.

You can reach the developers of it at:
kbuild test robot 

Hope this helps,

greg k-h
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Bug in 'git am' when applying a broken patch

[Greg KH]

On Mon, Jun 01, 2015 at 01:23:26PM -0700, Junio C Hamano wrote:
 Eric Sunshine sunsh...@sunshineco.com writes:
 
  s/enw/new/
 
 Heh, thanks; I wasn't planning to commit this one yet, but why not.

Well, it's not good to apply a commit with no actual commit.  That
never a good thing, and was the thing that really confused me about this
issue.

 Here is with an updated log message and a test.
 
 -- 8 --
 Subject: [PATCH] apply: reject a hunk that does not do anything
 
 A hunk like this in a hand-edited patch without correctly adjusting
 the line counts:
 
  @@ -660,2 +660,2 @@ inline struct sk_buff *ieee80211_authentic...
  auth = (struct ieee80211_authentication *)
  skb_put(skb, sizeof(struct ieee80211_authentication));
  -   some old text
  +   some new text
  --
  2.1.0
 
  dev mailing list
 
 at the end of the input does not have a good way for us to diagnose
 it as a corrupt patch.  We just read two context lines and discard
 the remainder as cruft, which we must do in order to ignore the
 e-mail footer.  Notice that the patch does not change anything and
 signal an error.
 
 Note that this fix will not help if the hand-edited hunk header were
 @@ -660,3, +660,2 to include the removal.  We would just remove
 the old text without adding the new one, and treat + some new text
 and everything after that line as trailing cruft.  So it is dubious
 that this patch alone would help very much in practice, but it may
 be better than nothing.
 
 Signed-off-by: Junio C Hamano gits...@pobox.com
 ---
  builtin/apply.c|  3 +++
  t/t4136-apply-check.sh | 13 +
  2 files changed, 16 insertions(+)

Looks good to me, thanks for fixing this, much appreciated.

greg k-h
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Bug in 'git am' when applying a broken patch

[Greg KH]

On Mon, Jun 01, 2015 at 09:17:59AM +0900, Greg KH wrote:
 Hi all,
 
 I received the patch attached below as part of a submission against the
 Linux kernel tree.  The patch seems to have been hand-edited, and is not
 correct, and patch verifies this as being a problem:
 
 $ patch -p1 --dry-run  bad_patch.mbox 
 checking file drivers/staging/rtl8192u/ieee80211/ieee80211_softmac.c
 patch:  malformed patch at line 133:skb_put(skb, 
 sizeof(struct ieee80211_authentication));
 
 But git will actually apply it:
 $ git am -s bad_patch.mbox
 Applying: staging: rtl8192u: ieee80211: Fix sparse endianness warnings
 
 But, there's nothing in the patch at all except the commit message:
 
 $ git show HEAD
 commit f6643dfef5b701db86f23be9ce6fb5b3bafe76b6
 Author: Gaston Gonzalez gasc...@gmail.com
 Date:   Sun May 31 12:17:48 2015 -0300
 
 staging: rtl8192u: ieee80211: Fix sparse endianness warnings
 
 Fix the following sparse warnings:
 
 drivers/staging/rtl8192u/ieee80211/ieee80211_softmac.c:663:32: warning: 
 incorrect type in assignment (different base types)
 drivers/staging/rtl8192u/ieee80211/ieee80211_softmac.c:663:32:
 expected restricted __le16 [usertype] frame_ctl
 drivers/staging/rtl8192u/ieee80211/ieee80211_softmac.c:663:32:got int
 drivers/staging/rtl8192u/ieee80211/ieee80211_softmac.c:664:50: warning: 
 invalid assignment: |=
 drivers/staging/rtl8192u/ieee80211/ieee80211_softmac.c:664:50:left 
 side has type restricted __le16
 drivers/staging/rtl8192u/ieee80211/ieee80211_softmac.c:664:50:right 
 side has type int
 
 Signed-off-by: Gaston Gonzalez gasc...@gmail.com
 Signed-off-by: Greg Kroah-Hartman gre...@linuxfoundation.org
 
 $ git diff HEAD^
 $ 
 
 Any ideas what is going on here?  Shouldn't 'git am' have failed?
 
 Oh, I'm using git version 2.4.2 right now.
 
 I've asked Gaston for the original patch to verify before he hand-edited
 it, to verify that git wasn't creating something wrong here, as well.

Gaston sent me his original patch, before he edited it, and it was
correct, so git is correctly creating the patch, which is good.  So it's
just a 'git am' issue with a broken patch file.

thanks,

greg k-h
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Bug in 'git am' when applying a broken patch

[Greg KH]

Hi all,

I received the patch attached below as part of a submission against the
Linux kernel tree.  The patch seems to have been hand-edited, and is not
correct, and patch verifies this as being a problem:

$ patch -p1 --dry-run  bad_patch.mbox 
checking file drivers/staging/rtl8192u/ieee80211/ieee80211_softmac.c
patch:  malformed patch at line 133:skb_put(skb, 
sizeof(struct ieee80211_authentication));

But git will actually apply it:
$ git am -s bad_patch.mbox
Applying: staging: rtl8192u: ieee80211: Fix sparse endianness warnings

But, there's nothing in the patch at all except the commit message:

$ git show HEAD
commit f6643dfef5b701db86f23be9ce6fb5b3bafe76b6
Author: Gaston Gonzalez gasc...@gmail.com
Date:   Sun May 31 12:17:48 2015 -0300

staging: rtl8192u: ieee80211: Fix sparse endianness warnings

Fix the following sparse warnings:

drivers/staging/rtl8192u/ieee80211/ieee80211_softmac.c:663:32: warning: 
incorrect type in assignment (different base types)
drivers/staging/rtl8192u/ieee80211/ieee80211_softmac.c:663:32:expected 
restricted __le16 [usertype] frame_ctl
drivers/staging/rtl8192u/ieee80211/ieee80211_softmac.c:663:32:got int
drivers/staging/rtl8192u/ieee80211/ieee80211_softmac.c:664:50: warning: 
invalid assignment: |=
drivers/staging/rtl8192u/ieee80211/ieee80211_softmac.c:664:50:left side 
has type restricted __le16
drivers/staging/rtl8192u/ieee80211/ieee80211_softmac.c:664:50:right 
side has type int

Signed-off-by: Gaston Gonzalez gasc...@gmail.com
Signed-off-by: Greg Kroah-Hartman gre...@linuxfoundation.org

$ git diff HEAD^
$ 

Any ideas what is going on here?  Shouldn't 'git am' have failed?

Oh, I'm using git version 2.4.2 right now.

I've asked Gaston for the original patch to verify before he hand-edited
it, to verify that git wasn't creating something wrong here, as well.

thanks,

greg k-h


bad_patch.mbox
Description: application/mbox

Re: Is there some way to suppress Cc email only to stable?

[Greg KH]

On Mon, Feb 09, 2015 at 03:35:37PM -0800, Paul E. McKenney wrote:
 On Mon, Feb 09, 2015 at 01:53:50PM -0800, Jonathan Nieder wrote:
  Hi,
  
  Paul E. McKenney wrote:
  
   Cc: sta...@vger.kernel.org
  
   Yet I cannot allow git-send-email to actually send email to that address,
   lest I get an automated nastygram in response.
  
  Interesting.  Last time this came up, the result seemed to be
  different[*].
 
 Hmmm...  Greg KH didn't say there were no automated nastygrams, just
 that he wasn't worried about it.
 
 I can try it on the next to-be-backported commit and see what happens.

There are no automated nastygrams, it's a hit this key to send out
this form message I have in my email client.

The only time it triggers a false-positive is when I haven't had enough
coffee in the morning, which is what happened recently with a patch from
John Stultz.  If I've sent you that message incorrectly, I'm sorry,
please let me know.

Again, any patch cc:ed to stable that has a stable mark on it in the
signed-off-by area is fine, and it helps me to know to watch out for
things when they hit Linus's tree, or most importantly, to notice if
they somehow _don't_ hit his tree.  Again, some recent patches from John
fall in to that category, they didn't make it into Linus's tree when
they probably should have for 3.19, and now I need to scoop them up
quickly when they finally do.  If I hadn't been cc:ed on them, I would
not have noticed that.

Hope this helps explain things,

greg k-h
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Sources for 3.18-rc1 not uploaded

[Greg KH]

On Mon, Oct 20, 2014 at 02:37:09PM -0400, Konstantin Ryabitsev wrote:
 On 20/10/14 02:28 PM, Junio C Hamano wrote:
  I have to wonder why 10f343ea (archive: honor tar.umask even for pax
  headers, 2014-08-03) is a problem but an earlier change v1.8.1.1~8^2
  (archive-tar: split long paths more carefully, 2013-01-05), which
  also should have broken bit-for-bit compatibility, went unnoticed,
  though.  What I am getting at is that correcting past mistakes in
  the output should not be forbidden unconditionally with a complaint
  like this.
 
 I think Greg actually ran into that one, and uses a separate 1.7 git
 tree for this reason.

I used to have to do this for the 3.0-stable kernel as one of the files
in it ran into the very long path problem.  I just ran the latest
version of git with that one commit reverted and all was fine.

After 3.0 was done, I just dropped that patch from my local version and
have been running with the latest git version of git with no problems.

 I can update our servers to git 2.1 (which most of them already have),
 which should help with previous incompatibilities -- but not the future
 ones obviously. :)

I thought you already did this.  Or was that only the public facing git
servers?

thanks,

greg k-h
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 4/8] staging: et131x: Remove ununsed statistics

[Greg KH]

On Sat, Sep 13, 2014 at 12:37:46PM +0300, Dan Carpenter wrote:
 On Thu, Sep 11, 2014 at 10:59:42PM +0100, Mark Einon wrote:
  From struct ce_stats; unicast_pkts_rcvd, unicast_pkts_xmtd,
  multicast_pkts_xmtd, broadcast_pkts_rcvd and broadcast_pkts_xmtd
 
 For some reason something adds a '' to the start of lines which start
 with 'From'.  I don't know what it is...

It's an email protocol requirement, some RFC dictates it as From at
the start of the line is an email start flag.

 When I apply this patch with 'git am' then it just removes the From
 line.

As it should :)

thanks,

greg k-h
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: git archve --format=tar output changed from 1.8.1 to 1.8.2.1

[Greg KH]

On Sun, Feb 03, 2013 at 09:05:55PM -0800, Junio C Hamano wrote:
 Greg KH gre...@linuxfoundation.org writes:
  The number of people this affects right now is only one (me), given that
  the offending file is not in Linus's tree right now, so he doesn't have
  issues with uploading new releases.
 
 As a tree grows larger over time, it may be just a matter of time
 for somebody else to be hit by another deep path, though.

I agree, and over time, everyone will have updated to a version of git
newer than 1.8.2.1 so we all will be fine again :)

thanks,

greg k-h
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: git archve --format=tar output changed from 1.8.1 to 1.8.2.1

[Greg KH]

On Thu, Jan 31, 2013 at 10:16:27AM -0800, Junio C Hamano wrote:
 Greg KH gre...@linuxfoundation.org writes:
 
  On Thu, Jan 31, 2013 at 09:32:12AM -0800, Junio C Hamano wrote:
 
  How about fixing kup to teach the let's cheat and let the other end
  run 'git archive', if the resulting archive and GPG signature
  locally created does match, we do not have to transfer the tarball
  itself trick a fall-back mode that says but if the signature does
  not match, then transfer the bulk used to create the signature to
  the remote anyway.  This fallback can and should of course be
  useful for the compressed patch transfer.
 
  Ugh, uploading a 431Mb file, over a flaky wireless connection (I end up
  doing lots of kernel releases while traveling), would be a horrible
  change.  I'd rather just keep using the same older version of git that
  kernel.org is running instead.
 
 Then how about fixing kup to try both versions of Git?  There will
 be people who run different versions of Git anyway, and kup should
 not be preventing Git from helping people on other platforms, or
 improving its output in general.

I think the combinations of different versions of git that would have to
be installed on kernel.org to handle stuff like this as things change
over time, wouldn't be worth it.

The number of people this affects right now is only one (me), given that
the offending file is not in Linus's tree right now, so he doesn't have
issues with uploading new releases.

So I'll just work to ensure I have the same version of git in place if I
ever run into this problem again.  Or just break down and do
full-compressed tarballs instead, if I'm in a place where I have a good
network connection.

thanks,

greg k-h
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: git archve --format=tar output changed from 1.8.1 to 1.8.2.1

[Greg KH]

On Thu, Jan 31, 2013 at 07:33:52PM +0100, René Scharfe wrote:
 Am 31.01.2013 18:28, schrieb Greg KH:
  I tracked this down to commit 22f0dcd9634a818a0c83f23ea1a48f2d620c0546
  (archive-tar: split long paths more carefully).  The diff of a hex dump
  of the tar archives shows the following difference:
  
  --- old_git_archive 2013-01-31 17:31:24.466343388 +0100
  +++ new_git_archive 2013-01-31 17:32:21.509674417 +0100
  @@ -19239998,8 +19239998,8 @@
   125943d0:         
   125943e0:         
   125943f0:         
  -12594400:         
  -12594410:         
  +12594400:7765 7374 6272 6964 6765 2d6f 6d61 7033  westbridge-omap3
  +12594410:2d70 6e61 6e64 2d68 616c 2f00    -pnand-hal/.
   12594420:         
   12594430:         
   12594440:         
  @@ -19240025,8 +19240025,8 @@
   12594580:2f61 7374 6f72 6961 2f61 7263 682f 6172  /astoria/arch/ar
   12594590:6d2f 706c 6174 2d6f 6d61 702f 696e 636c  m/plat-omap/incl
   125945a0:7564 652f 6d61 6368 2f77 6573 7462 7269  ude/mach/westbri
  -125945b0:6467 652f 7765 7374 6272 6964 6765 2d6f  dge/westbridge-o
  -125945c0:6d61 7033 2d70 6e61 6e64 2d68 616c   map3-pnand-hal..
  +125945b0:6467 6500        dge.
  +125945c0:         
   125945d0:         
   125945e0:         
   125945f0:         
 
 This is the only directory in the repository whose path is long enough to
 make a difference with the patch, 105 characters in total:
 
 drivers/staging/westbridge/astoria/arch/arm/plat-omap/include/mach/westbridge/westbridge-omap3-pnand-hal/
 
 Five characters less and you wouldn't notice a thing.  It contains
 westbridge thrice, so I think it's cheating just to reach that
 length, though. ;-)

Yeah, that file path was bad, which is just one reason why it was
deleted from the kernel in newer versions :)

  Interestingly, the output of uncompressing the tar archives is
  identical, so the data is correct, but the binary isn't.
 
 The path is split differently between two header fields, that's all.

Ok, thanks for the explaination, I didn't realize that.

  Now keeping binary compatibility of tar archive files isn't really a big
  deal, but, the commit to git that causes this seems a bit odd, is it
  really needed?  Or can we just fix the version of tar with NetBSD
  instead?  :)
 
 Apart from Junio's suggestion, I can't think of a practical solution.
 
 You could downgrade your git to a version before the fix.  A downside is
 that you won't be able to extract the archive on NetBSD without getting
 an error message (but the contents would be intact, except perhaps for
 permission bits of the directory above).
 
 You could upgrade the kernel.org version of git, but that might cause the
 same problem for other maintainers with long directory paths who in their
 repositories who still use git without the fix.
 
 You could make the path shorter.  Won't help at all with the release you
 just did, of course.

What I ended up doing was just to revert your patch, generating a tar
archive that matches what the version on kernel.org.

And originally I now recall that this was something we were worried
about, but we put off dealing with it until it caused problems :)

 I don't know if other tar implementations freak out when they see an
 empty name field.  NetBSD's tar might seem a bit too strict here, but
 overall I think it's right in complaining.

Ok, thanks, I now agree.

 What makes the commit odd, by the way?

Sorry, I was originally thinking that you were working around a bug in
the NetBSD version of tar, not making it more correct, which is
arguably the right thing to do here.

So I'll work with Konstantine to ensure we both are using the same
version of git in the future, it's our kernel.org infrastructure issue
here, not a git one, sorry for the noise.

greg k-h
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: git archve --format=tar output changed from 1.8.1 to 1.8.2.1

[Greg KH]

On Thu, Jan 31, 2013 at 12:52:15PM -0500, Konstantin Ryabitsev wrote:
 On 31/01/13 12:41 PM, Greg KH wrote:
  Ugh, uploading a 431Mb file, over a flaky wireless connection (I end up
  doing lots of kernel releases while traveling), would be a horrible
  change.  I'd rather just keep using the same older version of git that
  kernel.org is running instead.
 
 Well, we do accept compressed archives, so you would be uploading about
 80MB instead of 431MB, but that would still be a problem for anyone
 releasing large tarballs over unreliable connections. I know you
 routinely do 2-3 releases at once, so that would still mean uploading
 120-180MB.

That would mean I can't do kernel releases while on ferry rides, which
is probably a good thing in the end :)

 I don't have immediate statistics on how many people release using kup
 --tar, but I know that at least you and Linus rely on that exclusively.

What causes you to upgrade the version of git on the server?  Are you
relying on packages for a distro, or is this hand installed by
yourself?  As long as I stay in lock-step with your updates, all should
be fine.

Oh, maybe we can report back to the user, the version of git that is
being used on the server, if the checksums don't match, so that I know
to at least see if my version is different from yours?

thanks,

greg k-h
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

git archve --format=tar output changed from 1.8.1 to 1.8.2.1

[Greg KH]

Hi,

The way we upload the Linux kernel to kernel.org involves creating a tar
archive, signing the archive, and then just uploading the signature.
The server then checks out the repo based on the tag, generates the tar
archive and checks the signature to make sure they match.

A few days ago I released the 3.0.61 kernel, and it turned out that I
couldn't upload the kernel release because 'git archive' now creates a
binary file that differs from an older version of git.

I tracked this down to commit 22f0dcd9634a818a0c83f23ea1a48f2d620c0546
(archive-tar: split long paths more carefully).  The diff of a hex dump
of the tar archives shows the following difference:

--- old_git_archive 2013-01-31 17:31:24.466343388 +0100
+++ new_git_archive 2013-01-31 17:32:21.509674417 +0100
@@ -19239998,8 +19239998,8 @@
 125943d0:         
 125943e0:         
 125943f0:         
-12594400:         
-12594410:         
+12594400:7765 7374 6272 6964 6765 2d6f 6d61 7033  westbridge-omap3
+12594410:2d70 6e61 6e64 2d68 616c 2f00    -pnand-hal/.
 12594420:         
 12594430:         
 12594440:         
@@ -19240025,8 +19240025,8 @@
 12594580:2f61 7374 6f72 6961 2f61 7263 682f 6172  /astoria/arch/ar
 12594590:6d2f 706c 6174 2d6f 6d61 702f 696e 636c  m/plat-omap/incl
 125945a0:7564 652f 6d61 6368 2f77 6573 7462 7269  ude/mach/westbri
-125945b0:6467 652f 7765 7374 6272 6964 6765 2d6f  dge/westbridge-o
-125945c0:6d61 7033 2d70 6e61 6e64 2d68 616c   map3-pnand-hal..
+125945b0:6467 6500        dge.
+125945c0:         
 125945d0:         
 125945e0:         
 125945f0:         

Interestingly, the output of uncompressing the tar archives is
identical, so the data is correct, but the binary isn't.

Now keeping binary compatibility of tar archive files isn't really a big
deal, but, the commit to git that causes this seems a bit odd, is it
really needed?  Or can we just fix the version of tar with NetBSD
instead?  :)

Any ideas?

thanks,

greg k-h
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: git archve --format=tar output changed from 1.8.1 to 1.8.2.1

[Greg KH]

On Thu, Jan 31, 2013 at 09:32:12AM -0800, Junio C Hamano wrote:
 Greg KH gre...@linuxfoundation.org writes:
 
  The way we upload the Linux kernel to kernel.org involves creating a tar
  archive, signing the archive, and then just uploading the signature.
  The server then checks out the repo based on the tag, generates the tar
  archive and checks the signature to make sure they match.
  
  A few days ago I released the 3.0.61 kernel, and it turned out that I
  couldn't upload the kernel release because 'git archive' now creates a
  binary file that differs from an older version of git.
  ...
  Now keeping binary compatibility of tar archive files isn't really a big
  deal, but, the commit to git that causes this seems a bit odd, is it
  really needed?  Or can we just fix the version of tar with NetBSD
  instead?  :)
 
  Any ideas?
 
 How about fixing kup to teach the let's cheat and let the other end
 run 'git archive', if the resulting archive and GPG signature
 locally created does match, we do not have to transfer the tarball
 itself trick a fall-back mode that says but if the signature does
 not match, then transfer the bulk used to create the signature to
 the remote anyway.  This fallback can and should of course be
 useful for the compressed patch transfer.

Ugh, uploading a 431Mb file, over a flaky wireless connection (I end up
doing lots of kernel releases while traveling), would be a horrible
change.  I'd rather just keep using the same older version of git that
kernel.org is running instead.

thanks,

greg k-h
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

no diffstat for 'git request-pull' (was Re: [GIT PATCH] char/misc changes for 3.7-rc1)

[Greg KH]

On Mon, Oct 01, 2012 at 10:54:33AM -0700, Greg KH wrote:
 The following changes since commit fea7a08acb13524b47711625eebea40a0ede69a0:
 
   Linux 3.6-rc3 (2012-08-22 13:29:06 -0700)
 
 are available in the git repository at:
 
   git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/char-misc.git/ 
 tags/char-misc-3.6
 
 for you to fetch changes up to fea7a08acb13524b47711625eebea40a0ede69a0:
 
   Linux 3.6-rc3 (2012-08-22 13:29:06 -0700)
 
 
 char/misc driver merge for 3.7-rc1
 
 Here is the big char/misc driver tree update for the 3.7-rc1 merge
 window.
 
 Nothing major, just a number of driver updates and fixes, all of which
 have been in the linux-next releases for a while now either in my tree,
 or in Andrew's (the lis3l driver changes came from his tree last week).
 
 


Wait, what happened to the diffstat?  Does the latest version of git not
send out the diffstat for 'git request-pull'?  It used to on older
versions, I just updated the version on my machine that generated this
to
git version 1.7.12.2.421.g261b511

Do I have to give a new option to request-pull to have the diffstat show
up?  I'm using
git request-pull master 
git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/char-misc.git/ 
char-misc-3.6

For this specific request pull.

greg k-h
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: no diffstat for 'git request-pull' (was Re: [GIT PATCH] char/misc changes for 3.7-rc1)

[Greg KH]

On Mon, Oct 01, 2012 at 06:03:47PM +, Arnd Bergmann wrote:
 On Monday 01 October 2012, Greg KH wrote:
  Wait, what happened to the diffstat?  Does the latest version of git not
  send out the diffstat for 'git request-pull'?  It used to on older
  versions, I just updated the version on my machine that generated this
  to
  git version 1.7.12.2.421.g261b511
  
  Do I have to give a new option to request-pull to have the diffstat show
  up?  I'm using
  git request-pull master 
  git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/char-misc.git/ 
  char-misc-3.6
  
  For this specific request pull.
 
 It looks more like you just sent an empty pull request from v3.6-rc3 to 
 v3.6-rc3 (fea7a08acb135).

Ah crap, you are right, totally my fault.

I'll blame it on being Monday morning...

sorry for the noise...

greg k-h
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Funny 'git describe --contains' output

[Greg KH]

Hi,

In the Linux kernel tree, commit 0136db586c028f71e7cc21cc183064ff0d5919
is a bit odd.

If I go to look to see what release it was in, I normally do:
$ git describe --contains 0136db586c028f71e7cc21cc183064ff0d5919
v3.6-rc1~59^2~56^2~76

However, it really showed up first in the 3.5-rc1 kernel release, as can
be seen by doing the following:
$ git tag --contains 0136db586c028f71e7cc21cc183064ff0d5919
v3.5
v3.5-rc1
v3.5-rc2
v3.5-rc3
v3.5-rc4
v3.5-rc5
v3.5-rc6
v3.5-rc7
v3.6-rc1
v3.6-rc2
v3.6-rc3

This commit ended up coming into Linus's tree in two different places,
both in 3.5-rc1 and in 3.6-rc1, through different merge requests, so it
seems to be tricky to figure out when it first went in.

Asking Linus about this, he tried the following:

$ git name-rev --tags 0136db586c028f71e7cc21cc183064ff0d5919
0136db586c028f71e7cc21cc183064ff0d5919 tags/v3.6-rc1~59^2~56^2~76
$ git rev-list 0136db586c028f71e7cc21cc183064ff0d5919..v3.5-rc1 | wc
  11415   11415  468015
$ git rev-list 0136db586c028f71e7cc21cc183064ff0d5919..v3.4-rc1 | wc
  0   0   0
$ git rev-list 0136db586c028f71e7cc21cc183064ff0d5919..v3.6-rc1 | wc
  22279   22279  913439

which shows that there are less commits to get from this commit to
v3.5-rc1 instead of v3.6-rc1, so something odd is going on here.

Any ideas?

I can reproduce this right now with git version 1.7.12.116.g31e0100

thanks,

greg k-h
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: git applymbox is too anal

[Greg KH]

On Thu, Sep 08, 2005 at 05:58:18PM -0700, Linus Torvalds wrote:
 
 
 On Thu, 8 Sep 2005, Greg KH wrote:
  
  Or am I missing some option to 'git applymbox' that I can't seem to
  find?
 
 No. git-apply wants an exact bit-for-bit match. Partly because fuzz is 
 hard, but mostly because I don't like it. I apply a _lot_ of patches, and 
 if a unforgiving git-apply works for me, it should work for you too.

Ok, as I've been using quilt to stage patches before they are ready to
send to you, sometimes, when I build up the final tree, there are tiny
fuzz issues.  I'll just make sure to fix this up before running
applymbox in the future.

thanks,

greg k-h
-
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: git applymbox is too anal

[Greg KH]

On Thu, Sep 08, 2005 at 04:25:35PM -0700, Greg KH wrote:
 Ick.  I'm trying to apply a bunch of patches to a git repo (the kernel
 tree), using 'git applymbox' and it's just dieing on simple patches that
 apply with fuzz.

Ok, found another one.  This time I looked at the patch itself, and it
is a bit odd, but normal patch handles it fine.

The patch is:
--- gregkh-2.6.orig/drivers/usb/input/Makefile  2005-08-15 23:39:10.0 
-0700
+++ gregkh-2.6/drivers/usb/input/Makefile   2005-08-16 12:31:54.0 
-0700
@@ -39,5 +39,6 @@
 obj-$(CONFIG_USB_POWERMATE)+= powermate.o
 obj-$(CONFIG_USB_WACOM)+= wacom.o
 obj-$(CONFIG_USB_ACECAD)   += acecad.o
+obj-$(CONFIG_USB_YEALINK)  += yealink.o
 obj-$(CONFIG_USB_XPAD) += xpad.o
 obj-$(CONFIG_USB_APPLETOUCH)   += appletouch.o

While the original drivers/usb/input/Makefile in this area is:
obj-$(CONFIG_USB_POWERMATE) += powermate.o
obj-$(CONFIG_USB_WACOM) += wacom.o
obj-$(CONFIG_USB_ACECAD)+= acecad.o
obj-$(CONFIG_USB_XPAD)  += xpad.o

(ignore tab issues, this was cut-and-pasted).

So, the patch shows that there was another line at the end of the file,
while in reality it isn't (this is due to me excluding a patch from the
series that I'm applying due to other reasons.)

Is this something that git can handle without me editing the patch by
hand?  :)

thanks,

greg k-h
-
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: bisect gives strange answer

[Greg KH]

On Thu, Aug 04, 2005 at 03:23:28AM -0400, Sanjoy Mahajan wrote:
  Could you try this please?
 
 Thanks, it now finishes with the diff that I expected:
 
 3d3c2ae1101c1f2dff7e2f9d514769779dbd2737 is first bad commit
 diff-tree 3d3c2ae1101c1f2dff7e2f9d514769779dbd2737 (from 
 a18bcb7450840f07a772a45229de4811d930f461)
 Author: Greg KH [EMAIL PROTECTED]
 Date:   Wed Jul 6 09:09:38 2005 -0700
 
 [PATCH] PCI: fix !CONFIG_HOTPLUG pci build problem
 
 Here's a patch to fix the build issue when CONFIG_HOTPLUG is not enabled
 in 2.6.13-rc2.
 
 Signed-off-by: Greg Kroah-Hartman [EMAIL PROTECTED]
 Signed-off-by: Linus Torvalds [EMAIL PROTECTED]

By any chance, is this patch causing you problems?

Just curious :)

greg k-h
-
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

git-pull-script hates me

[Greg KH]

I just updated to the latest git tree, and now get the following when I
try to pull from a ssh repo:

 $ git-pull-script [EMAIL PROTECTED]:/public_html/udev.git/
 fatal: I don't like '@'. Sue me.

So I drop the @ and then get:
 $ git-pull-script someserver.org:/public_html/udev.git/
 fatal: I don't like '_'. Sue me.

This worked just fine before I updated git :(

Any hints?  Or should I be using a different command to do pulls?

thanks,

greg k-h
-
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: git-pull-script hates me

[Greg KH]

On Wed, Jul 06, 2005 at 01:46:27PM -0700, Greg KH wrote:
 Ok, below is a patch for this.  It works, but then errors out with:
   bash: git-upload-pack: command not found
   fatal: unexpected EOF
 
 So I'm guessing that I have to convince the server owner to update their
 version of git too?

Ok, so they did that, and the pull now works, sorry for the noise.

thanks,

greg k-h
-
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: git-pull-script hates me

[Greg KH]

On Wed, Jul 06, 2005 at 01:37:55PM -0700, Linus Torvalds wrote:
 
 
 On Wed, 6 Jul 2005, Greg KH wrote:
 
  I just updated to the latest git tree, and now get the following when I
  try to pull from a ssh repo:
  
   $ git-pull-script [EMAIL PROTECTED]:/public_html/udev.git/
   fatal: I don't like '@'. Sue me.
  
  So I drop the @ and then get:
   $ git-pull-script someserver.org:/public_html/udev.git/
   fatal: I don't like '_'. Sue me.
 
 Heh. It really is personal.
 
 The new git-pack handling tries to avoid special characters, because it 
 passes some things off to a shell (ie it opens up an ssh connection.
 
 But yeah, it's being a bit too anal. Just look at connect.c: shell_safe(),
 and add both '_' and '@' to the safe list (and any other safe characters),
 and off you go.

Ok, below is a patch for this.  It works, but then errors out with:
bash: git-upload-pack: command not found
fatal: unexpected EOF

So I'm guessing that I have to convince the server owner to update their
version of git too?

thanks,

greg k-h



Subject: allow _ and @ in addresses

Signed-off-by: Greg Kroah-Hartman [EMAIL PROTECTED]

diff --git a/connect.c b/connect.c
--- a/connect.c
+++ b/connect.c
@@ -57,6 +57,7 @@ static char *shell_safe(char *url)
['A'...'Z'] = 1,
['.'] = 1, ['/'] = 1,
['-'] = 1, ['+'] = 1,
+   ['@'] = 1, ['_'] = 1,
[':'] = 1
};
 
-
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [ANNOUNCE] git-pasky-0.6.3 request for testing

[Greg KH]

On Fri, Apr 22, 2005 at 05:09:31AM +0200, Petr Baudis wrote:
   Hello,
 
   FYI, I've released git-pasky-0.6.3 earlier in the night.

Hm, fun thing to try:
go into a kernel git tree.
rm Makefile
git diff

Watch it as it thinks that every Makefile in the kernel tree is now
gone...

thanks,

greg k-h
-
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [ANNOUNCE] git-pasky-0.6.2 heads-up on upcoming changes

[Greg KH]

On Wed, Apr 20, 2005 at 10:56:33PM +0200, Petr Baudis wrote:
   The short command version will change from 'git' to 'cg', which should
 be shorter to type and free the 'git' command for possible eventual
 entry gate for the git commands (so that they are more
 namespace-friendly, and it might make most sense anyway if we get fully
 libgitized; but this is more of long-term ideas).

Hm, but there already is a 'cg' program out there:
http://uzix.org/cgvg.html
I use it every day :(

How about 'cog' instead?

Or I can just rename my local copy of cg and try to retrain my
fingers...

thanks,

greg k-h
-
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [ANNOUNCE] git-pasky-0.6.2 heads-up on upcoming changes

[Greg KH]

On Thu, Apr 21, 2005 at 12:28:15AM +0200, Petr Baudis wrote:
 Dear diary, on Thu, Apr 21, 2005 at 12:09:06AM CEST, I got a letter
 where Linus Torvalds [EMAIL PROTECTED] told me that...
  Yeah, yeah, it looks different from cvs update, but dammit, wouldn't it 
  be cool to just write cg-tabtab and see the command choices? Or 
  cg-uptab and get cg-update done for you..
 
 I like this idea! :-) I guess that is in fact exactly what I have been
 looking for, and (as probably apparent from the current git-pasky
 structure) I prefer to have the scripts separated anyway.

I agree, it would solve the issue with 'cg' being overloaded, and I too
like the tabtab completion idea.

thanks,

greg k-h
-
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [ANNOUNCE] git-pasky-0.6.2 heads-up on upcoming changes

[Greg KH]

On Wed, Apr 20, 2005 at 06:12:34PM -0700, Linus Torvalds wrote:
 
 
 On Wed, 20 Apr 2005, Linus Torvalds wrote:
  
  Pasky,
   what do you think about this change to git log?
 
 Here's a slightly updated version.
 
 It's identical to the previous one, except that it also feeds the result 
 through | ${PAGER:-less} which makes it a lot more useful, in my 
 opinion.

Yeah!

I've gotten tired of counting how many times I forgot to pipe 'git log'
to less already.  Doesn't seem to want to be canceled either...

thanks for doing this.

greg k-h
-
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: GIT Web Interface

[Greg KH]

On Tue, Apr 19, 2005 at 05:59:45PM +0200, Kay Sievers wrote:
 On Tue, 2005-04-19 at 02:52 +0200, Petr Baudis wrote:
  Dear diary, on Tue, Apr 19, 2005 at 02:44:15AM CEST, I got a letter
  where Kay Sievers [EMAIL PROTECTED] told me that...
   I'm hacking on a simple web interface, cause I missed the bkweb too much.
   It can't do much more than browse through the source tree and show the
   log now, but that should change... :)
 http://ehlo.org/~kay/gitweb.pl?project=linux-2.6
  
  Hmm, looks nice for a start. (But you have obsolete git-pasky tree there! 
  ;-)
 
 Yeah, it's fresh now. :)
 
   How can I get the files touched with a changeset and the corresponding
   diffs belonging to it?
  
  diff-tree to get the list of files, you can do the corresponding diffs
  e.g. by doing git diff -r tree1:tree2. Preferably make a patch for it
  first to make it possible to diff individual files this way.
 
 Ah, nice! Got it working.

Looks good, care to post the updated version?

thanks,

greg k-h
-
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: GIT Web Interface

[Greg KH]

On Tue, Apr 19, 2005 at 07:32:42PM +0200, Kay Sievers wrote:
 On Tue, Apr 19, 2005 at 09:52:48AM -0700, Greg KH wrote:
  On Tue, Apr 19, 2005 at 05:59:45PM +0200, Kay Sievers wrote:
   On Tue, 2005-04-19 at 02:52 +0200, Petr Baudis wrote:
Dear diary, on Tue, Apr 19, 2005 at 02:44:15AM CEST, I got a letter
where Kay Sievers [EMAIL PROTECTED] told me that...
 I'm hacking on a simple web interface, cause I missed the bkweb too 
 much.
 It can't do much more than browse through the source tree and show the
 log now, but that should change... :)
   http://ehlo.org/~kay/gitweb.pl?project=linux-2.6

Hmm, looks nice for a start. (But you have obsolete git-pasky tree 
there! ;-)
   
   Yeah, it's fresh now. :)
   
 How can I get the files touched with a changeset and the corresponding
 diffs belonging to it?

diff-tree to get the list of files, you can do the corresponding diffs
e.g. by doing git diff -r tree1:tree2. Preferably make a patch for it
first to make it possible to diff individual files this way.
   
   Ah, nice! Got it working.
  
  Looks good, care to post the updated version?
 
 Sure, but expect it to change dramatically tonight. :)

Ok, how about putting a link to it somewhere then, so you don't have to
be bothered with people like me asking for the latest copy? :)

thanks,

greg k-h
-
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [script] ge: export commits as patches

[Greg KH]

On Tue, Apr 19, 2005 at 07:03:20PM +0200, Petr Baudis wrote:
 Dear diary, on Tue, Apr 19, 2005 at 03:48:43PM CEST, I got a letter
 where Ingo Molnar [EMAIL PROTECTED] told me that...
  is there any 'export commit as patch' support in git-pasky? I didnt find 
  any such command (maybe it got added meanwhile), so i'm using the 'ge' 
  hack below.
  
  e.g. i typically look at commits via 'git log', and then when i see 
  something interesting, i look at the commit via the 'ge' script. E.g.  
  ge 834f6209b22af2941a8640f1e32b0f123c833061 done in the kernel tree 
  will output a particular commit's header and the patch.
 
 Nice idea. I will add it, probably as 'git patch'.

Ah, thanks for doing this.  'git patch' works great (but you might want
to mention in the 'help' that you can give the commit id for the patch,
if you don't want to see the HEAD patch.)

thanks,

greg k-h
-
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [GIT PATCH] I2C and W1 bugfixes for 2.6.12-rc2

[Greg KH]

On Tue, Apr 19, 2005 at 12:40:44PM -0700, Linus Torvalds wrote:
 I'm still working out some performance issues with merges (the actual
 merge operation itself is very fast, but I've been trying to make the
 subsequent update the working directory tree to the right thing be much
 better).

Ok, if you want some practice with real merges, feel free to merge from
the following two trees whenever you are ready:
kernel.org/pub/scm/linux/kernel/git/gregkh/aoe-2.6.git/
for 11 aoe bugfix patches, and:
kernel.org/pub/scm/linux/kernel/git/gregkh/driver-2.6.git/
for 13 driver core, sysfs, and debugfs fixes.

The diffstats are:

aoe:
 Documentation/aoe/mkdevs.sh   |1 
 Documentation/aoe/mkshelf.sh  |1 
 Documentation/aoe/todo.txt|   14 
 Documentation/aoe/udev-install.sh |6 +-
 drivers/block/aoe/aoe.h   |   23 +--
 drivers/block/aoe/aoeblk.c|5 +
 drivers/block/aoe/aoecmd.c|  110 ++
 drivers/block/aoe/aoedev.c|8 +-
 drivers/block/aoe/aoenet.c|8 +-
 9 files changed, 111 insertions(+), 65 deletions(-)

driver:
 Documentation/kref.txt|  221 +-
 drivers/base/class.c  |2 
 drivers/base/core.c   |3 
 drivers/base/firmware_class.c |3 
 drivers/base/platform.c   |1 
 drivers/usb/host/hc_crisv10.c |1 
 fs/partitions/check.c |2 
 fs/sysfs/file.c   |   35 ++
 include/linux/debugfs.h   |   14 +-
 include/linux/sysfs.h |7 +
 lib/kobject.c |7 -
 net/bridge/br_sysfs_if.c  |2 
 scripts/ver_linux |2 
 13 files changed, 290 insertions(+), 10 deletions(-)

No rush, but they should be good test for your merge speeds, as they are
based off of an older HEAD than your current one :)

 In other words, I want it to be at the point where people can do
 
   git pull repo-address
 
 and it will just work, at least for people who don't have any local
 changes in their tree. None of this check out all the files again crap.

That would be very nice to have.

 But how about a plan that we go live tomorrow - assuming nobody finds
 any problems before that, of course.

That's fine with me.

thanks,

greg k-h
-
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [GIT PATCH] I2C and W1 bugfixes for 2.6.12-rc2

[Greg KH]

On Tue, Apr 19, 2005 at 06:27:38PM -0400, Daniel Jacobowitz wrote:
 On Tue, Apr 19, 2005 at 03:00:04PM -0700, Linus Torvalds wrote:
  
  
  On Tue, 19 Apr 2005, Greg KH wrote:
   
   It looks like your domain name isn't set up properly for your box (which
   is why it worked for you, but not me before, causing that patch).
  
  No, I think it's a bug in your domainname changes. I don't think you
  should do the domainname at all if the hostname has a dot in it.
  
  Most machines I have access to (and that includes machines that are
  professionally maintained, not just my own cruddy setup) says (none) to
  domainname and have the full hostname in hostname.
  
  And even the ones that use domainname tend to not have a fully qualified 
  DNS domain there. You need to use dnsdomainname to get that, and I don't 
  even know how to do it with standard libc.
  
  So how about something like this?
  
  (Somebody who actually knows how these things should be done - please feel 
  free to pipe up).
 
 The glibc documentation blows for this, but what getdomainname comes
 from uname(2), not from any DNS-related configuration.  Debian only
 ever sets this if you're using NIS.

Well, somehow Gentoo sets this up properly, and I'm not using NIS.  Hm,
my SuSE boxes on the other hand...

 There's no real great way to get the current hostname; a lot of
 applications do a reverse DNS lookup on the primary network interface,
 with appropriate handwaving to define primary.
 
 Easiest might be to punt to hostname --fqdn, or an equivalent to its
 algorithm - which appears to be fetch the hostname from uname, do a DNS
 lookup on that, and a reverse DNS lookup on the result.

Ick.  Let's stick with Linus's patch for now...

thanks,

greg k-h
-
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: wit 0.0.3 - a web interface for git available

[Greg KH]

On Wed, Apr 20, 2005 at 02:29:11AM +0200, Christian Meder wrote:
 Hi,
 
 ok it's starting to look like spam ;-)
 
 I uploaded a new version of wit to http://www.absolutegiganten.org/wit

Why not work together with Kay's tool:
http://ehlo.org/~kay/gitweb.pl?project=linux-2.6action=show_log


Thanks,

greg k-h
-
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Re-done kernel archive - real one?

[Greg KH]

On Sun, Apr 17, 2005 at 04:24:24PM -0700, Linus Torvalds wrote:
 
 Tools absolutely matter. And it will take time for us to build up that 
 kind of helper infrastructure. So being newbie might be part of it, but 
 it's the smaller part, I say. Rough interfaces is a big issue.

Speaking of tools, you had a dotest program to apply patches in email
form to a bk tree.  And from what I can gather, you've changed that to
handle git archives, right?  Any pointers to where I can find this so I
could try to build up some git trees for you to merge with?  I think I
can even make a tree with a merge issue if you want to test that out :)

thanks,

greg k-h
-
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Re-done kernel archive - real one?

[Greg KH]

On Mon, Apr 18, 2005 at 08:42:14AM -0700, Linus Torvalds wrote:
 
 
 On Mon, 18 Apr 2005, Greg KH wrote:
 
  On Sun, Apr 17, 2005 at 04:24:24PM -0700, Linus Torvalds wrote:
   
   Tools absolutely matter. And it will take time for us to build up that 
   kind of helper infrastructure. So being newbie might be part of it, but 
   it's the smaller part, I say. Rough interfaces is a big issue.
  
  Speaking of tools, you had a dotest program to apply patches in email
  form to a bk tree.  And from what I can gather, you've changed that to
  handle git archives, right?
 
 Yup.
 
 It's a git archive at 
 
   kernel.org:/pub/linux/kernel/people/torvalds/git-tools.git
 
 and it seems to work. It's what I've used for all the kernel patches 
 (except for the merge), and it's what I use for the git stuff that shows 
 up as authored by others.

Hm, have you pushed all of the recent changes public?  I get the
following when trying to apply a patch:
$ ../git-tools/dotest  ~/linux/patches/usb/usb-visor-tapwave_zodiac.patch 
 mailsplit mbox directory
$ 

I set my PATH to point to the git-tools/ directory:
$ which mailsplit
/home/greg/linux/git/git-tools/mailsplit

Any thoughts?

thanks,

greg k-h
-
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Re-done kernel archive - real one?

[Greg KH]

On Mon, Apr 18, 2005 at 03:05:41PM -0700, Greg KH wrote:
 On Mon, Apr 18, 2005 at 08:42:14AM -0700, Linus Torvalds wrote:
  
  
  On Mon, 18 Apr 2005, Greg KH wrote:
  
   On Sun, Apr 17, 2005 at 04:24:24PM -0700, Linus Torvalds wrote:

Tools absolutely matter. And it will take time for us to build up that 
kind of helper infrastructure. So being newbie might be part of it, but 
it's the smaller part, I say. Rough interfaces is a big issue.
   
   Speaking of tools, you had a dotest program to apply patches in email
   form to a bk tree.  And from what I can gather, you've changed that to
   handle git archives, right?
  
  Yup.
  
  It's a git archive at 
  
  kernel.org:/pub/linux/kernel/people/torvalds/git-tools.git
  
  and it seems to work. It's what I've used for all the kernel patches 
  (except for the merge), and it's what I use for the git stuff that shows 
  up as authored by others.
 
 Hm, have you pushed all of the recent changes public?  I get the
 following when trying to apply a patch:
 $ ../git-tools/dotest  ~/linux/patches/usb/usb-visor-tapwave_zodiac.patch 
  mailsplit mbox directory

Doh, you want it as a command line argument now.  Stupid me...

Anyway, I try it this way and get:

$ dotest ~/linux/patches/usb/usb-visor-tapwave_zodiac.patch 

Applying USB: visor Tapwave Zodiac support patch

fatal: preparing to update file 'drivers/usb/serial/visor.c' not uptodate in 
cache


What did I forget to do?

thanks,

greg k-h
-
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[GIT PATCH] I2C and W1 bugfixes for 2.6.12-rc2

[Greg KH]

Alright, let's try some small i2c and w1 patches...

Could you merge with:
kernel.org/pub/scm/linux/kernel/git/gregkh/i2c-2.6.git/

It contains 4 small patches, 2 i2c and 2 w1 bugfixes, diffstat is
below, I'll figure out how to send the individual patches later.

thanks,

greg k-h

 drivers/i2c/chips/it87.c|2 +-
 drivers/i2c/chips/via686a.c |7 ++-
 drivers/w1/w1.c |9 +
 drivers/w1/w1_smem.c|4 ++--
 4 files changed, 10 insertions(+), 12 deletions(-)
 
-
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html