Then I have to follow up on this comment I got which makes me think my answer is wrong

@Zanna I had been meaning to ask--and given the nature of the question it is perhaps out of character that I haven't yet asked... Do you want, at some point, to post a (self-answered) question on the site about why the output of wc -l with a recursive glob disagreed with the number of insertions reported by git?

@Zanna I get the same message from that command that the OP reported (with the default GNU sed 4.4 installation on Ubuntu 18.04 LTS).

@EliahKagan I tried with GNU sed 4.2.1 (in Ubuntu 12.04 LTS running in an LXD container) and got the same error.

I wonder how I managed it

I certainly would have pasted the command and output

But maybe I edited it afterwards somehow

Or, unlikely but slightly possible, maybe it's from Termux on Android...

But, it doesn't even make sense

O.o

Do you recall what OS (and release/version) it would have been on if not Android?

Also, what should that command do? Is the error message correct? I don't know sed nearly as well as you.

Aha! (sort of)

ek@Ilex:~/source$ sed 'ps/123/AAA/' a.txt
sed: -e expression #1, char 2: extra characters after command
ek@Ilex:~/source$ busybox sed 'ps/123/AAA/' a.txt
apple
apple
123
AAA
pear
pear
1234
AAA4

So some sed accepts that.

I'm not sure what you were saying doesn't make sense, the command or the error.

@Zanna That seems likely. I've just checked by installing Termux on my Android phone, and sed on Termux is provided by BusyBox.

I checked with ls -l $(command -v sed busybox) to see that sed is a symlink to ../busybox on that system, rather than just going by the strange output of sed --version.

@EliahKagan haha that seems like a good idea!

@EliahKagan I was saying the command doesn't make sense, because it really ought to have a semicolon

I am wondering if my example has any logic that relates to the question at all

thanks a lot for looking into it!

@EliahKagan that's pretty embarrassing then, because I noticed enough differences between sed on Termux and GNU sed that I should not have been using it for testing Ask Ubuntu answers

Maybe you thought you were SSHed in from your Android device to an Ubuntu system, or something?

I once overwrote the "right" disk but on the wrong machine because I forgot I was SSHed into a different machine. This could be like that, but the opposite, and also way less bad.

@Zanna But it does produce the same output as the output you showed in your answer. Is this usage a BusyBox extension that has the semantics your answer implies it has?

@EliahKagan That's slightly possible, but less likely than me just lazily not testing my answer properly

@EliahKagan in GNU sed, if we put in the semicolon between p and s, it looks the way I said

there are some situations where a new command doesn't need a semicolon

I'm not sure what the best solution is. Maybe use the command from the comment or one like it, and also include the original one in a footnote mentioning BusyBox sed?

@EliahKagan But it might be that the command should simply be changed without retaining the old one, and that I'm overly sensitive to radical changes in upvoted posts due to what was done here (which I noticed had occurred while looking into that stuff).

Do you want to continue with Git? We were going to fix your master branch.

I guess when there is nothing that could reasonably come after the command that could modify its action, then there's no need for a semicolon. So I guess GNU sed is stricter about interpreting characters after a command, if there is no semicolon, as some kind of attempted argument to that command, instead of trying to interpret them as the next command if possible. (When I say "command" here I mean in the sense that p and s are individual sed commands)

@Zanna I didn't end up losing anything. I pressed Ctrl+C soon enough that no actual files were affected! I was able to confirm that this was so by comparing between the still-mounted disk's contents and a backup. I restored from the backup anyway.

@Zanna So maybe just change it to

sed 'p;s/123/AAA/' a.txt

?

(i.e., add a semicolon after the p and leave it otherwise the same)

@EliahKagan awesome

@EliahKagan yes, that's what I have done so far in my edit

Sounds good.

I have also written a footnote about the original command

Okay.

but I am just trying to work out why the commenter mentioned the other command

that they say gave exactly what OP expected

Since the addition of a ; is slight and, given BusyBox sed's looser treatment, doesn't change the meaning, the footnote is probably not necessary -- I didn't realize at first that such a small change was all that was needed -- but I suppose it could be handy.

By slight I mean not that a one-character edit to a sed script is minor, but that in this case what you had is effectively an alternate syntax for the version where the ; is present.

yes. I think I feel better adding a footnote about it :)

