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

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

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.

vcs-home mailing list

Reply via email to