The problem:
I'm using bitbucket stash (server) API in a script for my project with the {path} api method:
/rest/api/1.0/projects/{projectKey}/repos/{repositorySlug}/browse/{path:.*}
The idea was to save versions of config files in a repository (version01-versionXX for every config). But those configs have the same structure with different names and parameters,
so when I push a new config with a commit message like 'version01' without specifying any sourceCommitId, bitbucket automatically adds a parent commit from the last file with the same structure (if it exists). As a result, in this new file's history I'm getting several 'version01' commits, which is not what I was intended to have.
What I've tried:
If I do specify sourceCommitId as the initial or the last commit on the branch, I get an error message since the file doesn't exist on this commit.
I've tried to experiment with empty sourceBranch parameter, but still some parent commit appears.
The only idea I came up with is to create a new branch for every config, but this seems like overkill to me.
All attempts to find a method for editing file commit history via API also failed.
At the moment as a work around I create every config file with its name as the only line of its content and then change it to the structure I need. This works so far, but doesn't look like a good solution to me and requires 2 API requests instead of one.
Is there a better way to prevent BitBucket from treating those new files as copies of old ones?
Related
I am using /rest/api/1.0/projects/{projectKey}/repos/{repositorySlug}/browse/{path:.*}
to push commit to a file using Bitbucket.
I am able to do that successfully with branch, content, sourceCommitId , etc as parameters.
My question is : Do I need to worry about conflicts when using this API ? The error messages returned are about file not being present, contents not changed, etc but will there ever be a scenario where despite giving the last commit ID (in soureCommitId) , there will be conflicts ?
Does Bitbucket overwrite the file blindly ? (that would work for me)
Thanks!
Yes, BB will overwrite the file.
You can pass branch name instead the commit.
This will update the tip of branch.
I’m using Docusaurus / Travis CI to build my docs and I’m trying to have them hosted on a custom domain - myproject.com. The way I have it setup right now Travis CI initiates a build every time I do a commit BUT the custom domain gets wiped out every time this happens. I can duplicate the issue by manually initiated builds myself.
It happens regardless of what the repo name is. I’ve tried myproject.github.io as the repo name and myproject.com (to match the custom domain) as the repo name. In both cases the custom domain gets wiped. When the repo name is myproject.github.io the site gets published to https://myproject.github.io/ and when the repo name is myproject.com the site gets published to https://myproject.github.io/myproject.com/ .
Am I just going to have to remember to always re-add the custom domain every time I make a commit to my build branch? 🙄
I had this issue, if you're pushing something to the gh-pages branch. it could be that you're not preserving the CNAME file.
When you add a custom domain, github automatically adds a CNAME file to your gh-pages branch with your domain inside it.
I figured this out. Farook's post pointed me in the right direction.
So when the branch is named myproject.github.io the master branch is used for deployments. Like myproject.github.io is a mirror of what's in the master branch.
The problem is that the *.md files that you modify to work with Docusaurus aren't the end product so you have to work out of a branch other than master. Within that branch a lot of the root contents are built from the *.md files but the rest of it is copied from the website/statics directory so I just put the CNAME file there and that worked!
I do alot of personal development tweaks on code on my side, like adding an account automatically, opening up sublime in a certain way when there's an exception (with a rescue_from from an ApplicationController), and other misc tweaks I think are very useful for me but that I don't think I should/other colleagues would like to have committed.
I searched around a bit and supposedly git doesn't have any way to ignore single file lines.
I figured a solution (albeit probably a little complicated and involving markup) would be using Git pre-commit hooks, but... doesn't sound very neat to me.
How can I keep personal code tweaks on my side, inside existing, committed files, without manually stashing/restoring them between commits, while also being branch-independent?
I searched around a bit and supposedly git doesn't have any way to ignore single file lines.
Good news you can do it.
How?
You will use something called hunk in git.
Hunk what?
Hunk allow you to choose which changes you want to add to the staging area and then committing them. You can choose any part of the file to add (as long as its a single change) or not to add.
Once you have chosen your changes to commit you will "leave" the changes you don't wish to commit in your working directory.
You can then choose if you want this file to be tracked as modified or not withe the help of the assume-unchanged flag.
Here is a sample code for you.
# make any changes to any given file
# add the file with the `-p` flag.
git add -p
# now you can choose form the following options what you want to do.
# usually you will use the `s` for splitting up your changes.
git add -P
Using git add -p to add only parts of changes which you will choose to commit.
You can choose which changes you wish to add (picking the changes) and not committing them all.
# once you done editing you will have 2 copies of the file
# (assuming you did not add all the changes)
# one file with the "private" changes in your working dir
# and the "public" changes waiting for commit in the staging area.
Add the file to .gitignore file
This will ignore the file and any changes made to it.
--assume-unchaged
Raise the --assume-unchaged flag on this file so it will stop tracking changes on this file
Using method (2) will tell git to ignore this file even when ts already committed.
It will allow you to modify the file without having to commit it to the repository.
git-update-index
--[no-]assume-unchanged
When this flag is specified, the object names recorded for the paths are not updated. Instead, this option sets/unsets the "assume unchanged" bit for the paths. When the "assume unchanged" bit is on, the user promises not to change the file and allows Git to assume that the working tree file matches what is recorded in the index. If you want to change the working tree file, you need to unset the bit to tell Git. This is sometimes helpful when working with a big project on a filesystem that has very slow lstat(2) system call (e.g. cifs).
Git will fail (gracefully) in case it needs to modify this file in the index e.g. when merging in a commit; thus, in case the assumed-untracked file is changed upstream, you will need to handle the situation manually.
We have a solution stored in TFS that deploys to SharePoint. As part of the solution we have a config file that has a path to a specific site. The problem is this path changes dependent on the users dev machine e.g
<site>devmachine1/somesite</site>
<site>devmachine2/somesite</site>
This can obviously be updated to work locally after a check out however when the file gets checked back in it will be incorrect on the next users machine if they do a Get. Is there a way that the file can be excluded or a script can be run to update the path when checked back in or out?
The best option I'd to rationalist all of the developer workstations.
I would do this by adding an identical entry to the hosts file that hard coded the name of the Sharepoint, allowing you to have the same config file work on every dev machine.
Make it dynamic by having a pre build instruction that adds the host, that way any developer can get and build.
You can use a custom check-in policy to update back the file when is checked-in. See here
I've got a need to checkout an entire source tree out of one server and check it into another server. I'm attempting to script this into a final builder script, but am running into some snags. I'm able to check everything out, but when I attempt to check it into the new server it tells me there are no pending changes. Obviously I'm missing something if this is even possible.
Anyone done something similar to this or know of a way I might accomplish this?
One more thing, if the src is empty on server 2 would I have to manually add the files before I can update them?
I would guess that the reason that TFS is saying no pending changes is that you haven't checked out the files from Server 2. This could get kind of ugly using a single directory, so I would recommend trying this:
Get (latest or specific version) from server 1 to
C:\Server1Files...
Get and Check out for edit everything from server 2 to
C:\Server2Files...
Copy from C:\Server1iles1\ to C:\Server2Files
Check in from C:\Server2Files
I think TFS is going to complain if you try to use a single directory here, as it would see the same directory mapped to two different workspaces (even though they're on different instances of TFS).