git@vger.kernel.org list mirror (unofficial, one of many)
 help / color / mirror / Atom feed
From: Junio C Hamano <gitster@pobox.com>
To: Edmundo Carmona Antoranz <eantoranz@gmail.com>
Cc: Git List <git@vger.kernel.org>
Subject: Re: [PATCH] [RFC PATCH] stash save/push: add --index-only option
Date: Thu, 13 Feb 2020 08:55:17 -0800
Message-ID: <xmqqr1yys9ze.fsf@gitster-ct.c.googlers.com> (raw)
In-Reply-To: <CAOc6etYA79mTHB595cCVphmYmFECYvgPgV09SNo-pdEPEVD37w@mail.gmail.com> (Edmundo Carmona Antoranz's message of "Thu, 13 Feb 2020 07:21:54 -0600")

Edmundo Carmona Antoranz <eantoranz@gmail.com> writes:

> Fair enough. It's ok to explain here, right?

Yes, absolutely.   How it works is 

 - an author comes up with a patch and its explanation and
   justificaiton, 

 - reviewers ask clarifications on what was unclear, point out what
   was wrong in the code, etc., and then 

 - the author responds with "here is what I meant", "yeah, you're
   right that the code is wrong--would it be right to write it this
   way?", and/or "not really, the code is OK because ...", etc.

All that exchange is to come up with a more polished version that
has correct code that is explained and justified in a clear manner.

The next iteration the author then sends would of course include the
fixes to bugs pointed out during the review, but also would explain
and justify the change better---the explanation in the original did
not convey what the author wanted to tell, but the explanation the
author gave during the review discussion did so better, so the new
iteration can learn from that exchange.

> There's no simple way to stash only
> what you have on index while retaining your working tree state.

Yes, that much can be inferred from what it does ("there is no easy
way to do X, so I am adding X").

The question is why would one want to do X in the first place.

IIUC, the simplest workflow using the new feature may go like this:

	$ edit file ;# edit a bit
	$ git add file
	$ edit file ;# even even more
	$ git stash --cached

After all of the above is done, "git stash list" may show that there
is a single stash that records the changes you made to the file
right after you added it, without your further changes (because you
are taking what is in the index).  Your working tree has all the
changes you made to file, both before and after "git add", and your
index is clean.

After you got yourself into this state where your index is clean,
your working tree file has all changes, and your stash entry has
only the earlier half of the change, what are you going to do with
that stash entry?  If we learn the answer to that question, perhaps
we may find (or we may even have) a better or easier way to achieve
whatever you were planning to do with that stash entry by some other
means---it might not even involve "git stash"---but without knowing
that, we cannot tell if the new feature is a good idea.

Thanks.

  reply	other threads:[~2020-02-13 16:55 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-02-12 23:50 Edmundo Carmona Antoranz
2020-02-12 23:52 ` Edmundo Carmona Antoranz
2020-02-13  5:04   ` Junio C Hamano
2020-02-13 13:21     ` Edmundo Carmona Antoranz
2020-02-13 16:55       ` Junio C Hamano [this message]
2020-02-13 17:12         ` Edmundo Carmona Antoranz

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: http://vger.kernel.org/majordomo-info.html

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=xmqqr1yys9ze.fsf@gitster-ct.c.googlers.com \
    --to=gitster@pobox.com \
    --cc=eantoranz@gmail.com \
    --cc=git@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link

git@vger.kernel.org list mirror (unofficial, one of many)

This inbox may be cloned and mirrored by anyone:

	git clone --mirror https://public-inbox.org/git
	git clone --mirror http://ou63pmih66umazou.onion/git
	git clone --mirror http://czquwvybam4bgbro.onion/git
	git clone --mirror http://hjrcffqmbrq6wope.onion/git

	# If you have public-inbox 1.1+ installed, you may
	# initialize and index your mirror using the following commands:
	public-inbox-init -V1 git git/ https://public-inbox.org/git \
		git@vger.kernel.org
	public-inbox-index git

Example config snippet for mirrors.
Newsgroups are available over NNTP:
	nntp://news.public-inbox.org/inbox.comp.version-control.git
	nntp://ou63pmih66umazou.onion/inbox.comp.version-control.git
	nntp://czquwvybam4bgbro.onion/inbox.comp.version-control.git
	nntp://hjrcffqmbrq6wope.onion/inbox.comp.version-control.git
	nntp://news.gmane.io/gmane.comp.version-control.git
 note: .onion URLs require Tor: https://www.torproject.org/

code repositories for the project(s) associated with this inbox:

	https://80x24.org/mirrors/git.git

AGPL code for this site: git clone https://public-inbox.org/public-inbox.git