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...

Feature request: "author branch" in commit object

[Ed Hutchins]

I realize that branch names are ephemeral repo-specific things, but it
would be really useful to be able to determine what branch a commit
was authored from (as a hint to ancestry graph layout tools, for
example). Is there any way to do this currently, is it planned, or
would it be deemed useful enough to be worth adding to each commit
object?

  - Ed

Re: Feature request: "author branch" in commit object

[Matthieu Moy]

Ed Hutchins <eh@demeterr.com> writes:

> I realize that branch names are ephemeral repo-specific things, but it
> would be really useful to be able to determine what branch a commit
> was authored from (as a hint to ancestry graph layout tools, for
> example). Is there any way to do this currently, is it planned, or
> would it be deemed useful enough to be worth adding to each commit
> object?

FWIW, this is what Mercurial's "named branches" do. Instead of having
branches point to commit, each commit says what branch it belongs to.

One drawback of this approach is that the branch name is part of the
commit and can't be changed without changing the commit's sha1. Hence, a
local, private, branch name becomes permanent the day it's merged
upstream.

(for completeness: Mercurial also has essentially Git-like branches,
but they call this "bookmarks")

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

Re: Feature request: "author branch" in commit object

[Ed Hutchins]

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. Currently if you have a
rebase-branch/ff-merge-to-master workflow, the graph of commits looks
like a single user produced all of the code. It would be very useful for
both forensic and display purposes to categorize those commits by their
original topics, but that history is lost in such a workflow. Certainly
there are work-arounds (notes etc.) to capture this history, but I think
that this is a basic feature which most projects would benefit from. I
fully understand that branches are not global and that it may be
confusing to keep an "author branch" name around in some cases, but the
vast majority of cases where authors pick meaningful branch names would
benefit from being able to look back and go "ah-ha! that was a commit to
fix bug such-and-such" or "that was a commit from when I was working on
super-cool feature X". Even just knowing that two commits were from
different (or the same) branches would tell you something useful about
the evolution of the project. Arguing that branch names are local and
thus meaningless misses the point: branches are *names* which were
meaningful to the author at the time the branch was being worked on.
Discarding this information makes it harder to reason about or display
the history of the project and is an irritating defect in an otherwise
wonderful tool.

On Wed, Jul 3, 2013 at 2:33 AM, Matthieu Moy
<Matthieu.Moy@grenoble-inp.fr> wrote:
> Ed Hutchins <eh@demeterr.com> writes:
>
>> I realize that branch names are ephemeral repo-specific things, but it
>> would be really useful to be able to determine what branch a commit
>> was authored from (as a hint to ancestry graph layout tools, for
>> example). Is there any way to do this currently, is it planned, or
>> would it be deemed useful enough to be worth adding to each commit
>> object?
>
> FWIW, this is what Mercurial's "named branches" do. Instead of having
> branches point to commit, each commit says what branch it belongs to.
>
> One drawback of this approach is that the branch name is part of the
> commit and can't be changed without changing the commit's sha1. Hence, a
> local, private, branch name becomes permanent the day it's merged
> upstream.
>
> (for completeness: Mercurial also has essentially Git-like branches,
> but they call this "bookmarks")
>
> --
> Matthieu Moy
> http://www-verimag.imag.fr/~moy/

Re: Feature request: "author branch" in commit object

[Junio C Hamano]

Ed Hutchins <eh@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. Currently if you have a
> rebase-branch/ff-merge-to-master workflow, the graph of commits looks
> like a single user produced all of the code. It would be very useful for
> both forensic and display purposes to categorize those commits by their
> original topics, but that history is lost in such a workflow.

I am not following that "a single user" part. As long as these
topics are done by different people, the authorship remains
separate, no matter what the shape of the graph is.

It all depends on what you show on the graph other than a circle and
connecting lines, but I presume at least you would show the subject
line. The graph would clearly show which groups of commits tackle
what problems in your history, even if you excessively linearlized
it by rebasing. You need subjects / commit log messages that are
better than "bugfix", of course, for it to work, though.

> Arguing that branch names are local and thus meaningless misses
> the point: branches are *names* which were meaningful to the
> author at the time the branch was being worked on.

That is not necessarily true.

Most of my commits start their life on a single branch that is named
after a very broad theme (or even on a detached HEAD) that ends up
touching different parts of the system and then later split into
separate topic branches that are named after more detailed single
issues. The name of the branch that happened to have been used to
create them have almost no meaning after I am done with multiple and
independent (but related in the larger scheme of things) topics.

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.

Projects that care about the shape of the ancestry graph have an
obvious option of not excessively/unnecessarily linearlizing their
history. We even have the "--no-ff" mode of merge to create an
otherwise unnecessary merge to mark the point where a topic is
merged to the mainline, so that merge log messages can say what
topic was merged (and also you can even have "merge.log").

Cleaning up a messy history created on a topic branch before
presenting to others by lineralizing is one thing. It is a good
practice. Requiring any update to fast-forward on top of the tip of
the project is quite different. It does not make your history any
easier to read. A topic that has been working fine on top of last
week's trunk can have a subtle interaction with the work done by
others on the trunk since it forked, and rebasing it on top of
today's trunk, just before pushing it out on the trunk, risks
breaking the topic in a subtle way without the person who does such
a rebase without noticing, making later bisection harder.

Any option to encourage such an artificially linear history _is_
actively detrimental.

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/