Probably because the -B switch didn’t exist for a long time and git reset was the only way of doing that.) The only difference is that it will (or might) re-setup the branch on every reset, though most of the time that is a no-op. Though your git checkout -f -B master origin/master has almost exactly the same effect, now that I look at it. Yes, git reset -hard origin/master would be the “obvious” way of going about that.
#Darktable 2.0 update
The default for those is already to always reflect the remote, regardless of whether an update was a fast-forward or not. You seem to be talking about remote tracking branches. Did I misunderstand what you’re talking about, or did you misunderstand Chris? My understanding of what Chris said is that he wants his local master to always be the same the as the remote master. Well… that fetch pattern is already the default configuration for any remotes you add. I suspect that this is theĬorrect approach and there is no magic ' git clone' option that Making repo copies with ' git clone' changes how git sees things I always, always test anything like this on a copy of my repo, not Procedure the right way the next time this comes up, starting fromĪ properly constructed repo.) Sidebar: How I test this stuff out ( This writeup of git rebase -onto is helpful too,īut again I need to digest it. Based on Aristotle Pagaltzis's commentīut I need to read the answers carefully and try it out before I'm Process, using explicit commit hashes for the cherry-picking and
#Darktable 2.0 plus
Not optimal I basically combined the reset origin plus cherry-pick Write down the process I used this time, because I'm convinced it's New version but reapply my changes on top. Now I want to replace the old version with the Probably follow the same process instead of hacking my way aroundįinally, we combine the two situations: I'm building on top of the The same situation (except this repo isn't an explicit PR). Upstream, switch to it, and either cherry-pick or rebase my ownĮxcept, well, looking back at my notes about working with Github What I really wanted to do was add the second repo as an alternate Think what I did was ' git pull -rebase /the/other/repo', but Iīelieve that probably wasn't the right approach. I still want my local changes on top of this. However, there is a repository of interesting changes that I want to try out of course I'm tracking the main repository for my shell and applying my changes on top of Git rebase is probably the correct approach and this is the one
I think that using git cherry-pick here instead of some form of To switch to the release branch but still add my changes on top. Latest git tip, but that's sort of in flux right now so I want Next, I'm tracking the repo for my favorite RAW development Git is like Perl sometimes it has so many different paths to the Searches, apparently I want ' git reset -hard origin/master'. Sound like asking for a rebase here will maybe do the right thing.īut I just found that and contriving a test case is not trivial. (The git pull manpage has some interesting wording that makes it Others, either I have local changes or this should never happen. This but there are only some repos that I want to do this for for Pull' would do this, ideally only if it's safe. It would be nice to have the repo set up so that a plain ' git
#Darktable 2.0 manual
Recently I've constructed the manual fix: Past I've just deleted the entire repo and re-cloned as the simple Rebases my plain git pull will fail, either telling me that itĬan't be fast-forwarded or demanding that I merge things. Master is always the same as origin/master). I have no local changes in such tracking repositories (ie my local I keep local tracking copies of a few upstream repos that are rebased The rebasing has been pretty easy and aĪ number of more complicated cases where I'm not sure that I'm For a while now, I've been both tracking upstream git repositoriesĪnd carrying and rebasing local changes on top of some of them inĪ straightforward way.
0 kommentar(er)
