[ Re-adding git@vger in Cc, I guess it was meant to be so ]

"Joachim Schmitz" <j...@schmitz-digital.de> writes:

>> Then, work on the tip of the topic branch you depend on instead of pu.
>> These are more stable, as they will be rewritten only if this particular
>> topic branch changes.
> These are not available from git hub. Or are they? How?

I think they exist in some of the repos junio pushes to, but I don't
remember how/which one.

Anyway, you can easily get it from the commit that merges the branch
(it's the-merge-commit^1).

>> > Like this?
>> > git pull --rebase HEAD~42
>> That would be "git fetch" and then "git rebase", as I don't think "git
>> pull --rebase" would allow you to specify the starting point for rebase.
> OK, I'll try that next time then. Like this?
>       git fetch;git rebase HEAD~42 --onto origin/pu

That should work, yes.

In general, when you have a somehow complex workflow, I recommand
fetch+(merge|rebase) over pull. It gives you more flexibility, and the
opportunity to check what you fetched before starting the merge.

>> > So far I create patches, wiped out the entire repository, cloned,
>> > forked and applied the changes, pretty painful.
>> This is conceptually similar to what "git rebase" does, but it does it
>> in a slightly more efficient way ;-).
> Indeed ;-)

Matthieu Moy
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Reply via email to