I personally think this is going to make the GIT experience lot more enjoyable for everybody. This brings the power of the index up front using a proper mental model without talking about the index at all. See for example how all the technical discussion has been evacuated from the git-add man page. Any content to be committed must be added together. Whether that content comes from new files or modified files doesn't matter. You just need to "add" it, either with git-add, or by providing g...

Why not? It is a well defined word in the SCM context, and I really think what is built in the index before a commit is a changeset. But actually I'd prefer "set of changes" even better as it is more First I don't know if "to stage" is such a good verb. According to http://dictionary.reference.com/search?q=stage I think "stage" has just too many definitions already, and none of which really make me think of In technical docs maybe. But I don't see the need for this wording in the t...

Nah. Too many concepts in the same paragraph. Nicolas -

The problem is that a newline is not inserted before the ".sp". I (and apparently a lot of other people on #git) thought it was just something broken by the system. It appears that the DocBook XSL files got broken between 1.69.0 and 1.69.1, but it appears to have been fixed upstream (I didn't try it by from looking at the xsl/manpages/block.xsl file it seems to insert a newline again before inserting a ".sp") Git already has a custom XSL file to handle callouts so this might be the right place t...

/me likes (both emails). Q: should git-commit require either -a or --staged when there is a staged commit? Mark -

Is there a good receipe on how to do this? Everytime I do it, I try a different method; since I'm testing out my understanding of things. It'd nice to have some of these "advanced receipes" that people often do noted down somewhere. Sometimes I feel git is kind of like the Emacs of VCS ... there is always more to learn, even when you think you have a good handle on things. Cheers, Anand -

Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com> --- generate-cmdlist.sh | 7 ++++++- 1 files changed, 6 insertions(+), 1 deletions(-) diff --git a/generate-cmdlist.sh b/generate-cmdlist.sh index 5450918..b45495d 100755 --- a/generate-cmdlist.sh +++ b/generate-cmdlist.sh @@ -9,7 +9,7 @@ struct cmdname_help struct cmdname_help common_cmds[] = {" -sort <<\EOF | +cat <<\EOF | add apply archive @@ -41,6 +41,11 @@ verify-tag EOF while read cmd do...

I don't think it belongs in the plumbing, the git-update-index but I think something like this would be very usefull. AFAIR darcs has this functionality. It selectively ask for each hunk if it should be commited. This would be awfull to have in git. -Peter -

Pretty often I end up with a file with two simple orthogonal fixes in it. git-diff shows me both, that's OK. Now I want to commit them as two separate commits. So far, it's * getting full diff * cp(1) * hand-edit both diffs * commit first * commit second Has anyone thought about aggregating this into git-update-index or somewhere? git-update-index -C1,3 #chunks 1, 3 git commit git-update-index -C1,3 # chunks 2,5 in original numbering git commit Relying on diff(1) ...

Raimund Bauer offered this suggestion (paraphrased): "Maybe we could do git-commit -a _only_ if the index matches HEAD, and otherwise keep current behavior? So people who don't care about the index won't get tripped up, and when you do have a dirty index, you get told about it?" Johannes Schindelin pointed out that this isn't the right thing to do for an --amend, so that is checked for. Additionally, it's probably not the right thing to do if any files are specified with "--only" or "--include...

No problem: just don't apply the patch :-) What you've asked for leaves it as a no-op. This patch activates "-a" when the index equals HEAD. i.e. git-commit would do nothing in this situation. If it is disabled when the index doesn't match the working tree, then we're back to "do nothing". i.e. HEAD==index==working How does that help you? You've updated the index manually, so the automatic "-a" is already disabled. Without this patch you would still have committed the wrong thing. ...

Sorry to be so ignorant, but I just updated to 2.6.19 using: git-checkout master git-pull ... sound/usb/usbaudio.c | 3 usr/Makefile | 2 92 files changed, 888 insertions(+), 371 deletions(-) create mode 100644 arch/mips/kernel/topology.c create mode 100644 arch/um/os-Linux/execvp.c create mode 100644 include/asm-arm/mach/udc_pxa2xx.h All seemed to go I then moved back to my branch and pulled from master...

Side note: the historically more common failure was to not have a merge program at all, but exactly because that was common, we check for that and complain about it. So that's not it for you - you do have a 'merge' program somewhere that git found. But if it returns the wrong error code, or doesn't do anything at all (ie you have "merge", but it's not the 3-way merge we expect, or it doesn't take the "-L" argument we use, or it's simply buggy) then that might explain the behaviour you r...

[ Tangentially related.. ] Btw, what's the status of the xdl_merge() thing in "pu"? It would be lovely if this could be one less thing we ever need to worry about, just because we just do it ourselves. But quite frankly, I've never looked at the RCS merge logic, so while I peeked at the xdl_merge patch itself, I have absolutely zero way of judging it. But the patch in "pu" to make merge-recursive use it looks pretty, and removes more lines than it adds, and the xdl_merge() code itself _...

..and just to be safe, remove the symlink first, so that you don't end up overwriting the "kdiff3" binary by mistake when you install the real "merge". Not that I think emerge is quite that stupid a package manager, but anyway.. Linus -

I'm actually using Debian Unstable and basically use the git-core package. Its at version 1.4.4.1 - so right up to date, and of course resolves all dependencies automatically. Doesn't Ubuntu have git-core in its repository? -- Alan Chandler http://www.chandlerfamily.org.uk -

Ubuntu is a Debian based. I think it uses Synaptic as its package manager gui with the standard Debian apt-xxx tools underneath. -- Alan Chandler http://www.chandlerfamily.org.uk -

That's what I thought but there isn't any "<<<<<" and git-diff also seems to indicate no differences: wink@winkc2d1:~/linux/linux-2.6$ git-diff kernel/fork.c diff --cc kernel/fork.c index d74b4a5,8cdd3e7..0000000 --- a/kernel/fork.c +++ b/kernel/fork.c wink@winkc2d1:~/linux/linux-2.6$ wink@winkc2d1:~/linux/linux-2.6$ git-diff kernel/spinlock.c diff --cc kernel/spinlock.c index f4d1718,2c6c2bf..0000000 --- a/kernel/spinlock.c +++ b/kernel/spinlock.c wink@winkc2d1:~/linux/l...

Hello, I searched the net and couldn't find the answer to how to revert a file to its "pre-modified" state. I did see in the 0.99.7 To Do: * Perhaps a tool to revert a single file to pre-modification state? git-cat-file blob `git-ls-files | grep foo` >foo or git-cat-file blob `git-ls-tree HEAD foo` >foo? What should the command be called? git-revert is taken so is git-checkout. Did such a command come to be? Thanks, Wink Saville -

FYI the above seems more obvious then what's in the man page: "It updates the named paths in the working tree from the index file (i.e. it runs git-checkout-index -f -u)." But for me saying something like; "It reverts the paths in the working tree to the most recent version stored in git." would even be better. It may not be as precise as the current sentence, but more obvious to this neophyte. Finally, in the EXAMPLES you might add another example of reverting a "modified the file" as w...

Also, if you are actually _using_ CVS to check it out, use cvs co -ko I think, to not check out with keyword expansion at all. (Also usable with "cvs diff -ko", I think) Linus PS. Clueless user alert: I have happily not used CVS in years and years, and I might remember that all wrong. -

My position on this subject is that "index" is a good name, but that description is a terrible description, and "index" is a word that needs a good description in context. If we just said up front: Git's "index" is a staging area that you use to prepare commits. It maps filenames to content. It allows git to remember changes you want to put into the next commit while you do more work. For normal commits, it is not necessary to use the index, but it is very helpful for complicated commi...

Hey, it was originally called "cache". I don't care _what_ it's called, I just want people knowing about it, because hiding it will just cripple git (ie at the very least, when you hit a merge conflict, you really do want to to understand it if you ever want to go the the "next level"). If people are more comfortable just calling it the "staging area", and Yes. And even "git diff" isn't really a problem once you understand the staging area. If people feel worried, let them use "gi...

Actually git-gui shows the index, but not quite as well as diff and friends would. But based on this thread I had a major realization: git-gui is totally wrong in how it displays files (and therefore gitool is too!). I'm going to rewrite that part of git-gui's UI, hopefully early next week. Linus is right: To deny the index is to deny git itself. Trying to hide part of the index in git-gui is just wrong and makes things like merge conflict resolutions harder, not easier. -- Shawn. - ...

I'm not so sure about that. I came from CVS / SVN, although I've fiddled quite a bit with other scm's as well. The two-step commit process of git didn't terrify me at all, and I had used git at least a month before I joined the mailing-list and found out that there's this thing called an "index". I knew about it before, since back then (June or July 2005) there was only git-update-index to mark things to commit. I just didn't worry about it but expected the scm to tell me if I was about to bre...