Re: GIT commit strategy
- From
Michael Witten <mfwitten@gmail.com>
- Date
- Aug 16, 2011, 16:46 UTC
- Message-ID
- <CAMOZ1Bvy2+8UdBuxRM03=Ynh6NpD-o_TVNoFG1M3+t993BikyA@mail.gmail.com>
- In-Reply-To
- <C0B80A98F4E14FA287D3BAFA8366BEAC@procyon>
2011/8/16 Vadim K. <klug@hot.ee>:
Show 20 quoted lines
> Hello all, > > Imagine developer A has changed files f1 and f2, then made commit and push > to the server > Developer B has changed files f2 and f3 and made local commit. > > Next B wants to publish changes to the server and make pull to resolve > conflicts at f2. After pulling from the server it has all 3 files - f1, f2 > and f3 to commit before push. But B did not changed f1 and actually can > "ban" this change if he commits only f2 and f3 - files that were changed by > him. In latter case after pushing to the server GIT will restore previous > version of the f1, even if it has more recent one !! It does not seem to be > very logical. > > Question: is it possible to show to the developer only files, that he > changes? Like in SVN - after updating from the server developer must resolve > conflicts (if any) and only commits changes that he has made. By the way - > in a case of non-conflicting files (let me say A changes f1, B changes f2) > GIT makes commit automatically and does not show to the B, that f1 was > changed and need to be re-commited. B only need to push the change back.
It is difficult to understand exactly what you have written here, but I feel that git already does what you want, so I don't understand why you are confused.
Please provide a concrete example (with git commands, expected results, actual results, etc.) so that we can understand each other.