headers
Øyvind A. Holm | 1 Mar 2012 01:11
Favicon
Gravatar

Re: What's cooking in git.git (Feb 2012, #09; Sun, 26)

On 27 February 2012 08:49, Junio C Hamano <gitster <at> pobox.com> wrote:
> * cb/fsck-squelch-dangling (2012-02-26) 1 commit
>  - fsck: do not print dangling objects by default
>
> Introduces "fsck --dangling" and removes the output for dangling objects
> from the default output.
>
> I personally do not think it is worth risking backward compatibility in
> the way this patch implements the squelching of the output.  An approach
> to add --no-dangling option without changing the default would be OK,
> though.

Agree. I use this functionality a lot, and this change would break a
script I use to restore dangling commits. There's probably some
(dirty) way around it, but I'd prefer if the backwards compatibility
is retained.

BTW, the script I use is located at
<https://github.com/sunny256/utils/blob/master/git-dangling> and I
find it quite useful. Do you think it could be a contrib/ candidate?

Cheers,
Øyvind
Permalink | Reply | 0 comments |
headers
Carsten Fuchs | 1 Mar 2012 01:35
Picon
Favicon
Gravatar

How to use subtrees when importing SVN repository with "vendor" branches?

Hi all,

using git-svn, I've been converting our old SVN repositories to git with great success, 
but I don't know how to deal with our biggest and most important one.
The SVN repository structure is like this:

	branches/
	tags/
	trunk/
		ExtLibs/
			libpng/
			zlib/
			...
		some_dir_a/
		some_dir_b/
	vendor/
		libpng/
		zlib/
		...

The key problem is that we used to use the SVN "vendor branches" strategy: When a new 
version of libpng or zlib or ... is released, we update the vendor/ directory 
appropriately (essentially: delete the old files of the library, extract the tarball of 
the new release, commit).
Then we "SVN merged" the vendor/ directory into trunk/ExtLibs/.
This way, we were able to preserve our occasional customizations to the libraries in 
ExtLibs/ while updating to new vendor releases.

Using something like
	git svn init "svn://.../project_root" --trunk "trunk" git_test_project
(Continue reading)

Permalink | Reply | 0 comments |
headers
Greg Troxel | 1 Mar 2012 01:37
Picon

Re: Why Is There No Bug Tracker And Why Are Patches Sent Instead Of Pull Requests


  I have set up a JIRA instance using Atlassian's OnDemand service,
  available at https://git-scm.atlassian.net/

Do people really think it's reasonable to use non-Free tools to develop
git?  That seems surprising to me.
Permalink | Reply | 9 comments |
headers
Andrew Ardill | 1 Mar 2012 01:45
Picon
Gravatar

Re: Why Is There No Bug Tracker And Why Are Patches Sent Instead Of Pull Requests

On 1 March 2012 11:37, Greg Troxel <gdt <at> ir.bbn.com> wrote:
>
>  I have set up a JIRA instance using Atlassian's OnDemand service,
>  available at https://git-scm.atlassian.net/
>
> Do people really think it's reasonable to use non-Free tools to develop
> git?  That seems surprising to me.
>

Maybe not, and if that is the case I am more than happy to let this die.

That said, this is the tool I know how to use best, and is in my
opinion the most flexible, reliable and supported. The source code is
available on request to customers to extend or modify (or at least it
used to be) and the company is very supportive of open source projects
in general.

Additionally, if we are not prepared to use non-Free tools, we should
probably stop using github. (This example is a little trite, seeing as
there are non-github alternatives available for grabbing the source
code. Then again, the mailing list is not disappearing any time soon,
so there is a free alternative to _any_ bug tracker that is used)

Regards,

Andrew Ardill
Permalink | Reply | 6 comments |
headers
Junio C Hamano | 1 Mar 2012 01:50
Picon
Picon
Favicon
Gravatar

Re: Why Is There No Bug Tracker And Why Are Patches Sent Instead Of Pull Requests

Andrew Ardill <andrew.ardill <at> gmail.com> writes:

