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

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

> git-diff|git-apply --index.

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

Hmmph. I was trying to come up with a better commit log message for this change. Paths given from the command line of checkout-index name files relative to the cwd, whose implication is that it is relative to where you are in relation with the top of the working tree. For doing that, you need to have the work tree to begin with. Does this mean that any command that uses its prefix parameter to cmd_xxx() needs NEED_WORK_TREE? I wonder if it would help us to catch similar breakages if we...

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? David Lang ---------- Forwarded message ---------- Date: Sat, 4 Aug 2007 15:19:54 -0400 From: Rob Landley <rob@landley.net> To: Geert Uytterhoeven <geert@linux-m68k.org> Cc: Roland Dreier <rdreier@cisco.com>, Linux K...

It should and it does, unless you have untracked files in that directory that you haven't told git about. Then removing the directory along with these files will lose the files there, which is a wrong thing to do. A simple "rm -fr this/directory/is/no/longer/interesting/to/me" would be all that is needed. -

Beginning with commit 6490a3383f1d0d96c122069e510ef1af1d019fbb Fix work-tree related breakages install-doc-quick.sh no longer installs man pages, at least not to the defined $mandir (if "git-checkout-index" is putting them somewhere else, I haven't discovered where). Reverting the above commit eliminates this problem. This is on Cygwin, haven't tried on Linux. Mark Levedahl -

<snip ...> git>git bisect good 6490a3383f1d0d96c122069e510ef1af1d019fbb is first bad commit commit 6490a3383f1d0d96c122069e510ef1af1d019fbb Author: Junio C Hamano <gitster@pobox.com> Date: Thu Aug 2 15:10:56 2007 -0700 Fix work-tree related breakages In set_work_tree(), variable rel needs to be reinitialized to NULL on every call (it should not be static). Make sure the incoming dir variable is not too long before copying to the temporary buffer, and ma...

Hi, It succeeds here... (without the patch I sent out, of course.) Ciao, Dscho -

Hi, your test script is slightly wrong... First you "git init", with GIT_DIR in $(pwd)/.git, i.e. the default. But then, you need not do this, test scripts are called when git init was already called. Then you make an untracked directory called untracked/. Tradition dictates that when we're in that directory, we get the prefix "untracked/", because we might add a file, or reference a file in another branch, where that directory is _not_ untracked. So it is expected that checkout-inde...

Hi, I thought I tested on master + --new-workdir... But I did not. And indeed, it fails. Sorry, Dscho -

Hi, Thanks for doing this. I will work on this in a few minutes; at the moment I am occupied with msysGit... Ciao, Dscho -

git>GIT_TRACE=1 make prefix=/usr quick-install-doc make -C Documentation quick-install make[1]: Entering directory `/usr/src/git/Documentation' make -C ../ GIT-VERSION-FILE make[2]: Entering directory `/usr/src/git' make[2]: `GIT-VERSION-FILE' is up to date. make[2]: Leaving directory `/usr/src/git' sh ./install-doc-quick.sh origin/man /usr/share/man trace: built-in: git 'rev-parse' '--git-dir' trace: built-in: git 'rev-parse' '--verify' 'origin/man^0' trace: built-in: git 'read-tree' 'origin/m...

Before the bad commit, set_work_tree returns (null), and variable dir_buffer in the call to get_relative_cwd is "/usr/src/git/.git/HEAD" After, it returns "Documentation/", and variable dir_buffer in the call to get_relative_cwd is "/usr/src/git" I do not understand what the desired changes in this patch were so am really lost as to what should be fixed. However, the above I hope will give you a good clue as to what is broken. Mark -

That won't work if $mandir doesn't exist, which can happen if you install the manpages for the first time. Simply add a mkdir: (mkdir -p "$mandir" && cd "$mandir" && git checkout-index -a -f) Ren

Hi, Just to hazard a guess... you see an error message there, such as "cannot chdir to <blablabla>: No such file or directory"? It's kinda hard to debug this with incomplete information. Ciao, Dscho -

This was broken as part of ecda072380. Signed-off-by: Lars Hjemli <hjemli@gmail.com> --- git-submodule.sh | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/git-submodule.sh b/git-submodule.sh index 2cfeadd..3320998 100755 --- a/git-submodule.sh +++ b/git-submodule.sh @@ -313,7 +313,7 @@ case "$add,$init,$update,$status,$cached" in ,,1,,) modules_update "$@" ;; -,,,1,*) +,,,*,*) modules_list "$@" ;; *) -- 1.5.3.rc4-dirty -

NOTE: This fix uses is_absolute_path from msysGit-0.3.exe that is not in mingw.git yet. Correctly test for absolute path This fix (while correct) actually avoids another nasty bug that must be fixed later: environment.c caches results of many getenv calls. Under MinGW setenv(X) invalidates all previous values returned by getenv(X) so cached values become dangling pointers. Signed-off-by: Dmitry Kakurin <Dmitry.Kakurin@gmail.com> --- setup.c | 2 +- 1 files changed, 1 insertions(+),...

I am trying to dig through man-pages and user manual and trying to match them with reality. I seem to have a hard time. My current understanding (which definitely differs from the documented state) is that there are two types of branches, local and remote branches, and both types of branches can be remote-tracking (it may not be possible to have a non-remote-tracking remote branch, though). A local branch is one with a local branch head. In contrast, checking out a remote branch, while possibl...

So --track does not set up a tracking branch, but makes a local _following_ branch _refer_ to a tracking branch. What happens with git checkout origin/branchX git branch --track mylocalbranch git checkout mylocalbranch ? What if after the checkout (which leads to a detached head) I check in a few things, and then decide to name the branch and set it up as following a remote tracking branch? Instead of using git-branch for setting up the following, do I have to explicitly add t...

Not according to my current understanding, but that can, of course, change again in the next few hours. As far as I understand right now, such a branch indeed tracks a remote branch (and not a remote tracking branch), it just does not track it recklessly: it has a head of its Yes, it seems --track does track after all. Just more cautiously than Good. It means that I may not be a complete idiot. It may also mean that the documentation can be improved in places. With a lot of "grep" and fine...

Jeff, I actually have no _clue_ what I "mean" with respect to the established git terminology because I can't reconcile the documentation's use of words with my meagre understanding of the technical processes involved. So I can't even tell you whether "by remote branch I mean a remote Well, of _course_ it is confusingly similar. After all, I am posting this question because I _am_ confused! And I am trying to both clear up my confusion as well as get an idea how to fix the documentation to ...

It would be helpful. Except that nothing whatsoever can be found in .git/config concerning my local and my remote tracking branches. So where is that information _really_ hidden away? .git/FETCH_HEAD maybe? It also appears that doing git-checkout --track -b mybranch origin on a git.git clone does _not_ create a tracking branch. I can't figure out what I could specify as an origin to create a tracking branch that would get reflected in .git/FETCH_HEAD. What gives? -- David Kastru...

I think I am going to cry. So I need to rebase my branches, pull out the resulting patch sets, scrap my repository, clone it new from upstream, reapply my branches, in order to have a system where the documentation is somewhat in synch with the actual behavior? [...] No, it would seem that I can just git-clone -l my repository and be set up in the new order of things. Nice. However, it would appear from my experiments up to now that the --track option _can't_ be made to work with a 1.4 re...