* Re: Some ideas for StGIT
From: Shawn O. Pearce @ 2007-08-05 2:31 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git
In-Reply-To: <f934ve$3oi$1@sea.gmane.org>
Jakub Narebski <jnareb@gmail.com> wrote:
> Shawn O. Pearce wrote:
>
> > (Regarding the performance, cherry-picking 55 patches is
> > slow, especially when many of them would apply trivially with
> > git-diff|git-apply --index. Be nice to improve that in 1.5.4.)
>
> Perhaps in the future you would be able to use -i/--interactive mode
> in merge driven git-rebase (git rebase --merge -i <base>), which I think
> should be faster.
Heh. You're talking to someone who actually knows what he is talking
about here, and was actually involved in some of these tools...
Let me fill the reader in on what's really happening...
`git-rebase` (non -i, non -m) uses `format-patch|am` to apply the
changes of each commit it is rebasing. This is insanely fast as
builtin diff and apply routines are quite efficient. It sometimes
fails due to patches not applying cleanly. In those cases you
have to either hand edit the patch, apply and continue the rebase,
or abort the rebase and restart with the -m flag so it uses a full
three-way file merge.
`git-rebase -m` (aka --merge) uses git-merge-recursive to apply the
changes of each commit it is rebasing. (That's the merge part!)
However merge-recursive usually takes longer to run then the above
`format-patch|am` pipeline, and that is why -m is not the default.
But it does handle cases `format-patch|am` cannot do automatically.
For quite a long time now both `git-revert` and `git-cherry-pick`
(which are actually the same program!) have also been using
git-merge-recursive as their implementation to revert or apply the
commit's change. This allows them to perform changes that also
involve renames, as well as to apply some changes that might fail
as a patch but succeed when done as a three-way file merge.
So really `revert`, `cherry-pick`, `rebase -m` (and also `am -3`
as it also uses merge-recursive) are all the same underlying
implementation. The major differences between them is what they
do *after* the changes have been applied, and which direction the
change goes (e.g. revert undoes the change).
Now the new `git-rebase -i` is really just a complicated loop around
`cherry-pick`. Really. Go look at the code, it never calls anything
except cherry-pick. So `rebase -i` is actually `rebase --merge -i`.
That's why its sluggish.
Why is merge-recursive sluggish? It does rename detection.
It does full three-way file merges, rather than just applying
a patch. It also tries to do a three-way read-tree before doing
file level merges. git-apply does none of these things, and is
faster because of it.
So that future you speak of above is today. Its also not faster,
its slower. Faster would be to do something like `format-patch|am -3`
so that merge-recursive is only invoked if git-apply was unable to
apply the patch automatically. Except we'd want to save the original
tree data so we can do proper rename detection when merge-recursive
is fired up.
--
Shawn.
^ permalink raw reply
* Re: [PATCH] git-gui: Added support for OS X right click
From: Shawn O. Pearce @ 2007-08-05 2:48 UTC (permalink / raw)
To: Jeff King; +Cc: Väinö Järvelä, git
In-Reply-To: <20070804074150.GA7738@coredump.intra.peff.net>
Jeff King <peff@peff.net> wrote:
> On Sat, Aug 04, 2007 at 03:33:21AM -0400, Shawn O. Pearce wrote:
>
> > My mutt-foo isn't very good. I tried to tell it utf-8, but I think
> > its ignoring me:
>
> Try looking at the send_charset config option; by default mutt will try
> to send us-ascii if possible. Also, should it be "utf-8"?
Thanks, that actually did the trick. This message might actually
arrive to you encoded in UTF-8. Not that it matters. ;-)
> > I just tried to reproduce it myself and I can't do whatever I did
> > before again now; it Just Works(tm). *sigh* No idea how I messed
> > the patch application up earlier, but I did.
>
> OK, given that I couldn't reproduce it either, we should perhaps chalk
> it up to cosmic rays.
Or more likely the gap between the keyboard and the chair (aka me).
I may have actually done something at one point to damage that mbox.
git-am ran anyway, but gave me a garbled author name. Always blame
the user, it probably really is his fault. ;-)
--
Shawn.
^ permalink raw reply
* Re: Some ideas for StGIT
From: Junio C Hamano @ 2007-08-05 3:32 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: Jakub Narebski, git
In-Reply-To: <20070805023130.GV20052@spearce.org>
"Shawn O. Pearce" <spearce@spearce.org> writes:
> So really `revert`, `cherry-pick`, `rebase -m` (and also `am -3`
> as it also uses merge-recursive) are all the same underlying
> implementation.
Minor factual correction. "am -3" uses merge-recursive *ONLY*
when patch does not apply, so it is often the best of both
worlds, as long as your changes do not involve renames. And
that is what the default rebase uses.
^ permalink raw reply
* git-diff new files (without using index)
From: Miles Bader @ 2007-08-05 3:42 UTC (permalink / raw)
To: git
One thing I often want to do is generate a complete diff of all changes,
including new/removed files.
If I add things to the index, I can use "git-diff --cached" to do it;
however I'd actually like to be able to do this _without_ updating the
index; in other words, any un-added new file as a change. As it is, the
"non-indexed" state seems kind of a second-class citizen, as you can
never have new files there (or rather, git will never really see them).
Is there anyway to do this currently? If not, maybe something like a
"git-diff -N" (mirroring diff's -N/--new-file option) option could be
added to do this?
Thanks,
-Miles
--
=====
(^o^;
(()))
*This is the cute octopus virus, please copy it into your sig so it can spread.
^ permalink raw reply
* way to automatically add untracked files?
From: Miles Bader @ 2007-08-05 3:31 UTC (permalink / raw)
To: git
One thing I often want to do is git-add all untracked files, and also
automatically git-rm all "disappeared" files (I keep my .gitignore files
well maintained, so the list of adding/missing files shown by git status
is almost always correct). At the same time, I usually want to do "git
add -u" to git-add modified files.
One way to do this seems to be just "git add .", but I'm always slightly
nervous using it because it sits there and churns the disk for an awful
long time (whereas "git status" is instantaneous). Is this the right
thing to do? Is there something funny causing the churning?
Thanks,
-Miles
--
Saa, shall we dance? (from a dance-class advertisement)
^ permalink raw reply
* Re: git-diff new files (without using index)
From: Shawn O. Pearce @ 2007-08-05 3:52 UTC (permalink / raw)
To: Miles Bader; +Cc: git
In-Reply-To: <87wswalkad.fsf@catnip.gol.com>
Miles Bader <miles@gnu.org> wrote:
> One thing I often want to do is generate a complete diff of all changes,
> including new/removed files.
>
> If I add things to the index, I can use "git-diff --cached" to do it;
> however I'd actually like to be able to do this _without_ updating the
> index; in other words, any un-added new file as a change. As it is, the
> "non-indexed" state seems kind of a second-class citizen, as you can
> never have new files there (or rather, git will never really see them).
Use a temporary index:
(export GIT_INDEX_FILE=.git/tempindex;
cp .git/index $GIT_INDEX_FILE;
git add new-file;
git add other-new-file;
git diff --cached)
We pull this trick sometimes in internal tools, when we want to
produce some result but aren't sure we want to keep the resulting
index, or really know we don't want to keep the resulting index.
Another option is to just add everything, then reset the index:
git add new-file
git add other-new-file
git diff --cached
git reset
Granted if you had other files staged they just became unstaged
and will need to be restaged... the temporary index trick above
avoids that.
--
Shawn.
^ permalink raw reply
* Re: way to automatically add untracked files?
From: Shawn O. Pearce @ 2007-08-05 3:58 UTC (permalink / raw)
To: Miles Bader; +Cc: git
In-Reply-To: <873ayymzc1.fsf@catnip.gol.com>
Miles Bader <miles@gnu.org> wrote:
> One way to do this seems to be just "git add .", but I'm always slightly
> nervous using it because it sits there and churns the disk for an awful
> long time (whereas "git status" is instantaneous). Is this the right
> thing to do? Is there something funny causing the churning?
That's the correct way to add those new files that aren't ignored.
The problem is actually a small bug in git-add; we did not take the
obvious performance optimization of skipping files that are stat
clean in the index. So what is happening here during `git add .`
is we are reading and hashing every single file, even if it is
already tracked and is not modified. In short we're just working
harder than we need to during this operation.
I believe this has been fixed in git 1.5.3-rc3 or rc4. Not sure
which one; I don't have access to a git repository right now to
look it up.
--
Shawn.
^ permalink raw reply
* Re: git-diff new files (without using index)
From: Miles Bader @ 2007-08-05 4:00 UTC (permalink / raw)
To: git
In-Reply-To: <20070805035245.GE9527@spearce.org>
"Shawn O. Pearce" <spearce@spearce.org> writes:
>> If I add things to the index, I can use "git-diff --cached" to do it;
>> however I'd actually like to be able to do this _without_ updating the
>> index
>
> Use a temporary index:
...
> Another option is to just add everything, then reset the index:
...
> Granted if you had other files staged they just became unstaged
> and will need to be restaged... the temporary index trick above
> avoids that.
Thanks for the tip (I guess I can roll my own "git-diff-uncached"
script)!
The above sort of quirkiness does seem kind of a wart though; in my
(admittedly limited, using git) experience this sort of thing really
reduces the utility of the index, and I often end up feeling like it's
just getting in the way as a result. Does adding something like a
"git-diff -N" option seem a _bad_ idea?
Thanks,
-Miles
--
"Suppose He doesn't give a shit? Suppose there is a God but He
just doesn't give a shit?" [George Carlin]
^ permalink raw reply
* Re: way to automatically add untracked files?
From: Miles Bader @ 2007-08-05 4:00 UTC (permalink / raw)
To: git
In-Reply-To: <873ayymzc1.fsf@catnip.gol.com>
I previously wrote
> One thing I often want to do is git-add all untracked files, and also
> automatically git-rm all "disappeared" files
...
> One way to do this seems to be just "git add ."
Oh, also, "git add ." doesn't seem to do the right thing with
"dissapeared" files: If I do:
mv foo.cc bar.cc
git add .
then git-status will show a new file "bar.cc", but will list "foo.cc"
as "deleted " in the "Changed but not updated" section. Perhaps the
right thing will happen if I do "git-commit -a" (though I don't know,
I don't really want to try it), this still results in incorrect
"git-diff --cached" output (it shows bar.cc as a new file, not as a
rename of foo.cc).
Am I doing something wrong, or is this just missing functionality?
Thanks,
-Miles
--
Do not taunt Happy Fun Ball.
^ permalink raw reply
* Re: git-diff new files (without using index)
From: Shawn O. Pearce @ 2007-08-05 4:08 UTC (permalink / raw)
To: Miles Bader; +Cc: git
In-Reply-To: <87r6miljfr.fsf@catnip.gol.com>
Miles Bader <miles@gnu.org> wrote:
> Thanks for the tip (I guess I can roll my own "git-diff-uncached"
> script)!
Indeed, Git is quite scriptable. ;-)
> The above sort of quirkiness does seem kind of a wart though; in my
> (admittedly limited, using git) experience this sort of thing really
> reduces the utility of the index, and I often end up feeling like it's
> just getting in the way as a result. Does adding something like a
> "git-diff -N" option seem a _bad_ idea?
I'm not interested in such an option. Typically if I want a
diff on a new untracked file I actually want that file in my next
commit anyway. So I'm usually staging it into the index along with
everything else that I have modified. In which case this quirkiness
isn't really a quirk at all. Its just not an issue to me.
If you want to try adding it, go right ahead. The source for git
is stored in git and available from many places. :-)
--
Shawn.
^ permalink raw reply
* Re: way to automatically add untracked files?
From: Shawn O. Pearce @ 2007-08-05 4:13 UTC (permalink / raw)
To: Miles Bader; +Cc: git
In-Reply-To: <fc339e4a0708042100jdf0a0f1jd1fddfb5dc1c1052@mail.gmail.com>
Miles Bader <miles@gnu.org> wrote:
> I previously wrote
> > One thing I often want to do is git-add all untracked files, and also
> > automatically git-rm all "disappeared" files
> ...
> > One way to do this seems to be just "git add ."
>
> Oh, also, "git add ." doesn't seem to do the right thing with
> "dissapeared" files: If I do:
>
> mv foo.cc bar.cc
> git add .
Right. Who wants "add" to actually mean "add and delete"?
Shouldn't that be then called "git-add-and-rm"?
We recently talked about this on the mailing list and decided that
git-add shouldn't remove files that have disappeared, as doing so
might break most user's expections of what git-add does.
> then git-status will show a new file "bar.cc", but will list "foo.cc"
> as "deleted " in the "Changed but not updated" section. Perhaps the
> right thing will happen if I do "git-commit -a" (though I don't know,
> I don't really want to try it),
"git commit -a" will remove disappeared files. It has for quite
some time.
> this still results in incorrect
> "git-diff --cached" output (it shows bar.cc as a new file, not as a
> rename of foo.cc).
>
> Am I doing something wrong, or is this just missing functionality?
Try adding the -M option to "git-diff". That will enable the rename
detection, and show the rename you are looking to see.
--
Shawn.
^ permalink raw reply
* Re: way to automatically add untracked files?
From: Junio C Hamano @ 2007-08-05 4:13 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: Miles Bader, git
In-Reply-To: <20070805035854.GF9527@spearce.org>
"Shawn O. Pearce" <spearce@spearce.org> writes:
> I believe this has been fixed in git 1.5.3-rc3 or rc4.
That performance fix is in rc4.
^ permalink raw reply
* Re: git-diff new files (without using index)
From: Junio C Hamano @ 2007-08-05 4:20 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: Miles Bader, git
In-Reply-To: <20070805040841.GG9527@spearce.org>
"Shawn O. Pearce" <spearce@spearce.org> writes:
>> The above sort of quirkiness does seem kind of a wart though; in my
>> (admittedly limited, using git) experience this sort of thing really
>> reduces the utility of the index, and I often end up feeling like it's
>> just getting in the way as a result. Does adding something like a
>> "git-diff -N" option seem a _bad_ idea?
>
> I'm not interested in such an option. Typically if I want a
> diff on a new untracked file I actually want that file in my next
> commit anyway.
I suspect that it's probably half superstition and half disease
to wish for "diff /dev/null new-file". Even CVS got this one
right by saying "is a new file, no diff available". The
contents of that new file is available in "less new-file" near
you anyway and it is quite pointless while you are working
toward next commit. It just is not interesting, until you tell
git you _care_ about that file. And the way you tell git about
it is with "git add".
Learn to love the index, run "git-add" and view "git-diff HEAD".
^ permalink raw reply
* Re: way to automatically add untracked files?
From: Miles Bader @ 2007-08-05 4:22 UTC (permalink / raw)
To: git
In-Reply-To: <20070805041320.GH9527@spearce.org>
"Shawn O. Pearce" <spearce@spearce.org> writes:
>> mv foo.cc bar.cc
>> git add .
>
> Right. Who wants "add" to actually mean "add and delete"?
> Shouldn't that be then called "git-add-and-rm"?
"git-add ." can just as easily be thought as meaning "add the current
state of directory ".", including additions and removals"; removals,
are, after all, part of the directory's state.
>> Am I doing something wrong, or is this just missing functionality?
>
> Try adding the -M option to "git-diff". That will enable the rename
> detection, and show the rename you are looking to see.
No, it doesn't.
The problem seems to be not because git's rename detection isn't enabled
(I have it turned on by default in my globaing settings), but rather
because git hasn't been told about the removal.
And I don't see anyway to automatically tell git "please mark for
removal all files that seem to have disappeared" -- "git-add ." doesn't do
it, and git-rm doesn't seem to have any option for doing this.
Really I want a single command that just tells git "please add to the
index _all changes that you can find_".
Thanks,
-Miles
--
A zen-buddhist walked into a pizza shop and
said, "Make me one with everything."
^ permalink raw reply
* Re: way to automatically add untracked files?
From: Junio C Hamano @ 2007-08-05 4:23 UTC (permalink / raw)
To: Miles Bader; +Cc: git
In-Reply-To: <87lkcqlif2.fsf@catnip.gol.com>
Miles Bader <miles@gnu.org> writes:
> Really I want a single command that just tells git "please add to the
> index _all changes that you can find_".
"git add -u"
^ permalink raw reply
* Re: way to automatically add untracked files?
From: Miles Bader @ 2007-08-05 4:30 UTC (permalink / raw)
To: git
In-Reply-To: <7v8x8qip7n.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano <gitster@pobox.com> writes:
>> Really I want a single command that just tells git "please add to the
>> index _all changes that you can find_".
>
> "git add -u"
So, to _really_ add all changes, I should give two commands:
git add .
git add -u
?
(I tried combining them: "git add -u .", but that didn't seem to do
anything useful)
-Miles
--
o The existentialist, not having a pillow, goes everywhere with the book by
Sullivan, _I am going to spit on your graves_.
^ permalink raw reply
* Re: [ANNOUNCE] GIT 1.5.3-rc4
From: Linus Torvalds @ 2007-08-05 4:29 UTC (permalink / raw)
To: David Kastrup
Cc: Steven Grimm, Sam Ravnborg, Junio C Hamano, Ismail D?nmez, git
In-Reply-To: <85bqdndqgr.fsf@lola.goethe.zz>
On Sat, 4 Aug 2007, David Kastrup wrote:
> >
> > None that any normal user would want to use.
>
> Linus, do you really think that the editor _you_ use is used by more
> people than Emacs? Think again.
No.
But I'm also not confused enough to think that people should use
micro-emacs for reading man-pages.
The UNIX philosophy is "do one thing, and do it well".
Man-pages with man. html with a web browser. And edit stuff with an
editor.
Why the *hell* do you confuse my choice of editor with my choice of
man-page format? I didn't.
That whole "do everything in emacs" is a disease. And then emacs users
think that it's "sane".
Linus
^ permalink raw reply
* Re: git-diff new files (without using index)
From: Miles Bader @ 2007-08-05 4:37 UTC (permalink / raw)
To: git
In-Reply-To: <7vd4y2ipd0.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano <gitster@pobox.com> writes:
> I suspect that it's probably half superstition and half disease
> to wish for "diff /dev/null new-file".
Er, please, a bit of consideration. It's not superstition, it's not a disease.
I _want to use the index_: I want to stage changes, and then make more
changes, and just generally be able to treat these three states (HEAD,
indexed, non-indexed) as points which can be used as inputs to git-diff
-- and I want _applyable patch files_ as the output from git-diff, not
pretty diffs for browsing.
Thanks,
-Miles
--
Any man who is a triangle, has thee right, when in Cartesian Space, to
have angles, which when summed, come to know more, nor no less, than
nine score degrees, should he so wish. [TEMPLE OV THEE LEMUR]
^ permalink raw reply
* Re: way to automatically add untracked files?
From: Junio C Hamano @ 2007-08-05 4:39 UTC (permalink / raw)
To: Miles Bader; +Cc: git
In-Reply-To: <87d4y2li2c.fsf@catnip.gol.com>
You are talking about two different operations.
Adding _new_ files, unless you are just beginning a new project,
are much more rare than updating modified files that you are
already tracking; and "git add new-file..." is what people
usually use for the former. "git add ." is almost always the
"initial import" and not used later (after all you ought to know
what files you are creating and controlling ;-)). You get into
an illusion that that is often used, only when you have just
started. As your project progresses, that feeling will fade
away.
And that is natural, if you think about it for 5 seconds.
"Add everything in sight, although I do not know what they are",
which is essentially what "git add ." is, makes perfect sense
for the initial import and vendor drop (after perhaps rm -fr
?*). If you are doing your own development, with your working
tree littered with build products and temporary notes files and
whatnot, "git add ." is usually the last thing you would want to
do.
Updating modified files, "git add -u", is more like "git commit
-a" (without creating commit). You do not add _new_ files, and
that is quite deliberate.
You _could_ argue that people should be more disciplined and
write perfect .gitignore files so that "git add ." is always
safe, but the world does not work that way.
^ permalink raw reply
* Re: possible bug in git apply?
From: Linus Torvalds @ 2007-08-05 4:48 UTC (permalink / raw)
To: david; +Cc: git, rob
In-Reply-To: <Pine.LNX.4.64.0708041243070.6905@asgard.lang.hm>
On Sat, 4 Aug 2007, david@lang.hm wrote:
>
> since git doesn't track directories, only content (per the big discussion
> recently) I beleive that doing a checkout would leave Rob without the
> directories that he emptied out, so shouldn't git apply also clear the
> directories to end up in the same state?
It should. I thought we did that, but maybe there's some bug there.
See "remove_file()" in builtin-apply.c.
But yeah, it seems that the file *rename* ends up not triggering that
logic! Very annoying.
Does this fix it? Totally untested, but it _looks_ obvious enough..
Linus
---
diff --git a/builtin-apply.c b/builtin-apply.c
index 0a0b4a9..da27075 100644
--- a/builtin-apply.c
+++ b/builtin-apply.c
@@ -2508,7 +2508,7 @@ static void write_out_one_result(struct patch *patch, int phase)
* thing: remove the old, write the new
*/
if (phase == 0)
- remove_file(patch, 0);
+ remove_file(patch, patch->is_rename);
if (phase == 1)
create_file(patch);
}
^ permalink raw reply related
* Re: way to automatically add untracked files?
From: Miles Bader @ 2007-08-05 4:53 UTC (permalink / raw)
To: git
In-Reply-To: <7v4pjeioi6.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano <gitster@pobox.com> writes:
> You get into an illusion that that is often used, only when you have
> just started. As your project progresses, that feeling will fade
> away.
I imagine this depends strongly on the nature of the project.
My current comments stem from using git a personal project which I've
been working on for about 2 years; maybe I'm weird, but I seem to
add/remove files fairly regularly (as far as I can tell, it's not an
illusion :-).
> And that is natural, if you think about it for 5 seconds.
...
> You _could_ argue that people should be more disciplined and
> write perfect .gitignore files so that "git add ." is always
> safe, but the world does not work that way.
Sigh. There are all sorts of people using git, and everybody has their
own working style. My personal style involves keeping .gitignore
up-to-date so that there's no cruft in the git-status output.
Anyway, I wouldn't be complaining except that I _keep_ running into
circumstances where I need to type "git-add NEWFILE1 NEWFILE2
NEWFILE3...; git rm OLD_FILE1..." -- which is kind of annoying after
seeing a list of _exactly_ the files I need to add/remove output just
previously by git-status. Thus my wish to have git "do it
automatically."
"git-add -u; git-add ." seems like it should do the job though.
Thanks,
-Miles
--
We live, as we dream -- alone....
^ permalink raw reply
* Re: possible bug in git apply?
From: Linus Torvalds @ 2007-08-05 4:53 UTC (permalink / raw)
To: david; +Cc: git, rob
In-Reply-To: <alpine.LFD.0.999.0708042141510.5037@woody.linux-foundation.org>
On Sat, 4 Aug 2007, Linus Torvalds wrote:
>
> But yeah, it seems that the file *rename* ends up not triggering that
> logic! Very annoying.
>
> Does this fix it? Totally untested, but it _looks_ obvious enough..
Side note: git will never remove a directory even if it becomes empty as
far as *git* is concerned, if there are other files that git doesn't know
about in there. So if you really really want to remove that directory, you
do end up having to often just doing
rm -rf some/dir/
and the fact that you don't find a "git rmdir" is that with git, you
really should not even need it.
We do "git mv" and friends, but the fact is, that may have confused people
into thinking that git cares.
The "default mindset" should be to just do everything directly in the
filesystem, and git will just figure things out on its own. The "git mv"
and "git rm" stuff is purely *convenience* features, nothing more.
Other SCM's really want you to do "scm rm" or "scm cp" or whatever. Git
really really really doesn't care, and I think people are a bit too afraid
of just doing the operation the normal UNIX way.
So next time you want to remove a directory, just remove it. With
bog-standard unix tools. Use "rm". Or a graphical file manager. Or muck
with the disk directly using a binary editor. Git won't care. It will
notice that the file is gone, and do the right thing.
Linus
^ permalink raw reply
* Re: way to automatically add untracked files?
From: Linus Torvalds @ 2007-08-05 5:03 UTC (permalink / raw)
To: Miles Bader; +Cc: git
In-Reply-To: <fc339e4a0708042100jdf0a0f1jd1fddfb5dc1c1052@mail.gmail.com>
On Sun, 5 Aug 2007, Miles Bader wrote:
> I previously wrote
> > One thing I often want to do is git-add all untracked files, and also
> > automatically git-rm all "disappeared" files
> ...
> > One way to do this seems to be just "git add ."
>
> Oh, also, "git add ." doesn't seem to do the right thing with
> "dissapeared" files: If I do:
>
> mv foo.cc bar.cc
> git add .
Do "git status -a" to figure out the removed ones.
I actually think we should probably make "git add ." do it too, but it's
not how we've done it historically ("git add ." really ends up just
reading the working directory tree and addign all the files it sees: so by
definition it doesn't do anything at all to files it does *not* see, ie
the removed ones).
> Am I doing something wrong, or is this just missing functionality?
Well, it's just "behaviour". It's probably largely historical, in that
"git add" used to be thought of as "adding new files", but obviously then
it got extended to mean "stage old files for commit" too, but in that
extension, the "remove old files" never came up.
But git certainly has the capability. "git commit -a" will notice all the
files that went away and automatically remove them, so
git add .
git commit -a
will do what you want (except, as we found out last week, we've had a huge
performance regression, so that's actually a really slow way to do it, and
so it's actually faster to do
git ls-files -o | git update-index --add --stdin
git commit -a
instead (where the first one just adds the *new* files, and then obviously
the "git commit -a" does the right thing for old files, whether deleted or
modified)
Linus
^ permalink raw reply
* Re: way to automatically add untracked files?
From: Junio C Hamano @ 2007-08-05 5:04 UTC (permalink / raw)
To: Miles Bader; +Cc: git
In-Reply-To: <874pjelgyz.fsf@catnip.gol.com>
Miles Bader <miles@gnu.org> writes:
> Anyway, I wouldn't be complaining except that I _keep_ running into
> circumstances where I need to type "git-add NEWFILE1 NEWFILE2
> NEWFILE3...; git rm OLD_FILE1..." -- which is kind of annoying after
> seeing a list of _exactly_ the files I need to add/remove output just
> previously by git-status. Thus my wish to have git "do it
> automatically."
As Linus explained in another thread, "git rm" is largely
unneeded. Just work with the filesystem in normal UNIX way, and
be done with "git add -u" or even "git commit -a" and you will
be fine.
If you are more perfect than most other people in maintaining
the .gitignore file, you do not even have to name individual
files like "git add NEWFILE1..." -- you can always safely run
"git add .".
Most of us are not as perfect as you are, as you might have
noticed that Randal pointed out this morning that we missed a
new entry from our own .gitignore ;-) I highly suspect that we
will be hated by most of our users if we changed "git add -u" to
add everything in sight for this reason, and I also suspect they
will feel that "git add-remove --all" will be code bloat for
little gain.
^ permalink raw reply
* Re: possible bug in git apply?
From: Junio C Hamano @ 2007-08-05 5:11 UTC (permalink / raw)
To: Linus Torvalds; +Cc: david, git, rob
In-Reply-To: <alpine.LFD.0.999.0708042141510.5037@woody.linux-foundation.org>
Linus Torvalds <torvalds@linux-foundation.org> writes:
> It should. I thought we did that, but maybe there's some bug there.
>
> See "remove_file()" in builtin-apply.c.
>
> But yeah, it seems that the file *rename* ends up not triggering that
> logic! Very annoying.
>
> Does this fix it? Totally untested, but it _looks_ obvious enough..
That would regress the fix made in aea19457, I am afraid. If
you are in a subdirectory and the rename patch moves away the
last file in your current directory, the shell session you ran
the git-apply from will end up in an unlinked directory.
Maybe that is a pilot error, and we can revert aea19457
altogether?
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox