On Sat, Jul 25, 2015 at 10:41:21AM -0700, Junio C Hamano wrote:
> > I'm still on the fence to have the config kick in only for HEAD.
>
> Hmm, I cannot tell offhand if the confusion factor is worth it (I
> didn't say "I don't think it is worth it").
> [...]
I've snipped most of your response beca
On Sat, Jul 25, 2015 at 10:18:45AM -0700, Junio C Hamano wrote:
> > [1] While reading the old "git commit --notes" thread recently, Johan
> > Herland gave a plausible confusing example:
> >
> > ...
> > Why
> > ---
> >
> > To show that "---" can be part of a commit message
On Sat, Jul 25, 2015 at 10:41 AM, Junio C Hamano wrote:
> Jeff King writes:
>
>> On Fri, Jul 24, 2015 at 08:07:49AM -0700, Junio C Hamano wrote:
>>
>>> Yeah, you actually convinced me reasonably well that it would
>>> happen. I'd never use it myself. If people want to shoot
>>> themselves in th
Jeff King writes:
> On Fri, Jul 24, 2015 at 08:07:49AM -0700, Junio C Hamano wrote:
>
>> Yeah, you actually convinced me reasonably well that it would
>> happen. I'd never use it myself. If people want to shoot
>> themselves in the foot, be my guest ;-)
>>
>> Perhaps we should drop this, and g
Jeff King writes:
> This works for "format-patch -s". But I guess that leaves open the
> question of "commit --signoff". It should not matter when making a
> commit new (after all, you have not yet had a chance to put the "---"
> in). But something like "git commit --amend --signoff" might want t
On Fri, Jul 24, 2015 at 08:07:49AM -0700, Junio C Hamano wrote:
> > I am not entirely convinced this won't bite somebody who gets a sha1
> > from some other source, and then wants to run:
> >
> > git log $some_other_sha1
> >
> > who might be quite confused to start a first-parent traversal from
On Fri, Jul 24, 2015 at 06:36:34PM -0700, Jeff King wrote:
> > I think in the cycle we merged Couder's trailer stuff we updated the
> > helper functions to locate where the S-o-b should go in an existing
> > message and consolidated (or, at least "talked about consolidating")
> > them into a singl
On Fri, Jul 24, 2015 at 08:31:55AM -0700, Junio C Hamano wrote:
> Jeff King writes:
>
> > Whoops. Usually I "format-patch -s" and then add any notes while
> > sending. But the wifi at OSCON was so abysmal that instead I wrote the
> > notes directly into the commit message to send the whole thing
On Fri, Jul 24, 2015 at 08:04:21AM -0700, Junio C Hamano wrote:
> > I think a really simple example is something like:
> >
> > 1. somebody implements as feature. It needs to handle cases a, b, and
> > c, but it only handles case a. Therefore it is buggy.
> >
> > 2. During review, somebody
Jeff King writes:
> Whoops. Usually I "format-patch -s" and then add any notes while
> sending. But the wifi at OSCON was so abysmal that instead I wrote the
> notes directly into the commit message to send the whole thing later.
> And of course format-patch is not smart enough to know that I mea
Jeff King writes:
> On Thu, Jul 23, 2015 at 03:46:33PM -0700, Junio C Hamano wrote:
>
>> Admittedly, that
>> merely is saying that "--first-parent" is not a solution to such a
>> project, and does not say much about the usefulness of the new
>> configuration, so I'd queue it as-is.
>
> Yeah, I ag
Jeff King writes:
> I think a really simple example is something like:
>
> 1. somebody implements as feature. It needs to handle cases a, b, and
> c, but it only handles case a. Therefore it is buggy.
>
> 2. During review, somebody notices case b, and a new commit is made to
> fix i
On Fri, Jul 24, 2015 at 12:46:57AM -0700, Jacob Keller wrote:
> On Fri, Jul 24, 2015 at 12:40 AM, Jeff King wrote:
> > Whoops. Usually I "format-patch -s" and then add any notes while
> > sending. But the wifi at OSCON was so abysmal that instead I wrote the
> > notes directly into the commit mes
On Fri, Jul 24, 2015 at 12:40 AM, Jeff King wrote:
> Whoops. Usually I "format-patch -s" and then add any notes while
> sending. But the wifi at OSCON was so abysmal that instead I wrote the
> notes directly into the commit message to send the whole thing later.
> And of course format-patch is not
On Fri, Jul 24, 2015 at 12:34 AM, Jeff King wrote:
> On Thu, Jul 23, 2015 at 11:07:58PM -0700, Jacob Keller wrote:
>
>> I think some projects definitely benefit from the first-parent setup,
>> and it could be valuable, but I do tend to agree with Junio here that
>> the mess is always helpful. If m
On Thu, Jul 23, 2015 at 03:14:50PM -0700, Stefan Beller wrote:
> Github pull request messages
> are similar to cover letters, so you could send a series with a
> good cover letter, but crappy unfinished patches inside the series.
> After applying all patches it could be all nice, i.e. compiles, te
On Thu, Jul 23, 2015 at 11:07:58PM -0700, Jacob Keller wrote:
> I think some projects definitely benefit from the first-parent setup,
> and it could be valuable, but I do tend to agree with Junio here that
> the mess is always helpful. If may be helpful if people's commit
> messages on that mess a
On Thu, Jul 23, 2015 at 03:46:33PM -0700, Junio C Hamano wrote:
> Admittedly, that
> merely is saying that "--first-parent" is not a solution to such a
> project, and does not say much about the usefulness of the new
> configuration, so I'd queue it as-is.
Yeah, I agree that this patch does not m
On Thu, Jul 23, 2015 at 03:46:33PM -0700, Junio C Hamano wrote:
> While I can see the reasoning behind the above [*1*], I am not sure
> if the output with "--first-parent" would always be a good match for
> the "simple" version. Wouldn't the people who keep these messy
> histories also those who
On Thu, Jul 23, 2015 at 3:46 PM, Junio C Hamano wrote:
> Jeff King writes:
>
>> But other projects prefer to keep the messy history intact.
>> For one thing, it makes collaboration on a topic easier, as
>> developers can simply pull from each other during the messy
>> development. And two, that h
Jeff King writes:
> But other projects prefer to keep the messy history intact.
> For one thing, it makes collaboration on a topic easier, as
> developers can simply pull from each other during the messy
> development. And two, that history may later be useful when
> tracking down a bug, because
On Wed, Jul 22, 2015 at 6:23 PM, Jeff King wrote:
> This patch adds an option to turn on --first-parent all the
> time, along with the corresponding --no-first-parent to
> disable it. The "why" of this requires a bit of backstory.
>
> Some projects (like git.git) encourage frequent rebasing to
> g
Jeff King writes:
> I am sympathetic, though. There are some things that git-log can do that
> rev-list cannot, so people end up using it in scripts. I think you can
> avoid it with a "rev-list | diff-tree" pipeline, though I'm not 100%
> sure if that covers all cases. But I would much rather see
On Thu, Jul 23, 2015 at 11:53:37AM +0200, Michael J Gruber wrote:
> That reminds me of my attempt to add those "categories" to the man pages
> of each command (rather than just to that of "git") so that users know
> where they landed. It died off, though: I preferred just specifying the
> category
Jacob Keller venit, vidit, dixit 23.07.2015 08:55:
> On Wed, Jul 22, 2015 at 11:53 PM, Jeff King wrote:
>> "man git" already has such a list (which is generated from the
>> annotations in command-list.txt). But I agree that it would probably be
>> helpful to point people directly from "git log" to
On Wed, Jul 22, 2015 at 11:53 PM, Jeff King wrote:
> "man git" already has such a list (which is generated from the
> annotations in command-list.txt). But I agree that it would probably be
> helpful to point people directly from "git log" to "git rev-list" and
> vice versa.
>
> -Peff
That's good
On Wed, Jul 22, 2015 at 11:32:49PM -0700, Jacob Keller wrote:
> Agreed. Fix the plumbing instead and document how/why to use it
> instead of the porcelain. We might do better to help clearly document
> which commands are porcelain and which are plumbing maybe by
> referencing which plumbings to us
On Wed, Jul 22, 2015 at 10:48 PM, Jeff King wrote:
> On Wed, Jul 22, 2015 at 10:14:45PM -0700, Jeff King wrote:
>
>> Script writers should not care here, because they should not be parsing
>> the output of the porcelain "log" command in the first place. It already
>> has many gotchas (e.g., log.da
On Wed, Jul 22, 2015 at 10:14:45PM -0700, Jeff King wrote:
> Script writers should not care here, because they should not be parsing
> the output of the porcelain "log" command in the first place. It already
> has many gotchas (e.g., log.date, log.abbrevCommit).
>
> I am sympathetic, though. Ther
On Wed, Jul 22, 2015 at 09:40:10PM -0700, David Aguilar wrote:
> On Wed, Jul 22, 2015 at 06:23:44PM -0700, Jeff King wrote:
> > This patch adds an option to turn on --first-parent all the
> > time, along with the corresponding --no-first-parent to
> > disable it.
>
> [Putting on my scripter hat]
On Wed, Jul 22, 2015 at 06:23:44PM -0700, Jeff King wrote:
> This patch adds an option to turn on --first-parent all the
> time, along with the corresponding --no-first-parent to
> disable it.
[Putting on my scripter hat]
I sometimes think, "it would be really helpful if we had a way
to tell Git
This patch adds an option to turn on --first-parent all the
time, along with the corresponding --no-first-parent to
disable it. The "why" of this requires a bit of backstory.
Some projects (like git.git) encourage frequent rebasing to
generate a set of clean, bisectable patches for each topic.
The
32 matches
Mail list logo
