Re: [PATCH 1/3] diff options: Introduce --ignore-submodules
- From
Johannes Schindelin <johannes.schindelin@gmx.de>
- Date
- May 14, 2008, 18:42 UTC
- Message-ID
- <alpine.DEB.1.00.0805141940460.30431@racer>
- In-Reply-To
- <7vbq38oi3j.fsf@gitster.siamese.dyndns.org>
Hi,
On Wed, 14 May 2008, Junio C Hamano wrote:
Show 14 quoted lines
> Johannes Schindelin <Johannes.Schindelin@gmx.de> writes: > > > @@ -3355,6 +3357,9 @@ void diff_addremove(struct diff_options *options, > > char concatpath[PATH_MAX]; > > struct diff_filespec *one, *two; > > > > + if (DIFF_OPT_TST(options, IGNORE_SUBMODULES) && S_ISGITLINK(mode)) > > + return; > > + > > /* This may look odd, but it is a preparation for > > * feeding "there are unchanged files which should > > * not produce diffs, but when you are doing copy > > So both removal and addition of a submodule is an uninteresting event.
Yes.
Show 14 quoted lines
> > @@ -3399,6 +3404,10 @@ void diff_change(struct diff_options *options, > > char concatpath[PATH_MAX]; > > struct diff_filespec *one, *two; > > > > + if (DIFF_OPT_TST(options, IGNORE_SUBMODULES) && S_ISGITLINK(old_mode) > > + && S_ISGITLINK(new_mode)) > > + return; > > And a submodule changing from revision A to B is uninteresting. > > Is it interesting if something that used to be a blob turns into a > submodule, or vice versa? The code says it is, but I think it would be > more convenient to treat it as a removal of blob and addition of a > submodule.
The point is: for the sake of a script (which wants to ignore submodules) asking if there is a diff, I think it makes sense to not ignore those changes. IOW I think my patch is enough for the purpose of getting stash/rebase to behave.
Ciao, Dscho