From: Junio C Hamano <hidden> Date: 2016-06-15 22:45:27
David Soria Parra [off-list ref] writes:
quoted
Any opinions on this?
would be great to have something like that build in git-core like
git branch -i 'Fix bla' ds/fix next
git branch -i
ds/fix (Fix Bla)
Haven't people watched Linus on google tech talk? Here is an excerpt from
the transcript (http://git.or.cz/gitwiki/LinusTalk200705Transcript):
... well actually you shouldn't call it "test", you should basically
name your branches the way you name your functions, you should call
them something short and sweet and to the point -- What is that branch
doing.
IOW, why did you name the branch "ds/fix" and not "ds/fix-bla"?
From: David Soria Parra <hidden> Date: 2016-06-15 22:45:27
Haven't people watched Linus on google tech talk? Here is an excerpt from
the transcript (http://git.or.cz/gitwiki/LinusTalk200705Transcript):
... well actually you shouldn't call it "test", you should basically
name your branches the way you name your functions, you should call
them something short and sweet and to the point -- What is that branch
doing.
IOW, why did you name the branch "ds/fix" and not "ds/fix-bla"?
Okay I just choosed a bad example. Actually I call it ds/fix-function,
but nevertheless more additional description can be useful when dealing
with a lot of branches. But yes, there might be porcelains that can do that.
David Soria Parra [off-list ref] writes:
>> Any opinions on this?
>
> would be great to have something like that build in git-core like
>
> git branch -i 'Fix bla' ds/fix next
> git branch -i
> ds/fix (Fix Bla)
Haven't people watched Linus on google tech talk? Here is an excerpt from
the transcript (http://git.or.cz/gitwiki/LinusTalk200705Transcript):
... well actually you shouldn't call it "test", you should basically
name your branches the way you name your functions, you should call
them something short and sweet and to the point -- What is that branch
doing.
IOW, why did you name the branch "ds/fix" and not "ds/fix-bla"?
Because it would be excessive typing every time you want to do
something to that branch?
I guess bash completions would help with this (if you're using bash),
but even then it's kind of unreasonable to name branches something
like "bug-111234-widget-performance-improvements-for-customer-x",
which is the sort of information that would be awfully helpful two
months later when you're looking at old unmerged branches.
Avery
On Wed, Oct 08, 2008 at 07:21:33PM -0400, Avery Pennarun [off-list ref] wrote:
I guess bash completions would help with this (if you're using bash),
but even then it's kind of unreasonable to name branches something
like "bug-111234-widget-performance-improvements-for-customer-x",
I think you haven't read the links mentioned in the previous mail.
IIRC the thread had a suggestion about creating such a 'desc' branch,
then you could just have a branch named 'fix' and you could do git show
desc:fix to see its description.
Just use git as a filesystem, as it was originally designed... ;-)
From: Peter Krefting <hidden> Date: 2016-06-15 22:45:28
Avery Pennarun:
I guess bash completions would help with this (if you're using bash),
but even then it's kind of unreasonable to name branches something
like "bug-111234-widget-performance-improvements-for-customer-x",
which is the sort of information that would be awfully helpful two
months later when you're looking at old unmerged branches.
That's exactly what I do for one of the projects I am working on (well,
minus the "bug-" prefix, that's implied). Bash completion works quite
well for that, and the merge commits do give meaningful information.
But I would still like to be able to annotate it. Especially for
long-living bug-fix branches, it could be useful to be able to add
describe a branch with what state it is in, for instance.
--
\\// Peter - http://www.softwolves.pp.se/