On Thu, Aug 9, 2012 at 11:50 AM, Tim Moore wrote:
> If you are going to keep a branch for a long time that you are not
> merging back into e.g., master, there are a couple of possibilities.
> One is to merge (pull) master into your branch. Another is to check
> out git-rerere (I kid you not), whi
On Thu, Aug 9, 2012 at 2:45 PM, Curtis Olson wrote:
> It looks like every time you rebase you have to reapply the same set of
> patches over top the target branch. So even if I figure out a way through
> it once, I'll have to repeat the same conconction of craziness each time I
> rebase. I think
On 08/09/2012 07:45 AM, Curtis Olson wrote:
> It looks like every time you rebase you have to reapply the same set of
> patches over top the target branch.
Not true in general. I've never had a problem like that.
> So even if I figure out a way through
> it once, I'll have to repeat the same c
On Thu, Aug 9, 2012 at 10:44 AM, Anders Gidenstam
wrote:
> If you can figure out which commits cause the problems you can edit them
> out of your branch (or, better, out of a copy of it) using
>
> git rebase -i HEAD~42
>
> (change 42 to the number of commits back from HEAD that you need to
> touch
On Thu, 9 Aug 2012, Curtis Olson wrote:
> It looks like every time you rebase you have to reapply the same set of
> patches over top the target branch. So even if I figure out a way through
> it once, I'll have to repeat the same conconction of craziness each time I
> rebase. I think I'm going t
It looks like every time you rebase you have to reapply the same set of
patches over top the target branch. So even if I figure out a way through
it once, I'll have to repeat the same conconction of craziness each time I
rebase. I think I'm going to create a new branch, untar my changes on top,
l
> The typical fix is to edit the conflicting files and "git add" them the run
> "git rebase --continue".
> But these files don't exist so I can't edit them, git add fails, git rm also
> fails since they don't exist.
If the files no longer exist, I think one solution is to tell the system to
s
On Wed, Aug 8, 2012 at 12:06 PM, Tim Moore wrote:
> It sounds like your local tree has not been completely committed. See
> what "git status" says. Check out the man page for git-mv. I can't say
> more right at the moment, but I'll see if I can add more details
> later.
>
There are a couple other
It sounds like your local tree has not been completely committed. See
what "git status" says. Check out the man page for git-mv. I can't say
more right at the moment, but I'll see if I can add more details
later.
Tim
On Wed, Aug 8, 2012 at 5:45 PM, Curtis Olson wrote:
> A quick update here. Rob
On Wed, Aug 8, 2012 at 10:45 AM, Curtis Olson wrote:
> A quick update here. Rob pointed out the "git rebase --abort" command
> which got me back to a sensible working state. I was able to reevaluate my
> original problem which turned out to be a simple merge conflict in my
> branch vs. changes
A quick update here. Rob pointed out the "git rebase --abort" command
which got me back to a sensible working state. I was able to reevaluate my
original problem which turned out to be a simple merge conflict in my
branch vs. changes in "master" and I was able to fix that and successfully
merge -
I've run into a problem with git and I seem to hit a dead end no matter
which way I turn. I'm hoping this is something easy to solve, but the
details might be complicated to communicate? I'll try to start simple --
I'm working with the fgdata repository. I created my own branch and have
been tra
12 matches
Mail list logo
