Re: [PATCH 4/6] stash: introduce 'git stash store'

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

 



Junio C Hamano wrote:
> I however suspect that you would regret later when you need more
> customization.  It already happened once for "git merge" when it was
> an internal API for "git pull" and it was painful to support saner
> interface and the traditional one at the same time [*1*].

Oh god.

  git-merge --stat --progress "$merge_name" HEAD 04c5b83c46760573

We made a design mistake at the command-level in merge.  This is at a
subcommand-level.

1. Will git stash store ever be more than a one-liner?  Can you think
of how this function could be larger?

2. Will git stash store ever become an interactive command?  Isn't the
whole point of interactive stash something that operates on a
worktree?  Why will I ever want to operate on a commit with stash,
interactively?

While it is absolutely necessary to avoid calamities like the merge
invocation in git-pull.sh, we shouldn't be over-engineering either.
--
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]