On Fri, Mar 16, 2012 at 7:34 AM, Miguel de Benito Delgado <
[email protected]> wrote:

> Hi Alex,
>
> Am 16.03.2012 06:41 schrieb "Aleksandr Dobkin" <[email protected]>:
>
> > What is nice about git is that you can maintain multiple branches of the
> project and switch between them very quickly. Had you been using git,
>  think you would have caught this error when you merged your work into the
> master branch and tried to compile.
>
> Thanks for the idea. So: I could constantly fetch the latest from the main
> branch, commit locally as much as I wanted, then decide when to push it
> back to main, right? And that way merging conflicts ought to happen
> seldom... because merging is a real PITA!
>

The answer is yes BECAUSE before you push your accumulated changes you
would type something like:

# get latest upstream
git fetch origin

# re-wind my changes and re-play them onto the latest master branch from
upstream
get rebase origin/master

# push my changes
git push origin

And so a merge is not even required!

When you do the rebase there may be conflicts if the upstream changed, but
you just fix up each commit and continue the rebase. It will be as if the
fixed-up commit was always that way.

It took me a few months to get to grips with git's power and safety, but
there is really no going back.

Git doesn't have branches the way you think it does.

Every commit is really a new branch because you can still check out the
previous state and make a different commit; or someone else on their
computer can make a different commit to the same point you just committed
to on your computer (rebasing makes it go away by letting you fetch his
changes and re-apply yours on top) or merging is also good.

But the point is, what git shows as a branch is really a labelled tip. When
you commit onto a checked out labelled tip, the label is updated to the new
commit. But of course only on your computer. (git is distributed).

So for big project work mature changes slowly make their way to the main
repo as they get acceptance.

Also with git, branches are not spacial like SVN - they don't look like
directories, instead they are like alternate states of the diretory

And git to svn and back work well? Well, I guess I could look that up ;-)
>
> Thanks!
>
> > On Thu, Mar 15, 2012 at 10:55 AM, Miguel de Benito Delgado <
> [email protected]> wrote:
> >> And... yep! it was yourself truly
>
> That would be of course, "yours truly".
> ___________________
> Miguel de Benito.
>
> _______________________________________________
> Texmacs-dev mailing list
> [email protected]
> https://lists.gnu.org/mailman/listinfo/texmacs-dev
>
>
_______________________________________________
Texmacs-dev mailing list
[email protected]
https://lists.gnu.org/mailman/listinfo/texmacs-dev

Reply via email to