git@vger.kernel.org mailing list mirror (one of many)
 help / color / mirror / code / Atom feed
From: Linus Torvalds <torvalds@linux-foundation.org>
To: Junio C Hamano <gitster@pobox.com>
Cc: Jeff King <peff@peff.net>, Graham Perks <gperks@ausperks.net>,
	Git List <git@vger.kernel.org>
Subject: Re: Am able to delete a file with no trace in the log
Date: Wed, 3 Jun 2009 15:17:49 -0700 (PDT)	[thread overview]
Message-ID: <alpine.LFD.2.01.0906031504080.4880@localhost.localdomain> (raw)
In-Reply-To: <7v8wk96knh.fsf@alter.siamese.dyndns.org>



On Wed, 3 Jun 2009, Junio C Hamano wrote:

> Linus Torvalds <torvalds@linux-foundation.org> writes:
> 
> > The original problem was:
> >
> >  - create new file 'x' in branch 'a'
> >
> >  - merge branch 'a' into branch 'b', but because of a merge conflict and 
> >    confurion in the merge, the merge result doesn't contain 'x' any more.
> >
> >  - try to find out what happened to 'x' after-the-fact.
> >
> > Try it. Git really doesn't make it very easy, because git will notice that 
> > 'x' didn't exist before the branch either (in branch 'b'), so there will 
> > be _no_ sign of 'x' actually going away.
> 
> That is true.  The "crude attempt" patch I just sent actually catches
> this, but it does not show the lossage of "new" in the "diff/diffstat"
> part of the merge, when run with "git log --stat -- x".  Besides, it shows
> too many other uninteresting "merged two branches, resolving to lossage of
> the path the same way as all the previous merges" to be really useful.

Yes.

Thinking more about it, we always did have fairly good workarounds for the 
"we optimized away the history too aggressively" (ie the original 
--full-history, and then the newer and nicer --simplify-merges).

So I'm starting to suspect that I was just wrong in looking at the 
revision history simplification. Yes, that can cause simplification that 
we don't want, but on the other hand, it's reasonably easy to work around.

Maybe what we want is a better model for showing diffs from merges.

For example, right now there is _no_ way to get even a "show diff relative 
to first parent". You can do "-m", which will show it relative to _both_ 
parents, but nobody ever wants that. And you can do "-c" or "--cc", but 
that simplifies away all the paths that match in one. 

So here's a challenge: in the git repository, get a nice view of what your 
merges looked like. The closest I can get is

	git log -c --stat --grep="Merge branch '"

which is actually very non-intuitive ("-c" on its own gives no useful 
output, but "-c --stat" gives nice diffstat against the first parent, 
which in this case is what we want).

But I can't actually get git to generate the _patch_ that the --stat 
describes. You'd have to do something like

	git rev-list --parents --grep="Merge branch '" HEAD |
		while read a b c; do git show -s $a ; git diff $b..$a; done | less -S

which is pretty ugly.

			Linus

  reply	other threads:[~2009-06-03 22:19 UTC|newest]

Thread overview: 26+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-06-02 19:33 Am able to delete a file with no trace in the log Graham Perks
2009-06-02 20:29 ` Tony Finch
2009-06-02 21:34 ` Jeff King
2009-06-02 21:55   ` Linus Torvalds
2009-06-03  0:47     ` Sitaram Chamarty
2009-06-03  1:20       ` Linus Torvalds
2009-06-03  1:34     ` Clean up and simplify rev_compare_tree() Linus Torvalds
2009-06-03  1:57     ` Am able to delete a file with no trace in the log Junio C Hamano
2009-06-03  3:03       ` Linus Torvalds
2009-06-03 21:18         ` Junio C Hamano
2009-06-03 21:26           ` Linus Torvalds
2009-06-03 21:33           ` Linus Torvalds
2009-06-03 21:59             ` Avery Pennarun
2009-06-03 22:02             ` Junio C Hamano
2009-06-03 22:17               ` Linus Torvalds [this message]
2009-06-03 22:38                 ` Junio C Hamano
2009-06-03 22:44                   ` Jeff King
2009-06-03 22:56                     ` Linus Torvalds
2009-06-03 23:06                       ` Jeff King
2009-06-03 23:27                         ` Linus Torvalds
2009-06-03 23:37                           ` Jeff King
2009-06-04  1:58                             ` Linus Torvalds
2009-06-04  6:57                       ` Junio C Hamano
2009-06-03 22:47                   ` Linus Torvalds
2009-06-03 22:56                 ` Junio C Hamano
2009-06-03 21:55         ` Junio C Hamano

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=alpine.LFD.2.01.0906031504080.4880@localhost.localdomain \
    --to=torvalds@linux-foundation.org \
    --cc=git@vger.kernel.org \
    --cc=gitster@pobox.com \
    --cc=gperks@ausperks.net \
    --cc=peff@peff.net \
    /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
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

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

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).