I created a new GitLab project and migrated my existing code from SVN following the
"Migrating from SVN to GitLab" instructions. All the project commits and contributors appear in the Commits view and elsewhere.
However, in the Graphs/Contributors commits are misattributed and some contributors don't appear at all. Is this somehow expected or is this an indication that the migration was not 100% successful?
It turns out this was caused by not following well the format specification of the authors.txt file. The file should look like this:
janedoe = Jane Doe <janedoe#example.com>
johndoe = John Doe <johndoe#example.com>
but instead we did this
janedoe = (blank) <janedoe#example.com>
johndoe = (blank) <johndoe#example.com>
After reimporting the SVN repository it looks as expected and the names show up everywhere.
Related
The way all version control systems I'm familiar with work is that each commit is attributed to a single developer. The rise of Agile Engineering, and specifically pair programming, has lead to a situation where two developers have made a significant contribution to the same task, a bug fix for example.
The issue of attribution won't be too much of a big deal in a work environment since the project manager will be aware of the work the pairs are doing, but what about if two open source contributors decide to pair up and push out some code to a particular project that has no idea they're working together. Is there any way for a version control system like Git to attribute a particular patch to multiple developers?
Commit title
Commit body
Co-authored-by: name <additional-dev-1#example.com>
Co-authored-by: name <additional-dev-2#example.com>
Supported by GitHub and GitLab
Used by others: https://git.wiki.kernel.org/index.php/CommitMessageConventions
One problem with this approach is that you can't create a signed key for this group of devs, so you could essentially add anybody to this list even if they didn't work on a feature and GitHub would treat it as if they did. However, this shouldn't be an issue in most cases.
e.g. Co-authored-by: Linus Torvalds <torvalds#linux-foundation.org>
With normal authors or signing groups (the old method) you would see it's not signed and know that you can't trust the commit. However, there is no signing process on co-authors.
Mostly outdated answer:
One solution would be to set a name for the pair:
git config user.name "Chris Wilson and John Smith"
Here is a related bug report with other temporary solutions:
Bug git-core: Git should support multiple authors for a commit
A git convention is to use Co-Authored-By at the end of the commit message (git kernel: Commit Message Conventions, referring to Openstack Commit Messages). This is also one of the solutions on the git-core bug linked in Gerry's answer
Co-authored-by: Some One <some.one#example.foo>
In that comment on May 5, 2010, Josh Triplett also suggests implementing corresponding support in git.
As Llopis pointed out in a comment, GitHub announced support for this on their blog on Jan 29, 2018: Commit together with co-authors (details).
For Bazaar:
bzr commit --author Joe --author Alice --author Bob
Those names will be shown in the log separately from committer name.
git-pair
https://github.com/pivotal/git_scripts#git-pair
This simple script from Pivotal to automate Git pair programming attribution.
You create a .pairs file like:
# .pairs - configuration for 'git pair'
pairs:
# <initials>: <Firstname> <Lastname>[; <email-id>]
eh: Edward Hieatt
js: Josh Susser; jsusser
sf: Serguei Filimonov; serguei
email:
prefix: pair
domain: pivotallabs.com
# no_solo_prefix: true
#global: true
and then:
git pair sp js
sets:
user.name=Josh Susser & Sam Pierson
user.email=pair+jsusser+sam#pivotallabs.com
for you.
git distinguishes between a commit's author and committer [1]. You could use it as a work-around, e.g. sign yourself as the committer and your co-author as the author:
GIT_COMMITTER_NAME='a' GIT_COMMITTER_EMAIL='a#a' git commit --author 'b <b#b>'
This way, both you and your co-author will be recorded in the git history. Running git log --format=fuller, will give you something like:
commit 22ef837878854ca2ecda72428834fcbcad6043a2
Author: b <b#b>
AuthorDate: Tue Apr 12 06:53:41 2016 +0100
Commit: a <a#a>
CommitDate: Tue Apr 12 09:18:53 2016 +0000
Test commit.
[1] Difference between author and committer in Git?
Try git-mob, we built it for attributing co-authors on commits.
E.g.
git mob <initials of co-authors>
git commit
git solo
Alternatively, there is an open source project, which I contribute to, on GitHub that provides a good way to do it from the command line. This project helps you to set an alias in order to create co-autored commits as follows:
$ git co-commit -m "Commit message" --co "co-author <co-author-email>"
Using this approach, you are able to create co-authored commits without a graphical interface.
We add our names to each commit message at the end as a convention
eg : Implemented cool feature <Aneesh | Hiren>
Most of the co-author tools do not support autocompletion. You can try git-coco, its written in python3 (I'm the developer). git-coco supports autocomplete and auto-suggest.
Here is a snapshot
autocomplete on sample authors
I am new to perforce. A weird behaviour of perforce is causing quite a bit of trouble. My original repo (the one that pushes to remote server) has
p4 changes
Change 3 on 2017/06/23 by user#user-dvcs-1498104674 'add test-copy.go'
Change 2 on 2017/06/23 by user#user-dvcs-1498104674 'add test.go'
Change 1 on 2017/06/22 by user#user-dvcs-1498104674 '"first sub repo" '
but my cloned repo (a newly created folder to make a clone from remote server) has
p4 changes
Change 6 on 2017/06/23 by user#user-dvcs-1498104674 'add test-copy.go'
Change 5 on 2017/06/23 by user#user-dvcs-1498104674 'add test.go'
Change 4 on 2017/06/22 by user#user-dvcs-1498104674 '"first sub repo" '
does anyone have a good idea to get around this when the resource action is to checkout a particular commit?
This is causing a problem when my colleague create a clone of my repo we reference to the same commit with the changelist number, whereas in git a commit sha is consistent across server and different clones.
Use the submit.identity configurable to set global IDs on changelists that will be preserved across servers:
https://www.perforce.com/perforce/r15.2/manuals/dvcs/fetching.changelists.html#fetching.track_identity
I'd like to enable wild repos except for one subrepo. For example:
repo proj/..*
C = #ops
RW+ = #all
repo proj/secret
RW+ = bob
I'd like to make sure that only Bob has access to proj/secret but others can create all the other repos they want. Is that possible? Would the second repo definition overwrite the first one?
I have the following setup. I want to check that commits have a certain commit message format (line limit, etc.). I want this for all repos, but one or two.
How can I tell this gitolite without having to define a group #check_msg that contains most repos. This would be cumbersome...
In my BADCOMMIT VREF, I already included some lines to not check the message if it is called with NOCHECK.
Any ideas??
repo testing
RW+ = #all
? VREF/BADCOMMIT/NOCHECK = #all
repo #all
- VREF/BADCOMMIT = #all
repo gitolite-admin
RW...
Instead of using git notes, I suggest you do this:
repo testing
RW+ = #all
option badcommit.nocheck = 1
repo #all
- VREF/BADCOMMIT = #all
Then, at the start of the VREF, you say
gitolite git-config -q $GL_REPO gitolite-options.badcommit.nocheck && exit 0
Much cleaner, and the knowledge of the exceptions stays within gitolite.conf.
(Assuming v3 of course).
Considering:
that a VREF has no idea of the git repo name or path it is called from, adding:
fallthrough means success (which means, as matt comments, that it will check all the VREFS)
The only solution seems for the VREF script "BADCOMMIT" to somehow detects it is in a git repo it should not test.
If, by convention, said git repo were to contain a **git notes (**which you can add at any time, without changing the git history, see man git notes) with a certain title on this note, it could decide to not go on with its check.
Since there are few git repos which shouldn't be tested with BADCOMMIT, you could add a note to the first commit of that repo.
That way, you don't need a NOCHECK, and you don't need to stop after a certain rule.
I'm having some problem to get a specific Label version for an old tree path (moved, renamed, etc..) in TFS2008.
The problem I have is the following:
I renamed and moved some portion of tree version files and folder and now I'm not able to get a specific version from a specific Label. This Label was applied on the old tree path, and when I get specific version (with overwrite options checked) appear "Not downloaded" on the Latest column and I'm not able to work on the old baseline (labelled files and folder).
There is the way to get specific version in a custom target path?
The TFPT are helpful to do this?
Thanks!
The solution is get specific version Label on the project root, so the old tree version path is proposed.
Nicola Celiento: I was about to post this as new question when I saw your question and answer, which have also worked for me.
I had a branch called $/MyProject/Dev/OldName, which was renamed to $/MyProject/Dev/NewName in May 2015. I now want to get all the files for this branch as of April 2014 (before the branch rename), but I can't work out how to do this. So far I have tried:
Creating a new workspace mapped to $/MyProject/Dev/NewName. Do Get Specific Version on $/MyProject/Dev/NewName, set Type to Date as of April 2014, set Overwrite writeable files and Overwrite all files. This results in the message: "All files are up to date. No files were updated because the requested file versions were previously downloaded. To force an update, use the "Get Specific Version" command with the "Overwrite all...) option checked." This message is odd because it is telling me to do precisely what I have done to get the message! In Source Control Explorer all files have a status of Not downloaded.
From the command line, do a get using the new branch name (does not work - no files in workspace):
C:\Workspace>tf get $/MyProject/Dev/NewName /version:D"2014-04-08 21:00:00" /overwrite /force /recursive
All files are up to date.
From the command line, do a get using the old branch name (also does not work - no files in workspace):
C:\Workspace>tf get $/MyProject/Dev/OldName /version:D"2014-04-08 21:00:00" /overwrite /force /recursive
No appropriate mapping exists for $/MyProject/Dev/OldName.
Changed my workspace to map to the old branch $/MyProject/Dev/OldName, and then repeated the previous get (also does not work - no files in workspace):
C:\Workspace>tf get $/MyProject/Dev/OldName /version:D"2014-04-08 21:00:00" /overwrite /force /recursive
C:\Projects:
Getting OldName
Using View History on individual files, I can see the files definitely existed at April 2014, and I can also see their contents, I just can't get them for that date (but I can get them OK after the branch rename).
Based on Nicola Celiento's answer the solution for me was to Get Specific Version on the root $/MyProject/Dev project. This got all the branches below $/MyProject/Dev, including the old $/MyProject/Dev/OldName that I wanted.