If you're not sure how to get the branch back, but you do know how how to get to the commit that was at the tip of the branch, then you're part of the way most of the way there.

well, I checked out the commit the branch was at, and made a new branch there with the same name as the old one

I don't know if that was the right thing

but I got the change back

That was 100% the right thing.

You could also have made the new branch directly from the commit without checking it out.

But I would have done it the way you did it.

ok! ^_^

Had you gotten the commit's hash from the reflog?

So, the change you made is one you actually want to keep -- what branch do you actually want that change to be on?

@EliahKagan yes. Although I could have just scrolled up a bit since the start of the hash was in the message I got when I deleted the branch

Yes.

That would also have been reasonable.

@EliahKagan It can be on the New branch

@EliahKagan I wanted to make sure you knew about how you can get it from the reflog though.

@Zanna Then you can just merge newer into New.

@EliahKagan it was my first thought. Like uhhh the thing I lost will be found in the reflog

After you merge newer into New, it will be safe to delete newer and you can do so with git branch -d, but I suggest keeping it around a bit longer so I can show you something else with it.

@EliahKagan done :)

@EliahKagan ok :)

IIRC you don't currently have a thursday branch, right?

right

Cool. So, make a thursday branch from the commit just after (i.e., from the child of) master. That is, make a branch whose history is the same as the history that master had before you reset it.

You don't have to call that thursday of course.

You can do that without checking out the commit.

git branch thursday ...

^^ where ... is the hash of the commit.

ok, done

I called this branch little instead of calling it thursday

Sounds good.

I'd like to show you how reverts interact with merges.

They often do exactly the right thing.

However, in this particular situation, you would likely not consider the mostly easily achieved effect to be the right one.

So, if you were to reset little back one commit, you would be doing the same thing with it as you did with master earlier today.

Instead of resetting little back one commit, please revert its latest commit.

(So check the little branch out first, if you haven't.)

sorry, I went to check on some kitchen stuff and it took longer than I expected

No problem!

@EliahKagan done!

So it should still have that commit, as well as a newer commit that reverts it.

Thus the little branch has actually already diverged from all other branches.

yes it does

That diversion is totally not a problem.

What I want to show doesn't depend having another commit, but to have a more realistic and interesting scenario, I suggest that you make a change to something in the little branch and commit that change, before merging little into newer.

ok :)

This is the sort of thing that would occur in that situation.

@Zanna So you've committed a change to little?

Have you also merged little into newer?

@EliahKagan I just did that

and two files got deleted

Indeed! :)

haha :)

Because the reverting commit was one of the commits whose effects were applied in the merge.

ah!

That's why I ended up recommending a reset instead.

yes!

wow

haha that was very smart

Thanks. But it wasn't quite as smart as it would have been if I'd initially recommended it. At first I was recommending a revert, then shortly thereafter I saw the problem.

I often make a "feature branch" that lasts twenty minutes before being merged back to master, on a repo I'm the only one working on. In that situation, if master was one ahead, a revert would be fine, because master isn't getting merged into the feature branch.

But in the more common case of feature branches that coexist with other changes, such a revert is not so good.

Now, of course this can be fixed.

One way to fix it is to undo the merge, which you can do by resetting the merged-to branch back to the appropriate commit.

...But you can also revert the reversion in the merged-to branch.

I think the most common situations where it's reasonable to revert a commit is when it's the last commit, or when you want to "undo" multiple recent commits and you revert them in the order they were committed (so [A] [B] [C] [revert C] [revert B] to get back to A).

But you can revert any commit.

This won't always succeed and when the commit made changes to a file that has since been edited... well, that's confusing.

But in this case where you just want to bring the files back into existence for future commits on the branch, I think it would be the way to go.

Would you like to try that in newer?

To be clear, I'm not saying to revert the reversion in the branch where the reversion was done. I'm saying to revert it in the branch where you want to undo its effects and cause the files it deleted to exist.

before I did this merge, you suggested making another change

so I did that

Right.

and I want to keep that change

@EliahKagan (unrelated) [Btw, in case this is referred back to, I should have mentioned that git rebase rewrites history.]

@Zanna Is there a problem relating to that?

You're attempting to revert the specific commit that deleted the files, right?

@EliahKagan probably not

To be clear, this is not one of those common situations I mentioned. :)

@EliahKagan yes. That won't undo the change I made

Right, if you attempt to revert a commit that did not make change X, that should either fail and do nothing, or succeed and undo something but not undo change X.

Ok, so I reverted the reversion!

now it looks like everything is OK from newer

Cool.

Now let's do a merge conflict!

(I can give specific suggestions about how to create one, but I think you may be abe to come up with it yourself.)

I edited the same file and committed the change on the New branch and the newer branch

then I tried to merge New into newer

and I get

$ git merge New
Auto-merging CurryStewMain/CabbageKootu
CONFLICT (content): Merge conflict in CurryStewMain/CabbageKootu
Automatic merge failed; fix conflicts and then commit the result.

Cool. Before proceeding I should ask, since you're using the New branch, and not just for Git experimentation: are either of the changes you made ones you wish to retain?

on purpose I made two different changes which are both improvements, so ideally I would like to keep both of them

However they were both small improvements and aren't important enough to worry about losing

No problem. (By which I mean, you should be able to keep both.)

But you're merging New into newer. Isn't New the branch you're actually using (besides for Git experimentation)?

