git@vger.kernel.org list mirror (unofficial, one of many)
 help / color / mirror / Atom feed
* Issue with staging, unstaging, discarding hunks with no context
       [not found] <CAFfHKJ7kAJ7030GPywKHEWG0vJjC0hhEGt4MMR=85nSHnu5Q-w@mail.gmail.com>
@ 2020-10-18  5:48 ` Daniel Dinnyes
  2020-10-18  9:12   ` Phillip Wood
  0 siblings, 1 reply; 2+ messages in thread
From: Daniel Dinnyes @ 2020-10-18  5:48 UTC (permalink / raw)
  To: git

The problem I have is described in more detail in the issue here with magit:
https://github.com/magit/magit/issues/4222

The conclusion there was that this is an upstream problem due to some
recent changes in git.

As it has been mentioned in the issue itself, it is understood that
git had problems with handling hunks without context, so I assume this
upstream change was to eliminate such issues.

Yet my experience was that hunks without context worked fine before
80% of the time, except if they were right next to each other, they
might get mixed/messed up. Even in that case, I found that if I
staged/unstaged hunks in top-down order in magit it didn't cause
problems.

Without handling no-context hunks, I see I will have to stash/redo
entire change-sets, to be able to commit logically separate hunks
separately. This would be a major PITA.

Is there a plan to reintroduce handling of hunks with 0 line context
in the future, or is this something which is technically not going to
be possible ever?

Cheers,
Dan

^ permalink raw reply	[flat|nested] 2+ messages in thread

* Re: Issue with staging, unstaging, discarding hunks with no context
  2020-10-18  5:48 ` Issue with staging, unstaging, discarding hunks with no context Daniel Dinnyes
@ 2020-10-18  9:12   ` Phillip Wood
  0 siblings, 0 replies; 2+ messages in thread
From: Phillip Wood @ 2020-10-18  9:12 UTC (permalink / raw)
  To: Daniel Dinnyes, git

Hi Daniel

On 18/10/2020 06:48, Daniel Dinnyes wrote:
> The problem I have is described in more detail in the issue here with magit:
> https://github.com/magit/magit/issues/4222
> 
> The conclusion there was that this is an upstream problem due to some
> recent changes in git.

That's not my reading of that issue. Specifically this comment by kyleam

     You're blaming the wrong git :) I introduced this change with
     6b3c90d (magit-apply-patch: Abort when there is no context,
     2019-08-02). It was prompted by gh-3924, which also brought
     about d508f02 (apply: Adjust hunk line positions for partial
     application, 2019-07-28).

Seems to point to this being a change in magit not git.

`git apply --unidiff-zero` will apply zero context patches but as a 
safety measure they will be rejected without `--unidiff-zero`

Best Wishes

Phillip

> As it has been mentioned in the issue itself, it is understood that
> git had problems with handling hunks without context, so I assume this
> upstream change was to eliminate such issues.
> 
> Yet my experience was that hunks without context worked fine before
> 80% of the time, except if they were right next to each other, they
> might get mixed/messed up. Even in that case, I found that if I
> staged/unstaged hunks in top-down order in magit it didn't cause
> problems.
> 
> Without handling no-context hunks, I see I will have to stash/redo
> entire change-sets, to be able to commit logically separate hunks
> separately. This would be a major PITA.
> 
> Is there a plan to reintroduce handling of hunks with 0 line context
> in the future, or is this something which is technically not going to
> be possible ever?
> 
> Cheers,
> Dan
> 

^ permalink raw reply	[flat|nested] 2+ messages in thread

end of thread, other threads:[~2020-10-18  9:13 UTC | newest]

Thread overview: 2+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
     [not found] <CAFfHKJ7kAJ7030GPywKHEWG0vJjC0hhEGt4MMR=85nSHnu5Q-w@mail.gmail.com>
2020-10-18  5:48 ` Issue with staging, unstaging, discarding hunks with no context Daniel Dinnyes
2020-10-18  9:12   ` Phillip Wood

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