headers
Thomas Adam | 1 Feb 2011 01:01
Gravatar

Re: [1.8.0] (v2) default "git merge" without argument to "git merge <at> {u}"

On 31 January 2011 22:55, Jeff King <peff <at> peff.net> wrote:
> On Mon, Jan 31, 2011 at 12:50:30PM -0800, Junio C Hamano wrote:
>
>> Perhaps I should start a new directory in todo branch (say, 1.8.0), accept
>> patches from people?  I'd grudgingly admit that using Wiki on k.org may be
>> less burdensome (I hate editing inside the browser myself), but I'd want
>> to keep the mailing list the center of discussion and am afraid that
>> forcing people to go to Wiki would fragment the discussion.
>
> I really wish we had a git-backed wiki. I also hate using the browser
> for such things (though browser extensions to edit textareas in a Real
> Editor at least make it tolerable, it still ends up clunky).

You mean like ikiwiki (were it used on the main sites)?

http://ikiwiki.info

-- Thomas Adam
Permalink | Reply | 0 comments |
headers
Sverre Rabbelier | 1 Feb 2011 01:13
Picon
Gravatar

Re: [RFC] fast-import: notemodify (N) command

Heya,

On Mon, Jan 31, 2011 at 23:37, Sam Vilain <sam <at> vilain.net> wrote:
> This is not a "fact".
>
> If you add configuration in your git config to fetch and push the refs,
> then they are propagated.

Heh, I was contemplating whether to add "(by default)" or not, I guess
I should have.

--

-- 
Cheers,

Sverre Rabbelier
Permalink | Reply | 0 comments |
headers
Alex Budovski | 1 Feb 2011 01:12
Picon

Re: [1.8.0] 't/' is standard name for directory with tests

>> Nope.  't/' is the standard name for directory with "normal" tests, at
>> least in Perl / CPAN land, where TAP comes from ('xt/' is for extra
>> tests)
>
> So what?  It is not because Perl has set this horrible precedent that we
> have to perpetuate it.  I personally never saw t used as a directory
> name for tests before Git, and I'm not that young anymore unfortunately.

The MySQL project (and its clones) also uses the t/ convention.
Permalink | Reply | 4 comments |
headers
Nicolas Pitre | 1 Feb 2011 01:29

Re: [1.8.0] reorganize the mess that the source tree has become

On Mon, 31 Jan 2011, Jeff King wrote:

> On Mon, Jan 31, 2011 at 04:28:49PM -0500, Nicolas Pitre wrote:
> 
> > So... we do suck at something?  So why not take this opportunity to 
> > shake yourself out of this easy comfort and improve Git as a result on 
> > both front?  :-)
> 
> Yes, we do suck at rename following. The problem is that it is partially
> an implementation issue, and partially a fundamental issue. Obviously
> --follow sucks pretty hard right now, and that could be fixed. Namely it
> follows only a single file, and it interacts very badly with history
> simplification.

This is no excuse not to do proper source tree reorganization.

Telling people not to move files around because Git sucks at tracking 
them is also the wrong answer.

> But even with those things fixed, there will still be annoyances.
> 
> It will still be _slower_ to turn it on all the time, for one[1]. And
> that's due to fundamental design decisions of the git data structure.
> And I'm not knocking those decisions; I think they made the right
> tradeoff. But that doesn't mean we don't pay the cost for that tradeoff.

I agree.  However sitting on our back and resisting a cleanup just 
because our very tool does poorly in that scenario is just like putting 
our heads in the sand and pretend that the problem doesn't exist.  
Better do what most people without internal knowledge of Git would do
(Continue reading)

Permalink | Reply | 8 comments |
headers
Nicolas Pitre | 1 Feb 2011 01:33

Re: [1.8.0] 't/' is standard name for directory with tests

On Tue, 1 Feb 2011, Alex Budovski wrote:

> >> Nope.  't/' is the standard name for directory with "normal" tests, at
> >> least in Perl / CPAN land, where TAP comes from ('xt/' is for extra
> >> tests)
> >
> > So what?  It is not because Perl has set this horrible precedent that we
> > have to perpetuate it.  I personally never saw t used as a directory
> > name for tests before Git, and I'm not that young anymore unfortunately.
> 
> The MySQL project (and its clones) also uses the t/ convention.

OK, that makes for another one.

Now what about those hundred counter-example projects _not_ using "t" 
but something more descriptive?

Nicolas
Permalink | Reply | 3 comments |
headers
Erik Faye-Lund | 1 Feb 2011 01:35
Picon
Gravatar

Re: [1.8.0] reorganize the mess that the source tree has become