@Zanna Did you think of anything, from the "merge" hint? (Feel free to ignore this message if you don't want to put attention to git stuff at the moment, btw.)

I think there are enough messages here about improving the sed command in that post that they should go to the Island. I'll get around to moving them there fairly soon, if you have no objection.

Nice edit. Btw, busybox sed on Ubuntu also behaves the way you observed.

oh, yeah we would expect that! I edited again to try to not make it sound like that wouldn't be the case

thanks so much for helping me fix my answer!

No problem!

← 51 messages moved from Raiders of the Lost Downboat

oh I should have said I was going to do that

maybe you had already started doing it yourself, sorry

I had not.

ok, good :)

@EliahKagan (relating to that) I'm not expecting any guess, btw. It's not really obvious, at least not if one hasn't performed merges with git. I had missed it originally when I had suggested, without qualification, to use git revert for the extra commit in master.

oh!

well the only thought I had was that when we did the reset before, the orphaned commits were still there

so if I reset master to before the new files being added, the new files commit would be similarly orphaned

but we could make a branch from them and merge it into New

but that seems like a possibly dangerous way to do it

If you reset the master branch to an earlier commit, that will not affect the New branch.

The commit that is currently at the tip of the master branch is currently reachable both from master (which right now is really a pointer to that commit) and from New (which right now is a pointer to a later commit).

and the New branch knows about the new files

Resetting master to an earlier commit causes the commit it currently points to no longer to be reachable from master but it doesn't prevent it from being reachable from other branches from which it is currently reachable.

@Zanna The commits in the New branch -- that is, the commit New currently refers to and the ones in the chain up to it -- know about, and also store snapshots of, the files that are in them, yes.

@EliahKagan oh!

git reset doesn't affect what commits exist, nor their contents, except in the indirect sense that if it causes a commit no longer to be reachable at all then that commit may eventually be deleted automatically.

Of course it can affect what commits will come into existence in that if you reset a branch to an earlier commit and then push the branch to a remote, then the commits that were on the branch before but are no longer on the branch will not be pushed.

hmm

Idk how much sense that last bit makes since we've not yet actually used a remote.

I think I am too sleepy to think properly right now :(

Does that mean you want me to hold off on saying what the potential disadvantage of running git revert HEAD with master checked out would be?

The effect of the alternative, running git reset HEAD^ on the master branch, would be made clearer by either (a) trying it, or (b) looking at the output of git log while New is checked out (or the output of git log New regardless of what's checked out).

I suggest starting with (b), if you're up for it.

@EliahKagan no, better if you tell me; even if I don't get it now I'll probably get it later

Running git log and not passing --all shows what can be seen from the "vantage point" of the commit you name as its argument, or from HEAD if you don't pass a (non-option) argument. If you run this, I can show you in it what the effect will be of reverting the tip of the master branch. I think that will make it clear.

And by "show you in it" I mean describe it based on the contents of git log.

I ran it and I can see the commit where I added the new files. That commit has the (master) label

Were you on the New branch when you ran it?

I mean, do you also see more commit after that, up to and including the latest commit which should be marked as being the tip of the New branch?

yes

So, if you run git log master you'll see it just from there.

And if you run git log ... where ... is replaced with the hash of the commit currently at the tip of the master branch then you'll see the same thing.

yup :)

If instead of passing master or that hash to git log, you pass master^ (or master~1) or manually pass the hash of the preceding commit, you'll see the log from (i.e., up to) the preceding commit.

That preceding commit is what you currently want master to be at.

If you reset master to that commit, then running git log master will show the log starting from (i.e., up to) that commit, but will indicate that master is there.

Both as it stands now and as it would after you reset master to the preceding commit, all the commits up to the tip of the New branch will remain visible from New.

Because resetting a branch doesn't change or directly remove any commits, it just changes what commit that branch is set to.

In effect, resetting master to the preceding commit would have the effect of rewinding it by one commit.

Does that make sense?

ok... but if we do reset that, then it seems to me that the view from New would be confusing, since that commit that was reset from master would not reflect the actual situation with the files

Can you elaborate?

so, we can still see the commit that added them, but, we won't have those files any more

so it looks from New like they are there, but they are not there

and we can't see why they are not there

maybe that's quite normal

because master could keep growing and we wouldn't see what was going on with it from New

Each commit has a snapshot of the files in the repository. Whatever was staged when the commit was made went into the commit and remains in the commit as long as the commit exists.

@Zanna New will be correct to think they are there. :)

