top button
Flag Notify
    Connect to us
      Site Registration

Site Registration

Would it be possible to add -u option to git tag for updating tag (with message) to a new commit, e.g. after rebase

+2 votes
311 views

Ref
http://stackoverflow.com/questions/8044583/how-can-i-move-a-tag-on-a-git-branch-to-a-different-commit

posted May 6, 2015 by anonymous

Looking for an answer?  Promote on:
Facebook Share Button Twitter Share Button LinkedIn Share Button

Similar Questions
+2 votes
Diff in git rebase -i commit message?

Could somebody tell me how to make git rebase -i show diff of squashed commits (for example), like git commit -v does it?

+1 vote
Can we mark a commit as authoritative in interactive rebase in Git?

I have many commits: A, B, C, ..., Z. I plan to do some housekeeping using rebase. One thing I want to do is to reorder Z to be the first commit. However, other commits will be in conflict with Z's changes. I know I can go through and interactively resolve the conflicts manually. But this is tedious and error prone. I would like to be able to mark Z's changes as authoritative while rebasing. That is, I want to tell git, "whenever a commit conflicts with Z (during this rebase operation) I want you to keep Z's changes and ignore the other." Is this possible? Is there another (hopefully better) way to accomplish what I'm trying to do?

0 votes
Git rebase for cleanup, after pushing

I run across this problem quite a bit: I have a branch that I'm working on. Unfortunately for me, in order to get my code tested and built by our build servers and infrastructure (which is a requirement before it can be code reviewed and merged, plus it builds my code on platforms I don't otherwise have easy access to) I have to push it to our main git repo, since that's the only place the build infrastructure can get it from.

This means I have to publish my work-in-progress branches up to the git server, including all the false starts, backups, single-line "oops" fixes, etc. Then if I merge my branch into the master branch, all that
becomes part of the mainline of the code.

If it's a small change which is really just one thing I can just use a squash merge into master. But for larger changes what I'd like to do is clean it all up into a smaller set of well-formed commits and push
those. This sounds like a job for rebase -i.

However, I've already pushed my branch to master. I know rebasing stuff you've already pushed is considered a no-no in general, but I can't avoid it. Does anyone have suggestions for how to make this work better? Should I be rebasing to a brand new branch, then merge that to master? Just rebase directly to master? None of the above? Something else entirely?

+1 vote
git rebase after a pull

Is it required to do a git pull before doing a git push.and is it required to do a git rebase after git pull just before git push. one of my git repo mandates the above wondering if there is a valid reason for this.

...