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

  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

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

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.

Reply via email to