Re: What's cooking in git.git (Aug 2014, #01; Fri, 1)

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Jeff King <peff@xxxxxxxx> writes:

> On Fri, Aug 01, 2014 at 03:01:31PM -0700, Junio C Hamano wrote:
>
>> * jk/stash-list-p (2014-07-30) 7 commits
>>  - SQUASH??? future-proof, log --cc should imply -p without being told
>>  - stash: show combined diff with "stash show"
>>  - stash: default listing to "--cc --simplify-combined-diff"
>>  - add --simplify-combined-diff option
>>  - pretty: make empty userformats truly empty
>>  - pretty: treat "--format=" as an empty userformat
>>  - revision: drop useless string offset when parsing "--pretty"
>> 
>>  Teach "git stash list -p" to DWIM to "git stash list -p --cc", with
>>  even nicer twist to collapse combined diff from identical two
>>  parents into a regular diff.
>
> What do you want to do with this topic?
>
> I think we want to drop the "stash show" patch, based on the discussion
> we had.  The first three patches are nominally prep for that final
> patch, but actually are things I've often wanted over the years. I'd be
> glad if they made it in separately, but there were some compatibility
> questions.

I am not sure what compatibility you are worried about.  The empty
format one looks like a pure bugfix to me, and I agree that they
are good changes regardless of the remainder of the series.

> As clever as I find the --simplify-combined-diff patch, I think we came
> to the conclusion that "--first-parent" is probably the reasonable
> choice. It matches "stash show", and it's simple and obvious. Do we just
> want a patch to specify "--first-parent" to stash-log? That would make
> "-p" just work. The only downside is that there isn't a good way to turn
> it off.

Perhaps we can add --no-first-parent to countermand it?

> Is it enough to say "if you want to do something clever, use
> git-log"?

> Or do we want to scrap the whole thing and try to update the
> documentation to make it more clear why "-p" by itself doesn't do
> anything?

The latter is the most conservative, but it may be too conservative
to be useful ;-).  Unless we stop advertising that "stash list" is a
thin wrapper around "log -g" with options that would be useful to
view the stash, which is a strange ref with useful reflog entries,
the "--first-parent" approach would be the most sensible, I would
say.  If we can dissociate "stash list" from "log" (in other words,
the set of options "stash list" takes does not have anything to do
with the underlying "log", even though both may have "-p" to tell
them to give patches, etc.), it would be a totally different matter,
and it might give us a better future, but I suspect it might be a
bit too late for that.





--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html




[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]