I want to switch to Perforce Fusion to use git with Perforce. As I understand, whenever I push a commit it creates a submitted changelist on the Perforce server. Is there any way to create pending changelist from git?
Git Fusion stick's to Git's all or nothing approach when dealing with pushes.
Either all of the commits that make up a push make it in to the Helix Server (P4D) or none of them do.
It therefore does not provide an option to store Git Commits in pending changelists, because then the chance of commits that make up a push being split up or becoming out of order would be greatly increased.
Hope this helps,
Jen.
Related
We recently migrated from using Subversion and Trac to Git and GitLab. We successfully migrated all of our old data.
I'm still trying to learn GitLab and generally like it better than Trac, but one thing I don't like as much is that when you reference a GitLab Issue in the git commit, it adds a reference and link to that commit under the issue, but you have to browse to the commit itself to see the associated Git commit message.
In Trac, we had it configured such that the Subversion commit messages were all displayed in the Trac ticket with the commit link, so it was easier to view all the relevant information for that ticket in one place.
Is there a way to configure GitLab to display the Git commit message with the Git commit link that shows up under Issues? The message does show up in the commit list, but not on a referenced Issue.
I thought about trying to use a server hook to generate a note with the Git commit message when a commit is made, but just wondering if there is an easier/better way to accomplish this?
There is no built-in way to show the commit message of a crosslinked commit in the issue log. After all, commits are handled the same way as any other mentions: in the issue's history/mention log.
While the example in GitLab's documentation unfortunately misses the opportunity to show an example of a mention in the commit, here's an issue from GitLab itself with a mention. This commit also shows how mentions often get used within commits—with keywords:
Merge branch '65375-broken-master-gitlab-svg-path-test-failing' into 'master'
Update failing jest snapshot
Closes #13186
See merge request gitlab-org/gitlab-ee!14933
These kind of commits close the specific issue and don't require any further user action. Adding that kind of noise to the discussion/comment section of an issue is, in my opinion, only cluttering the discussion between actual humans*. However, the commit still shows up in the log and is clickable and hoverable.
To get back to your question:
Is there a way to configure GitLab to display the Git commit message with the Git commit link that shows up under Issues?
If you hover over the linked commit, then you'll get the commit's subject. There's nothing more that can be achieved within GitLab itself.
I thought about trying to use a server hook to generate a note with the Git commit message when a commit is made, but just wondering if there is an easier/better way to accomplish this?
If you follow the usual commit/merge message based issue closing and use [Closes?|Fix(es)?] #issue in your commit message, you may end up with more noise in the comments than you would like too.
* well, except for some bots
I am working on my master branch and have some uncommitted changes inside the master branch. I have already created a feature branch and I am able to switch to my feature branch using the git checkout feature_branch command. I have couple of doubts here which I am listing below:
Why am I seeing the uncommitted changes in my branch when I have made my changes inside my master branch. If I commit my changes in the master branch and switch to my feature branch, I do not see the committed changes specific to master. I am expecting the same behavior for uncommitted changes also.
I came across the stash command in Git and there it was mentioned that if you have any uncommitted changes inside the master branch, and would like to switch to some other branch, git will not allow you and hence you need to stash the changes inside the master branch and then only switch to the development branch. I did not face this issue. Am I missing something here and if so, what is the significance of using the stash command?
If I commit my changes in the master branch and switch to my feature branch, I do not see the committed changes specific to master. I am expecting the same behavior for uncommitted changes also.
That's not a sensible behavior. Uncommitted changes are by definition not made to a branch. Branches are pointers to commits, and there is no commit associated with uncommitted changes. They are made to your working directory and have nothing tying them to any branch. They aren't even associated with Git. Until you commit (or stash) them, Git does absolutely nothing to track them, and it will never try to manage them for you.
I came across the stash command in Git and there it was mentioned that if you have any uncommitted changes inside the master branch, and would like to switch to some other branch, git will not allow you and hence you need to stash the changes inside the master branch ...
That's wrong. Stashes don't exist inside any branch. There is one global pool of stashes.
... I did not face this issue.
You will only be prevented from switching branches if doing so would cause your uncommitted changes to be overwritten.
Am I missing something here and if so, what is the significance of using the stash command?
You only need to worry about stashing your changes if they affect any files that would be changed by switching branches. If you have modifications to a file that is identical between two branches, switch from one branch to the other will not require a stash. If the file is different on your other branch, Git will not let you switch branches, as this would destroy your uncomitted changes.
It is safe to try switching branches, and if Git warns you that "uncommitted changes would be overwritten" and refuses to switch branches, you can stash your changes and try again.
Summary: What is the equivalent to git pull and git push when using P4Sandbox?
Details:
I'm more familiar with git so I'm trying out using P4Sandbox with Perforce. I've been able to commit my changes in my local sandbox, but I am having trouble pushing them to the central server. I'd prefer to use P4V, but knowing the command line option to complete this task would be great as well.
Submitting changes to the "mirror" stream will cause P4Sandbox to submit to the shared server. Similarly shelving a change to the "mirror" stream will cause P4Sandbox to shelve to the shared server.
In the stream graph of P4V you should will see a stream at the top of the graph with a badge that looks is using echolocation. Right click that and select "Copy to ''". In the resulting dialog select the child stream that has the contents you want to push, enter a changelist description, and press 'Copy'.
From the command line, you can run 'p4 copyup' from the development stream you want to push. This will copy your changes up and switch your workspace. A 'p4 submit' at this point will send the changes to the shared server.
I have a bare git repository that I use to push to and pull from on a linux machine (let's call the bare git repository remote originlinux). From my working repository that has originlinux as a remote I push and pull until finally I decide to put it on github. I add the repository for github on their web gui and add the remote repository on my working repository (let's call the remote origingithub) using the git remote add command followed by git pull --rebase, then git push (pull before push since I wasn't allowed to simply push to a newly created github repository without getting one of these: 'hint: Updates were rejected because the tip of your current branch is behind'. I figure this has something to do with their option to create a readme file). And here's the issue, after performing these steps, the originlinux repository is completely not synced with the origingithub repository even though they have exactly the same commits and were pushed to from the same exact working repository. Could someone please explain in good detail why this occurring and also what I could do differently to prevent this from happening without reordering how I create my remote repositories? It seems like the workflow or order of operations I'm using doesn't make sense in git land, but how else would you keep multiple remote repositories sync'd on one working copy?
Thanks!
The two repositories do not have the same commits.
When you did git pull --rebase, you rewrote the entire history of the project so that every revision contains that readme file. So every commit in the history will have a different SHA1 identifier.
There are a couple of ways that you may be able to recover from this.
First, you could revert the state of your local repository to match the state or your first (non-github) remote. This would eliminate the readme file that you created on github (you can copy that to some other location and add it back in to git later if desired), along with any changes that you hadn't pushed to the first remote (including changes that haven't been committed).
git reset --hard originlinux/master
git push -f origingithub
The -f option there causes the push to be forced even though that is removing some commits. This is something that should be avoided in general, but it is sometimes necessary such as in this case.
The other option would be to just do a force push to your first remote, accepting the new history caused by the rebase.
git push -f originlinux
If the three repositories that you mentioned are the only ones, it shouldn't matter much which of these methods you use. If there are other repositories you may want try to determine which version of the history is more widely known, and keep that version.
I noticed that in my developpment team, sometimes someone forgets to commit a file that must go with an other to keep the site working. this causes problemes and waste of time...
The question is : Is it possible to tell SVN tortoise : if someone tries to commit a file A without files (A1, A2,...An) ask them if they are sure they don't need to commit them too?
You need to have look at hooks.hook is nothing but a program triggered by some repository event.You can write whatever set of activities(alert in your case) inside hooks.use pre hooks for running the hooks before any task take place.
EDIT:
Refer commit monitor.CommitMonitor is a small tool to monitor Apache™ Subversion® repositories for new commits.