[Xastir-dev] Git question

[Tom Russo]

On Mon, Apr 22, 2019 at 09:25:56AM -0700, we recorded a bogon-computron collision of the <curt.we7u at gmail.com> flavor, containing:
> On Mon, Apr 22, 2019 at 9:05 AM Jason Godfrey <godfreja at gmail.com> wrote:
> 
> > Is origin Xastir/Xastir and upstream we7u/Xastir?
> > In any case, I would probably try a git pull from origin
> >
> 
> Other way around: I'm working in the we7u/Xastir fork so it is "origin".
> Xastir/Xastir is "upstream".
> 
> In general I try to avoid working in master. I will do work in another
> > branch and have master track the "official" master. If needed I will update
> > my local master  and then merge master into my branch to pick up any
> > changes from upstream.
> >
> 
> Right. I've been mostly doing that too, but for Travis-CI configuration I
> needed to push stuff up to we7u/Xastir and we7u/Xastir-Qt to test
> Travis-CI. I ended up with commits on we7u/Xastir:master that I don't need
> anymore. I was trying some fixes that didn't work for Travis-CI, Tom
> committed something that did work, now my commits are moot and in the way.
> 
> Another option would be creating a new branch that matches GitHub master
> > and then cherry picking the commits you need from your local master into
> > it. Once everything is checked in upstream you can blow away that clone and
> > start over.
> >
> 
> Which will blow away my Travis-CI config and I'll have to start that over
> too I think.

It is always possible to fix mistakes in git repos *and* not lose work.

Without knowing exactly how you've done this work, I can't give specific 
advice for how to do it, but assuming we're talking about you having 
uncommitted, half-done changes to travis-ci config, the way I'd think about 
handling itwould be to make a branch (git checkout -b <newbranch>), commit 
your travis-ci changes to that branch, then go back to master and clean up 
the mess, then rebase your branch back to master so it's a clean change.

Another option is to use the stash to tuck away the uncommitted changes 
temporarily, fix the mess, then pop the stashed changes back into the working 
directory.

Learning to use the stash and side branches to prevent work loss is worth
the time it takes to learn it.


> If I didn't have the feature-greeklanguage branch on my local fork I'd
> probably just blow away the repo and start over with a new fork.

You should never have to destroy a whole repo to fix a little mistake like 
this.  There is always a way to get it done without resorting to the nuclear
option.



-- 
Tom Russo    KM5VY
Tijeras, NM  

 echo "prpv_a'rfg_cnf_har_cvcr" | sed -e 's/_/ /g' | tr [a-m][n-z] [n-z][a-m]