Hi,
why don't they just do a simple git commit -a of their work before pulling?
That's different to cvs! Committing only affects the cloned repository.
I think one of the biggest advantages of git is the concept of everyone working on a clone. So developers are not prevented from actually using revision control just because they are afraid of disturbing others. They don't until they e.g. push!
Cheers, Michael
Bill LearOn Wednesday, June 13, 2007 at 17:03:58 (+0200) MichaelTiloDressel@t-online.de writes:
>Hi, > >why don't they just do a simple >git commit -a >of their work before pulling?
Because they are basically playing with some code and don't want to commit it.
>That's different to cvs! Committing only affects the cloned repository.
Yup, we realize that.
>I think one of the biggest advantages of git is the concept of everyone >working on a clone. So developers are not prevented from actually using >revision control just because they are afraid of disturbing others. They >don't until they e.g. push!
Right, but they just want updates to their working tree, as they could do under CVS, without issuing five (or even one) other commands.
Bill
Hi,
but even if they just play with the code. Why not always commit? As long as they don't push nobody else will be affected.
Even if you play with the code it's useful to go back to earlier versions. Why would you not want to benefit from this possibility?
So this would really only be two commands the commit and the pull command.
I hope I didn't miss your point completely.
Cheers Michael
On Wed, 13 Jun 2007, Bill Lear wrote:
> On Wednesday, June 13, 2007 at 17:03:58 (+0200) MichaelTiloDressel@t-online.de writes: > >Hi, > > > >why don't they just do a simple > >git commit -a > >of their work before pulling? > > Because they are basically playing with some code and don't want to > commit it. > > >That's different to cvs! Committing only affects the cloned repository. > > Yup, we realize that. > > >I think one of the biggest advantages of git is the concept of everyone > >working on a clone. So developers are not prevented from actually using > >revision control just because they are afraid of disturbing others. They > >don't until they e.g. push! > > Right, but they just want updates to their working tree, as they could > do under CVS, without issuing five (or even one) other commands. > > > Bill >
Bill LearOn Wednesday, June 13, 2007 at 19:31:50 (+0200) Michael Dressel writes:
>Hi, > >but even if they just play with the code. Why not always commit? >As long as they don't push nobody else will be affected. > >Even if you play with the code it's useful to go back to earlier >versions. Why would you not want to benefit from this possibility? > >So this would really only be two commands the commit and the pull command. > >I hope I didn't miss your point completely.
Not completely: they don't want to commit, as this will then "pollute" the history in their working repository (which is just temporarily being used to play with a new feature, idea, bug fix, optimization, etc.). This pollution with a handful of garbage would then have to be undone were they to say "ok, that's really not a good idea". If a pull into a dirty tree were possible, that last step could be just a simple reset, or continuing to explore with the code, etc.
Their benchmark is CVS: CVS lets them do this easily (and yes, I understand that CVS sucks compared to git, so don't even start), and so even if they have to have 2 commands to do what they did in CVS with 1, they complain. My job is to either justify what git does to them to shut them up, or to speak to the git community to see if their desires are remotely rational.
It seems to me, based on several posts here, particularly Junio's, that they are being remotely rational and it might be a reasonable addition to git to be able to say "git pull --dirty" or whatever...
Bill
Johannes SchindelinHi,
On Wed, 13 Jun 2007, Bill Lear wrote:
> Not completely: they don't want to commit, as this will then "pollute" > the history in their working repository (which is just temporarily > being used to play with a new feature, idea, bug fix, optimization, > etc.). This pollution with a handful of garbage would then have to be > undone were they to say "ok, that's really not a good idea". If a > pull into a dirty tree were possible, that last step could be just a > simple reset, or continuing to explore with the code, etc.
Notice that I am _not_ saying that CVS is bad. I am saying that their workflow is likely bad (and yes, they should change that workflow, since they now _can_).
Two things do they risk happily, which they should not do:
- they test their new feature against different references. For example, it might well be that they tested cases A, B, and C before pull, and D, E and F after that. It is really easy to get lost in what you have, and what not. Now, guess what. Merges are known to break things sometimes. Even the best merge algorithm. Now your developers say "we tested it, and the merge broke it, it's not our fault". But it is.
- That new feature will have to be committed at some stage. Either your devs commit at the end, which makes it a monster commit, which is bad. Or they are _already_ using the suggested workflow "commit && pull", which makes your whole complaint moot.
Ciao, Dscho
Bill LearOn Wednesday, June 13, 2007 at 19:30:23 (+0100) Johannes Schindelin writes:
>Hi, > >On Wed, 13 Jun 2007, Bill Lear wrote: > >> Not completely: they don't want to commit, as this will then "pollute" >> the history in their working repository (which is just temporarily >> being used to play with a new feature, idea, bug fix, optimization, >> etc.). This pollution with a handful of garbage would then have to be >> undone were they to say "ok, that's really not a good idea". If a >> pull into a dirty tree were possible, that last step could be just a >> simple reset, or continuing to explore with the code, etc. > >Notice that I am _not_ saying that CVS is bad. I am saying that their >workflow is likely bad (and yes, they should change that workflow, since >they now _can_).
Yes, I have urged this. But, they are stubborn, smart people, and if they see tool X allow something, they wonder why tool Y does not support it.
>Two things do they risk happily, which they should not do: > >- they test their new feature against different references. For example, > it might well be that they tested cases A, B, and C before pull, and D, > E and F after that. It is really easy to get lost in what you have, and > what not. Now, guess what. Merges are known to break things sometimes. > Even the best merge algorithm. Now your developers say "we tested it, > and the merge broke it, it's not our fault". But it is.
Well, their testing is something along the line of "I'm going to hack something here, and then I want to see if Joe's latest changes work with it". Then, they want to pull in Joe's changes, run a test, and if their changes don't work, fix them, discard them, etc.
>- That new feature will have to be committed at some stage. Either your > devs commit at the end, which makes it a monster commit, which is bad. > Or they are _already_ using the suggested workflow "commit && pull", > which makes your whole complaint moot.
Perhaps: again, they may just be taking stabs that they know are wild, and will likely not be committed.
I'm not trying to argue for their point: I do most of my new work on branches, very rarely on the master branch, and can handle the git pull not working in a dirty tree with merge issues.
Some of the people we work with are not developers per se: they are engineers who sometimes like to fiddle (say, with a compiler optimization setting) and who never push into our company repo. They only see CVS and compare git to it. When git prevents you from doing something they see as perfectly reasonable, they get annoyed and say "git sucks". I'm battling in the git corner against this, but there is only so much I can do.
Bill
Robin Rosenbergonsdag 13 juni 2007 skrev Bill Lear:
> On Wednesday, June 13, 2007 at 19:30:23 (+0100) Johannes Schindelin writes: > >Hi, > > > >On Wed, 13 Jun 2007, Bill Lear wrote: > > > >> Not completely: they don't want to commit, as this will then "pollute" > >> the history in their working repository (which is just temporarily > >> being used to play with a new feature, idea, bug fix, optimization, > >> etc.). This pollution with a handful of garbage would then have to be > >> undone were they to say "ok, that's really not a good idea". If a > >> pull into a dirty tree were possible, that last step could be just a > >> simple reset, or continuing to explore with the code, etc. > > > >Notice that I am _not_ saying that CVS is bad. I am saying that their > >workflow is likely bad (and yes, they should change that workflow, since > >they now _can_). > > Yes, I have urged this. But, they are stubborn, smart people, and if > they see tool X allow something, they wonder why tool Y does not > support it. > > >Two things do they risk happily, which they should not do: > > > >- they test their new feature against different references. For example, > > it might well be that they tested cases A, B, and C before pull, and D, > > E and F after that. It is really easy to get lost in what you have, and > > what not. Now, guess what. Merges are known to break things sometimes. > > Even the best merge algorithm. Now your developers say "we tested it, > > and the merge broke it, it's not our fault". But it is. > > Well, their testing is something along the line of "I'm going to hack > something here, and then I want to see if Joe's latest changes work > with it". Then, they want to pull in Joe's changes, run a test, and > if their changes don't work, fix them, discard them, etc. > > >- That new feature will have to be committed at some stage. Either your > > devs commit at the end, which makes it a monster commit, which is bad. > > Or they are _already_ using the suggested workflow "commit && pull", > > which makes your whole complaint moot. > > Perhaps: again, they may just be taking stabs that they know are wild, > and will likely not be committed. > > I'm not trying to argue for their point: I do most of my new work > on branches, very rarely on the master branch, and can handle > the git pull not working in a dirty tree with merge issues. > > Some of the people we work with are not developers per se: they are > engineers who sometimes like to fiddle (say, with a compiler > optimization setting) and who never push into our company repo. > They only see CVS and compare git to it. When git prevents you > from doing something they see as perfectly reasonable, they get > annoyed and say "git sucks". I'm battling in the git corner against > this, but there is only so much I can do.
A typical case I recognize is a few printfs or disabling a feature that makes it harder to debug with no intentions whatsoever to commit them. What we see when the tools more or less forces people to "temporarily" commit stuff is that that stuff is often left there. "Oh, I forgot". Gah.
Git has this ability when checking out, so why not on pull or merge?
With stacked git I typically create a new patch, then I can push it whenever I want to have some more tracing.
-- robin
Johannes SchindelinHo,
On Wed, 13 Jun 2007, Robin Rosenberg wrote:
> A typical case I recognize is a few printfs or disabling a feature that > makes it harder to debug with no intentions whatsoever to commit them. > What we see when the tools more or less forces people to "temporarily" > commit stuff is that that stuff is often left there. "Oh, I forgot". > Gah. > > Git has this ability when checking out, so why not on pull or merge?
You should hold your breath for git-stash. Now that Junio declared he'd work on it.
> With stacked git I typically create a new patch, then I can push it > whenever I want to have some more tracing.
My evil plan is to work git-stash into sort of a lightweight StGit. I never liked that dependency to Python, and I always felt that it must be simpler than that.
Ciao, Dscho