From: Peter Baumann <siprbaum@stud•informatik.uni-erlangen.de>
To: Carl Worth <cworth@cworth•org>
Cc: Junio C Hamano <junkio@cox•net>, git@vger•kernel.org
Subject: Re: Importing from tarballs; add, rm, update-index?
Date: Sat, 13 Jan 2007 17:48:11 +0100 [thread overview]
Message-ID: <20070113164811.GC4825@xp.machine.xx> (raw)
In-Reply-To: <87y7o6x60w.wl%cworth@cworth.org>
On Sat, Jan 13, 2007 at 08:09:35AM -0800, Carl Worth wrote:
> On Fri, 12 Jan 2007 16:48:09 -0800, Junio C Hamano wrote:
> > Peter Baumann <waste.manager@gmx•de> writes:
> >
> > > Yes. I fully second Linus opinion. But I think there should be
> > > a difference in adding completly new content to the index
> > > (number of entries in the index grows) or replacing content in
> > > the index.
> >
> > Huh?
>
> Here's an easy way to see the difference that Peter is trying to point
> out, (and it really has nothing to do with whether "git add" for a new
> file should add the content of that file to the index---that's a
> totally separate issue that Linus was talking about in that other
> message).
>
> Just look at "commit -a" and how its documented right now. Currently
> it's documented as doing an automatic "add" to all known files. That
> descriptions is unsatisfactory for two reasons:
>
> 1. "commit -a" will also commit the removal of files---which requires
> an index modification that "git add" cannot do
>
> 2. "add" can cause an entirely new path (with content, Vader!) to be
> added to the index. So the user has to carefully separate out this
> behavior of "add" to properly understand what "commit -a" is
> doing. The documentation tries to help here with "known files", but
> the talk of an "automatic 'add'" that never adds any new paths
> really goes against the primary functionality of "git add".
>
> I say "primary functionality" because the 'commit -a' workflow,
> (which we've all agreed should be the thing that is taught first),
> requires users to use 'git add' when adding a new path to the
> index, but never requires the user to use the 'update the index'
> sense of 'git add', (instead, the user just needs to _learn_ this
> sense to understand commit -a).
>
> So there's lots of room for potential confusion there, and we've got
> evidence of that confusion in the messages that started this an other
> recent threads about how to remove files.
>
> I like the idea of adding a porcelain command for update-index, and
> it's nice to try to describe "commit -a" in terms of the new porcelain
> command. But, to make that really work, I think that porcelain for
> update-index should really match the semantics needed by "commit
> -a". That is, it should never add new paths to the index, but it
> should update content for existing paths, and it should remove paths
> >from the index when files have been removed from the working tree.
>
> Let's call this new command "refresh", just to experiment with another
> name. If it existed, then "commit -a" could be described as simply
> doing "refresh" on all files, (with no need to have a notion of
> "tracked files", nor any extra language about file removal). That is,
> "commit -a" could be understood as something like:
>
> git refresh -a
> git commit
>
> (or maybe "git refresh .; git commit" if one prefers that, but I think
> it'd be nice to carry the -a option over to the new porcelain).
>
> Also, this would even make it possible to provide an accurate
> index-based description of "commit paths...". Namely, something like:
>
> commit paths...
>
> This command starts with a new index initialized from the
> contents of the current commit (HEAD). It then performs the
> following commands:
>
> git refresh paths...
> git commit
>
> [Some extra language needed here about restoring into the
> index other changes that were "skipped over".]
>
> So, someone might like to have that kind of description somewhere in
> the technical documentation of git. (I'd still prefer to see "commit
> paths..." documented as simply "commits the working-tree content of
> all specified paths").
>
> Anyway, did I succeed in pointing out why some of us think that the
> "add a new path (with content) to the index" and the "update content
> for existing path" really shouldn't be mixed up in the same "add"
> command?
>
Yes. At least for me :-)
-Peter
> -Carl
next prev parent reply other threads:[~2007-01-13 16:47 UTC|newest]
Thread overview: 45+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-01-12 13:41 Importing from tarballs; add, rm, update-index? Chris Riddoch
2007-01-12 14:09 ` Horst H. von Brand
2007-01-12 14:39 ` Johannes Sixt
2007-01-12 15:39 ` Horst H. von Brand
2007-01-12 14:40 ` Morten Welinder
2007-01-12 18:47 ` Junio C Hamano
2007-01-12 19:11 ` Peter Baumann
2007-01-12 19:43 ` Junio C Hamano
2007-01-12 21:04 ` Peter Baumann
2007-01-13 0:48 ` Junio C Hamano
2007-01-13 9:33 ` Peter Baumann
2007-01-13 11:17 ` Johannes Schindelin
2007-01-13 16:19 ` Peter Baumann
2007-01-13 16:27 ` Julian Phillips
2007-01-13 18:01 ` Junio C Hamano
2007-01-13 16:09 ` Carl Worth
2007-01-13 16:45 ` Brian Gernhardt
2007-01-13 16:48 ` Peter Baumann [this message]
2007-01-13 18:54 ` Nicolas Pitre
2007-01-13 19:32 ` Carl Worth
2007-01-13 20:25 ` Junio C Hamano
2007-01-13 20:29 ` Nicolas Pitre
2007-01-13 6:36 ` Brian Gernhardt
2007-01-13 9:36 ` Peter Baumann
2007-01-13 16:31 ` Brian Gernhardt
2007-01-13 18:15 ` Alan Chandler
2007-01-13 19:31 ` Brian Gernhardt
2007-01-13 20:34 ` Shawn O. Pearce
2007-01-14 12:42 ` Johannes Schindelin
2007-01-14 22:42 ` Shawn O. Pearce
2007-01-14 23:49 ` Horst H. von Brand
2007-01-15 1:06 ` Junio C Hamano
2007-01-15 1:12 ` Shawn O. Pearce
2007-01-15 22:46 ` Daniel Barkalow
2007-01-16 0:34 ` Horst H. von Brand
2007-01-16 3:35 ` Daniel Barkalow
2007-01-16 12:12 ` Christian MICHON
2007-01-16 0:51 ` Jakub Narebski
2007-01-13 21:41 ` Horst H. von Brand
2007-01-13 21:47 ` Shawn O. Pearce
2007-01-13 22:04 ` Horst H. von Brand
2007-01-12 19:34 ` Carl Worth
2007-01-12 23:28 ` Johannes Schindelin
2007-01-13 0:01 ` Junio C Hamano
2007-01-12 20:20 ` Jakub Narebski
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=20070113164811.GC4825@xp.machine.xx \
--to=siprbaum@stud$(echo .)informatik.uni-erlangen.de \
--cc=cworth@cworth$(echo .)org \
--cc=git@vger$(echo .)kernel.org \
--cc=junkio@cox$(echo .)net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
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