On Sun, 2 Nov 2014 18:26:15 -0800 (PST) Anthony Berglas <aberg...@gmail.com> wrote:
> Thank you for all your very considered replies. The solution I end > ed up using (without the complex explanations) was > > git push > # fail > git pull > git merge origin/master This step is not needed: `git pull`, when you're on "master" which is set to track "origin/master" (we imply this is the case here) will fetch all the new stuff from "master" at origin and then merge it into "master". I would reiterate that `git pull` has too much magic built in so I would use git fetch origin git merge origin/master instead until you do really understand what these two commands do and how `git pull` combines them. > # resolve conflicts > git push > > This should go up the front of any manual of GIT, right after git > clone. But I have not seen it explicitly that I can recall. (I threw > the abtmp branch away) > > My interpretation is that that when you push to a remote it will will > follow any direct set of arrows (only) to move origin/master along. Correct, unless you use "--force" with `git push` *and* the remote repository allows such forced pushes--they are disallowed by default for obvious reasons (if these are not obvious feel free to ask). > I have not read that anywhere though. > > <rant> > > One problem with GIT is that every document author gets so carried > away with advanced features for obscure branching and even partial > staged commits(!) that they just lose track of the basics. > > For example the Git Basics chapter in the git-scm.com book talks about > advanced things like staging in the intro (which I would never use, > just always commit -a) but does not describe how to check in to a > shared repository and resolve conflicts. Then the external > repository chapter does not talk about merging! > > The simple model, which I use, is that there is one shared repository > used by all developers. I have a local cache, much like Subversion > but storing all the history for convenience. We all normally work on > head, with branches for releases that are kept very short. Big > merges are dangerous and avoided. > > I have seen teams get into big trouble just introducing branches to > CVS. As code is merged backwards and forwards between the branches > errors are introduced. Buggy code often reappears on different > branches, only to be merged back onto good branches. But the good > news is that once you fix the same bug multiple times you get really > good at fixing that bug. Of course because of all this merging the > code could never be restructured which would make the merges > unmanageable. > > Note that the above is not because of CVS's many, many issues. It is > instead the nature of branching and merging code. And in particular > to rely on complex branching rather than having a good module > structure that makes branching largely unnecessary. > > The idea that people are only staging some file in their working > directory at particular times during the edit, and then putting > different staged changes into different branches, and then pushing > different branches to different shared repositories seems just crazy > to me. Broken builds would be the least of the problems. Maybe a > team of people as smart as Linus Torvald might be able to handle it, > but not the people that I have worked with. > > So it is great to have fancy functionality. But getting the basics > right is most important. Using git like Subversion doc should be > chapter 1, not just left as a something implied. > > </rant> The problem is that "basics" is a different thing depending on where you stand for. For instance, you take for granted that everyone would use `git commit -a` for a start and then may be try using "advanced" stuff. But as one example, here at my $dayjob a bunch of webdevs hired about 2-3 month ago used those partial staged commits all the time even before they did their first `git merge` (actually, they used `git add --patch` which provides for even more fine-grained staging). Why? Because we here value clean history and atomic commits and so we focussed on that first. You seem to assume that the approach Subversion takes is a de-facto standard and hence every other tool out there must strive to make Subversion users feel at home. While Subversion does indeed have a great "market share" and is well entrenched in the shops not completely sold on Microsoft-supplied stuff, and there's nothing really wrong with the approaches to SCM it implements, Git is just different. I know this sounds weak, but no, you can't really make it work like Subversion because it has been created with different mindset and different goals. It's like procedural programming languages vs functional: you can write programs in both, and (typically) you can to a certain extent mimic approaches from a "foreign" domain in a code written in "native" but it will look and feel clumsy at best. The same goes to Git vs Subversion: the key to getting Git paradigms right when you come from Subversion is to unlean Subversion and get Git's (I stress: Git's) basics right. Not trying to find Subversion's basics in the Git feature set but learn "whys" and "hows" of Git. Beleive be, I came from Subversion so I know what I'm talking about. For instance, understanding local vs remote branches was hard for me. I think I did not read any document on them which gave me a picture clear enough back when I was learning Git. I hope I did not sounded like a zealot because I'm not one. I have no desire to "convert" you, neither do I think that everyone should enjoy Git or whatever. If you feel like it's OK for you to try to understand the premesis Git is based on, ask away. Also I think you might check out Fossil [1]. I'd say it's a DVCS with a Subversion touch, catered for devs with a centralized mindset. Tcl/Tk is being maintained in it for a couple of years now, and they seems to be reasonably happy with the tool. While my weapon of choice for most cases is Git (for a number of reasons, flexible staging and rebasing included) I have completed one project of moderate complexity in Fossil and have mostly positive conclusions (to say it more bluntly: if I did not know Git by then I'd be a Fossil aficionado now). A feature it has which seems should have a particular appeal to you is "autosync". 1. http://www.fossil-scm.org -- 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. For more options, visit https://groups.google.com/d/optout.
