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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.