@Zanna master can diverge from the commit its reset to, yes. But the commits after it that are in New's history will still be in New's history.

nooo totally confused

I will go to sleep

sorry

Sorry, was afk.

No problem!

no worries!

hahaha

I can show you, via a paste from my terminal.

But I can also show you another day.

hmm please show me another day, because I suck at reading right now

Okay.

I might paste something here but I will avoid pinging you as I do it.

oh, feel free to write anything and ping as well

Okay.

I will catch up and reply when I have a chance :)

I still might not ping. Only if it makes sense. :)

ok

ek@Ilex:~/source/repos$ mkdir tmp
ek@Ilex:~/source/repos$ cd tmp
ek@Ilex:~/source/repos/tmp$ git init
Initialized empty Git repository in /home/ek/source/repos/tmp/.git/
ek@Ilex:~/source/repos/tmp$ echo 'Hello, world!' >greeting
ek@Ilex:~/source/repos/tmp$ git add .
ek@Ilex:~/source/repos/tmp$ git commit -m 'initial commit'
[master (root-commit) 7e83432] initial commit
 1 file changed, 1 insertion(+)
 create mode 100644 greeting
ek@Ilex:~/source/repos/tmp$ echo 'This is a second line.' >>greeting

even though I don't mind any pings at all, I'll still appreciate you being nice about it haha

In that example, I make a repo with two commits and just a master branch. Then I make a new branch, twolines, from master. Then I "realize" I should have branched twolines off the first commit to master and committed the second commit to twolines so master would remain at the initial commit. So, to achieve that effect, I reset master back by one commit to the initial commit. The second commit is no longer part of master's history, but it remains part of twolines's history.

I think the key point of possible confusion here may be that reset is often used in an attempt to achieve the effect of undoing some action. But resetting a branch back past one or more commits does not undo the action of making those commits. Those commits still exist. In cases where the reset causes them to be unreachable, they may later be deleted for real. But git reset ... (with ... as the commit to reset to) is just resetting the branch, it's not changing or deleting any commits.

In the above example, as in the case we were discussing of resetting your master branch back one commit, the reset operation does not even cause any commits to become unreachable. It only changes what commit master points to. The same series of commits continues to constitute the history of the New branch.

If the master branch then gets more commits, thereby diverging from the feature branch (New in your repo, twolines in mine), that's still no problem. Looked toward the root of the tree (i.e., toward the initial commit), the two branches diverge after whatever commit is the newest one they both share.

Because master was reset one commit back between when the branch was created from it and when anything else was committed to master, that commit after which the divergence occurs is one commit prior to where it would otherwise be, which is the goal.

On the other hand, if you have a commit that is only on master (or any one branch) and you reset the branch to a commit before it, then that commit becomes inaccessible if you don't have its hash (which you can obtain from the output of git reflog). When you're on a branch, even git log --all won't show it.

ek@Ilex:~/source/repos/tmp$ git status
On branch master
nothing to commit, working tree clean
ek@Ilex:~/source/repos/tmp$ sed -i '1s/^/This is a... "zeroth" line?\n/' greeting
ek@Ilex:~/source/repos/tmp$ git diff
diff --git a/greeting b/greeting
index af5626b..9cca50a 100644
--- a/greeting
+++ b/greeting
@@ -1 +1,2 @@
+This is a... "zeroth" line?
 Hello, world!
ek@Ilex:~/source/repos/tmp$ git add .
ek@Ilex:~/source/repos/tmp$ git commit -m 'added a line at the beginning'
[master 6ca3d80] added a line at the beginning

But you can still access it by its hash, including in git log, and you can restore it by resetting the branch back to it:

ek@Ilex:~/source/repos/tmp$ git reflog
7e83432 (HEAD -> master) HEAD@{0}: reset: moving to HEAD^
6ca3d80 HEAD@{1}: commit: added a line at the beginning
7e83432 (HEAD -> master) HEAD@{2}: reset: moving to HEAD^
6e69061 (twolines) HEAD@{3}: commit: added second line
7e83432 (HEAD -> master) HEAD@{4}: commit (initial): initial commit
ek@Ilex:~/source/repos/tmp$ git log 6ca3d80
commit 6ca3d80d1f131f7221e88d1642acc58b81e04c68
Author: Eliah Kagan <[email protected]>
Date:   Wed Aug 7 16:26:09 2019 -0400