Noob question

[Jean-Christophe Boggio]

Maarten,

Thanks for your fast reply.

Le 07/03/2015 16:28, Maarten De Munck a écrit :
> In your first session, the 'vcsh commit' will in fact commit all
> changes staged for commit in all repositories. In most real cases, I
> think you want different commit messages for different repositories,
> each reflecting your changes in that particular repository. The vcsh
> manpage or vcsh --help show no additional command line parameters and
> it just ignores any parameters it doesn't need.

You are right.

> Your change after the first commit (both in your first and second
> session) will not be committed until you explicitly add it. This
> requires two actions (add and commit), but in practice, you can make
> a lot of changes and split them in several commits, which is useful,
> for example, to store different bugfixes in different commits, so
> that they can be selectively applied to other branches. You can even
> add some changes in a file to a first commit and other changes in the
> same file to a second commit. This is absolutely standard git
> behaviour. If you want to add and commit in one command, specify
> which files you want to commit (e.g. vcsh repo commit file1 file2 -m
> "comment").

Ok, I understand the behaviour which can be useful in some complex
scenarii but I was looking at vcsh for simple dotfile synchronization
and the way I see it now, I will have to re-add all modified files on
every commit.

> Git's behaviour requires some extra commands sometimes which can
> look useless for simple test scenarios, but when I started using git
> for larger and more complex projects, each of these strange
> situations proved to be very useful in quite some situations.

This is not a test scenario, it is the purpose of vcsh (as I understand 
it) : manage a few dotfiles in a repository. Clone/pull, modify, commit 
and push.

I daily use mercurial and hopefully I don't have to re-add every single
modified file on every commit. I was expecting the same simple behaviour
from git but it seems you have to manage simple things as if they were
complex so that when you do face complex situations you are already
prepared.

This is the exact opposite way I want to think computing. This is what 
makes Apple win, this is the reason why people are forced to look at 
computers as if they were magic, why they think computers as "too 
complicated for them".

I am really disappointed by git. It is probably an excellent tool for 
super-smart people which I am not so I'll keep with dumb tools. 
Mercurial and symlinks.

Many (sincere) thanks for your enlightenments.

JC