Re: [ANNOUNCE] Git v1.9-rc0
On Mon, Jan 27, 2014 at 02:56:28PM -0800, Junio C Hamano wrote: > > # replace this with however you store your oauth token > > # if you don't have one, make one here: > > # https://github.com/settings/tokens/new > > token() { > > pass -n github.web.oauth > > Hmph, what is this "pass" thing? It's a poor man's Keychain: https://github.com/peff/pass Judging from your use of netrc in Meta/RelUpload, you probably just want: token() { cat ~/.github-token } -Peff -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [ANNOUNCE] Git v1.9-rc0
Jeff King writes: > On Thu, Jan 23, 2014 at 10:15:33AM -0800, Junio C Hamano wrote: > >> Jeff King writes: >> >> > Junio, since you prepare such tarballs[1] anyway for kernel.org, it >> > might be worth uploading them to the "Releases" page of git/git. I >> > imagine there is a programmatic way to do so via GitHub's API, but I >> > don't know offhand. I can look into it if you are interested. >> >> I already have a script that takes the three tarballs and uploads >> them to two places, so adding GitHub as the third destination should >> be a natural and welcome way to automate it. > > I came up with the script below, which you can use like: > > ./script v1.8.2.3 git-1.8.2.3.tar.gz > > It expects the tag to already be pushed up to GitHub. I'll leave > sticking it on the "todo" branch and integrating it into RelUpload to > you. This can also be used to backfill the old releases (though I looked > on k.org and it seems to have only partial coverage). > > It sets the "prerelease" flag for -rc releases, but I did not otherwise > fill in any fields, including the summary and description. GitHub seems > to display reasonably if they are not set. Thanks. > -- >8 -- > #!/bin/sh > # > # usage: $0 > > repo=git/git > > # replace this with however you store your oauth token > # if you don't have one, make one here: > # https://github.com/settings/tokens/new > token() { > pass -n github.web.oauth Hmph, what is this "pass" thing? > } > > post() { > curl -H "Authorization: token $(token)" "$@" > } > > # usage: create > create() { > case "$1" in > *-rc*) > prerelease=true > ;; > *) > prerelease=false > ;; > esac > > post -d ' > { > "tag_name": "'"$1"'", > "prerelease": '"$prerelease"' > }' "https://api.github.com/repos/$repo/releases"; > } > > # use: upload > upload() { > url="https://uploads.github.com/repos/$repo/releases/$1/assets"; && > url="$url?name=$(basename $2)" && > post -H "Content-Type: $(file -b --mime-type "$2")" \ >--data-binary "@$2" \ >"$url" > } > > # This is a hack. If you don't mind a dependency on > # perl's JSON (or another parser), we can do a lot better. > extract_id() { > perl -lne '/"id":\s*(\d+)/ or next; print $1; exit 0' > } > > create "$1" >release.json && > id=$(extract_id upload "$id" "$2" >/dev/null && > rm -f release.json -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [ANNOUNCE] Git v1.9-rc0
On Thu, Jan 23, 2014 at 10:15:33AM -0800, Junio C Hamano wrote: > Jeff King writes: > > > Junio, since you prepare such tarballs[1] anyway for kernel.org, it > > might be worth uploading them to the "Releases" page of git/git. I > > imagine there is a programmatic way to do so via GitHub's API, but I > > don't know offhand. I can look into it if you are interested. > > I already have a script that takes the three tarballs and uploads > them to two places, so adding GitHub as the third destination should > be a natural and welcome way to automate it. I came up with the script below, which you can use like: ./script v1.8.2.3 git-1.8.2.3.tar.gz It expects the tag to already be pushed up to GitHub. I'll leave sticking it on the "todo" branch and integrating it into RelUpload to you. This can also be used to backfill the old releases (though I looked on k.org and it seems to have only partial coverage). It sets the "prerelease" flag for -rc releases, but I did not otherwise fill in any fields, including the summary and description. GitHub seems to display reasonably if they are not set. -- >8 -- #!/bin/sh # # usage: $0 repo=git/git # replace this with however you store your oauth token # if you don't have one, make one here: # https://github.com/settings/tokens/new token() { pass -n github.web.oauth } post() { curl -H "Authorization: token $(token)" "$@" } # usage: create create() { case "$1" in *-rc*) prerelease=true ;; *) prerelease=false ;; esac post -d ' { "tag_name": "'"$1"'", "prerelease": '"$prerelease"' }' "https://api.github.com/repos/$repo/releases"; } # use: upload upload() { url="https://uploads.github.com/repos/$repo/releases/$1/assets"; && url="$url?name=$(basename $2)" && post -H "Content-Type: $(file -b --mime-type "$2")" \ --data-binary "@$2" \ "$url" } # This is a hack. If you don't mind a dependency on # perl's JSON (or another parser), we can do a lot better. extract_id() { perl -lne '/"id":\s*(\d+)/ or next; print $1; exit 0' } create "$1" >release.json && id=$(extract_id /dev/null && rm -f release.json -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [ANNOUNCE] Git v1.9-rc0
Jeff King writes: > Junio, since you prepare such tarballs[1] anyway for kernel.org, it > might be worth uploading them to the "Releases" page of git/git. I > imagine there is a programmatic way to do so via GitHub's API, but I > don't know offhand. I can look into it if you are interested. I already have a script that takes the three tarballs and uploads them to two places, so adding GitHub as the third destination should be a natural and welcome way to automate it. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [ANNOUNCE] Git v1.9-rc0
On Wed, Jan 22, 2014 at 08:30:30PM +, Ken Moffat wrote: > Two questions: Does regenerating (e.g. if the tarball has dropped > out of the cache) change its sums (md5sum or similar) ? In (beyond) > linuxfromscratch we use md5sums to verify that a tarball has not > changed. The tarballs we auto-generate from tags are cached, but they can change if the cached version expires _and_ the archive-generation code changes. We use "git archive" to generate the tarballs themselves, and then gzip the with "gzip -n". So it should be consistent from run to run. However, very occasionally there are bugfixes in "git archive" which can affect the output. E.g., commit 22f0dcd (archive-tar: split long paths more carefully, 2013-01-05) changes the representation of certain long paths, and generating a tarball with and without it will result in different checksums (for some repos). So if you are planning on baking md5sums into a package-build system, it is much better to point at "official" releases which are rolled once by the project maintainer, rather than the automatic tag page. Junio, since you prepare such tarballs[1] anyway for kernel.org, it might be worth uploading them to the "Releases" page of git/git. I imagine there is a programmatic way to do so via GitHub's API, but I don't know offhand. I can look into it if you are interested. -Peff -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [ANNOUNCE] Git v1.9-rc0
On Wed, Jan 22, 2014 at 01:04:02PM -0800, Junio C Hamano wrote: > Ken Moffat writes: > > > I note that all of these *are* still available at googlecode for > > the moment : https://code.google.com/p/git-core/downloads/list > > As I said, Cgc is not the ony download site. The end of > > http://git-blame.blogspot.com/p/git-public-repositories.html > > lists the two sites that currently have the material. I may replace > Cgc with something else (and add it/them to the list), but in the > meantime I do not think k.org will go out of business in anytime > soon, so... > OK, thanks for the pointer to https://www.kernel.org/pub/software/scm/git/ for released tarballs. ĸen -- das eine Mal als Tragödie, dieses Mal als Farce -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [ANNOUNCE] Git v1.9-rc0
Ken Moffat writes: > I note that all of these *are* still available at googlecode for > the moment : https://code.google.com/p/git-core/downloads/list As I said, Cgc is not the ony download site. The end of http://git-blame.blogspot.com/p/git-public-repositories.html lists the two sites that currently have the material. I may replace Cgc with something else (and add it/them to the list), but in the meantime I do not think k.org will go out of business in anytime soon, so... -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [ANNOUNCE] Git v1.9-rc0
On Wed, Jan 22, 2014 at 10:10:18AM -0800, Junio C Hamano wrote: > Vicent Martí writes: > > >> Do these consume CPU every time somebody asks for a tarball? That > >> might be considered "wrong" depending on the view. > > > > No, our infrastructure caches frequently requested tarballs so they > > don't have to be regenerated on the fly. > > Thanks. That is certainly good enough for consumers, and better > than having to manually create and upload for me ;-) Two questions: Does regenerating (e.g. if the tarball has dropped out of the cache) change its sums (md5sum or similar) ? In (beyond) linuxfromscratch we use md5sums to verify that a tarball has not changed. Also, will there be links for manpages and htmldocs tarballs ? I note that all of these *are* still available at googlecode for the moment : https://code.google.com/p/git-core/downloads/list ĸen -- das eine Mal als Tragödie, dieses Mal als Farce -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [ANNOUNCE] Git v1.9-rc0
Vicent Martí writes: >> Do these consume CPU every time somebody asks for a tarball? That >> might be considered "wrong" depending on the view. > > No, our infrastructure caches frequently requested tarballs so they > don't have to be regenerated on the fly. Thanks. That is certainly good enough for consumers, and better than having to manually create and upload for me ;-) -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [ANNOUNCE] Git v1.9-rc0
On Wed, Jan 22, 2014 at 5:11 PM, Junio C Hamano wrote: > Stefan Näwe writes: > >> Am 22.01.2014 13:53, schrieb Javier Domingo Cansino: >>> Will there be any change on how tarballs are distributed, taking into >>> account that Google will be shutting down Google Code Downloads >>> section[1][2]? >>> >> >> Am I missing something or what's wrong with this: >> >> https://github.com/gitster/git/archive/v1.9-rc0.tar.gz >> >> or any >> >> https://github.com/gitster/git/archive/$TAG.tar.gz >> >> ?? > > Do these consume CPU every time somebody asks for a tarball? That > might be considered "wrong" depending on the view. No, our infrastructure caches frequently requested tarballs so they don't have to be regenerated on the fly. If you would prefer to distribute a different version of the tarball for the release (e.g. one with a different filename or folder structure), you can upload it directly to the release page of the tag: https://github.com/gitster/git/releases/tag/v1.9-rc0 We'll automatically mirror your release to S3 and serve it from there. You can also go ahead and edit the release page with the changelog you've posted in this email thread to make it more user friendly. WE WILL SERVE YOUR RELEASES, JUNIO BECAUSE WE LOVE YOU -vmg -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [ANNOUNCE] Git v1.9-rc0
Stefan Näwe writes: > Am 22.01.2014 13:53, schrieb Javier Domingo Cansino: >> Will there be any change on how tarballs are distributed, taking into >> account that Google will be shutting down Google Code Downloads >> section[1][2]? >> > > Am I missing something or what's wrong with this: > > https://github.com/gitster/git/archive/v1.9-rc0.tar.gz > > or any > > https://github.com/gitster/git/archive/$TAG.tar.gz > > ?? Do these consume CPU every time somebody asks for a tarball? That might be considered "wrong" depending on the view. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [ANNOUNCE] Git v1.9-rc0
Am 22.01.2014 13:53, schrieb Javier Domingo Cansino: > Will there be any change on how tarballs are distributed, taking into > account that Google will be shutting down Google Code Downloads > section[1][2]? > Am I missing something or what's wrong with this: https://github.com/gitster/git/archive/v1.9-rc0.tar.gz or any https://github.com/gitster/git/archive/$TAG.tar.gz ?? (As long as Junio continues to push to github, of course) Stefan -- /dev/random says: Folks who think they know it all bug those of us who do python -c "print '73746566616e2e6e616577654061746c61732d656c656b74726f6e696b2e636f6d'.decode('hex')" -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [ANNOUNCE] Git v1.9-rc0
Javier Domingo Cansino writes: > Will there be any change on how tarballs are distributed, taking into > account that Google will be shutting down Google Code Downloads > section[1][2]? Aside from the obvious "we won't be able to use something that is no longer offered"? They are not the only download site even now, so... -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [ANNOUNCE] Git v1.9-rc0
Will there be any change on how tarballs are distributed, taking into account that Google will be shutting down Google Code Downloads section[1][2]? Cheers Javier Domingo Cansino [1] Google Code download service change announcement: http://google-opensource.blogspot.se/2013/05/a-change-to-google-code-download-service.html [2] Google Code download section FAQ: https://code.google.com/p/support/wiki/DownloadsFAQ -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[ANNOUNCE] Git v1.9-rc0
An early preview release Git v1.9-rc0 is now available for testing at the usual places. I tagged this late last week, but forgot to send out the announcement before I left for the weekend, and then I wasn't well yesterday, but anyway. There still may be a few minor topics not in this preview but should be in the final release, but otherwise, this should be pretty close to "it". It has been reported that turning git.rc into git.res does not like the new 2-dewey-decimal release numbering scheme; packagers of various distro might find similar issues in their build procedures, in which case they have about 3 weeks to update them until the final release. The release tarballs are found at: http://code.google.com/p/git-core/downloads/list and their SHA-1 checksums are: 495108620f8547ec8e979549857dae96bfabb0f7 git-1.9.rc0.tar.gz daf964f46acd9ba72ebcdfbd1ef0c668206a0d92 git-htmldocs-1.9.rc0.tar.gz a3b83356f738d1452bcee1d43ac5267a08986292 git-manpages-1.9.rc0.tar.gz The following public repositories all have a copy of the v1.9-rc0 tag and the v1.9-rc0 branch that the tag points at: url = https://kernel.googlesource.com/pub/scm/git/git url = git://repo.or.cz/alt-git.git url = https://code.google.com/p/git-core/ url = git://git.sourceforge.jp/gitroot/git-core/git.git url = git://git-core.git.sourceforge.net/gitroot/git-core/git-core url = https://github.com/gitster/git Git v1.9 Release Notes (draft) == Backward compatibility notes "git submodule foreach $cmd $args" used to treat "$cmd $args" the same way "ssh" did, concatenating them into a single string and letting the shell unquote. Careless users who forget to sufficiently quote $args gets their argument split at $IFS whitespaces by the shell, and got unexpected results due to this. Starting from this release, the command line is passed directly to the shell, if it has an argument. Read-only support for experimental loose-object format, in which users could optionally choose to write in their loose objects for a short while between v1.4.3 to v1.5.3 era, has been dropped. The meanings of "--tags" option to "git fetch" has changed; the command fetches tags _in addition to_ what are fetched by the same command line without the option. The way "git push $there $what" interprets $what part given on the command line, when it does not have a colon that explicitly tells us what ref at the $there repository is to be updated, has been enhanced. A handful of ancient commands that have long been deprecated are finally gone (repo-config, tar-tree, lost-found, and peek-remote). Backward compatibility notes (for Git 2.0) -- When "git push [$there]" does not say what to push, we have used the traditional "matching" semantics so far (all your branches were sent to the remote as long as there already are branches of the same name over there). In Git 2.0, the default will change to the "simple" semantics, which pushes: - only the current branch to the branch with the same name, and only when the current branch is set to integrate with that remote branch, if you are pushing to the same remote as you fetch from; or - only the current branch to the branch with the same name, if you are pushing to a remote that is not where you usually fetch from. Use the user preference configuration variable "push.default" to change this. If you are an old-timer who is used to the "matching" semantics, you can set the variable to "matching" to keep the traditional behaviour. If you want to live in the future early, you can set it to "simple" today without waiting for Git 2.0. When "git add -u" (and "git add -A") is run inside a subdirectory and does not specify which paths to add on the command line, it will operate on the entire tree in Git 2.0 for consistency with "git commit -a" and other commands. There will be no mechanism to make plain "git add -u" behave like "git add -u .". Current users of "git add -u" (without a pathspec) should start training their fingers to explicitly say "git add -u ." before Git 2.0 comes. A warning is issued when these commands are run without a pathspec and when you have local changes outside the current directory, because the behaviour in Git 2.0 will be different from today's version in such a situation. In Git 2.0, "git add " will behave as "git add -A ", so that "git add dir/" will notice paths you removed from the directory and record the removal. Versions before Git 2.0, including this release, will keep ignoring removals, but the users who rely on this behaviour are encouraged to start using "git add --ignore-removal " now before 2.0 is released. The default prefix for "git svn" will change in Git 2.0. For a long time, "git svn" created its remote-tracking branches directly under refs/remotes, but it will place them under refs/remotes/origin/ unless it is told otherwise with its --prefix option. Updates since v1