From: Andreas Ericsson <ae@op5.se>
To: Junio C Hamano <junkio@cox.net>
Cc: Paul Jakma <paul@clubi.ie>,
git@vger.kernel.org, Linus Torvalds <torvalds@osdl.org>
Subject: Re: seperate commits for objects already updated in index?
Date: Wed, 15 Mar 2006 15:00:30 +0100 [thread overview]
Message-ID: <44181DFE.7080204@op5.se> (raw)
In-Reply-To: <7vy7zcie5c.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano wrote:
> The background behind this is around beginning of February 2006,
> the thread "Two ideas" by Carl Worth. And the current behaviour
> is defined by this commit. I'll talk about a possible
> improvement but first, here is what it does:
>
> commit 130fcca63fe8e7e087e7419907e018cbbaf434a3
> Author: Junio C Hamano <junkio@cox.net>
> Date: Sun Feb 5 00:07:44 2006 -0800
>
>
> 2. refuses to run if named paths... are different in HEAD and
> the index (ditto about reminding). Added paths are OK.
>
>
> The check that prevents you from doing
>
> $ edit A B
> $ git update-index A B
> $ git commit -o B
>
> is the rule #2, which I think could use further improvement. It
> is to address the "committing skewed files" issue Carl brought
> up in that thread.
>
> It might be better to further check if the working tree file is
> the same as the index, and to allow a commit in such a case.
>
> The intent of rule #2 is to prevent this from happening:
>
> $ edit A B
> $ git update-index A B
> $ edit B again
> $ git commit -o B
>
> When this happens, the real index will have _old_ contents of B
> that never was committed, and does not match what is in the
> index. But after the commit, we will match the real index to
> what was committed, so we will _lose_ the index entry for B
> before the second edit you explicitly told git to remember by
> saying 'update-index'.
>
Can't this be done by updating .git/index first and then use the
temporary index to commit? Then .git/index would match the current tree
and everybody would be happy with very little tweaking. Doing the
temporary index commit first could cause data-loss as described above if
the updating of .git/index somehow fails and the user is unaware of it
(or what to do to fix it).
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
next prev parent reply other threads:[~2006-03-15 14:00 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-03-14 16:37 seperate commits for objects already updated in index? Paul Jakma
2006-03-14 17:00 ` Linus Torvalds
2006-03-14 17:04 ` Paul Jakma
2006-03-14 17:20 ` Linus Torvalds
2006-03-14 17:27 ` Paul Jakma
2006-03-14 23:51 ` Junio C Hamano
2006-03-15 3:24 ` Junio C Hamano
2006-03-15 13:28 ` Paul Jakma
2006-03-15 14:00 ` Andreas Ericsson [this message]
2006-03-15 19:25 ` Junio C Hamano
2006-03-15 19:43 ` Andreas Ericsson
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
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=44181DFE.7080204@op5.se \
--to=ae@op5.se \
--cc=git@vger.kernel.org \
--cc=junkio@cox.net \
--cc=paul@clubi.ie \
--cc=torvalds@osdl.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
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
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 NNTP newsgroup(s).