Re: [PATCH] fmt-patch: understand old <his> notation

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

 



Hi,

On Sat, 6 May 2006, Junio C Hamano wrote:

> Johannes Schindelin <Johannes.Schindelin@xxxxxx> writes:
> 
> > When calling "git fmt-patch HEAD~5", you now get the same as if you would
> > have said "git fmt-patch HEAD~5..". This makes it easier for my fingers
> > which are so used to the old syntax.
> 
> While this would be easier on _my_ fingers as well, I have a
> suspicion that it might make more sense to make this "single
> ref" case to mean "HEAD~5^..HEAD~5" (if we _were_ designing a
> new command that is called format-patch today, that would be
> more natural).  But probably it is too late to break it by now.

No, it is not too late. I did this patch only to prevent cluttering my 
directory with millions of patches, only because I forgot _again_ to type 
the two dots.

> > 	I wonder: would it make sense to make add_pending_object() and 
> > 	get_reference() in revision.c non-static?
> 
> I'd rather not expose such revision.c internals too much.  An
> alternative approach would be to give instruction to revision.c
> (read: another flag like rev.no_walk) to tell it to do something
> special when the user has only one commit, but I think what you
> did in your patch is cleaner and sufficient.

I just stole the function add_head() from builtin-diff.c, but that feels 
wrong. I think adding a pending object should not be internal to 
revision.c.

> Also we probably would want to default the diff options to show
> the root commit diff (rev.show_root_diff).

I gather this is needed for git-am/git-rebase to continue working?

Ciao,
Dscho

-
: 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]