On 06/05/2020 08:06, SJW wrote: > Thanks Philip. > I have that mental model right. I get that bit,
Been there... Often it's the confusion between the intellectual model, our heuristics and our unthinking models that cause these problems. Every now and then I still get 'pulled up short' by some aspect of Git where my expectation wasn't fully aligned. Expect these little 'gotchas' to to continue. > and for the most part, I can make basic updates and copy them to the > server. I even incorporated my stating server as another remote where > I would push to when something was ready for viewing but I didn't like > the process and didn't think it fit the right process. Have a look for discussions about "pushRemote" if you follow an 'upstream', and also about 'publishing' remotes, along with triangular workflows. I suspect that your use of a 'stating' (did you mean 'staging) server, and a viewing server is one step more specialised than most. I know that the Git development has a multi-layer set of servers and the maintainer uses some scripts to push the different selections to different servers (his own, one for contributing developers, and one for latest sources). > > I think all I wanted to do was not have a whole commit dedicated to > removing a few comments - it really was a part of the same commit - > just after the fact... I'd say this issue is a key 'learning point' for using Git. Yes _you_ should be doing a lot more commits like this. The more the merrier (every few working minutes!). You can't actually change your local history, but then again, you won't be 'publishing' it until it is polished. This is where you can rebase the 'mess', and make it nice for publishing. (create a branch for the messy history, then another for the polished rebase - they are zero cost). > > Yes, forcing it sounds like what I should be doing. > From my understanding, it updated and committed locally without any > issue - it just refused to do the same to the server. If that is you personal backup server, then that is the way to do it, in terms of keeping a respectable level of sync. If you had a one patch series of commits that just needed a minor amendment to polish it, then Ok it's all squeezed into one amend and force push. but if the patch has any size (i.e. you can't show it in a small 24x80 terminal window) then consider splitting the series or add "fixups" (rather than amending it as you are playing with too much in one go..) > > In the grand scheme of things - it probably doesn't matter but from a > cleanliness point of view, I'd prefer to not have to commit comment > changes... An 'amend' is a commit... Just sayin'. The old commit is still there for weeks until the 'gc' get around to it. Git tries hard to never forget! -- You received this message because you are subscribed to the Google Groups "Git for human beings" group. To unsubscribe from this group and stop receiving emails from it, send an email to git-users+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/git-users/2874d396-0d79-b866-95ff-7d5ccebbb865%40iee.email.