On Tue, Feb 1, 2011 at 12:12 AM, Jeff King <peff <at> peff.net> wrote:
> On Mon, Jan 31, 2011 at 04:28:49PM -0500, Nicolas Pitre wrote:
>
>> > Besides being just one more directory to go up and down, it does make
>> > history browsing more annoying. As much as I love git's "don't record
>> > renames" philosophy, our handling of renames on the viewing side is
>> > often annoying. I already get annoyed sometimes following stuff across
>> > the s!builtin-!builtin/! change. This would be like that but more so.
>>
>> So... we do suck at something?  So why not take this opportunity to
>> shake yourself out of this easy comfort and improve Git as a result on
>> both front?  :-)
>
> Yes, we do suck at rename following. The problem is that it is partially
> an implementation issue, and partially a fundamental issue. Obviously
> --follow sucks pretty hard right now, and that could be fixed. Namely it
> follows only a single file, and it interacts very badly with history
> simplification.
>
> But even with those things fixed, there will still be annoyances.
>
> It will still be _slower_ to turn it on all the time, for one[1]. And
> that's due to fundamental design decisions of the git data structure.

Does it really have to be? I mean, for whole-file rename-detection, if
we say that we automatically enable rename-detection (by default) as
we reach the first commit that doesn't have a given tree-entry, then
it would only kick in as we're about to terminate the log-output. And
since we're usually reading through a pager, it should means that it
takes a little bit more time before the user knows he's at the end of
(Continue reading)

Permalink | Reply | 1 comment |
headers
Jakub Narebski | 1 Feb 2011 01:58
Picon
Gravatar

Re: [1.8.0] 't/' is standard name for directory with tests

On Tue, 1 Feb 2011, Nicolas Pitre wrote:
> On Tue, 1 Feb 2011, Alex Budovski wrote:
> 
> > >> Nope.  't/' is the standard name for directory with "normal" tests, at
> > >> least in Perl / CPAN land, where TAP comes from ('xt/' is for extra
> > >> tests)
> > >
> > > So what?  It is not because Perl has set this horrible precedent that we
> > > have to perpetuate it.  I personally never saw t used as a directory
> > > name for tests before Git, and I'm not that young anymore unfortunately.

CPAN is around 21000 distributions and 88000 modules.  Most of those use
't/' for tests (default CPAN client to download and install modules runs
those tests before installing module).

> > The MySQL project (and its clones) also uses the t/ convention.
> 
> OK, that makes for another one.
> 
> Now what about those hundred counter-example projects _not_ using "t" 
> but something more descriptive?

You mean those counter-example projects that use and include comprehensive
tests, isn't it?

Well, GCC uses 'testsuite/'.  Mozilla uses 'testing/'.
--

-- 
Jakub Narebski
Poland
(Continue reading)

Permalink | Reply | 0 comments |
headers
Sverre Rabbelier | 1 Feb 2011 02:00
Picon
Gravatar

Re: [1.8.0] reorganize the mess that the source tree has become

Heya,

On Tue, Feb 1, 2011 at 00:12, Jeff King <peff <at> peff.net> wrote:
> [1] I'd be interested to see how much we can get around that slowness
> using a notes-cache.

Do you mean something like a refs/notes/renames namespace in which we
stick notes on commits indicating that a rename indicated at that
commit, with an option of the user, after-the-fact, adding this
information manually?

--

-- 
Cheers,

Sverre Rabbelier
Permalink | Reply | 1 comment |
headers
Junio C Hamano | 1 Feb 2011 02:13
Picon
Picon
Favicon
Gravatar

Re: [1.8.0] make two-argument fetch update remote branches

Eugene Sajine <euguess <at> gmail.com> writes:

> I did understand what Thomas illustrated. I'm just thinking that the
> range origin/master...FETCH_HEAD seems to be useful but in fact is
> pretty useless, because you cannot guarantee the state of the
> origin/master _before_ the fetch and therefore you cannot rely on the
> results of range selections involving it.

With the current system, origin/master is what I _used to_ have before
running this fetch, iow, what I have been looking at as a reference
material while I did my own work so far.  The current "when fetching refs
explicitly, do not touch tracking branches" behaviour guarantees that.

The range above shows what I already knew about the work the other people
did, and what is new on both sides, to help me decide what I want to do
next with the fetched result.  At least that is the workflow the "when
fetching refs explicitly, do not touch tracking branches" behaviour allows
us to support (I am not recommending that the workflow in particular, by
the way).  The next action after seeing what they added is sane may be to
run "git pull" (no arguments), which would fast-forward my view of the
other side to whatever I reviewed this round.
Permalink | Reply | 0 comments |
headers
Junio C Hamano | 1 Feb 2011 02:15
Picon
Picon
Favicon
Gravatar

Re: [1.8.0] 't/' is standard name for directory with tests

Nicolas Pitre <nico <at> fluxnic.net> writes:

> On Tue, 1 Feb 2011, Alex Budovski wrote:
> ...
>> The MySQL project (and its clones) also uses the t/ convention.
>
> OK, that makes for another one.
>
> Now what about those hundred counter-example projects _not_ using "t" 
> but something more descriptive?

I am fine with "tests/", by the way.
Permalink | Reply | 1 comment |

Gmane