I recently noticed that i have committed two tickets with wrong ticket numbers and I have to correct them now. I am new to smartgit and hence don't know much about it.
For the last commit, you can use Local|Edit Last Commit Message, for slightly older commits, make sure you are using at least version 8 and invoke Edit Commit Message in the Journal's context menu. Be careful when editing commit messages of already pushed commits.
In later versions of SmartGit version > 20.x you need to enable a preference to do this. The preference on the OS X version is at
Smartgit --> Preferences --> Commands --> Allow modifying pushing commits (e.g. forced push)
Related
I'm going through the tutorial for angularjs. In step 0 of the tutorial it instructs me to run:
git checkout -f step-0
When I ran this I got "You are in 'detached HEAD' state" which I take to mean that I just created a new feature branch called "step-0" that did not previously exist. Then I reloaded my web page and saw that all the cool stuff from the master branch is now gone. Instead I get this basic page that says "Nothing here yet!".
Now this is all correct behavior. My question is why did git checkout change the state of my code?
I could understand if the branch existed and I switched branches then yea that would change my code. But in this case it looks like the branch does not exist and I don't see a branch by the name "step-0" on github.
So in my mind I just branched off Master and created a new feature branch. Any changes in code don't make sense to me in this case.
What happened?
The "detached HEAD" message means that you're not at the tip of any branch. You've gone back to an earlier commit on the master branch, but you haven't created a new branch that begins there.
You got there by switching to the "step-0" tag. A tag in Git is basically an alias for a commit ID: "step-0" refers to the commit 96a9b5b7fa5e5667e099d25c20a4bb19992c0f72. Tags are commonly used for naming releases (e.g. a "v1.0" tag on the revision that was released as version 1.0), but in this case they're just used to make it easy to switch to specific revisions as you follow the tutorial. A branch isn't needed because you aren't going to be committing a divergent set of changes from there.
Branches and tags are similar in that they're both names that refer to commits. The difference is that a branch changes as you create new commits — the branch name is updated to refer to the new commit ID each time — whereas tags are typically used to record points in history that don't change, such as the contents of a specific released version. (It's possible to change a tag, but only in the same sense that it's possible to change the history of a branch: if you've already pushed the tag to others, you'll have to ask them to delete it and pull the new one instead. You can't force tag changes on others.)
If you want to start a new branch from the commit you've just moved to, you can do so: git checkout -b my-branch.
What is the Clearcase equivalent of git's no fast forward (--no-ff) switch? Or how can I achieve the same functionality?
BACKGROUND
The situation is we are running multiple release branches and we need to be able to pull a feature or defect fix from the release branch if required. Currently (and I'm not the one managing Clearcase) all defect work is checked directly into the release branch, so backing out changes is time-consuming and potentially error-prone.
When using git with --no-ff, I can back out a feature or defect very quickly with minimal chance of causing an issue.
In ClearCase, you would instead cancel an activity (if you are using ClearCase UCM), or cancelling merges for a set of files with negative merges.
But there is no notion of "fast-forward": there is no HEAD to move, only versions (file by file) to merge. So if you know the merged versions, you can create new versions which cancel them (that is what the negative merge does).
There is no ff but there is also no HEAD in clearcase in the sense of git. The workflow is different. You always check in your code to a new checkin (or commit in git terminology). So it is like you are always doing a merge commit
we have delivered some set of packages to testing team and they completed testing.
In one of the package they report a defect and it was fixed and delivered to integration stream. But while deliver it asked for rebase and delivery contained reabase activity.
In rebase activity due to merging issues one of the file was modified in a package which had no defect.
As testing was already completed and the changes in the delivery is not required , our team wants to delete the latest version of a file [which is added as inadvertent] in integration stream.
If i delete the version of a file , will it have any ill-effect? ( For ex. while doing rebase again)
Deleting a version is almost never a good idea.
If that version has any hyperlink: don't delete it!
(You can see it by looking at its version tree: look for any red arrow coming to or going from that version)
If that version has any tag: don't delete it.
That label is probably the result of a baseline, and that would break the integrity of said baseline.
I would recommend checkout that file, and replace its content with the right one, before check it in back in ClearCase.
See also:
"How do I undo a checkin in ClearCase remote client": rmver is dangerous
"How do I roll back a file checked in to Clearcase?": a subtractive merge is preferable to restore the right content in a new version
I have a requirement posted by the development team to reverse all changes in a given UCM activity. Constraint being we do not have delete rights. Meaning I know I can do a lsactivity to list all elements in an activity with their respective versions and then in the easy world would be able to delete those versions.
But the SCM policy does not permit us to delete/rmver anything. So I am left with back merging 1 version back. Meaning let us say I have version 5 of a.java checked into an activity. One way I think to achieve this, is find version 4 (using -predecessor) and blind copy this ver 4 as ver 6. Assume that each file has only 1 version in an activity this time. If a file had more than 1 versions checked in through an activity, this would be more complex, so lets ignore that for now.
Any other ideas or whether my approach would/would not work ?
One more robust way would be to:
list all files in an activity
for each file, find the oldest version
make a negative merge, or subtractive merge.
A subtractive merge can be performed to exclude or bypass bad versions on a branch without actually removing the bad versions.
Cleartool merge using the -delete option will allow a user to merge from the last known good version to a new version on the same branch which excludes the work done in the versions identified as bad versions.
That would be compliant with your SCM policies in place.
That is in essence what does the cset.pl script mentioned by Tamir, as I explain in "Clearcase: how to rollback all changes on specific branch?"
ccperl cset.pl -undo myActivity
After a fresh checkout, I want to get ALL files,
specifically this file: etc/config.ini
However, once I modify etc/config.ini, I do not want it committed with "svn commit ..." nor should it be reverted on a "svn up".
This would allow you to get default values on an initial checkout (convention over configuration), but then after configuring, you don't want these "local" configuration files committed into svn.
The best way to do this is not to directly version control the file.
A common way to avoid this issue is to have config.ini.sample (or something along those lines) under version control, and then config.ini ignored in your svn:ignore property.
Then, after checking out, copy config.ini.sample to config.ini and you're good to go. This way you can also version control your template config file.
If you use TortoiseSVN and/or VisualSVN (>= 1.5), you can move these files to the changelist 'ignore-on-commit'. This causes the files to show up in a separate section in the commit dialog, and never automatically selected for committing.
Obviously this is a TortoiseSVN-specific solution.
Jason already hit on the general accepted solution (the one promoted by the SVN folks themselves), but there is another option, if you're using TortoiseSVN as the client. When you're at the commit dialog, right-click the file you don't want to ever commit and choose Add To Changelist->Ignore On Commit. It will still show up in the commit dialog every time you go to commit it, but it defaults to unchecked so it won't actually be committed unless you explicitly check the box. Again, only useful for Tortoise, so if you use the same WC with a non-Tortoise client, you'll accidentally commit it.