1 |
"Fernando J. Pereda" <ferdy@g.o> said: |
2 |
> Ryan: |
3 |
> |
4 |
> I think you are talking about very old versions of Git: |
5 |
> |
6 |
> On Fri, Apr 28, 2006 at 02:20:43PM -0700, Ryan Phillips wrote: |
7 |
> > What I meant is, if you have a change within one directory pending |
8 |
> > a commit, and you have a commit pending in a current directory, both |
9 |
> > files will be picked up for the commit. I think that is bad. That |
10 |
> > means you can't have pending changes not ready for commit and commit |
11 |
> > something. |
12 |
> |
13 |
> Of course you can have pending commits. You can even have uncommited |
14 |
> changes in your index since git-commit uses a temporary index when doing |
15 |
> this kind of checkins. |
16 |
> |
17 |
> > yes. git-commit will allow the commit, it will walk the directories |
18 |
> > backwards, but it will find all the pending changes and want to commit |
19 |
> > them. |
20 |
> |
21 |
> It will if you don't use git-commit correctly :) |
22 |
> |
23 |
> > I don't think that is beneficial. I'm open to comments though. |
24 |
> |
25 |
> 'git commit' semantics are a bit different from 'cvs commit' and 'svn |
26 |
> commit' semantics. That's probably the reason you faced that problem :) |
27 |
> |
28 |
|
29 |
the only option I saw was git-commit -o and you had to specify the |
30 |
files that you wanted to commit. |
31 |
|
32 |
I tried doing a git-commit paths/ and still everything wants to be |
33 |
committed. |
34 |
|
35 |
It isn't pretty. |
36 |
|
37 |
-Ryan |