Hugh Sasse wrote:
That first step will mean getting it again. I thought git was designed to
avoid network loading, so I could get the bits that rub out my changes, and
the new bits, without getting the stuff that has not changed?
Or is the separate remote just a pointer to the far repository? I'm really
not used to this mode of working but am tryin to learn to do it right from
the start. Yes, I've found RCS had been adequate for my needs pretty much,
but it's about time I was dragged into the 1990's :-)
repo, do a git co -b why_master when inside the remote master. Then you can
pull, etc. into that and then git rebase your own master against that.
And that will add to my revision history so I can regenerate the patches if
he wants patches against the new stuff?
Does this help?
Thanks, I'm a step closer, perhaps!
--
Jeff
Thanks.
Hugh
Okay, adding a remote is basically saying "here is a remote repository
that contains stuff like the things I have in my repository locally".
Obviously, there is the "origin" one that is already created if you used
github. In fact, if you cloned directly from _why's public Shoes git
repository (instead of using github to fork it to your own profile),
origin is already _why's repo.
You can pull commits from any remote to anywhere in your repo. git
really is a patch manager with lots and lots of helper glue. rebasing
against another branch (even one on a remote repository!) is saying
"okay, take all teh changes I've commited locally and put them to the
side. Now, take those new changes that we see on that branch and apply
them. Then, take my changes and apply them afterwards". pulling from a
branch into another branch is just putting any new commits right on top
of whatever has been done.
I'm not sure if I've explained what you needed explained, but,
hopefully, we're moving in the right direction. :)
--
Jeff