You can change your mind about this of course. But I am hoping to get a good picture of what the actual goal is. It's always good to have such a picture in one's mind when one does a merge or resolves a merge conflict.

yes, actually I was thinking about what you said about testing merges when I did it that way

Okay.

Sounds good.

but, I suspect I will probably use branches in a different way to this. Like having a branch for each recipe

I'm trying to remember if there's any other stuff in newer that shouldn't ultimately make it into New.

I have not figured out how I should eventually manage this repository yet, so, whatever we do is ok (there are backups!)

@Zanna Well, or you could ultimately not really use branching at all, since you have the recipes in their own TEST directory when they're experimental, anyway. git would still help, since you'd still commit changes iteratively as you work on the repo.

@Zanna Haha okay.

So, git status can be helpful in a merge conflict especially if you have run various other commands and you're not sure where the conflict is.

In this case you do know, so run git status or not, as you please.

@EliahKagan I think there isn't anything bad in newer and New is ahead of it

Good.

@EliahKagan The conflict is in a file with conflicting edits, so to fix the conflict, open the file.

well the output is quite interesting even though I know about it

$ git status
On branch newer
You have unmerged paths.
  (fix conflicts and run "git commit")
  (use "git merge --abort" to abort the merge)

Unmerged paths:
  (use "git add <file>..." to mark resolution)

	both modified:   CurryStewMain/CabbageKootu

no changes added to commit (use "git add" and/or "git commit -a")

You will see that git has marked the file in a way that indicates the conflict. You can edit (and then stage) the file to resolve the conflict (or the part of the conflict that involves that file, which in this case is the whole conflict).

@Zanna Yes, and I should perhaps have mentioned earlier that if you want to abort a merge that is in progress (i.e., that is started but not finished because it has a conflict) then you can run git merge --abort.

I believe the --abort option for git merge was added recently enough that you might plausibly use a system whose Git version doesn't have it (but there are still ways to abort a merge).

so if I edit the file now, I will have to re-do half of my work

How so?

It should show the changes added in both versions.

Doesn't it?

oh yeah, it does

though in a potentially confusing way

Can you elaborate?

I mean I sort of agree. But can you say more?

I mean there are both versions there and some extra markers. So I need to clean it up

Yes.

It might be difficult if there were many complicated changes

that were not done by the same person even

There was ways to do this more efficiently and with less confusion, including one that I want to show you very soon. But I think it's valuable to try it out manually first.

@Zanna Wait what?

How big were the changes?

Oh sorry.

I totally misread you.

sorry, I was just imagining a possibly more realistic situation where a merge conflict might happen

Yes, you definitely want to use more sophisticated tooling if you can't avoid doing a big and complex merge with changes from multiple authors.

@Zanna The fault was totally in my misreading. :)

I have edited the file to be the way I want and committed that

Cool. That should have resolved the merge.

now I'm getting working tree clean

and the merge completed

Nice.

Okay, so now... tooling.

Actually, first, did you want this in New?

aha

well no, it was just a little correction

so really it belongs in master

Both commits that were merged belong in master?

yes. I suppose so. I didn't think about it

however, I need to go and do some housework things now

@Zanna There are ways to fix this. :)

@Zanna Okay.

@EliahKagan I expected that! :D

maybe I can try them tomorrow

I mean, ideally it would have been committed to a branch that didn't have other stuff on it that didn't belong on master. Then that branch could just be merged into master.

Or it could even perhaps have been committed directly to master.

I was going to say that what you should next is try fixing a merge conflict through the use of a mergetool, and that after that you should try out remotes.

But it is probably best to fix this first. Another day it is!

the list of things to do always grows!

sometimes people complain to me that they are bored

I want to ask them if they would like to do some of my things for me

Though not exactly ideal, in that it "redoes" work, I'd fix it by checking out master, making a new temporary branch from it and checking out that branch, checking out the specific file you want from the specific command, staging and committing that file to the temporary branch, inspecting the situation to make sure it's what you want, and then merging the temporary branch into master.

And then probably deleting the temporary branch.

You can work directly on master (without the additional temporary branch) if you really want to.

There are also other approaches. Like you could try to git cherry-pick the changes.

This touches on an important concept, though: the issue of where bug-fixes that apply to multiple branches should be committed.

One approach, which is the one I would typically advocate, is to make a new branch as close to the root of the repository as the bug fix makes sense but no lower (or perhaps even higher than that, but in any case no higher than the lowest divergence that goes to a branch where the bug fix may need to be applied). Then you can make the change, commit it to the branch for that bugfix, and then merge that bugfix branch into the branches where you want the fix applied.

In this situation, those branches should not be merged into the bugfix branch first. However, if you want to test out the result of applying the fix before committing it to a target branch, you can make a new branch from that target branch, merge the bugfix branch into that branch, and then if everything's good you can merge that branch into the target branch.

(Or if the fix applies to master and you want all the other branches in applies to to be up to date with changes to master anyway, then you can just merge the change into master and then merge from master into the other branches.)

@Zanna Btw if you want to work on git at some point but I'm not around then.... obviously you should! Also, though, if at some point you want to do something Git-related that doesn't mess with the repo we've been talking about here but that will be directly useful to what we've been doing, you could think about how you'll want to work with remotes.

@EliahKagan * checking out the specific file you want from the specific branch that has it