Re: email as a bona fide git transport
On Thu, Oct 17, 2019 at 04:45:32PM -0400, Konstantin Ryabitsev wrote: > On Thu, Oct 17, 2019 at 01:43:43PM -0700, Greg KH wrote: > > > I wonder if it'd be also possible to then embed gpg signatures over > > > send-mail payloads so as they can be transparently transferred to the > > > commit. > > > > That's a crazy idea. It would be nice if we could do that, I like it :) > > It could only possibly work if nobody ever adds their own "Signed-Off-By" or > any other bylines. I expect this is a deal-breaker for most maintainers. Yeah it is :( But, if we could just have the signature on the code change, not the changelog text, that would help with that issue. thanks, rgeg k-h
Re: email as a bona fide git transport
On Wed, Oct 16, 2019 at 10:45:19AM -0400, Santiago Torres Arias wrote: > Hi Willy, Vegard. > > On Wed, Oct 16, 2019 at 01:10:09PM +0200, Willy Tarreau wrote: > > Hi Vegard, > > > > On Wed, Oct 16, 2019 at 12:22:54PM +0200, Vegard Nossum wrote: > > > (cross-posted to git, LKML, and the kernel workflows mailing lists.) > > > > > > Hi all, > > > > > > I've been following Konstantin Ryabitsev's quest for better development > > > and communication tools for the kernel [1][2][3], and I would like to > > > propose a relatively straightforward idea which I think could bring a > > > lot to the table. > > > > > > Step 1: > > > > > > * git send-email needs to include parent SHA1s and generally all the > > > information needed to perfectly recreate the commit when applied so > > > that all the SHA1s remain the same > > > > > > * git am (or an alternative command) needs to recreate the commit > > > perfectly when applied, including applying it to the correct parent > > > > > > Having these two will allow a perfect mapping between email and git; > > > essentially email just becomes a transport for git. There are a lot of > > > advantages to this, particularly that you have a stable way to refer to > > > a patch or commit (despite it appearing on a mailing list), and there > > > is no need for "changeset IDs" or whatever, since you can just use the > > > git SHA1 which is unique, unambiguous, and stable. > > I wonder if it'd be also possible to then embed gpg signatures over > send-mail payloads so as they can be transparently transferred to the > commit. That's a crazy idea. It would be nice if we could do that, I like it :) greg k-h
git email From: parsing (was Re: [GIT PULL] Staging/IIO driver patches for 4.11-rc1)
On Wed, Feb 22, 2017 at 11:59:01AM -0800, Linus Torvalds wrote: > On Wed, Feb 22, 2017 at 6:56 AM, Greg KH 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
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
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
On Mon, Jun 01, 2015 at 01:23:26PM -0700, Junio C Hamano wrote: > Eric Sunshine 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 > --- > 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
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 > 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 > Signed-off-by: Greg Kroah-Hartman > > $ 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
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 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 Signed-off-by: Greg Kroah-Hartman $ 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?
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: > > > > > > 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
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
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
On Sun, Feb 03, 2013 at 09:05:55PM -0800, Junio C Hamano wrote: > Greg KH 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
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
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
Re: "git archve --format=tar" output changed from 1.8.1 to 1.8.2.1
On Thu, Jan 31, 2013 at 10:16:27AM -0800, Junio C Hamano wrote: > Greg KH 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
On Thu, Jan 31, 2013 at 09:32:12AM -0800, Junio C Hamano wrote: > Greg KH 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
"git archve --format=tar" output changed from 1.8.1 to 1.8.2.1
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: no diffstat for 'git request-pull' (was Re: [GIT PATCH] char/misc changes for 3.7-rc1)
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
no diffstat for 'git request-pull' (was Re: [GIT PATCH] char/misc changes for 3.7-rc1)
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: Funny 'git describe --contains' output
On Tue, Aug 28, 2012 at 11:36:46PM -0700, Junio C Hamano wrote: > Junio C Hamano writes: > > > Greg KH writes: > > > >> 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 > >> ... > >> Any ideas? > > > > That is 59 + 1 + 56 + 1 + 76 = 193 steps away from the tag v3.6-rc1. > > > > $ git name-rev --refs=refs/tags/v3.5-rc1 0136db58 > > 0136db58 tags/v3.5-rc1~83^2~81^2~76 > > > > which is 83 + 1 + 81 + 1 + 76 = 242 steps away from that tag. > > > > So it _is_ odd that the newly tagged tip merged a branch that had > > smaller development since it merged the commit, but name-rev seems > > to be measuring the steps it takes from the tags to reach the commit > > and giving us the one that gives the shortest path correctly. > > > > Obviously, that is not the same as "which tag is the oldest one > > among the ones that can reach this commit?" > > As is usual for what I say, the above is an explanation of what we > are seeing, not necessarily a justification. > > Given a history of this shape: > > o---o---o---o TONS!!! > \ > ---o--o--o--o--o--Y--o---o---Z > \ / / > \ / / >X---o > > where Y is v3.5-rc1 and Z is v3.6-rc1, "name-rev X" measures the > distance of the shortest path between Z and X (Z^^2^ = 3 steps away) > and between Y and X (Y~3^2 = 4 steps away), and uses the tag with > the shortest path. > > But in order to answer "which is the earlier tag that merges X", > what "name-rev" measures is not very interesting. > > What we want to see is the tag whose "weight" (imagine these commits > are beads on strings, and you hold the tag between your fingers and > lift it, pulling all the commits behind it on the history) is the > smallest and reaches the commit X in question. The distance on the > shortest path to X totally ignores tons of merges that went into the > mainline between Y and Z. That is what makes name-rev not useful > for this purpose. > > That "weight" is what Linus's "rev-list | wc -l" showed, but it is > fairly expensive to compute. We do have a code that computes such > weight in the history bisection code (it computes this exact weight > for each and every commit that is still suspect, and picks the one > that is half-way). We know how to compute it, but I suspect that > applying that code naively to name-rev would make it unusably slow. Thanks for the full explaination. "Normally" this never is an issue for me, as this is the first time, in the history of Linux stable kernel releases, that I've ever noticed this. And I agree, it's probably not something that can easily be resolved in git, given how it's calculated. 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
Funny 'git describe --contains' output
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
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
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
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
Re: git-pull-script hates me
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: git-pull-script hates me
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
git-pull-script hates me
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: [ANNOUNCE] git-pasky-0.6.3 && request for testing
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: wit 0.0.3 - a web interface for git available
On Thu, Apr 21, 2005 at 03:28:27AM +0200, Kay Sievers wrote: > On Wed, Apr 20, 2005 at 10:42:53AM +0100, Christoph Hellwig wrote: > > On Tue, Apr 19, 2005 at 09:18:29PM -0700, Greg KH wrote: > > > 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.6&action=show_log > > > > That one looks really nice. One major feature I'd love to see would > > be a show all diffs link for a changeset. > > It's working now: > http://ehlo.org/~kay/gitweb.pl > > Many thanks to Christian Gierke for all the interface work, the nice > layout and the git logo. Thanks for the colored diff to Ken Brush. Very nice, this looks great. And hey, we have a git logo now :) 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
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: [ANNOUNCE] git-pasky-0.6.2 && heads-up on upcoming changes
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-" and see the command choices? Or > > "cg-up" 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 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
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: wit 0.0.3 - a web interface for git available
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.6&action=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: [GIT PATCH] I2C and W1 bugfixes for 2.6.12-rc2
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: [GIT PATCH] I2C and W1 bugfixes for 2.6.12-rc2
On Tue, Apr 19, 2005 at 01:20:47PM -0700, Linus Torvalds wrote: > > > On Tue, 19 Apr 2005, Greg KH wrote: > > > > 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. > > Done, pushed out. Can you verify that the end result looks sane to you? I > just cheched that the diffstat looks similar (mine claims just 108 lines > changed in aoecmd.c - possibly due to different diff formats). Looks good to me (the diffstat difference is probably because the patches were consecutive, and the sum of them are smaller (modifying same parts of the files, etc.)) The git-changes-script shows that you picked up everything from my trees successfully (assuming we trust that so far) and a raw diff looks good too. Two "odd" things in the changelog: commit cebc2380426b64aaa60a169834a7aefc956c tree 484292d57c19acbf04cf5c783e7d26181b95e96e parent 334a4e1b19f7f471594f7abd3bfead3720c1bd61 author Hugh Dickins <[EMAIL PROTECTED]> Wed, 20 Apr 2005 03:29:23 -0700 committer Linus Torvalds <[EMAIL PROTECTED](none)> Wed, 20 Apr 2005 03:29:23 -0700 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). Also the date is in the future with the -0700, yet the time is in UTC. Oh wait, that's a 'git log' thing, the raw changeset is correct, I guess I'll wait for Pasky to fix that :) > And yes, my new merge thing seems to have kept the index-cache much better > up-to-date, allowing an optimized checkout-cache -f -a to work and only > get the new files. Very nice. 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
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 > > 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: [script] ge: export commits as patches
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
On Mon, Apr 18, 2005 at 09:39:38PM -0700, Greg KH wrote: > 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/ Nice, it looks like the merge of this tree, and my usb tree worked just fine. So, what does this now mean? Is your kernel.org git tree now going to be the "real" kernel tree that you will be working off of now? Should we crank up the nightly snapshots and emails to the -commits list? Can I rely on the fact that these patches are now in your tree and I can forget about them? :) Just wondering how comfortable you feel with your git tree so far. 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
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: GIT Web Interface
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
[GIT PATCH] I2C and W1 bugfixes for 2.6.12-rc2
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
Re: [PATCH] provide better committer information to commit-tree.c
On Tue, Apr 19, 2005 at 10:52:30AM +1000, David Woodhouse wrote: > On Mon, 2005-04-18 at 17:45 -0700, Greg KH wrote: > > Well Russell has stated that he has to for EU Privacy reasons. And I'd > > like to do it as I don't have a local suse.de hostname for my laptop and > > my employer probably doesn't really want my [EMAIL PROTECTED] address > > showing up :) > > Why not? Do they complain that we see '[EMAIL PROTECTED]' when you > connect to an IRC server? No, this employer seems quite sane :) However, irc connections are as "real" as a kernel changelog message to a lot of people. > This _isn't_ an email address, and doesn't really need to be treated > as such. Ok, then why display it as one? Seriously, it doesn't really bother me, just added it as I thought others would need it. I know the "shortlog" program can pick the real names out of the Signed-off-by: lines. But I'll wait for Russell to wake up and start quoting the proper EU privacy laws that he feels causes him to be forced to obfuscate his email addresses in the changelog commits (as he did for the bk ones.) 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] USB updates for 2.6.12-rc2
Hm, I think I got this set up properly, but don't have an automated script to generate the changelog and diffstat messages yet, so bear with me... Could you merge with: kernel.org/pub/scm/linux/kernel/git/gregkh/usb-2.6.git/ It should be against your latest git tree. It contains a number of USB patches (that I'm holding on to still, in case something happens to this...) that are bug fix only. The diffstat is below. I'll figure out how to send the patches out to the mailing list later on, if these "stick". And damm if git isn't fast on applying these patches, very nice job, I like it. thanks, greg k-h drivers/net/irda/stir4200.c |4 drivers/usb/class/audio.c | 48 +++--- drivers/usb/class/bluetty.c |4 drivers/usb/core/config.c |3 drivers/usb/core/devices.c|8 - drivers/usb/core/devio.c | 72 ++-- drivers/usb/core/file.c |2 drivers/usb/core/hcd-pci.c| 151 -- drivers/usb/core/hcd.h|4 drivers/usb/core/hub.c| 24 ++--- drivers/usb/core/inode.c |1 drivers/usb/core/message.c| 25 - drivers/usb/core/urb.c| 16 ++- drivers/usb/core/usb.c| 13 -- drivers/usb/core/usb.h|8 + drivers/usb/gadget/ether.c| 56 +--- drivers/usb/gadget/omap_udc.c | 12 +- drivers/usb/gadget/rndis.c| 40 - drivers/usb/gadget/rndis.h|4 drivers/usb/gadget/serial.c |5 - drivers/usb/host/ehci-dbg.c |2 drivers/usb/host/ehci-hcd.c |4 drivers/usb/host/ehci-mem.c |3 drivers/usb/host/ehci-sched.c |4 drivers/usb/host/ehci.h |2 drivers/usb/host/ohci-omap.c |4 drivers/usb/host/ohci-pci.c | 21 +++- drivers/usb/host/ohci-pxa27x.c|5 - drivers/usb/host/ohci-q.c | 13 ++ drivers/usb/host/ohci.h |2 drivers/usb/host/uhci-hcd.c |9 -- drivers/usb/input/aiptek.c|1 drivers/usb/input/hid-core.c |9 -- drivers/usb/media/dabusb.c|3 drivers/usb/media/ov511.c | 12 -- drivers/usb/media/se401.c | 15 +-- drivers/usb/media/usbvideo.c |6 - drivers/usb/media/w9968cf.c |6 - drivers/usb/misc/auerswald.c | 26 ++--- drivers/usb/misc/sisusbvga/sisusb.c |3 drivers/usb/net/pegasus.c | 22 drivers/usb/net/usbnet.c | 32 +-- drivers/usb/net/zd1201.c |3 drivers/usb/serial/belkin_sa.c|3 drivers/usb/serial/cypress_m8.c |5 - drivers/usb/serial/digi_acceleport.c | 10 +- drivers/usb/serial/empeg.c|6 - drivers/usb/serial/ftdi_sio.c | 10 -- drivers/usb/serial/io_edgeport.c | 24 + drivers/usb/serial/io_ti.c|5 - drivers/usb/serial/kl5kusb105.c |3 drivers/usb/serial/omninet.c |5 - drivers/usb/serial/pl2303.c | 56 drivers/usb/serial/pl2303.h |4 drivers/usb/serial/ti_usb_3410_5052.c |3 drivers/usb/serial/visor.c|6 + drivers/usb/serial/visor.h|4 drivers/usb/storage/sddr55.c | 24 + drivers/usb/storage/transport.c |2 drivers/usb/storage/unusual_devs.h| 13 ++ include/linux/usb.h |4 include/linux/usb_cdc.h |2 62 files changed, 467 insertions(+), 429 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
Re: [PATCH] provide better committer information to commit-tree.c
On Mon, Apr 18, 2005 at 05:31:16PM -0700, Linus Torvalds wrote: > > > On Mon, 18 Apr 2005, Greg KH wrote: > > > > Here's a small patch to commit-tree.c that does two things: > > Gaah, I really was hoping that people wouldn't feel like they have to lie > about their committer information. > > I guess we don't have much choice, but I'm not happy about it. Well Russell has stated that he has to for EU Privacy reasons. And I'd like to do it as I don't have a local suse.de hostname for my laptop and my employer probably doesn't really want my [EMAIL PROTECTED] address showing up :) But if you really don't like it, and you don't want anyone trying to hide anything, at least allow for a proper domainname. On my boxes, the domainname doesn't show up at all without that patch (just the getdomainname() part). I'll split it out if you want. 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
[PATCH] provide better committer information to commit-tree.c
Here's a small patch to commit-tree.c that does two things:
- allows the committer email address and name to be overridden
by environment variables (if you don't like the environment
variable names I've used (COMMIT_AUTHOR_NAME,
COMMIT_AUTHOR_EMAIL), feel free to change them.)
- provide the proper domainname to the author/committer email
address (otherwise, my address was only showing up as from the
hostname.)
This allows people to set sane values for the commit names and email
addresses, preventing odd, private hostnames and domains from being
exposed to the world.
Signed-off-by: Greg Kroah-Hartman <[EMAIL PROTECTED]>
--- a/commit-tree.c.orig2005-04-18 17:02:50.0 -0700
+++ b/commit-tree.c 2005-04-18 17:03:19.0 -0700
@@ -284,8 +284,8 @@
unsigned char tree_sha1[20];
unsigned char parent_sha1[MAXPARENT][20];
unsigned char commit_sha1[20];
- char *gecos, *realgecos;
- char *email, realemail[1000];
+ char *gecos, *realgecos, *commitgecos;
+ char *email, *commitemail, realemail[1000];
char date[20], realdate[20];
char *audate;
char comment[1000];
@@ -317,20 +317,24 @@
memcpy(realemail, pw->pw_name, len);
realemail[len] = '@';
gethostname(realemail+len+1, sizeof(realemail)-len-1);
+ strcat(realemail, ".");
+ getdomainname(realemail+strlen(realemail),
sizeof(realemail)-strlen(realemail)-1);
time(&now);
tm = localtime(&now);
strftime(realdate, sizeof(realdate), "%s %z", tm);
strcpy(date, realdate);
+ commitgecos = getenv("COMMIT_AUTHOR_NAME") ? : realgecos;
+ commitemail = getenv("COMMIT_AUTHOR_EMAIL") ? : realemail;
gecos = getenv("AUTHOR_NAME") ? : realgecos;
email = getenv("AUTHOR_EMAIL") ? : realemail;
audate = getenv("AUTHOR_DATE");
if (audate)
parse_rfc2822_date(audate, date, sizeof(date));
- remove_special(gecos); remove_special(realgecos);
- remove_special(email); remove_special(realemail);
+ remove_special(gecos); remove_special(realgecos);
remove_special(commitgecos);
+ remove_special(email); remove_special(realemail);
remove_special(commitemail);
init_buffer(&buffer, &size);
add_buffer(&buffer, &size, "tree %s\n", sha1_to_hex(tree_sha1));
@@ -345,7 +349,7 @@
/* Person/date information */
add_buffer(&buffer, &size, "author %s <%s> %s\n", gecos, email, date);
- add_buffer(&buffer, &size, "committer %s <%s> %s\n\n", realgecos,
realemail, realdate);
+ add_buffer(&buffer, &size, "committer %s <%s> %s\n\n", commitgecos,
commitemail, realdate);
/* And add the comment */
while (fgets(comment, sizeof(comment), stdin) != NULL)
-
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?
On Mon, Apr 18, 2005 at 04:16:45PM -0700, Linus Torvalds wrote: > > > On Mon, 18 Apr 2005, Greg KH wrote: > > > > Anyway, I try it this way and get: > > You should update to the newest version anyway.. > > > $ 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? > > The most common reason is that the scripts _really_ want the index to > match your current tree exactly. Run "update-cache --refresh". And if you > have any uncommitted information, make sure to commit it first. Ah, that was the step I was missing, thanks, it's working now. 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?
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 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
Re: Re-done kernel archive - real one?
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 $ 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?
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
