Is there a git hook that runs when I hit the "Commit" button in SourceTree?
What I am trying to do is add everything. I've tried the following, in the file ./git/hooks/pre-commit:
#!/bin/sh
git add .
echo "hook added everything!"
It runs all right, but the timing is wrong -- it appears to run as a part of actually performing the commit. So what happens is that git first decides that that nothing has been added, so the commit needs to fail. THEN it runs the hook and adds everything. Lastly, the commit fails. If I repeat the commit, it will succeed the second time. But that's wrong on several levels. What I really want is to add everything before it opens up the window for the commit message. Then if I want to un-add some stuff, I should be able to do that in that window. Lastly, when I tell SourceTree to go ahead with the commit, I don't actually want a hook at that point, as I've already configured add/remove the way I want it to be.
The problem is, you cannot commit in SourceTree unless you have added something by staging it for commit.
You're trying to start the commit process in SourceTree before having staged anything - you simply cannot do that.
Related
I've managed to fetch from the remote, and I'm running the code below to get the changes staged in the local master branch.
git_annotated_commit * fetchhead_commit;
git_annotated_commit_lookup(&fetchhead_commit,
repo,
oid
);
git_merge(repo,&fetchhead_commit,1,NULL,NULL);
So now if I use the git command line tool to commit I get an automatic merge commit comment and after I can see that the log is the same as from the remote. I'm trying to obtain the same with libgit but my efforts so far in trying to create a commit of the merge results in the remote history to be lost.
How should I do a "proper" commit of the merged changes in order to preserve the history from the remote?
EDIT: Got a little further by doing a fast forward, but still if there are local commits these are lost after the incoming merge. Local changes are not lost, but staged after the merge and have to be committed again.
You can see my code here: https://github.com/fintechneo/libgit2/blob/master/jsbuild/jslib.c
The merge is happening in the fetchead_foreach_cb function which again is called from jsgitpull
And for the record this hack does work in the web-browser if anyone wonders what the emscripten stuff is about.
Create the merge commit with git_commit_create. The merge commit should have two parents. One is the current HEAD commit. The second is the same annotated commit you merged in git_merge (e.g. the fetch head).
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.
I was just updating my webapp on AppEngine but it got stuck while compiling. I pressed CTRL-C to abort, and appcfg.py gave me some output that it would rollback the update. Since this had happened multiple times today and I knew that there was an update, I downloaded the newest Python SDK, deleted the old one and tried to update again. Now it keeps telling me that there is still a transaction going on by myself, but whenever I try to rollback using ~/google_appengine/appcfg.py update rollback [my-app-directory] it says that the Directory does not contain an rollback.yaml file. I am absolutely sure I did not delete any file in that directory.
Is there any way to solve this without having to use a new ID?
rollback is a command like update. You need to rollback the previous update before launching a new update:
appcfg.py rollback [my-app-directory]
then
appcfg.py update [my-app-directory]
I found out what to do myself. I set the version in the app.yaml file to 2 and was then able to update it. Next thing I did was to go to appengine.google.com, chose "Versions" on the left and selected the new one as default.
During a rebase, TortoiseGit gave me a list of conflicts to resolve. I did that and tried to commit, but then it complained that I was committing to a detached head. I was given the option to create another branch which I declined.
I've read somewhere that you don't normally want to commit to a detached head, but I read elsewhere that this is a normal part of the rebase operation. It appeared to work fine, and nothing seems to have been lost.
Did I do the right thing committing to a detached head in this case?
The rebase dialog has a commit button for this case - there is no need for a manual commit.
If you do a manual commit you create an additional commit in the history.
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.