* Antw: Re: Q: "git diff" using tag names
From: Ulrich Windl @ 2011-11-02 7:35 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git
In-Reply-To: <m3aa8l5k1y.fsf@localhost.localdomain>
>>> Jakub Narebski <jnareb@gmail.com> schrieb am 28.10.2011 um 15:21 in Nachricht
<m3aa8l5k1y.fsf@localhost.localdomain>:
> "Ulrich Windl" <Ulrich.Windl@rz.uni-regensburg.de> writes:
>
> > When using a somewhat older git (of SLES11 SP1 SDK),
>
> Nb. you can check version of git with "git --version".
Hi!
For the records, it's "1.6.0.2"...
>
> > I could not
> > find a way to "git diff" between two tag names; I can only diff
> > between two commit numbers. I can display a changeset using "git
> > show", but that's not what I wanted.
> >
> > Is it possible to get the diff I want using older versions, and is
> > such a feature implemented in the current version? If so, since
> > when?
>
> From the very beginning in Git you can use tag name where you need
> commit identifier; Git would use commit that tag points to (will
> dereference or peel a tag).
As said before, I was confused by the simplicity: I was looking for an option to specify revisions (as opposed to file names), like "-r" for RCS, but found none. To make things complicated, I had mistyped one tag name without noticing, so I failed to diff, making me think that tag names won't work the way they actually do.
Sorry, and thanks to everybody who helped!
Ulrich
>
> That is not possible in some [censored] version control systems; I am
> looking at you, Subversion!
>
>
> So if you can do
>
> $ git show v0.9
> $ git show v1.0
>
> you can also do
>
> $ git diff v0.9 v1.0
>
> and
>
> $ git log v0.9..v1.0
^ permalink raw reply
* Re: [msysGit] Re: [PATCHv2] Compile fix for MSVC
From: Vincent van Ravesteijn @ 2011-11-02 7:34 UTC (permalink / raw)
To: Pat Thoyts
Cc: Johannes Schindelin, ramsay, msysgit, Karsten Blees, git,
Junio C Hamano, Erik Faye-Lund
In-Reply-To: <CABNJ2G+Km4wob4_uNYQLkQUL61-ohZg5cL2yu7j1cngoL9W7Cw@mail.gmail.com>
Op 2-11-2011 1:48, Pat Thoyts schreef:
> On 1 November 2011 22:32, Vincent van Ravesteijn<vfr@lyx.org> wrote:
>>> Maybe if someone donates Jenkins resources, we could make an automatic
>>> branch in the future that has git.sln in it (similar to the 'html' branch
>>> in git.git).
>>>
>> As long as this means to just run a not so complicated perl script, this
>> Could even be done in a commit hook.
>>
>> Just another question. How does the (msys)git community feel about adding
>> CMake support ? I can probably do that quite easily.
>>
>> Vincent
>>
> -1. We have a make. We don't need two of them.
Make won't offer anything if you want to support MSVC. So, if you want
to support MSVC, there has to be some sort of alternative.
Vincent
^ permalink raw reply
* Antw: Re: Q: "git diff" using tag names
From: Ulrich Windl @ 2011-11-02 7:31 UTC (permalink / raw)
To: Alexey Shumkin; +Cc: git
In-Reply-To: <20111028165943.2cc8253d@ashu.dyn.rarus.ru>
Hello Alexey,
thank you very much for your reply. I felt I did something wrong, but couldn't find out what it was. Actually it turned out that I had just mistyped one tag name.
Also it seems that both syntaxes work:
git diff v0.4..v0.5
git diff v0.4 v0.5
The question is: How does git disambiguate between tag names, commits and file names? (All may start with a letter)
This seems to work automagically, and I was desparately looking for an option like "--" to separate revisions from file names. I found "SPECIFYING REVISIONS" in git-rev-parse(1), so you don't really have to answer.
Regards,
Ulrich
>>> Alexey Shumkin <Alex.Crezoff@gmail.com> schrieb am 28.10.2011 um 14:59 in
Nachricht <20111028165943.2cc8253d@ashu.dyn.rarus.ru>:
> Tag is a pointer to a commit (if to say simply)
>
> e.g. in my repo
> $ git show-ref --tags --abbrev=7
> -->8--
> 676f194 refs/tags/v2.6.7
> b23c481 refs/tags/v2.6.8
> -->8--
>
> so
>
> $ git diff v2.6.7..v2.6.8
> is equivalent to
> $ git diff 676f194..b23c481
>
> etc
> > Hi,
> >
> > when using a somewhat older git (of SLES11 SP1 SDK), I could not find
> > a way to "git diff" between two tag names; I can only diff between
> > two commit numbers. I can display a changeset using "git show", but
> > that's not what I wanted. Is it possible to get the diff I want using
> > older versions, and is such a feature implemented in the current
> > version? If so, since when?
> >
> > As I'm not subscribed to the list, I'd appreciate CC'ed replies.
> > Thank you.
> >
> > Greeting
> > Ulrich
> >
> >
>
>
^ permalink raw reply
* Re: Git is exploding
From: Miles Bader @ 2011-11-02 4:51 UTC (permalink / raw)
To: Matthieu Moy; +Cc: Øyvind A. Holm, git
In-Reply-To: <vpqfwi8tary.fsf@bauges.imag.fr>
Matthieu Moy <Matthieu.Moy@grenoble-inp.fr> writes:
> The recent rise is essentially due to the git-core package renamed to
> git, and people doing updates:
The renaming would obviously explain the extreme initial steepness of
the rise, but it shouldn't have much effect on the absolute values or
the more recent numbers.
[Look at git-core+git, basically it makes the initial part of the
graph fill in a bit, getting rid of the weird kink and making it more
smoothly exponential but doesn't really change the conclusion.]
Probably the main distortion is just the fact that it counts Debian
users ... subversion has a lot of stodgy corporate users etc that are
unlikely to use Debian! :]
--Miles
--
Twice, adv. Once too often.
^ permalink raw reply
* [ANNOUNCE] Git 1.7.7.2
From: Junio C Hamano @ 2011-11-02 1:23 UTC (permalink / raw)
To: git; +Cc: Linux Kernel
The latest maintenance release Git 1.7.7.2 is available.
The release tarballs are found at:
http://code.google.com/p/git-core/downloads/list
and their SHA-1 checksums are:
be5be63fbab63517fcccf5c876749c61b0019d14 git-1.7.7.2.tar.gz
8f0eb6f1150ea8c6922343aa4c3ee6cf37e8a091 git-htmldocs-1.7.7.2.tar.gz
07e0887315224ac83c61ed60602c345c32a5d658 git-manpages-1.7.7.2.tar.gz
Also the following public repositories all have a copy of the v1.7.7.2
tag and the maint branch that the tag points at:
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.7.7.2 Release Notes
==========================
Fixes since v1.7.7.1
--------------------
* We used to drop error messages from libcurl on certain kinds of
errors.
* Error report from smart HTTP transport, when the connection was
broken in the middle of a transfer, showed a useless message on
a corrupt packet.
* "git fetch --prune" was unsafe when used with refspecs from the
command line.
* The attribute mechanism did not use case insensitive match when
core.ignorecase was set.
* "git bisect" did not notice when it failed to update the working tree
to the next commit to be tested.
* "git config --bool --get-regexp" failed to separate the variable name
and its value "true" when the variable is defined without "= true".
* "git remote rename $a $b" were not careful to match the remote name
against $a (i.e. source side of the remote nickname).
* "git mergetool" did not use its arguments as pathspec, but as a path to
the file that may not even have any conflict.
* "git diff --[num]stat" used to use the number of lines of context
different from the default, potentially giving different results from
"git diff | diffstat" and confusing the users.
* "git pull" and "git rebase" did not work well even when GIT_WORK_TREE is
set correctly with GIT_DIR if the current directory is outside the working
tree.
* "git send-email" did not honor the configured hostname when restarting
the HELO/EHLO exchange after switching TLS on.
* "gitweb" used to produce a non-working link while showing the contents
of a blob, when JavaScript actions are enabled.
----------------------------------------------------------------
Changes since v1.7.7.1 are as follows:
Brandon Casey (4):
attr.c: avoid inappropriate access to strbuf "buf" member
cleanup: use internal memory allocation wrapper functions everywhere
builtin/mv.c: plug miniscule memory leak
attr.c: respect core.ignorecase when matching attribute patterns
Carlos Martín Nieto (6):
Remove 'working copy' from the documentation and C code
fetch: free all the additional refspecs
t5510: add tests for fetch --prune
remote: separate out the remote_find_tracking logic into query_refspecs
fetch: honor the user-provided refspecs when pruning refs
fetch: treat --tags like refs/tags/*:refs/tags/* when pruning
Christian Couder (1):
bisect: fix exiting when checkout failed in bisect_start()
Haitao Li (1):
date.c: Support iso8601 timezone formats
Jakub Narebski (1):
gitweb: Strip non-printable characters from syntax highlighter output
Jeff King (8):
add sha1_array API docs
quote.h: fix bogus comment
refactor argv_array into generic code
quote: provide sq_dequote_to_argv_array
bisect: use argv_array API
checkout: use argv_array API
run_hook: use argv_array API
pull,rebase: handle GIT_WORK_TREE better
Jim Meyering (1):
make the sample pre-commit hook script reject names with newlines, too
Jonathan Nieder (2):
http: remove extra newline in error message
http: avoid empty error messages for some curl errors
Jonathon Mah (1):
mergetool: Use args as pathspec to unmerged files
Junio C Hamano (5):
refactor run_receive_hook()
diff: teach --stat/--numstat to honor -U$num
mergetool: no longer need to save standard input
attr: read core.attributesfile from git_default_core_config
Git 1.7.7.2
Martin von Zweigbergk (4):
remote: write correct fetch spec when renaming remote 'remote'
remote: "rename o foo" should not rename ref "origin/bar"
remote rename: warn when refspec was not updated
remote: only update remote-tracking branch if updating refspec
Matthew Daley (1):
send-email: Honour SMTP domain when using TLS
Michael Haggerty (1):
notes_merge_commit(): do not pass temporary buffer to other function
Michael J Gruber (3):
unpack-trees: print "Aborting" to stderr
git-read-tree.txt: language and typography fixes
git-read-tree.txt: correct sparse-checkout and skip-worktree description
Nguyễn Thái Ngọc Duy (2):
git-read-tree.txt: update sparse checkout examples
Reindent closing bracket using tab instead of spaces
Pat Thoyts (1):
t7511: avoid use of reserved filename on Windows.
Peter Stuge (1):
gitweb: Fix links to lines in blobs when javascript-actions are enabled
Ramsay Allan Jones (1):
t9159-*.sh: skip for mergeinfo test for svn <= 1.4
René Scharfe (1):
read-cache.c: fix index memory allocation
Richard Hartmann (1):
clone: Quote user supplied path in a single quote pair
Shawn O. Pearce (1):
remote-curl: Fix warning after HTTP failure
Stefan Naewe (1):
Documentation/git-update-index: refer to 'ls-files'
Thomas Rast (1):
Documentation: basic configuration of notes.rewriteRef
^ permalink raw reply
* Re: [msysGit] Re: [PATCHv2] Compile fix for MSVC
From: Pat Thoyts @ 2011-11-02 0:48 UTC (permalink / raw)
To: Vincent van Ravesteijn
Cc: Johannes Schindelin, ramsay, msysgit, Karsten Blees, git,
Junio C Hamano, Erik Faye-Lund
In-Reply-To: <CAAH6HY8WfOQQ4g54y7mriq6BKoJCWYsVPrQUTMndqpKdniLAtw@mail.gmail.com>
On 1 November 2011 22:32, Vincent van Ravesteijn <vfr@lyx.org> wrote:
>
>> Maybe if someone donates Jenkins resources, we could make an automatic
>> branch in the future that has git.sln in it (similar to the 'html' branch
>> in git.git).
>>
>
> As long as this means to just run a not so complicated perl script, this
> Could even be done in a commit hook.
>
> Just another question. How does the (msys)git community feel about adding
> CMake support ? I can probably do that quite easily.
>
> Vincent
>
-1. We have a make. We don't need two of them.
^ permalink raw reply
* Re: Re: [PATCHv2] Compile fix for MSVC
From: Vincent van Ravesteijn @ 2011-11-01 23:33 UTC (permalink / raw)
To: Johannes Schindelin
Cc: ramsay, msysgit, Karsten Blees, git, Junio C Hamano,
Erik Faye-Lund
In-Reply-To: <alpine.DEB.1.00.1111011738550.32316@s15462909.onlinehome-server.info>
[-- Attachment #1: Type: text/plain, Size: 1342 bytes --]
>
>
> > > Maybe if someone donates Jenkins resources, we could make an automatic
> > > branch in the future that has git.sln in it (similar to the 'html'
> > > branch in git.git).
> >
> > As long as this means to just run a not so complicated perl script, this
> > Could even be done in a commit hook.
>
> I actually was thinking about something automatic which does not require
> any of the busy msysGit developers to do something manual every once in a
> while.
I thought that a commit hook, was something automatic (iff the busy
developers
do commit something once in a while). I guess I can even set this up very
easily
(given push rights, otherwise it will involve manual labor again).
> > Just another question. How does the (msys)git community feel about
> > adding CMake support ? I can probably do that quite easily.
>
> There was somebody who strongly favored CMake over any other solution but
> was not willing to maintain it in the long run (also, I have to admit that
> I have had quite a few problems with CMake, but maybe I am just pampered
> by projects that Just Compile...)
>
The current way of generating a MSVC project is rather outdated, so the
worst
thing that can happen is that you have a different build system which is not
maintained. At least the CMake people will continue to improve on their
side.
Vincent
[-- Attachment #2: Type: text/html, Size: 2011 bytes --]
^ permalink raw reply
* Re: t5800-*.sh: Intermittent test failures
From: Alex Riesen @ 2011-11-01 23:02 UTC (permalink / raw)
To: Junio C Hamano
Cc: Ramsay Jones, Jeff King, Sverre Rabbelier, GIT Mailing-list,
Jonathan Nieder
In-Reply-To: <7vfwi7lc54.fsf@alter.siamese.dyndns.org>
On Tue, Nov 1, 2011 at 23:18, Junio C Hamano <gitster@pobox.com> wrote:
> Alex Riesen <raa.lkml@gmail.com> writes:
>
>> On Sun, Sep 11, 2011 at 21:14, Ramsay Jones <ramsay@ramsay1.demon.co.uk> wrote:
>>> ... these hangs *are* the failures of which I speak! Yes, the script
>>> doesn't get to declare a failure, but AFAIAC a hanging test (and it
>>> isn't the same test # each time) is a failing test. :-D
>>
>> Was there any outcome of this discussion? I'm asking because I
>> can reproduce this very reliably on a little server here.
>
> I do remember this discussion and recall seeing _no_ outcome.
>
> I did see the hang myself once or twice but did not and do not have a
> reliable reproduction. I have been waiting for somebody to raise the issue
> again ;-).
>
I think I managed to bisect it (between 1.7.6 and 1.7.7):
$ git bisect start v1.7.7 v1.7.6
...
$ git bisect good
a515ebe9f1ac9bc248c12a291dc008570de505ca is the first bad commit
commit a515ebe9f1ac9bc248c12a291dc008570de505ca
Author: Sverre Rabbelier <srabbelier@gmail.com>
Date: Sat Jul 16 15:03:40 2011 +0200
transport-helper: implement marks location as capability
Now that the gitdir location is exported as an environment variable
this can be implemented elegantly without requiring any explicit
flushes nor an ad-hoc exchange of values.
Signed-off-by: Sverre Rabbelier <srabbelier@gmail.com>
Acked-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
:100644 100644 1ed7a5651ef5a2320c56856b5a1fe784e178ab23
e9c832bfd3da7db771cc2113027d3e590dc51d59 M git-remote-testgit.py
:100644 100644 0cfc9ae9059ce121b567406d7941b71cd54b961c
74c3122df1835c45a6b621205fb18b4fc89af366 M transport-helper.c
Sadly, I'm going to be able to repeat the test in about 20 hours.
^ permalink raw reply
* Re: [msysGit] Re: [PATCHv2] Compile fix for MSVC
From: Johannes Schindelin @ 2011-11-01 22:51 UTC (permalink / raw)
To: Erik Faye-Lund
Cc: Junio C Hamano, Vincent van Ravesteijn, git, ramsay, msysgit,
Karsten Blees
In-Reply-To: <CABPQNSb07fRUCqPCX7JbfGW_55etZZtPyP=yuCKV9wJeNP-iQw@mail.gmail.com>
Hi kusma,
On Tue, 1 Nov 2011, Erik Faye-Lund wrote:
> On Tue, Nov 1, 2011 at 7:40 PM, Johannes Schindelin
> <Johannes.Schindelin@gmx.de> wrote:
>
> > Maybe if someone donates Jenkins resources, we could make an automatic
> > branch in the future that has git.sln in it (similar to the 'html'
> > branch in git.git).
>
> CloudBees seems to have some kind of a free Jenkins service. Perhaps
> it's sufficient? http://www.cloudbees.com/dev-pricing.cb
Looks quite cool, but keep in mind: they only have Linux build machines.
We'd need to pimp up our cross-platform compiling capabilities; WINE will
most likely not be good enough (we'd only have 2000 minutes per month).
Ciao,
Dscho
^ permalink raw reply
* Re: [msysGit] Re: [PATCHv2] Compile fix for MSVC
From: Johannes Schindelin @ 2011-11-01 22:40 UTC (permalink / raw)
To: Vincent van Ravesteijn
Cc: ramsay, msysgit, Karsten Blees, git, Junio C Hamano,
Erik Faye-Lund
In-Reply-To: <CAAH6HY8WfOQQ4g54y7mriq6BKoJCWYsVPrQUTMndqpKdniLAtw@mail.gmail.com>
Hi,
On Tue, 1 Nov 2011, Vincent van Ravesteijn wrote:
> > Maybe if someone donates Jenkins resources, we could make an automatic
> > branch in the future that has git.sln in it (similar to the 'html'
> > branch in git.git).
>
> As long as this means to just run a not so complicated perl script, this
> Could even be done in a commit hook.
I actually was thinking about something automatic which does not require
any of the busy msysGit developers to do something manual every once in a
while.
> Just another question. How does the (msys)git community feel about
> adding CMake support ? I can probably do that quite easily.
There was somebody who strongly favored CMake over any other solution but
was not willing to maintain it in the long run (also, I have to admit that
I have had quite a few problems with CMake, but maybe I am just pampered
by projects that Just Compile...)
Ciao,
Johannes
^ permalink raw reply
* Re: [PATCH] name-hash.c: always initialize dir_next pointer
From: Jeff King @ 2011-11-01 22:39 UTC (permalink / raw)
To: Johannes Sixt; +Cc: git, Junio C Hamano
In-Reply-To: <4EB070D2.4040709@kdbg.org>
On Tue, Nov 01, 2011 at 11:21:06PM +0100, Johannes Sixt wrote:
> Test t2021-checkout-overwrite.sh reveals a segfault in 'git add' on a
> case-insensitive file system when git is compiled with XMALLOC_POISON
> defined. The reason is that 2548183b (fix phantom untracked files when
> core.ignorecase is set) added a new member dir_next to struct cache_entry,
> but forgot to initialize it in all cases.
>
> Signed-off-by: Johannes Sixt <j6t@kdbg.org>
> ---
> You can also insert git config core.ignorecase true before the first
> test script in t2021 to see the segfault.
Yikes, thanks.
-Peff
^ permalink raw reply
* Re: [git patches] libata updates, GPG signed (but see admin notes)
From: Ted Ts'o @ 2011-11-01 22:39 UTC (permalink / raw)
To: Linus Torvalds
Cc: Junio C Hamano, git, James Bottomley, Jeff Garzik, Andrew Morton,
linux-ide, LKML
In-Reply-To: <CA+55aFx_rAA6TJkZn1Zvu6u9UjxnmTVt0HpMnvaE_q9Sx-jzPg@mail.gmail.com>
On Tue, Nov 01, 2011 at 02:21:59PM -0700, Linus Torvalds wrote:
> So I'm wondering if we want to save it at all. it's quite possible
> that realistically speaking "google the mailing list archives" is the
> *right* way to look up the signature if it is ever needed later.
Given the number of trees that you merge in every merge window (never
mind over an entire release), I don't think "google the mailing list
archives" is going to scale. Finding some way to keep it along with
the merge window seems the right thing. I agree that it should hidden
normally, but that's a UI display issue. Heck, we could just hide
after the terminating NULL in the commit description, per a discussion
on the git list 2-3 weeks ago. :-)
> Because in many ways, "git request-pull" is when you do want to sign
> stuff. A developer might well want to push out his stuff for some
> random internal testing (linux-next, for example), and then only later
> decide "Ok, it was all good, now I want to make it 'official' and ask
> Linus to pull it", and sign it at *that* time, rather than when
> actually pushing it out.
Sure, the signed content should be buried in the commit that it
describes. Whether we carry it in an emphemeral tag or in the git
request-pull is not really important from a security perspective. The
tag is nicer simply because the person doing the pull won't need to
cut and paste the signature information.
One approach which might work is if git request-pull sends the e-mail
message with the git shortlog and diffstat, *and* an MIME attachment
that contained all of the necessary information. The maintainer would
then save the attachment, and feed it to git, which will display the
git shortlog and diffstat, ask for confirmation, and then embed the
digital signature into the merge commit.
The only problem with that is (a) you'd have to get over your hatred
of attachment (but if you're using Gmail hopefully that's relative
convenient :-), and (b) LKML list filter would have to be taught to
tolerate git-generated attachments.
- Ted
^ permalink raw reply
* Re: Re: [PATCHv2] Compile fix for MSVC
From: Vincent van Ravesteijn @ 2011-11-01 22:32 UTC (permalink / raw)
To: Johannes Schindelin
Cc: ramsay, msysgit, Karsten Blees, git, Junio C Hamano,
Erik Faye-Lund
In-Reply-To: <alpine.DEB.1.00.1111011332400.32316@s15462909.onlinehome-server.info>
[-- Attachment #1: Type: text/plain, Size: 414 bytes --]
> Maybe if someone donates Jenkins resources, we could make an automatic
> branch in the future that has git.sln in it (similar to the 'html' branch
> in git.git).
>
As long as this means to just run a not so complicated perl script, this
Could even be done in a commit hook.
Just another question. How does the (msys)git community feel about adding
CMake support ? I can probably do that quite easily.
Vincent
[-- Attachment #2: Type: text/html, Size: 481 bytes --]
^ permalink raw reply
* Re: [PATCH] name-hash.c: always initialize dir_next pointer
From: Junio C Hamano @ 2011-11-01 22:31 UTC (permalink / raw)
To: Johannes Sixt; +Cc: Jeff King, git
In-Reply-To: <4EB070D2.4040709@kdbg.org>
Thanks.
^ permalink raw reply
* [PATCH] name-hash.c: always initialize dir_next pointer
From: Johannes Sixt @ 2011-11-01 22:21 UTC (permalink / raw)
To: Jeff King; +Cc: git, Junio C Hamano
Test t2021-checkout-overwrite.sh reveals a segfault in 'git add' on a
case-insensitive file system when git is compiled with XMALLOC_POISON
defined. The reason is that 2548183b (fix phantom untracked files when
core.ignorecase is set) added a new member dir_next to struct cache_entry,
but forgot to initialize it in all cases.
Signed-off-by: Johannes Sixt <j6t@kdbg.org>
---
You can also insert git config core.ignorecase true before the first
test script in t2021 to see the segfault.
I actually found the crash with an MSVC debug build, which has something
like XMALLOC_POISON built-in.
name-hash.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/name-hash.c b/name-hash.c
index 225dd76..d8d25c2 100644
--- a/name-hash.c
+++ b/name-hash.c
@@ -74,7 +74,7 @@ static void hash_index_entry(struct index_state *istate, struct cache_entry *ce)
if (ce->ce_flags & CE_HASHED)
return;
ce->ce_flags |= CE_HASHED;
- ce->next = NULL;
+ ce->next = ce->dir_next = NULL;
hash = hash_name(ce->name, ce_namelen(ce));
pos = insert_hash(hash, ce, &istate->name_hash);
if (pos) {
--
1.7.7.1.586.ga0958b
^ permalink raw reply related
* Re: t5800-*.sh: Intermittent test failures
From: Junio C Hamano @ 2011-11-01 22:18 UTC (permalink / raw)
To: Alex Riesen
Cc: Ramsay Jones, Jeff King, Sverre Rabbelier, GIT Mailing-list,
Jonathan Nieder
In-Reply-To: <CALxABCbnZp-y0Fqzoa=Ab92P+hsT7hs3nXZsnA=ph3yGfkXhdA@mail.gmail.com>
Alex Riesen <raa.lkml@gmail.com> writes:
> On Sun, Sep 11, 2011 at 21:14, Ramsay Jones <ramsay@ramsay1.demon.co.uk> wrote:
>> ... these hangs *are* the failures of which I speak! Yes, the script
>> doesn't get to declare a failure, but AFAIAC a hanging test (and it
>> isn't the same test # each time) is a failing test. :-D
>
> Was there any outcome of this discussion? I'm asking because I
> can reproduce this very reliably on a little server here.
I do remember this discussion and recall seeing _no_ outcome.
I did see the hang myself once or twice but did not and do not have a
reliable reproduction. I have been waiting for somebody to raise the issue
again ;-).
^ permalink raw reply
* Re: t5800-*.sh: Intermittent test failures
From: Alex Riesen @ 2011-11-01 21:57 UTC (permalink / raw)
To: Ramsay Jones
Cc: Jeff King, Junio C Hamano, Sverre Rabbelier, GIT Mailing-list,
Jonathan Nieder
In-Reply-To: <4E6D089C.4090006@ramsay1.demon.co.uk>
On Sun, Sep 11, 2011 at 21:14, Ramsay Jones <ramsay@ramsay1.demon.co.uk> wrote:
> ... these hangs *are* the failures of which I speak! Yes, the script
> doesn't get to declare a failure, but AFAIAC a hanging test (and it
> isn't the same test # each time) is a failing test. :-D
Was there any outcome of this discussion? I'm asking because I
can reproduce this very reliably on a little server here.
^ permalink raw reply
* Re: [git patches] libata updates, GPG signed (but see admin notes)
From: Junio C Hamano @ 2011-11-01 21:56 UTC (permalink / raw)
To: Linus Torvalds
Cc: git, James Bottomley, Jeff Garzik, Andrew Morton, linux-ide, LKML
In-Reply-To: <CA+55aFx_rAA6TJkZn1Zvu6u9UjxnmTVt0HpMnvaE_q9Sx-jzPg@mail.gmail.com>
Linus Torvalds <torvalds@linux-foundation.org> writes:
> Having thought about it, I'm also not convinced I really want to
> pollute the "git log" output with information that realistically
> almost nobody cares about. The primary use is just for the person who
> pulls things to verify it, after that the information is largely stale
> and almost certain to never be interesting to anybody ever again. It's
> *theoretically* useful if somebody wants to go back and re-verify, but
> at the same time that really isn't expected to be the common case.
> ...
> So I'm wondering if we want to save it at all. it's quite possible
> that realistically speaking "google the mailing list archives" is the
> *right* way to look up the signature if it is ever needed later.
I'd rather want to hear opinions from people who base their work on public
kernels (e.g. distros, and companies who roll their own prod kernels), on
that.
But my gut feeling is that "usually hidden not to disturb normal users,
but is cast in stone in the history and cannot be lost" strikes the right
balance. Both your "next merge commit records the signature together with
the largely useless merge summary cruft but everybody learned to ignore it
with 'log --no-merges' anyway so it does not hurt to have it there" and
the commit signature topic from the next branch [*1*] that puts the
signature in the object header and teaches '--show-signature' option to
the log family to show it share this property.
> Maybe just verifying the email message (with the suggested kind of
> change to "git request-pull") is actually the right approach. And what
> I should do is to just wrap my "git pull" in some script that I can
> just cut-and-paste the gpg-signed thing into, and which just does the
> "gpg --verify" on it, and then does the "git pull" after that.
>
> Because in many ways, "git request-pull" is when you do want to sign
> stuff. A developer might well want to push out his stuff for some
> random internal testing (linux-next, for example), and then only later
> decide "Ok, it was all good, now I want to make it 'official' and ask
> Linus to pull it", and sign it at *that* time, rather than when
> actually pushing it out.
>
> And I suspect signing the pull request fits better into peoples
> existing workflow anyway - sending out the email to ask the maintainer
> to pull really is the "special event", rather than pushing out the
> code itself.
"I can silently push and re-push or even rewind-and-then-push until I
officially send pull-request out" fits well with the "defer the decision
as much as possible" model Git takes in general, and I find certain
attractiveness in it.
But on the other hand, in many ways, publishing your commit to the outside
world, not necessarily for getting pulled into the final destination
(i.e. your tree) but merely for other people to try it out, is the point
of no return (aka "don't rewind or rebase once you publish"). "pushing
out" might be less special than "please pull", but it still is special.
Also there is nothing lost if you sign commits whenever you push them
out.
[Footnote]
*1* Here are three examples on the same commit that is signed for
illustration.
------------------------------------------------
$ git show -s pu
commit c9d870fceac787fdb1c1c43b136c1a94ab2ab005
Merge: 8367c51 71f45ee
Author: Junio C Hamano <gitster@pobox.com>
Date: Mon Oct 31 20:06:58 2011 -0700
Merge branch 'jc/stream-to-pack' into pu
* jc/stream-to-pack:
Bulk check-in
finish_tmp_packfile(): a helper function
create_tmp_packfile(): a helper function
write_pack_header(): a helper function
------------------------------------------------
$ git show -s --show-signature pu
commit c9d870fceac787fdb1c1c43b136c1a94ab2ab005
gpg: Signature made Mon 31 Oct 2011 08:07:04 PM PDT using RSA key ID 96AFE6CB
gpg: Good signature from "Junio C Hamano <gitster@pobox.com>"
gpg: aka "Junio C Hamano <junio@pobox.com>"
gpg: aka "Junio C Hamano <jch@google.com>"
Merge: 8367c51 71f45ee
Author: Junio C Hamano <gitster@pobox.com>
Date: Mon Oct 31 20:06:58 2011 -0700
Merge branch 'jc/stream-to-pack' into pu
* jc/stream-to-pack:
Bulk check-in
finish_tmp_packfile(): a helper function
create_tmp_packfile(): a helper function
write_pack_header(): a helper function
------------------------------------------------
$ git cat-file commit pu
tree 9add290d468800c3c51ff68fedfb3d16427872ff
parent 8367c51becc5a225b9a192348b7d7c615fb6d250
parent 71f45eeb8278670257bea83620f7d3eac174eee7
author Junio C Hamano <gitster@pobox.com> 1320116818 -0700
committer Junio C Hamano <gitster@pobox.com> 1320116824 -0700
gpgsig -----BEGIN PGP SIGNATURE-----
gpgsig Version: GnuPG v1.4.10 (GNU/Linux)
gpgsig
gpgsig ...
gpgsig =c62U
gpgsig -----END PGP SIGNATURE-----
Merge branch 'jc/stream-to-pack' into pu
* jc/stream-to-pack:
Bulk check-in
finish_tmp_packfile(): a helper function
create_tmp_packfile(): a helper function
write_pack_header(): a helper function
------------------------------------------------
^ permalink raw reply
* Re: [ANNOUNCE] Git 1.7.8.rc0
From: Stefan Naewe @ 2011-11-01 21:53 UTC (permalink / raw)
To: git
In-Reply-To: <loom.20111101T205618-231@post.gmane.org>
Stefan Naewe <stefan.naewe <at> gmail.com> writes:
> I'll recheck everything at work, where I live behind a very restrictive
> firewall (Don't know if that makes any difference).
s/firewall/proxy/
Stefan
^ permalink raw reply
* [PATCH v3] Display change history as a diff between two dirs
From: Roland Kaufmann @ 2011-11-01 21:37 UTC (permalink / raw)
To: gitster; +Cc: git
Watching patches serially it can be difficult to get an overview of how
a pervasive change is distributed through-out different modules. Thus;
Extract snapshots of the files that have changed between two revisions
into temporary directories and launch a graphical tool to show the diff
between them.
Use existing functionality in git-diff to get the files themselves, and
git-difftool to launch the diff viewer.
Based on a script called 'git-diffc' by Nitin Gupta.
Signed-off-by: Roland Kaufmann <rlndkfmn+git@gmail.com>
---
Issues addressed in this revision are:
* Diff-viewer is searched for in order: env. var. GIT_EXTERNAL_TREEDIFF,
env. var. GIT_EXTERNAL_DIFF, conf. of git-difftool.
If dir. comp. is found useful, there should probably be some config
var. to control it too, but I think that will require some refactoring
of git-mergetool--lib.
* Only platforms where mktemp is known to exist (and have sane options)
are explicitly tested for; the default is to fallback to a Perl module
implementation which is heavier, but has a greater chance of working
I reckon (git-send-email uses this module).
* Less convoluted testing of empty directory.
contrib/dirdiff/README | 10 ++++
contrib/dirdiff/git-dirdiff--helper.sh | 37 ++++++++++++++++
contrib/dirdiff/git-dirdiff.sh | 72 ++++++++++++++++++++++++++++++++
contrib/dirdiff/git-dirdiff.txt | 71 +++++++++++++++++++++++++++++++
4 files changed, 190 insertions(+), 0 deletions(-)
create mode 100644 contrib/dirdiff/README
create mode 100755 contrib/dirdiff/git-dirdiff--helper.sh
create mode 100755 contrib/dirdiff/git-dirdiff.sh
create mode 100644 contrib/dirdiff/git-dirdiff.txt
diff --git a/contrib/dirdiff/README b/contrib/dirdiff/README
new file mode 100644
index 0000000..d06461a
--- /dev/null
+++ b/contrib/dirdiff/README
@@ -0,0 +1,10 @@
+# install on GNU, BSD:
+for f in "" "--helper"; do
+ b=git-dirdiff$f
+ sudo install -m 0755 contrib/dirdiff/$b.sh $(git --exec-path)/$b
+done
+
+# install on Windows
+for /f %a in ('git --exec-path') do set GIT_PATH=%a
+set GIT_PATH=%GIT_PATH:/=\%
+for %a in ("" "--helper") do copy contrib\dirdiff\git-dirdiff%~a.sh "%GIT_PATH%\%~a" /y
diff --git a/contrib/dirdiff/git-dirdiff--helper.sh b/contrib/dirdiff/git-dirdiff--helper.sh
new file mode 100755
index 0000000..8ff0124
--- /dev/null
+++ b/contrib/dirdiff/git-dirdiff--helper.sh
@@ -0,0 +1,37 @@
+#!/bin/sh
+#
+# Accumulate files in a changeset into a pre-defined directory.
+#
+# Copyright (C) 2011 Roland Kaufmann
+#
+# Based on a script called git-diffc by Nitin Gupta and valuable
+# suggestions by Junio C. Hamano.
+#
+# This file is licensed under the GPL v2, or a later version
+# at the discretion of the official Git maintainer.
+
+. git-sh-setup
+
+# check that we are called by git-dirdiff
+test -z "$__GIT_DIFF_DIR" &&
+ die Error: Do not call $(basename "$0") directly
+
+# what is the directory name of the file that has changed
+RELDIR=$(dirname "$1") ||
+ exit $?
+
+# don't attempt to copy new or removed files
+if test "$2" != "/dev/null"
+then
+ mkdir -p "$__GIT_DIFF_DIR/old/$RELDIR" ||
+ exit $?
+ cp "$2" "$__GIT_DIFF_DIR/old/$1" ||
+ exit $?
+fi
+if test "$5" != "/dev/null"
+then
+ mkdir -p "$__GIT_DIFF_DIR/new/$RELDIR" ||
+ exit $?
+ cp "$5" "$__GIT_DIFF_DIR/new/$1" ||
+ exit $?
+fi
diff --git a/contrib/dirdiff/git-dirdiff.sh b/contrib/dirdiff/git-dirdiff.sh
new file mode 100755
index 0000000..c5834ae
--- /dev/null
+++ b/contrib/dirdiff/git-dirdiff.sh
@@ -0,0 +1,72 @@
+#!/bin/sh
+#
+# Display differences between two commits with a directory comparison.
+#
+# Copyright (C) 2011 Roland Kaufmann
+#
+# Based on a script called git-diffc by Nitin Gupta and valuable
+# suggestions by Junio C. Hamano.
+#
+# This file is licensed under the GPL v2, or a later version
+# at the discretion of the official Git maintainer.
+
+. git-sh-setup
+
+# TMPDIR points to the designated space for temporary files; only if
+# not set use /tmp (MSYS even mounts %TEMP% to there)
+test -z "$TMPDIR" && TMPDIR=/tmp
+
+# create a temporary directory to hold snapshots of changed files
+# fallback on crippled platforms is to use a Perl module
+case $(uname -s) in
+Linux | *BSD | Darwin | windows* | CYGWIN_NT*)
+ __GIT_DIFF_DIR=$(mktemp -d "$TMPDIR/git-dirdiff.XXXXXX")
+ ;;
+*)
+ __GIT_DIFF_DIR=$(perl -e "use File::Temp qw/tempdir/; print tempdir(\"git-dirdiff.XXXXXX\", DIR=>\"$TMPDIR\")")
+ ;;
+esac
+test -d "$__GIT_DIFF_DIR" -a -w "$__GIT_DIFF_DIR" ||
+ die Error: Could not create a temporary subdir in $TMPDIR
+
+# cleanup after we're done
+trap 'rm -rf $__GIT_DIFF_DIR' 0
+
+# export this variable so that scripts called indirectly can access it
+export __GIT_DIFF_DIR
+
+# let the helper script accumulate all changed files into the temporary
+# directory letting 'git diff' do all the heavy lifting
+GIT_EXTERNAL_DIFF=git-dirdiff--helper git --no-pager diff "$@" ||
+ exit $?
+
+# first and second argument will always be the special directory links
+# if there are no hidden files nor regular files, then $3 will be the
+# second wildcard unexpanded
+isempty () {
+ set - $1/.* $1/*
+ test ! -f "$3"
+}
+
+# no-op if no files were changed
+isempty "$__GIT_DIFF_DIR/old" && isempty "$__GIT_DIFF_DIR/new" &&
+ exit 0
+
+# if a different tool is setup for tree comparison, launch that instead
+# if GIT_EXTERNAL_TREEDIFF is not set, then use GIT_EXTERNAL_DIFF
+if test -n "$GIT_EXTERNAL_DIFF"
+then
+ GIT_DIFFTOOL_EXTCMD=$GIT_EXTERNAL_DIFF
+ export GIT_DIFFTOOL_EXTCMD
+fi
+if test -n "$GIT_EXTERNAL_TREEDIFF"
+then
+ GIT_DIFFTOOL_EXTCMD=$GIT_EXTERNAL_TREEDIFF
+ export GIT_DIFFTOOL_EXTCMD
+fi
+
+# run original diff program, reckoning it will understand directories
+# modes and shas does not apply to the root directories so submit dummy
+# values for those, hoping that the diff tool does not use them.
+git-difftool--helper - "$__GIT_DIFF_DIR/old" deadbeef 0755 "$__GIT_DIFF_DIR/new" babeface 0755 ||
+ exit $?
diff --git a/contrib/dirdiff/git-dirdiff.txt b/contrib/dirdiff/git-dirdiff.txt
new file mode 100644
index 0000000..b80430a
--- /dev/null
+++ b/contrib/dirdiff/git-dirdiff.txt
@@ -0,0 +1,71 @@
+git-dirdiff(1)
+==============
+
+NAME
+----
+git-dirdiff - Show changes using directory compare
+
+SYNOPSIS
+--------
+[verse]
+'git dirdiff' [<options>] [<commit> [<commit>]] [--] [<path>...]
+
+DESCRIPTION
+-----------
+'git dirdiff' is a git command that allows you to compare revisions
+as a difference between two directories. 'git dirdiff' is a frontend
+to linkgit:git-diff[1].
+
+OPTIONS
+-------
+See linkgit:git-diff[1] for the list of supported options.
+
+ENVIRONMENT VARIABLES
+---------------------
+'GIT_EXTERNAL_TREEDIFF'::
+ When 'GIT_EXTERNAL_TREEDIFF' is set, the program named by it is
+ used as a diff viewer. The program must accept 7 parameters, where
+ parameter 2 is the path to a temporary directory containing the
+ "old" revision, and parameter 5 is the path of the "new" revision.
+ The other five parameters will only contain dummy values, and their
+ contents are subject to change.
+
+'GIT_EXTERNAL_DIFF'::
+ If and only if 'GIT_EXTERNAL_TREEDIFF' is not set, 'git dirdiff'
+ will use the contents of 'GIT_EXTERNAL_DIFF' as the name of the
+ diff viewer.
+
+CONFIG VARIABLES
+----------------
+If none of the above environment variables are set, 'git dirdiff' will
+use the same config variables as linkgit:git-difftool[1] to determine
+which difftool should be used.
+
+TEMPORARY FILES
+---------------
+'git dirdiff' creates a directory with 'mktemp' to hold snapshots of the
+files which are different in the two revisions. This directory is removed
+when the diff viewer terminates.
+
+NOTES
+-----
+The diff viewer must support being passed directories instead of files
+as its arguments.
++
+Files that are not put under version control are not included when
+viewing the difference between a revision and the working directory.
+
+SEE ALSO
+--------
+linkgit:git-diff[1]::
+ Show changes between commits, commit and working tree, etc
+
+linkgit:git-difftool[1]::
+ Show changes using common diff tools
+
+linkgit:git-config[1]::
+ Get and set repository or global options
+
+GIT
+---
+Part of the linkgit:git[1] suite
--
1.7.1
^ permalink raw reply related
* Re: [git patches] libata updates, GPG signed (but see admin notes)
From: Linus Torvalds @ 2011-11-01 21:21 UTC (permalink / raw)
To: Junio C Hamano
Cc: git, James Bottomley, Jeff Garzik, Andrew Morton, linux-ide, LKML
In-Reply-To: <7vwrbjlj5r.fsf@alter.siamese.dyndns.org>
On Tue, Nov 1, 2011 at 12:47 PM, Junio C Hamano <gitster@pobox.com> wrote:
>
> While I like the "an ephemeral tag is used only for hop-to-hop
> communication to carry information to be recorded in the resulting
> history" approach, I see a few downsides.
So I do agree.
I'd actually be *happier* with a generic multi-line "branch
description" thing that involves no git objects at all, just a nice
description of what the branch is.
The fact that you could also hide a signed version of the
top-of-branch there would be kind of a side effect, and wouldn't be a
requirement.
I hate how anonymous our branches are. Sure, we can use good names for
them, but it was a mistake to think we should describe the repository
(for gitweb), rather than the branch.
Ok, "hate" is a strong word. I don't "hate" it. I don't even think
it's a major design issue. But I do think that it would have been
nicer if we had had some branch description model.
The only reason I suggest a tag is really because it would fit with
existing tooling - especially the git transport protocol. So it's not
that I actually think that a tag is the right way to describe (and
sign) the branch, it's just that it's the way that wouldn't require
any changes other than in "git push -s" and "git pull".
> * To verify the commit C that was taken from the tip of lieutenant's tree
> some time ago, one has to find the merge commit that has C as a parent,
> and look at the merge commit. For example "git log --show-signature"
> would either show or not show the authenticity of C depending on where
> the traversal comes from. You certainly can implement it that way, but
> "some child describes an aspect of its parent, but not necessarily all
> children do so" feels philosophically less correct than "the commit has
> data to describe itself".
Yeah.
Having thought about it, I'm also not convinced I really want to
pollute the "git log" output with information that realistically
almost nobody cares about. The primary use is just for the person who
pulls things to verify it, after that the information is largely stale
and almost certain to never be interesting to anybody ever again. It's
*theoretically* useful if somebody wants to go back and re-verify, but
at the same time that really isn't expected to be the common case.
So I'm wondering if we want to save it at all. it's quite possible
that realistically speaking "google the mailing list archives" is the
*right* way to look up the signature if it is ever needed later.
Maybe just verifying the email message (with the suggested kind of
change to "git request-pull") is actually the right approach. And what
I should do is to just wrap my "git pull" in some script that I can
just cut-and-paste the gpg-signed thing into, and which just does the
"gpg --verify" on it, and then does the "git pull" after that.
Because in many ways, "git request-pull" is when you do want to sign
stuff. A developer might well want to push out his stuff for some
random internal testing (linux-next, for example), and then only later
decide "Ok, it was all good, now I want to make it 'official' and ask
Linus to pull it", and sign it at *that* time, rather than when
actually pushing it out.
And I suspect signing the pull request fits better into peoples
existing workflow anyway - sending out the email to ask the maintainer
to pull really is the "special event", rather than pushing out the
code itself.
Linus
^ permalink raw reply
* git sticker svg
From: Jeff King @ 2011-11-01 21:16 UTC (permalink / raw)
To: git
[-- Attachment #1: Type: text/plain, Size: 835 bytes --]
If you were at the GSoC mentor summit or the GitTogether last week, you
may seen Git stickers floating around. I printed 500, thinking there
would be some leftovers to distribute afterwards. But either git is very
popular, or somebody decided to re-wallpaper their bedroom, because we
ran out.
In case anybody wants to make their own git sticker (or whatever), I'm
providing the SVG that I sent to the printer. I ordered 2"x4" stickers,
but it's scalable, you should be able to do any size.
Credit where credit is due:
The logo is shamelessly stolen from one Sam Vilain made for GitTogether
t-shirts in 2008. It's really just the "---/+++" logo done in FreeMono
with a few pretty colors and outlines. I have no idea who did the
original "---/+++" logo. It's awesome, but I couldn't find a nice
scalable version, hence this.
-Peff
[-- Attachment #2: git-sticker.svg --]
[-- Type: image/svg+xml, Size: 4761 bytes --]
^ permalink raw reply
* Re: [msysGit] Re: [PATCHv2] Compile fix for MSVC
From: Junio C Hamano @ 2011-11-01 20:47 UTC (permalink / raw)
To: kusmabite
Cc: Junio C Hamano, Johannes Schindelin, Vincent van Ravesteijn, git,
ramsay, msysgit, Karsten Blees
In-Reply-To: <CABPQNSaiFpmHa_GLF8PaejvXTkqCMoWG+Cd4MbNrqXF-SXR1yw@mail.gmail.com>
Erik Faye-Lund <kusmabite@gmail.com> writes:
>> It seems, from your description, that msvc update series has some way to
>> go and it probably is better to be cooked by Windows-savvy folks for
>> another cycle.
>
> I don't think you need to hold these three patches; with them I was
> able to build your 'master'. I believe the problems I bumped into only
> exist in msysgit's 'devel' (or in your 'next', which msysgit/devel is
> based upon).
Ok, then. Thanks for clarifying.
^ permalink raw reply
* Re: [PATCH] git-svn: add hook to allow modifying the subversion commit message
From: Michael Lutz @ 2011-11-01 20:45 UTC (permalink / raw)
To: Eric Wong; +Cc: git
In-Reply-To: <20111101202806.GB29769@dcvr.yhbt.net>
Am 01.11.2011 21:28 schrieb Eric Wong:
> I'm not convinced this is a good feature to support. We already have
> --no-metadata to remove git-svn-id: lines and I hate that feature
> because it introduced extra variables for testing/debugging/recovery.
>
> Metadata in the commit message is important, if you want to remove
> it after-the-fact, there's git-filter-branch.
The actual use case here is to replace a custom hack that adds some info
to the git commit message. In this case filter-branch isn't an option
because git-svn continuously pulls from the subversion master repository.
Additionally, especially for *adding* information, the information might
not be available later any more.
The only current metadata (the git-svn-id line) isn't affected by this
change as git-svn outputs it separately after the svn commit message that
the proposed hook can modify.
I fully realize that this is a rather specialized feature but I wanted to
publish it in case somebody else finds a use for this as well.
Michael Lutz
^ permalink raw reply
* Re: Re: [PATCHv2] Compile fix for MSVC
From: Erik Faye-Lund @ 2011-11-01 20:43 UTC (permalink / raw)
To: Johannes Schindelin
Cc: Junio C Hamano, Vincent van Ravesteijn, git, ramsay, msysgit,
Karsten Blees
In-Reply-To: <alpine.DEB.1.00.1111011332400.32316@s15462909.onlinehome-server.info>
On Tue, Nov 1, 2011 at 7:40 PM, Johannes Schindelin
<Johannes.Schindelin@gmx.de> wrote:
> Hi kusma,
>
> On Tue, 1 Nov 2011, Erik Faye-Lund wrote:
>> I've applied the patches to 'devel', verified that the result builds,
>> and pushed it out.
>
> I've applied your patches and made up commit messages. So far, I only
> tested with MSVCE 9.0 (AKA Express 2008) before running out of time.
> Please have a look at the commits (since I could build a git.exe with the
> correct version, I felt comfortable enough to push out to 'devel').
The commits look good to me. Thanks for following up on it :)
> Maybe if someone donates Jenkins resources, we could make an automatic
> branch in the future that has git.sln in it (similar to the 'html' branch
> in git.git).
CloudBees seems to have some kind of a free Jenkins service. Perhaps
it's sufficient?
http://www.cloudbees.com/dev-pricing.cb
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox