git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
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

  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).