0

I have a branch that shows no difference from master, but its being reported as This branch is 28 commits ahead of master". I tried to clear it with the following, but it did not work. After the process, it remains in the same state.

--squash is used in an attempt to keep accurate log of events. Nothing that happens on the dev-branch arm-neon affects master until after its merged. We cannot have inaccurate logs, and its a hard requirement.

How do I clear the This branch is 28 commits ahead of master" message?

$ git checkout master
Already on 'master'
Your branch is up-to-date with 'origin/master'.

$ git diff master arm-neon
$

$ git merge arm-neon --squash -m "Synch branch 'arm-neon' with 'master'. Version control is showing arm-neon 28 commits ahead even though there are no differences"
Updating 7319206..9c8ee31
Fast-forward (no commit created; -m option ignored)
Squash commit -- not updating HEAD

$ git commit -am "Synch branch 'arm-neon' with 'master'. Version control is showing arm-neon 28 commits ahead even though there are no differences"
On branch master
Your branch is up-to-date with 'origin/master'.

$ git push
Everything up-to-date
$ git push --force
Everything up-to-date

Not a duplicate. The cited question's problem states:

1- change files
2- commit
3- repeat 1-2 until satisfied
4- push to master

We have no differences.

Another answer states to git fetch -p. I have this in a bash script and it runs regularly because its impossible to get Git to update everything with one simple command, and its impossible to get Git to delete branches with one simple command:

if [ -d "$HOME/cryptopp" ]; then
    (
    cd "$HOME/cryptopp"
    git fetch -p && for branch in `git branch -vv | grep ": gone]" | $AWK '{print $1}'`; do git branch -D $branch; done
    ) </dev/null &>/dev/null &
    disown $!
fi

Yet another answer states to git pull --rebase. I believe that's incompatible with --squash. But if that's the answer, then someone needs to state it. It gets old experimenting with "maybe this will work, maybe that will work" answers.

Community
  • 1
  • 1
jww
  • 97,681
  • 90
  • 411
  • 885
  • 2
    You're still thinking of squash merges as merges. They're not. Don't try to use them as merges, it simply won't work. You *must* do a real (non-squash) merge to make Git work. As Steve Jobs said when the iPhone didn't work, "you're holding it wrong". :-) Maybe it *ought* to work like that, but it doesn't, and won't, at least not without some major change (I wouldn't hold my breath on that one...). Your other alternative is to fight with Git, ignore complaints about branches being ahead, etc. – torek Jun 18 '16 at 00:30
  • Possible duplicate of [git: Your branch is Ahead by X commits](http://stackoverflow.com/questions/2432579/git-your-branch-is-ahead-by-x-commits) – Andrew Li Jun 18 '16 at 00:30
  • @Torek. We have to use `--squash` or find another solution to the logging problem. – jww Jun 18 '16 at 00:41
  • @Torek - Thanks again for your insight Torek. I just announced we have to stop using [Git development branches](http://groups.google.com/d/msg/cryptopp-users/WvyI6Z63z1I/8xM9cAqRBAAJ). I refuse to accept inaccurate logs. The Git developers really should fix these problems. – jww Jun 18 '16 at 01:24
  • I'm...not convinced there's any actual Git problem here. What does `git log --graph --oneline --decorate --all` show you? Do you see where the tip of `master` is relative to the tip of your feature branch? – Makoto Jun 18 '16 at 01:37
  • @Makoto - *`git log --graph --oneline --decorate --all`* - Unfortunately, the branch has been deleted. We stopped using Git development branches. – jww Jun 18 '16 at 01:51
  • I'm not sure how I can help you then, considering that if we had the log, we could see the state of `origin/master` and whatever your local `master` had and go from there. `--all` is concerned with the state of your remotes, and not your branches (necessarily). – Makoto Jun 18 '16 at 01:53
  • We [stopped using Git development branches](https://groups.google.com/d/msg/cryptopp-users/WvyI6Z63z1I/8xM9cAqRBAAJ). All of these problems are now solved. I cast the first close vote using the reason ***Problem can no longer be reproduced***. – jww Jun 18 '16 at 01:55
  • For what it's worth, the other way to deal with the `git log` issue is to use `--first-parent`. That requires a fair bit of additional discipline, lest Git lose the plot, as it were, with other merges. – torek Jun 18 '16 at 02:13
  • 1
    One more note, nothing to do with Git this time: Mercurial branches work the way you want. They're totally static, and merging a branch does not cause the *commits* from that branch to show up. (Though `hg log` shows all branches by default, so you need `hg log -b default` to show just the main-line.) Mercurial and Git have roughly equal power in terms of source management, but Git is far more popular. – torek Jun 18 '16 at 03:02
  • Thanks Torek. I wanted either SVN or HG when we migrated away from Sourceforge. I mildly lobbied against Git because I had some experience with it, but I did not want to sound too negative because the community was providing its feedback. I was overruled by the democratic process. I've pretty much reached my limit with Git and its policy of *"take every simple task and make it difficult to impossible"*. I really regret not choosing another tool that's a better fit for our version control needs. – jww Jun 18 '16 at 03:48

0 Answers0