On 29 April 2014 13:32:29 GMT+10:00, Felipe Contreras
felipe.contre...@gmail.com wrote:
James Denholm wrote:
No, true, but my point was more related to that it's ones own task,
perhaps being the better term than job, to debate the merits of one's
own work when the merits are currently unknown
list git@vger.kernel.org
Skickat: tisdag, 29 apr 2014 5:32:29
Ämne: Re: Recording the current branch on each commit?
James Denholm wrote:
Felipe Contreras felipe.contre...@gmail.com wrote:
James Denholm wrote:
It's not anybody else's job to take your patches and drizzle them
James Denholm wrote:
You cannot expect that anybody but yourself is willing to propose,
debate the merits of and otherwise defend patches that you have
authored (herein your patches, implying authorship, not
ownership).
This is the original comment:
David Kastrup wrote:
It becomes easier
Felipe Contreras felipe.contre...@gmail.com writes:
Contributors don't have any responsibility to champion their patches.
It is pro bono work.
No, that's just the appearance that should be upheld in the higher
society. It's ok to get paid for work on Git as long as you don't
mention it in
David Kastrup wrote:
Felipe Contreras felipe.contre...@gmail.com writes:
Contributors don't have any responsibility to champion their
patches. It is pro bono work.
No, that's just the appearance that should be upheld in the higher
society. It's ok to get paid for work on Git as long
David Kastrup wrote:
Felipe Contreras felipe.contre...@gmail.com writes:
David Kastrup wrote:
Even while the ones getting the benefits from your work will not
feel an obligation to make it worth your while, there is a
difference in satisfaction between getting your work trashed and
Felipe Contreras felipe.contre...@gmail.com writes:
David Kastrup wrote:
Well, there you have it. The ones that do any kind of relevant change
are the ones that need thinking about and consideration. And when you
are so verbose about them that
a) you are getting on people's nerves
b)
David Kastrup wrote:
Felipe Contreras felipe.contre...@gmail.com writes:
David Kastrup wrote:
Well, there you have it. The ones that do any kind of relevant change
are the ones that need thinking about and consideration. And when you
are so verbose about them that
a) you are
Felipe Contreras felipe.contre...@gmail.com writes:
David Kastrup wrote:
The default behavior of git push.
This is a minor change that not many people would notice, and it has not
actually happend. But fine, let's count it as one.
Shrug. Your diatribe is to a good part about the default
I've no right to say this, given that I've no contributions
thus far to the project, little history in open source at all,
and have only been following the list for less than a week,
but I'll say it anyway, mayhaps.
And I don't mean this to cause offence, or inspire outrage,
or any similar sort
David Kastrup wrote:
Felipe Contreras felipe.contre...@gmail.com writes:
David Kastrup wrote:
The default behavior of git push.
This is a minor change that not many people would notice, and it has not
actually happend. But fine, let's count it as one.
Shrug. Your diatribe is to
James Denholm wrote:
I've no right to say this, given that I've no contributions I'm not
saying that you shouldn't work on the git codebase, you could very
easily fork it and make the innovative SCMS none of us can see, and
kill git. Can be done, if hunting really is the best choice as you
On 29 April 2014 21:47:42 GMT+10:00, Felipe Contreras
felipe.contre...@gmail.com wrote:
James Denholm wrote:
I've no right to say this, given that I've no contributions I'm not
saying that you shouldn't work on the git codebase, you could very
easily fork it and make the innovative SCMS none
James Denholm wrote:
So that we can all have egg on our faces when it takes off and is
proven superior... Right?
I don't know what you mean by we, but it certainly doesn't include
you.
% git log --author=nod.h...@gmail.com master
empty
--
Felipe Contreras
--
To unsubscribe from this
On 29 April 2014 23:31:29 GMT+10:00, Felipe Contreras
felipe.contre...@gmail.com wrote:
James Denholm wrote:
So that we can all have egg on our faces when it takes off and is
proven superior... Right?
I don't know what you mean by we, but it certainly doesn't include
you.
% git log
On Tue, Apr 29, 2014 at 12:17 PM, Felipe Contreras
felipe.contre...@gmail.com wrote:
That's all you could list for *four* years? None of that would even be noticed
by most of our users, maybe push.default (when it actually happens), but
that's
*one*.
*One* important change in *four* years.
James Denholm wrote:
On 29 April 2014 23:31:29 GMT+10:00, Felipe Contreras
felipe.contre...@gmail.com wrote:
James Denholm wrote:
So that we can all have egg on our faces when it takes off and is
proven superior... Right?
I don't know what you mean by we, but it certainly doesn't
On Mon, 28 Apr 2014, David Kastrup wrote:
Jeremy Morton ad...@game-point.net writes:
On 28/04/2014 10:02, David Kastrup wrote:
Jeremy Mortonad...@game-point.net writes:
On 28/04/2014 09:32, Felipe Contreras wrote:
some people to is to always merge with --no-ff, that way you see the
On Mon, 28 Apr 2014, Jeremy Morton wrote:
On 28/04/2014 10:09, Johan Herland wrote:
On Mon, Apr 28, 2014 at 11:01 AM, Jeremy Mortonad...@game-point.net
wrote:
On 28/04/2014 07:45, Christian Couder wrote:
Yes, it's possible. Yesterday, I sent the following patch:
[RFC/PATCH 2/2] trailer: add
On 30 April 2014 07:45:37 GMT+10:00, Felipe Contreras
felipe.contre...@gmail.com wrote:
James Denholm wrote:
On 29 April 2014 23:31:29 GMT+10:00, Felipe Contreras
felipe.contre...@gmail.com wrote:
James Denholm wrote:
So that we can all have egg on our faces when it takes off and is
proven
James Denholm wrote:
Either way your analogy is completely wrong as I already explained
multiple times. I'm not trying to convince vegetarians to go
hunting, I'm saying they should eat something, bread, meat,
vegetables, anything. Instead they choose to starve to death.
I'm the
Felipe Contreras wrote:
James Denholm wrote:
Either way your analogy is completely wrong as I already explained
multiple times. I'm not trying to convince vegetarians to go
hunting, I'm saying they should eat something, bread, meat,
vegetables, anything. Instead they choose to starve to
James Denholm wrote:
Felipe Contreras wrote:
James Denholm wrote:
Either way your analogy is completely wrong as I already explained
multiple times. I'm not trying to convince vegetarians to go
hunting, I'm saying they should eat something, bread, meat,
vegetables, anything. Instead
Felipe Contreras wrote:
You are obviously not very good with analogies, or reading for that
matter. The answer is quoted right in the begginning of the mail.
Congratulations, you've achieved a mail quote loop.
I'll rephrase the question and it's context. Please attempt to answer
it.
You've
On Mon, Apr 28, 2014 at 11:15:10AM -0700, Junio C Hamano wrote:
Any additional information about the commit can be added you
suggest is exactly the kind of thing we want to avoid, which made
Linus say in an even older discussion [*2*]:
No this random field could be used this random way
Johan Herland jo...@herland.net writes:
Obviously, the feature would necessarily have to be optional, simply
because Git would have to keep understanding the old commit object
format for a LONG time (probably indefinitely), and there's nothing
you can do to prevent others from creating
Hi.
Obviously, the feature would necessarily have to be optional, simply
because Git would have to keep understanding the old commit object
format for a LONG time (probably indefinitely), and there's nothing
you can do to prevent others from creating old-style commit objects.
Doesn't git
Personally, I am _strongly_ opposed. How I name and juggle my private
branches is nobody else's business in a distributed version control
system.
They are private. My personal workflow. Not part of a commit.
Mercurial inherits the branch label from previous commit, unless
it's specified
From: Johan Herland jo...@herland.net
Subject: Re: Recording the current branch on each commit?
Date: Mon, 28 Apr 2014 01:39:26 +0200
On Sun, Apr 27, 2014 at 10:55 PM, Jeremy Morton ad...@game-point.net wrote:
On 27/04/2014 20:33, Johan Herland wrote:
On Sun, Apr 27, 2014 at 7:38 PM, Jeremy
Jeremy Morton wrote:
On 27/04/2014 09:51, Robin Rosenberg wrote:
Currently, git records a checksum, author, commit date/time, and commit
message with every commit (as get be seen from 'git log'). I think it
would be useful if, along with the Author and Date, git recorded the
name of the
On 28/04/2014 09:32, Felipe Contreras wrote:
some people to is to always merge with --no-ff, that way you see the branch
name in the merge commit.
But surely, it's recommended with Git that you try to avoid doing
--no-ff merges to avoid commit noise?
Nope. Different people have different
On 28/04/2014 03:30, Sitaram Chamarty wrote:
On 04/28/2014 01:03 AM, Johan Herland wrote:
Yeah, sure. Author and Date (and Committer, for that matter) is just
metadata, and the current branch name is simply just another kind of
metadata. All of them are more-or-less free-form text fields, and
Jeremy Morton wrote:
On 27/04/2014 10:09, Johan Herland wrote:
On Sun, Apr 27, 2014 at 1:56 AM, Jeremy Mortonad...@game-point.net wrote:
Currently, git records a checksum, author, commit date/time, and commit
message with every commit (as get be seen from 'git log'). I think it
would
On 28/04/2014 07:45, Christian Couder wrote:
Yes, it's possible. Yesterday, I sent the following patch:
[RFC/PATCH 2/2] trailer: add examples to the documentation
and it shows a commit-msg hook to do something like that:
$ cat.git/hooks/commit-msgEOF
#!/bin/sh
git interpret-trailers
Jeremy Morton ad...@game-point.net writes:
On 28/04/2014 09:32, Felipe Contreras wrote:
some people to is to always merge with --no-ff, that way you see the branch
name in the merge commit.
But surely, it's recommended with Git that you try to avoid doing
--no-ff merges to avoid commit
Johan Herland wrote:
On Sun, Apr 27, 2014 at 7:38 PM, Jeremy Morton ad...@game-point.net wrote:
Whatsmore, tracking down which branch a commit pertains to is still rather
difficult using this approach. You can go back through the history and
find Merge branch 'pacman-minigame', but how do
On Mon, Apr 28, 2014 at 11:01 AM, Jeremy Morton ad...@game-point.net wrote:
On 28/04/2014 07:45, Christian Couder wrote:
Yes, it's possible. Yesterday, I sent the following patch:
[RFC/PATCH 2/2] trailer: add examples to the documentation
and it shows a commit-msg hook to do something like
On 28/04/2014 10:02, David Kastrup wrote:
Jeremy Mortonad...@game-point.net writes:
On 28/04/2014 09:32, Felipe Contreras wrote:
some people to is to always merge with --no-ff, that way you see the branch
name in the merge commit.
But surely, it's recommended with Git that you try to avoid
Jeremy Morton wrote:
On 27/04/2014 20:33, Johan Herland wrote:
The problem is not really less tidy commit trees - by which I gather
you mean history graphs that are non-linear. IMHO, the history graph
should reflect parallel/branched development when that is useful.
Blindly rebasing
On 28/04/2014 10:09, Johan Herland wrote:
On Mon, Apr 28, 2014 at 11:01 AM, Jeremy Mortonad...@game-point.net wrote:
On 28/04/2014 07:45, Christian Couder wrote:
Yes, it's possible. Yesterday, I sent the following patch:
[RFC/PATCH 2/2] trailer: add examples to the documentation
and it
On 28/04/2014 10:01, Felipe Contreras wrote:
Jeremy Morton wrote:
On 27/04/2014 20:33, Johan Herland wrote:
The problem is not really less tidy commit trees - by which I gather
you mean history graphs that are non-linear. IMHO, the history graph
should reflect parallel/branched development
Jeremy Morton wrote:
On 28/04/2014 10:01, Felipe Contreras wrote:
Jeremy Morton wrote:
On 27/04/2014 20:33, Johan Herland wrote:
The problem is not really less tidy commit trees - by which I gather
you mean history graphs that are non-linear. IMHO, the history graph
should reflect
On 28/04/2014 10:17, Felipe Contreras wrote:
I don't seem to what? I'm the one arguing for change, and I sent the patches to
fix this default behavior.
Well maybe you should work on phrasing things better - you come across
as quite negative.
--
Best regards,
Jeremy Morton (Jez)
--
To
On 04/28/2014 02:22 PM, Jeremy Morton wrote:
On 28/04/2014 03:30, Sitaram Chamarty wrote:
On 04/28/2014 01:03 AM, Johan Herland wrote:
Yeah, sure. Author and Date (and Committer, for that matter) is just
metadata, and the current branch name is simply just another kind of
metadata. All of them
Felipe Contreras felipe.contre...@gmail.com writes:
Jeremy Morton wrote:
Sounds like the default behaviour of git pull might not be ideal if
it easily causes these problems.
It's not idea. Virtually everyone agrees with that, even Linus
Torvalds, and we have the patches to fix it, but
Jeremy Morton ad...@game-point.net writes:
On 28/04/2014 10:02, David Kastrup wrote:
Jeremy Mortonad...@game-point.net writes:
On 28/04/2014 09:32, Felipe Contreras wrote:
some people to is to always merge with --no-ff, that way you see the
branch
name in the merge commit.
But surely,
On Mon, Apr 28, 2014 at 12:03 PM, Sitaram Chamarty sitar...@gmail.com wrote:
Johan Herland jo...@herland.net writes:
Obviously, the feature would necessarily have to be optional, simply
because Git would have to keep understanding the old commit object
format for a LONG time (probably
Jeremy Morton wrote:
On 28/04/2014 10:17, Felipe Contreras wrote:
I don't seem to what? I'm the one arguing for change, and I sent the
patches to fix this default behavior.
Well maybe you should work on phrasing things better - you come across as
quite negative.
What is the difference
Max Kirillov m...@max630.net writes:
Obviously, the feature would necessarily have to be optional, simply
because Git would have to keep understanding the old commit object
format for a LONG time (probably indefinitely), and there's nothing
you can do to prevent others from creating old-style
David Kastrup wrote:
Felipe Contreras felipe.contre...@gmail.com writes:
Jeremy Morton wrote:
Sounds like the default behaviour of git pull might not be ideal if
it easily causes these problems.
It's not idea. Virtually everyone agrees with that, even Linus
Torvalds, and we have
Jeremy Morton ad...@game-point.net writes:
But surely, it's recommended with Git that you try to avoid doing
--no-ff merges to avoid commit noise?
That is a misconception, I am afraid, coming from two different
camps.
Some projects do not want any merges for whatever reason, not
limited to
Felipe Contreras felipe.contre...@gmail.com wrote:
David Kastrup wrote:
It becomes easier to actually change things when communicating in a
less
abrasive and destructive manner.
That would make sense if I was the only one with the itch. But I wasn't
the
only one, so anybody could take the
James Denholm wrote:
Felipe Contreras felipe.contre...@gmail.com wrote:
David Kastrup wrote:
It becomes easier to actually change things when communicating in a less
abrasive and destructive manner.
That would make sense if I was the only one with the itch. But I wasn't the
only
Felipe Contreras felipe.contre...@gmail.com writes:
Except that in this case virtually everyone agreed the default was wrong. I
already said that.
Clarly you didn't read the relevant discussions where everyone, including
Linus
Torvalds, agreed. Did you?
My recollection is that everybody
Junio C Hamano wrote:
Felipe Contreras felipe.contre...@gmail.com writes:
Except that in this case virtually everyone agreed the default was wrong. I
already said that.
Clarly you didn't read the relevant discussions where everyone, including
Linus
Torvalds, agreed. Did you?
My
Felipe Contreras felipe.contre...@gmail.com writes:
In this context James was talking about what Git should be. But the vast
majority agree on this issue, so that's not what's preventing change.
Sorry, I saw take your patches from James and my patch from you
in the context above that part, and
Junio C Hamano wrote:
Felipe Contreras felipe.contre...@gmail.com writes:
In this context James was talking about what Git should be. But the vast
majority agree on this issue, so that's not what's preventing change.
I agree that recognition of the issue is not what prevents a change.
Felipe Contreras felipe.contre...@gmail.com wrote:
James Denholm wrote:
It's not anybody else's job to take your patches and drizzle them in the
honey of respectable discourse.
It's nobody's job to do anything. This a collaborative effort and in a
collaborative effort everbody chimes in to
James Denholm wrote:
Felipe Contreras felipe.contre...@gmail.com wrote:
James Denholm wrote:
It's not anybody else's job to take your patches and drizzle them in the
honey of respectable discourse.
It's nobody's job to do anything. This a collaborative effort and in a
collaborative
- Ursprungligt meddelande -
Från: Jeremy Morton ad...@game-point.net
Till: git@vger.kernel.org
Skickat: söndag, 27 apr 2014 1:56:47
Ämne: Recording the current branch on each commit?
Currently, git records a checksum, author, commit date/time, and commit
message with every commit
On Sun, Apr 27, 2014 at 1:56 AM, Jeremy Morton ad...@game-point.net wrote:
Currently, git records a checksum, author, commit date/time, and commit
message with every commit (as get be seen from 'git log'). I think it would
be useful if, along with the Author and Date, git recorded the name of
On 27/04/2014 09:51, Robin Rosenberg wrote:
Currently, git records a checksum, author, commit date/time, and commit
message with every commit (as get be seen from 'git log'). I think it
would be useful if, along with the Author and Date, git recorded the
name of the current branch on each
On Sun, Apr 27, 2014 at 7:38 PM, Jeremy Morton ad...@game-point.net wrote:
On 27/04/2014 10:09, Johan Herland wrote:
On Sun, Apr 27, 2014 at 1:56 AM, Jeremy Mortonad...@game-point.net
wrote:
Currently, git records a checksum, author, commit date/time, and commit
message with every commit (as
On 27/04/2014 20:33, Johan Herland wrote:
On Sun, Apr 27, 2014 at 7:38 PM, Jeremy Mortonad...@game-point.net wrote:
On 27/04/2014 10:09, Johan Herland wrote:
As far as I can tell from that discussion, the general opposition to
encoding the branch name as a structural part of the commit object
I'm skipping a lot of the discussion here, sorry about that, but
on one particular note:
Jeremy Morton ad...@game-point.net wrote:
(...) and besides it takes up space that could be
used for a commit message. As short commit messages are valued in Git,
it's particularly bad to waste space this
On 27/04/2014 22:40, James Denholm wrote:
Also, you don't always have something you can link a commit to in an
issue tracker. You may just be implementing a feature that has been
agreed upon, independently of any such tracker. In that case, there's
no bug# to link to.
In which case, refer to
Jeremy Morton ad...@game-point.net wrote:
On 27/04/2014 22:40, James Denholm wrote:
Also, you don't always have something you can link a commit to in an
issue tracker. You may just be implementing a feature that has been
agreed upon, independently of any such tracker. In that case,
there's
On Sun, Apr 27, 2014 at 10:55 PM, Jeremy Morton ad...@game-point.net wrote:
On 27/04/2014 20:33, Johan Herland wrote:
On Sun, Apr 27, 2014 at 7:38 PM, Jeremy Mortonad...@game-point.net
wrote:
On 27/04/2014 10:09, Johan Herland wrote:
As far as I can tell from that discussion, the general
On 04/28/2014 01:03 AM, Johan Herland wrote:
On Sun, Apr 27, 2014 at 7:38 PM, Jeremy Morton ad...@game-point.net wrote:
On 27/04/2014 10:09, Johan Herland wrote:
On Sun, Apr 27, 2014 at 1:56 AM, Jeremy Mortonad...@game-point.net
wrote:
Currently, git records a checksum, author, commit
Currently, git records a checksum, author, commit date/time, and commit
message with every commit (as get be seen from 'git log'). I think it
would be useful if, along with the Author and Date, git recorded the
name of the current branch on each commit. The branch name can provide
useful
70 matches
Mail list logo
