feature request (?)

feature request (?)

[xmb]

Yo,

is there a place to make something like a future feature request

./xmb

Re: feature request (?)

[Hacksaw]

>is there a place to make something like a future feature request

I would say kernel newbies is the place for that. It's a little less likely to 
be lost in the shuffle, and enough code wizards lurk there that if it's an 
idea of merit, they'll pick it up.

Alternatively, you could take a hand at coding it yourself. Kernel newbies is 
a good resource for you in that case as well.

http://www.kernelnewbies.org/ 
-- 
Each part does the work of that part, and no other.
http://www.hacksaw.org -- http://www.privatecircus.com -- KB1FVD

Re: feature request (?)

[Pavel Machek]

Hi!

> is there a place to make something like a future feature request
> 

/dev/null?

:-)

-- 
				Pavel
My velo broke, so I got Zaurus. If you have Philips Velo 1 you don't need...

Re: Feature request:

[Jakub Narebski]

[I'm sorry about breaking Cc: chain - responding via GMane web interface]

Junio C Hamano <gitster <at> pobox.com> writes:
> Ed Hutchins <eh <at> demeterr.com> writes:
> 
> > I'm not trying to change the way git does things (which works perfectly
> > well), I'm asking for some extra information to be added to the commit
> > so that analysis of the ancestry graph can be tied to the branch topics
> > that the original author was working from. [...]
[...]
> It is not just misleading but is actively wrong to recording the
> name of the original branch in commits and carrying them forward via
> rebase. If you want a record of what a group of commits were about,
> the right time to do so is when you merge.
[...]

There is even git-resurrect.sh script in 'contrib/' that makes
use of that practice to find merged-in and deleted branches,
and resurrect them (among other tools).

-- 
Jakub Narębski

Re: Feature request:

[Dany]

Hey Jonathan,

Thanks for the quick reply. I think that's a great message; I do have to say that I wouldn't have known what the `matching` and `simple` modes are without that message; I just had to look it up is all. It may be helpful to tell users that `simple` is probably what they want :)

@DanyJoumaa
1 520 991 5001

On Jul 3, 2013, at 4:46 PM, Jakub Narebski <jnareb@gmail.com> wrote:

> [I'm sorry about breaking Cc: chain - responding via GMane web interface]
> 
> Junio C Hamano <gitster <at> pobox.com> writes:
>> Ed Hutchins <eh <at> demeterr.com> writes:
>> 
>>> I'm not trying to change the way git does things (which works perfectly
>>> well), I'm asking for some extra information to be added to the commit
>>> so that analysis of the ancestry graph can be tied to the branch topics
>>> that the original author was working from. [...]
> [...]
>> It is not just misleading but is actively wrong to recording the
>> name of the original branch in commits and carrying them forward via
>> rebase. If you want a record of what a group of commits were about,
>> the right time to do so is when you merge.
> [...]
> 
> There is even git-resurrect.sh script in 'contrib/' that makes
> use of that practice to find merged-in and deleted branches,
> and resurrect them (among other tools).
> 
> -- 
> Jakub Narębski
> 
> --
> To unsubscribe from this list: send the line "unsubscribe git" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Feature request:

[Dany]

lol, confusion abound. this message was intended to be in response to "Re: Feature request: prevent push -f from pushing all branches at once"

On Jul 3, 2013, at 4:52 PM, Dany <nessup@gmail.com> wrote:

> Hey Jonathan,
> 
> Thanks for the quick reply. I think that's a great message; I do have to say that I wouldn't have known what the `matching` and `simple` modes are without that message; I just had to look it up is all. It may be helpful to tell users that `simple` is probably what they want :)
> 
> @DanyJoumaa
> 1 520 991 5001
> 
> On Jul 3, 2013, at 4:46 PM, Jakub Narebski <jnareb@gmail.com> wrote:
> 
>> [I'm sorry about breaking Cc: chain - responding via GMane web interface]
>> 
>> Junio C Hamano <gitster <at> pobox.com> writes:
>>> Ed Hutchins <eh <at> demeterr.com> writes:
>>> 
>>>> I'm not trying to change the way git does things (which works perfectly
>>>> well), I'm asking for some extra information to be added to the commit
>>>> so that analysis of the ancestry graph can be tied to the branch topics
>>>> that the original author was working from. [...]
>> [...]
>>> It is not just misleading but is actively wrong to recording the
>>> name of the original branch in commits and carrying them forward via
>>> rebase. If you want a record of what a group of commits were about,
>>> the right time to do so is when you merge.
>> [...]
>> 
>> There is even git-resurrect.sh script in 'contrib/' that makes
>> use of that practice to find merged-in and deleted branches,
>> and resurrect them (among other tools).
>> 
>> -- 
>> Jakub Narębski
>> 
>> --
>> To unsubscribe from this list: send the line "unsubscribe git" in
>> the body of a message to majordomo@vger.kernel.org
>> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 

Re: Feature request:

[Matthieu Moy]

Dany <nessup@gmail.com> writes:

> lol, confusion abound. this message was intended to be in response to "Re: Feature request: prevent push -f from pushing all branches at once"

While we're there: please, don't top-post here. Quote the part of the
message you're replying to, and reply below.

-- 
Matthieu Moy
http://www-verimag.imag.fr/~moy/