> Additionally, if we are not prepared to use non-Free tools, we should
> probably stop using github. (This example is a little trite, seeing as
> there are non-github alternatives available for grabbing the source
> code.

Just on this part.

Github is not the only place to grab the source code.  Far from it.
Permalink | Reply | 1 comment |
headers
Junio C Hamano | 1 Mar 2012 02:05
Picon
Picon
Favicon
Gravatar

Re: Why Is There No Bug Tracker And Why Are Patches Sent Instead Of Pull Requests

Andrew Ardill <andrew.ardill <at> gmail.com> writes:

> On 1 March 2012 11:37, Greg Troxel <gdt <at> ir.bbn.com> wrote:
>>
>> Do people really think it's reasonable to use non-Free tools to develop
>> git? That seems surprising to me.
>
> Maybe not, and if that is the case I am more than happy to let this die.

I won't speculate how big or small part of the Git community you would be
repelling by using a closed/commertial offering. It may not be such a big
deal, or it may be. I simply do not know.

But we will never find out until we try. The same thing can be said for
the usefulness of having a bug tracker and feasibility of keeping it
reasonably clean and useful over time with volunteer effort.  I commend
you for finally stepping up and biting the bullet to start an experiment.

One request I may have is to give read/browse-only access to unregistered
users without any account (I hate having to maintain credentials to random
websites, and I imagine so do many other people), but I am not the target
audience, so please do not bend backwards to implement such if it is too
much trouble with the system.

Thanks.
Permalink | Reply | 1 comment |
headers
Andrew Ardill | 1 Mar 2012 02:05
Picon
Gravatar

Re: Why Is There No Bug Tracker And Why Are Patches Sent Instead Of Pull Requests

On 1 March 2012 11:50, Junio C Hamano <gitster <at> pobox.com> wrote:
> Andrew Ardill <andrew.ardill <at> gmail.com> writes:
>
>> Additionally, if we are not prepared to use non-Free tools, we should
>> probably stop using github. (This example is a little trite, seeing as
>> there are non-github alternatives available for grabbing the source
>> code.
>
> Just on this part.
>
> Github is not the only place to grab the source code.  Far from it.

I understand that Github is not the only place to grab the source code
(maybe it was not clear that I understood that), however the point was
more that even though Github is not-Free many people still use it to
develop Free software (including people developing git). As Free
alternatives to Github are available not many people mind too much (or
so it seems).

Why do people use Github at all? Perhaps, because it provides an
accessible, reliable, powerful and supported platform, with large
amount of penetration in the market and some very desirable features.

I believe that JIRA in the OnDemand package offers similar benefits.
Additionally, Free alternatives would still be available (the mailing
list). Perhaps there is too much controversy to anoint a JIRA issue
tracker as 'official', however I continue to hear people ask for a
tracker, and apart from Jonathan Nieder with the Debian bug tracker
see no one else putting their hands up.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Andrew Ardill | 1 Mar 2012 02:20
Picon
Gravatar

Re: Why Is There No Bug Tracker And Why Are Patches Sent Instead Of Pull Requests

On 1 March 2012 12:05, Junio C Hamano <gitster <at> pobox.com> wrote:
> Andrew Ardill <andrew.ardill <at> gmail.com> writes:
>
>> On 1 March 2012 11:37, Greg Troxel <gdt <at> ir.bbn.com> wrote:
>>>
>>> Do people really think it's reasonable to use non-Free tools to develop
>>> git? That seems surprising to me.
>>
>> Maybe not, and if that is the case I am more than happy to let this die.
>
> I won't speculate how big or small part of the Git community you would be
> repelling by using a closed/commertial offering. It may not be such a big
> deal, or it may be. I simply do not know.

Neither do I - let's find out!

> But we will never find out until we try. The same thing can be said for
> the usefulness of having a bug tracker and feasibility of keeping it
> reasonably clean and useful over time with volunteer effort.  I commend
> you for finally stepping up and biting the bullet to start an experiment.

I have been meaning to get this going for a few months now, the latest
thread kickstarted me again.

> One request I may have is to give read/browse-only access to unregistered
> users without any account (I hate having to maintain credentials to random
> websites, and I imagine so do many other people), but I am not the target
> audience, so please do not bend backwards to implement such if it is too
> much trouble with the system.
>
(Continue reading)

Permalink | Reply | 0 comments |
headers
Tom Grennan | 1 Mar 2012 02:45
Picon

[PATCH 0/5] modernize test style

Tom Grennan <tmgrennan <at> gmail.com> writes:
>On Tue, Feb 21, 2012 at 10:33:29PM -0800, Junio C Hamano wrote:
>>I know you are imitating the style of surrounding tests that is an older
>>parts of this script, but it is an eyesore.  More modern tests are written
>>like this:
>>
>>	test_expect_success 'label for the test' '
>>		cat >expect <<-EOF &&
>>                v0.2.1
>>		EOF
>>	        git tag -l ... >actual &&
>>		test_cmp expect actual
>>	'
>>
>>to avoid unnecessary backslash on the first line, and have the preparation
>>of test vectore _inside_ test_expect_success.  We would eventually want to
>>update the older part to the newer style for consistency.
>>
>>Two possible ways to go about this are (1) have a "pure style" patch at
>>the beginning to update older tests to a new style and then add new code
>>and new test as a follow-up patch written in modern, or (2) add new code
>>and new test in modern, and make a mental note to update the older ones
>>after the dust settles.  Adding new tests written in older style to a file
>>that already has mixed styles is the worst thing you can do.
>>
>>This comment applies to all the patches in this series with tests.
>
>I'd prefer, (1) precede each "--exclude" patch with a "pure style" patch
>to update the respective tests.  However, since this will result in a
>lot of conflict with concurrent development;  I'll separate the test
(Continue reading)

Permalink | Reply | 36 comments |
headers
Tom Grennan | 1 Mar 2012 02:45
Picon

[PATCH 1/5] t6300 (for-each-ref): modernize style

- Guard setup with test_expect_success
- Single-quoted, tab prefaced test blocks of < 80 cols
- Redirect unwanted output

Signed-off-by: Tom Grennan <tmgrennan <at> gmail.com>
---
 t/t6300-for-each-ref.sh |  364 +++++++++++++++++++++++++----------------------
 1 files changed, 191 insertions(+), 173 deletions(-)

diff --git a/t/t6300-for-each-ref.sh b/t/t6300-for-each-ref.sh
index 1721784..12916b2 100755
--- a/t/t6300-for-each-ref.sh
+++ b/t/t6300-for-each-ref.sh
 <at>  <at>  -5,9 +5,17  <at>  <at> 

 test_description='for-each-ref test'

+if ! test -r test-lib.sh ; then
+	(cd ${0%/*} && ./${0##*/} $ <at> )
+	exit $?
+fi
+
 . ./test-lib.sh
 . "$TEST_DIRECTORY"/lib-gpg.sh

+quiet () { "$ <at> " >/dev/null; }
+silent () { "$ <at> " >/dev/null 2>&1; }
+
 # Mon Jul 3 15:18:43 2006 +0000
 datestamp=1151939923
(Continue reading)

Permalink | Reply | 2 comments |

Gmane