Thanks again.

It seems I didn't express myself clearly. OK, let me elaborate on specific 
examples:


 *Scenario 1:*


 *$ cat>a.txt *

alpha 

*$ git add a.txt *

*$ cat>>a.txt *

beta 

*$ git st *

# On branch master 

# Changes to be committed: 

# (use "git reset HEAD <file>..." to unstage) 

# 

# new file: a.txt 

# 

# Changed but not updated: 

# (use "git add <file>..." to update what will be committed) 

# (use "git checkout -- <file>..." to discard changes in working directory) 

# 

# modified: a.txt 

# 

*$ git ci -m 'add a.txt' *

*$ git st *

# On branch master 

# Your branch is ahead of 'origin/master' by 1 commit. 

# 

# Changed but not updated: 

# (use "git add <file>..." to update what will be committed) 

# (use "git checkout -- <file>..." to discard changes in working directory) 

# 

# modified: a.txt 

# 

no changes added to commit (use "git add" and/or "git commit -a") 


 OK, that's clear. Next:


 *Scenario 2:*


 *$ cat>b.txt *

gamma 

*$ git add b.txt *

*$ cat>c.txt *

delta 

*$ git add c.txt *

*$ cat>>b.txt *

epsilon 

*$ cat>>c.txt *

zeta 

*$ git st *

# On branch master 

# Changes to be committed: 

# (use "git reset HEAD <file>..." to unstage) 

# 

# new file: b.txt 

# new file: c.txt 

# 

# Changed but not updated: 

# (use "git add <file>..." to update what will be committed) 

# (use "git checkout -- <file>..." to discard changes in working directory) 

# 

# modified: b.txt 

# modified: c.txt 

# 


Up till now it's also clear. Then we do:

*
*

*$ git ci -m 'add c.txt' c.txt *

*$ git st *

# On branch master 

# Your branch is ahead of 'origin/master' by 1 commit. 

# 

# Changes to be committed: 

# (use "git reset HEAD <file>..." to unstage) 

# 

# new file: b.txt 

# 

# Changed but not updated: 

# (use "git add <file>..." to update what will be committed) 

# (use "git checkout -- <file>..." to discard changes in working directory) 

# 

# modified: b.txt 

# 


>From the output of the above command I can conclude that b.txt, although 
having staged (as well as unstaged) changes, preserves its state exactly as 
it was before last commit, so git left other files except c.txt 'as-is'.

To sum it up:

«Scenario 1» tells that git lets us commit staged changes and preserves 
unstaged changes of a file.

«Scenario 2» tells that git lets us commit only selected files from the 
index, and leave other files 'as-is'.

What prevents us from combining these two behaviours, so that we could 
commit only selected files from the index, preserving their unstaged 
changes, as well as leaving other files 'as-is'?


 If it's too cumbersome an explanation, could you please tell me how to see 
which plumbing commands are executed with a specified porcelain command 
(something like a trace or debug feature)? I could have then decomposed 
`git commit' and `git commit file' into low-level commands and craft my own 
porcelain command based on those plumbing commands.

-- 
You received this message because you are subscribed to the Google Groups "Git 
for human beings" group.
To view this discussion on the web visit 
https://groups.google.com/d/msg/git-users/-/sqL98mmgvckJ.
To post to this group, send email to git-users@googlegroups.com.
To unsubscribe from this group, send email to 
git-users+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/git-users?hl=en.

Reply via email to