Let us suppose I have a master branch X and I want to migrate changes to separate branch Y in perforce.
changelist #NUMbER in X branch and want to unshelve into Y branch.
Given a branch spec XY that maps between branches X and Y:
Branch: XY
View:
//depot/X/... //depot/Y/...
you can shelve the pending change from X and unshelve it as a pending change on Y:
p4 shelve -c NUMBER
p4 unshelve -s NUMBER -b XY
If the branches are streams where X is the parent of Y, the syntax is more like:
p4 unshelve -s NUMBER -S Y
Related
I am quite new to P4 and being a junior dev I am having some issues when trying to automate merges from streams, I am running p4 merge, and then p4 resolve -am, then I build the project and run some tests and if everything goes well I want to submit otherwise shelve the files so a engineer can go through the conflicts, and manually resolve them and submit. The thing is that the p4 shelve command as far as I know needs to have -c <CL#> argument, and I do not know how or where I can get the CL number I just generated when running the script. Is there any way to do this? or any documentation that can help me with this?
The shelve command does not require a -c argument.
C:\Perforce\test\python>p4 help shelve
shelve -- Store files from a pending changelist into the depot
p4 shelve [-Af] [-p] [files]
p4 shelve [-Af] [-a option] [-p] -i [-f | -r]
p4 shelve [-Af] [-a option] [-p] -r -c changelist#
p4 shelve [-Af] [-a option] [-p] -c changelist# [-f] [file ...]
p4 shelve [-As] -d -c changelist# [-f] [file ...]
...
By default, 'p4 shelve' creates a changelist, adds files from the
user's default changelist, then shelves those files in the depot.
If you just ran p4 merge and p4 resolve -am, the files are open in your default changelist. Running p4 shelve with no arguments will automatically create a new changelist out of those files and shelve it, and it will display the number of the new changelist, so all your script needs to do is print the result of the command.
I just tried to rename the branch with following command
git branch -m <oldname> <newname>
my older branch name is feature/AAM-443 and this branch is already merged with parent now when i renamed it with feature/AAMN-443 and push it to remote then the branch in network is showing
*<commit id> feature/AAM-443, feature/AAMN-443
and if i do some commit to feature/AAMN-443 then graph is like
* <new-commit id> feature/AAMN-443
|
|
* <old-commit id> feature/AAM-443
what is happening i am wondering that what the meaning of a branch having two names is it some symbolic reference and why the feature/AAM-443 is still there why not it removed can anyone help
To add to #RomainValeri's answer, a branch can't have two names, so what you did was this:
You had a remote tracking branch:
git branch -a
feature/AAM-443
origin/feature/AAM-443 <-- tracked by feature/AAM-443
You renamed your branch locally:
git branch -m feature/AAM-443 feature/AAMN-443
git branch -a
feature/AAMN-443
origin/feature/AAM-443 <-- still thinks it's tracked by feature/AAM-443
You pushed your renamed branch to origin:
git push -u feature/AAMN-443
git branch -a
feature/AAMN-443
origin/feature/AAMN-443 <-- tracked by feature/AAMN-443
origin/feature/AAM-443 <-- no longer tracked by any local branch!
Then you made a new commit and pushed:
git commit -am "new commit" <-- on branch feature/AAMN-443
Your remote repo updated like this:
o <-- origin/feature/AAMN-443
|
o <-- origin/feature/AAM-443 (branch is no longer tracked! It has been left behind!!)
Like #RomainValeri said, you need to delete origin/feature/AAM-443:
git push --delete origin feature/AAM-443
You just have to remove the remote counterpart that's still there.
(assuming your remote is named origin here)
git push --delete origin feature/AAM-443
# or
git push origin :feature/AAM-443
This is probably a very minor thing to ask. I noticed someone on the internet typing -B instead of -b when switching to a new branch.
git checkout -B new_branch
What are the implications and when do we use the capital B.
In case of -D we force the deletion with capital D flag. What happens with with capital B.
Force deletion:
git branch -D local_branch
I tried looking at these awesome git Flight Rules but didn't find anything.
Any help would be appreciated.
From git checkout --help:
git checkout -b|-B <new_branch> [<start point>]
Specifying -b causes a new branch to be created as if git-branch(1) were called
and then checked out. In this case you can use the --track or --no-track
options, which will be passed to git branch. As a convenience, --track without
-b implies branch creation; see the description of --track below.
If -B is given, <new_branch> is created if it doesn’t exist; otherwise, it is
reset.
Context:
assume you have some rather tricky CI/CD workflow which relies on git tags
the feature branches are built and generate some short-lived tags to signify commits which yield the deployable artifacts
when the feature branch gets squash-merged, usually it's deleted, but the tags, unsurprisingly, survive
after, say, several months of development the tag listing predictably becomes hairy
Hence, the question:
how would I, using git command line and, optionally, basic bash tooling
list all the branches which have given tag reachable (the dual to that is git tag -l --merged ${BRANCH_COMMITTISH}, but I need not tags for the given branch but branches for a given tag)
list all the tags which have empty output from point 1 above (obviously this is doable with a for loop (given any terminating implementation for 1), but maybe there's some neat magical git one-liner)?
git log --simplify-by-decoration --tags --not --branches --remotes --pretty=%d
--simplify-by-decoration says only show the bare minimum needed to reveal the ancestry (usually you use this with --graph). --tags --not --branches --remotes says, well, what it says: list the tag history that's not in the branches or remotes history, i.e. tags unreachable from any branch or remote-tracking branch. --pretty=%d says just show the refs.
git branch --contains ${TAG}
https://git-scm.com/docs/git-branch#git-branch---containsltcommitgt.
Just to illustrate all solutions I've seen so far:
~$ git init dangling_tags
Initialized empty Git repository in ~/dangling_tags/.git/
$ cd dangling_tags/
~/dangling_tags$ touch a.txt && git add a.txt && git commit -m a
[master (root-commit) f1b1070] a
1 file changed, 0 insertions(+), 0 deletions(-)
create mode 100644 a.txt
~/dangling_tags$ git tag a
~/dangling_tags$ git checkout -b feature/add_some_tags
Switched to a new branch 'feature/add_some_tags'
~/dangling_tags$ touch b.txt && git add b.txt && git commit -m b
[feature/add_some_tags 1871cde] b
1 file changed, 0 insertions(+), 0 deletions(-)
create mode 100644 b.txt
~/dangling_tags$ git tag b
~/dangling_tags$ touch c.txt && git add c.txt && git commit -m c
[feature/add_some_tags 26f6611] c
1 file changed, 0 insertions(+), 0 deletions(-)
create mode 100644 c.txt
~/dangling_tags$ git tag c
~/dangling_tags$ git checkout master
Switched to branch 'master'
~/dangling_tags$ git merge --squash feature/add_some_tags
Updating f1b1070..26f6611
Fast-forward
Squash commit -- not updating HEAD
b.txt | 0
c.txt | 0
2 files changed, 0 insertions(+), 0 deletions(-)
create mode 100644 b.txt
create mode 100644 c.txt
~/dangling_tags$ git commit
[master 99b33ae] Squashed commit of the following:
2 files changed, 0 insertions(+), 0 deletions(-)
create mode 100644 b.txt
create mode 100644 c.txt
~/dangling_tags$ git branch --contains a
* master
~/dangling_tags$ git branch --contains b
feature/add_some_tags
~/dangling_tags$ git branch -D feature/add_some_tags
Deleted branch feature/add_some_tags (was 26f6611).
~/dangling_tags$ git tag
a
b
c
~/dangling_tags$ git branch --contains a
* master
~/dangling_tags$ git branch --contains b
~/dangling_tags$ for t in $(git tag); do if test "$(git branch --contains $t | wc -l)" == "0" ; then echo $t; fi done
b
c
~/dangling_tags$ git log --simplify-by-decoration --tags --not --branches --remotes --pretty=%d
(tag: c)
(tag: b)
How can I get list of files that were affected by specific user in the specified branch?
Regards, Evgeniy
This gets you a list of all files modified by user X on branch Y:
hg log --branch Y --user X --template '{join(files, "\n")}\n'
but it will have duplicate entries for files modified, added, or removed in multiple changesets on that branch. To consolidate them (on a unix-like you'd do):
hg log --branch Y --user X --template '{join(files, "\n")}\n'| sort -u
Update
If your Mercurial is to old for that fancy template to work you can probably do the same with this (if you're on a unix-like):
hg log --branch Y --user X --template '{files}\n' | tr ' ' '\n' | sort -u