Max Kirillov writes:
> I might be late for this discussion, but I seem to have
> a case when blame --reverse --first-parent seems to work.
I think during the discussion we already established that there are
cases where the mode happens to do the right thing (the most trivial
is a completely line
On Tue, Sep 15, 2015 at 06:05:39AM -0400, Jeff King wrote:
> It seems like nobody is actually that interested in what "blame
> --first-parent --reverse" does in the first place, though, and there's
> no reason for its complexity to hold up vanilla --first-parent. So what
> do you think of:
...
> Co
Jeff King writes:
> On Tue, Sep 15, 2015 at 06:14:26PM -0700, Junio C Hamano wrote:
>
>> Jeff King writes:
>>
>> > It seems like nobody is actually that interested in what "blame
>> > --first-parent --reverse" does in the first place, though, and there's
>> > no reason for its complexity to hol
On Tue, Sep 15, 2015 at 06:14:26PM -0700, Junio C Hamano wrote:
> Jeff King writes:
>
> > It seems like nobody is actually that interested in what "blame
> > --first-parent --reverse" does in the first place, though, and there's
> > no reason for its complexity to hold up vanilla --first-parent.
Jeff King writes:
> It seems like nobody is actually that interested in what "blame
> --first-parent --reverse" does in the first place, though, and there's
> no reason for its complexity to hold up vanilla --first-parent. So what
> do you think of:
I like the part that explicitly disables the c
On Sun, Sep 13, 2015 at 10:19:33PM -0700, Junio C Hamano wrote:
> For that matter, I am not sure how "blame A..B" with first-parent &
> reverse should behave when A is not an ancestor on the first-parent
> chain. Wouldn't we try to find a cut-point on the first-parent chain by
> traversing first-p
On Sun, Sep 13, 2015 at 3:07 AM, Jeff King wrote:
>> The thing is, traversing first-parent chain in reverse fundamentally
>> is undefined. You can fork multiple topics at the tip of 'master'
>> and each of the topics may be single strand of pearls, but which one
>> of the topics is the first-chil
On Sat, Sep 12, 2015 at 01:29:43AM -0700, Junio C Hamano wrote:
> >> - for (p = commit->parents; p; p = p->next)
> >> + for (p = commit->parents;
> >> + p && !revs->first_parent_only;
> >> + p = p->next)
> >>add_child(revs, p->item,
From: "Junio C Hamano"
Sent: Saturday, September 12, 2015 9:29 AM
Jeff King writes:
Yeah, I think what is happening in this first hunk:
...
is doing the right thing. It did feel a little weird to me to be
munging
the global commit objects themselves, but I guess it is fairly normal
for git
Jeff King writes:
> Yeah, I think what is happening in this first hunk:
> ...
> is doing the right thing. It did feel a little weird to me to be munging
> the global commit objects themselves, but I guess it is fairly normal
> for git code.
Yeah, the above may be brilliant, but ...
>> diff --gi
On Fri, Sep 11, 2015 at 12:06:27PM -0700, Junio C Hamano wrote:
> So here is an outline of what I had in mind when I was writing the
> above. Instead of trusting that num_scapegoats() is always used to
> limit the enumeration of commit->parents, we discard the second and
> subsequent parents from
Junio C Hamano writes:
> Jeff King writes:
>
>> I'm not too familiar with the code, but this _seems_ to work for me:
>>
>> diff --git a/builtin/blame.c b/builtin/blame.c
>> index 21321be..2e03d47 100644
>> --- a/builtin/blame.c
>> +++ b/builtin/blame.c
>> @@ -1375,6 +1375,10 @@ static struct com
Jeff King writes:
> I'm not too familiar with the code, but this _seems_ to work for me:
>
> diff --git a/builtin/blame.c b/builtin/blame.c
> index 21321be..2e03d47 100644
> --- a/builtin/blame.c
> +++ b/builtin/blame.c
> @@ -1375,6 +1375,10 @@ static struct commit_list *first_scapegoat(struct
>
On 11 September 2015 at 15:01, Jeff King wrote:
> On Fri, Sep 11, 2015 at 11:47:30AM +0100, Stephen Connolly wrote:
>
>> A command line option to `git blame HEAD -- path` that instructs that
>> the revisions of blame be the revisions where the change was applied
>> to the current branch not the re
On Fri, Sep 11, 2015 at 11:47:30AM +0100, Stephen Connolly wrote:
> A command line option to `git blame HEAD -- path` that instructs that
> the revisions of blame be the revisions where the change was applied
> to the current branch not the revision where the change first
> originated (i.e. limit
Background
===
My colleagues and I disagree on how exactly to handle feature
development in branches.
There are approximately two camps:
Camp 1: All feature branches should be squashed after code review to a
single commit before merging.
Camp 2: Leave the history of development alone, being able
16 matches
Mail list logo
