git@vger.kernel.org mailing list mirror (one of many)
 help / color / mirror / code / Atom feed
From: Duy Nguyen <pclouds@gmail.com>
To: Jeff King <peff@peff.net>
Cc: Jacob Keller <jacob.keller@gmail.com>,
	Junio C Hamano <gitster@pobox.com>,
	Git Mailing List <git@vger.kernel.org>,
	Jonathan Nieder <jrnieder@gmail.com>,
	Eric Sunshine <sunshine@sunshineco.com>
Subject: Re: [PATCH v2 0/1] Make 'git commit' not accidentally lose staged content
Date: Wed, 19 Sep 2018 18:12:23 +0200	[thread overview]
Message-ID: <CACsJy8A3QCYY6QeJQYkbCKYh=7Q7pj=rer_OQHLGoAMqTNomNA@mail.gmail.com> (raw)
In-Reply-To: <20180918231903.GA30695@sigill.intra.peff.net>

On Wed, Sep 19, 2018 at 1:19 AM Jeff King <peff@peff.net> wrote:
>
> On Tue, Sep 18, 2018 at 12:36:06PM -0700, Jacob Keller wrote:
>
> > > I like that, too. It's a little more costly just because it may involve
> > > object-db writes, but I think in most cases it would be fine. I almost
> > > always "git stash" away discarded changes these days instead of "git
> > > reset --hard", because it effectively provides this kind of log.
> >
> > Obviously we do eventually turn the index into a tree, which is used
> > by the commit. Would it be possible to simply somehow store these
> > trees, and have commands which blow the tree away simply instead, save
> > it? I'm not sure how costly that is.
>
> For an up-to-date index with the cache-tree extension, this should be
> pretty cheap.  Even for a partially-staged index, where we already have
> the blob in the object database, it should just incur the tree
> computation (and parts you didn't touch would hopefully have an
> up-to-date cache-tree).

Just FYI. I wanted to get at least pruning support in place before
posting another RFC. But right now I'm going without cache-tree.
Whenever a file is updated, the _blob_ hashes are recorded in the
index log (one line per update, same as reflog format) and the
description part of the line is the updated path.

This is simpler to do, and we can still reconstruct a tree/commit in
memory if we need to (but not whole tree snapshots; but I don't think
that would be very useful). But maybe cache-tree approach is better.
We will see.
-- 
Duy

  reply	other threads:[~2018-09-19 16:12 UTC|newest]

Thread overview: 28+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-08-20 15:41 [PATCH/RFC] commit: new option to abort -a something is already staged Nguyễn Thái Ngọc Duy
2018-08-20 15:55 ` Junio C Hamano
2018-08-20 17:48 ` Eric Sunshine
2018-08-20 19:30 ` Jonathan Nieder
2018-08-21 14:43   ` Duy Nguyen
2018-08-23  2:11     ` Jonathan Nieder
2018-08-23  2:15       ` Jonathan Nieder
2018-08-23 14:49         ` Duy Nguyen
2018-08-23 15:28           ` Junio C Hamano
2018-08-24  3:02             ` Jacob Keller
2018-08-24 14:42               ` Duy Nguyen
2018-08-24 23:23                 ` Jacob Keller
2018-08-24  2:59 ` Jacob Keller
2018-09-16  6:31 ` [PATCH v2 0/1] Make 'git commit' not accidentally lose staged content Nguyễn Thái Ngọc Duy
2018-09-16  6:31   ` [PATCH v2 1/1] commit: do not clobber the index Nguyễn Thái Ngọc Duy
2018-09-17 17:09   ` [PATCH v2 0/1] Make 'git commit' not accidentally lose staged content Junio C Hamano
2018-09-17 17:29     ` Duy Nguyen
2018-09-17 18:15       ` Jeff King
2018-09-17 18:41         ` Duy Nguyen
2018-09-18 17:35           ` Jeff King
2018-09-18 19:36         ` Jacob Keller
2018-09-18 23:19           ` Jeff King
2018-09-19 16:12             ` Duy Nguyen [this message]
2018-09-19 16:16               ` Jeff King
2018-09-17 19:26       ` Junio C Hamano
2018-09-18 19:41         ` Jacob Keller
2018-09-18 21:11           ` Eckhard Maaß
2018-09-18 19:33     ` Jacob Keller

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='CACsJy8A3QCYY6QeJQYkbCKYh=7Q7pj=rer_OQHLGoAMqTNomNA@mail.gmail.com' \
    --to=pclouds@gmail.com \
    --cc=git@vger.kernel.org \
    --cc=gitster@pobox.com \
    --cc=jacob.keller@gmail.com \
    --cc=jrnieder@gmail.com \
    --cc=peff@peff.net \
    --cc=sunshine@sunshineco.com \
    /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).