Re: How to update a cloned git repository

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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

"Joachim Schmitz" <jojo@xxxxxxxxxxxxxxxxxx> 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
http://www-verimag.imag.fr/~moy/
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]