I have noticed that when we pull changes from non-committers into our
repo, sometimes meta information about who committed the change to the
repo is included along side info about who actually wrote the changes.
For example, see
http://github.com/grails/grails/commit/8ac450c37d16b0468ba0f92d3008968fd6a41a75
and note that graemerocher has commit privileges to the repo but
ihotary does not. ihatory's commit was pulled in by graemerocher.
The commit at http://github.com/grails/grails/commit/ff770359d152683d5794887cd743a10ce7d04501
was also authored by a non committer. I pulled that change in myself
this evening. Notice that there is no info displayed there to
indicate that I (jeffbrown) am the person who pushed that change into
the repo.
I don't know what was done differently for those 2 scenarios but both
of those commits were authored by folks who do not have commit
privileges to the repo at
http://github.com/grails/grails/commits/master.
I don't think this is a github issue. If I am wrong, please let me know.
If I want to track not only who authored the commit but also who
pushed it into the repo (like you see at
http://github.com/grails/grails/commit/8ac450c37d16b0468ba0f92d3008968fd6a41a75),
what is the procedure for making that happen?
jb
--
Jeff Brown
SpringSource
http://www.springsource.com/
Autism Strikes 1 in 166
Find The Cause ~ Find The Cure
http://www.autismspeaks.org/
On Mon, 25 May 2009, Jeff Brown wrote:
I have noticed that when we pull changes from non-committers into our
repo, sometimes meta information about who committed the change to the
repo is included along side info about who actually wrote the changes.
For example, see
http://github.com/grails/grails/commit/8ac450c37d16b0468ba0f92d3008968fd6a41a75
and note that graemerocher has commit privileges to the repo but
ihotary does not. ihatory's commit was pulled in by graemerocher.
The commit at http://github.com/grails/grails/commit/ff770359d152683d5794887cd743a10ce7d04501
was also authored by a non committer. I pulled that change in myself
this evening. Notice that there is no info displayed there to
indicate that I (jeffbrown) am the person who pushed that change into
the repo.
I don't know what was done differently for those 2 scenarios but both
of those commits were authored by folks who do not have commit
privileges to the repo at
http://github.com/grails/grails/commits/master.
You say "pulled" for both commits, but do you mean that in an exact git
sense (i.e. 'git pull ...' command was used)? I assume not ...
If you pull from someone, then you get their commits, so they are the
committer - on the other hand if you apply patches they have sent, then
you become committer (though they remain the author of course) as you
create new commits (containing basically the same changes and message).
If you compare the git repository
(http://git.kernel.org/?p=git/git.git;a=summary) where all changes are
made by Junio applying patches, to the Linux kernel
(http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=summary)
where Linus pulls from many (trusted) people you can see that while the
commits in git are all committed by Junio, the kernel commits are made by
a wide variety of people.
I don't think this is a github issue. If I am wrong, please let me know.
If I want to track not only who authored the commit but also who
pushed it into the repo (like you see at
http://github.com/grails/grails/commit/8ac450c37d16b0468ba0f92d3008968fd6a41a75),
what is the procedure for making that happen?
This easiest way is to not pull from people who "don't have commit
rights" but to apply a patch series instead, as by pulling you are
basically trusting them - possibly more that you intend/want?
HTH,
--
Julian
---
When in doubt, do what the President does -- guess.
On Mon, May 25, 2009 at 6:28 PM, Julian Phillips
[off-list ref] wrote:
On Mon, 25 May 2009, Jeff Brown wrote:
quoted
I have noticed that when we pull changes from non-committers into our
repo, sometimes meta information about who committed the change to the
repo is included along side info about who actually wrote the changes.
For example, see
http://github.com/grails/grails/commit/8ac450c37d16b0468ba0f92d3008968fd6a41a75
and note that graemerocher has commit privileges to the repo but
ihotary does not. ihatory's commit was pulled in by graemerocher.
The commit at
http://github.com/grails/grails/commit/ff770359d152683d5794887cd743a10ce7d04501
was also authored by a non committer. I pulled that change in myself
this evening. Notice that there is no info displayed there to
indicate that I (jeffbrown) am the person who pushed that change into
the repo.
I don't know what was done differently for those 2 scenarios but both
of those commits were authored by folks who do not have commit
privileges to the repo at
http://github.com/grails/grails/commits/master.
You say "pulled" for both commits, but do you mean that in an exact git
sense (i.e. 'git pull ...' command was used)? I assume not ...
If you pull from someone, then you get their commits, so they are the
committer - on the other hand if you apply patches they have sent, then you
become committer (though they remain the author of course) as you create new
commits (containing basically the same changes and message).
If you compare the git repository
(http://git.kernel.org/?p=git/git.git;a=summary) where all changes are made
by Junio applying patches, to the Linux kernel
(http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=summary)
where Linus pulls from many (trusted) people you can see that while the
commits in git are all committed by Junio, the kernel commits are made by a
wide variety of people.
quoted
I don't think this is a github issue. If I am wrong, please let me know.
If I want to track not only who authored the commit but also who
pushed it into the repo (like you see at
http://github.com/grails/grails/commit/8ac450c37d16b0468ba0f92d3008968fd6a41a75),
what is the procedure for making that happen?
This easiest way is to not pull from people who "don't have commit rights"
but to apply a patch series instead, as by pulling you are basically
trusting them - possibly more that you intend/want?
HTH,
--
Julian
I understand all of that but now I am not sure what the best procedure
is. This is what I have been doing.
- create an integration branch
- pull changes from someones repo into my integration branch
- do whatever testing/reviewing/etc. necessary and if I want their
changes, continue...
- merge integration branch (which contains their changes) into my
master branch (test etc...)
- push my master to my origin
I expect there is a simple way to do what I want without having to
create patch files, but I don't know what that is.
Thanks for any suggestions.
jb
--
Jeff Brown
SpringSource
http://www.springsource.com/
Autism Strikes 1 in 166
Find The Cause ~ Find The Cure
http://www.autismspeaks.org/
Jeff Brown wrote:
On Mon, May 25, 2009 at 6:28 PM, Julian Phillips
[off-list ref] wrote:
quoted
On Mon, 25 May 2009, Jeff Brown wrote:
quoted
I have noticed that when we pull changes from non-committers into our
repo, sometimes meta information about who committed the change to the
repo is included along side info about who actually wrote the changes.
For example, see
http://github.com/grails/grails/commit/8ac450c37d16b0468ba0f92d3008968fd6a41a75
and note that graemerocher has commit privileges to the repo but
ihotary does not. ihatory's commit was pulled in by graemerocher.
The commit at
http://github.com/grails/grails/commit/ff770359d152683d5794887cd743a10ce7d04501
was also authored by a non committer. I pulled that change in myself
this evening. Notice that there is no info displayed there to
indicate that I (jeffbrown) am the person who pushed that change into
the repo.
I don't know what was done differently for those 2 scenarios but both
of those commits were authored by folks who do not have commit
privileges to the repo at
http://github.com/grails/grails/commits/master.
You say "pulled" for both commits, but do you mean that in an exact git
sense (i.e. 'git pull ...' command was used)? I assume not ...
If you pull from someone, then you get their commits, so they are the
committer - on the other hand if you apply patches they have sent, then you
become committer (though they remain the author of course) as you create new
commits (containing basically the same changes and message).
If you compare the git repository
(http://git.kernel.org/?p=git/git.git;a=summary) where all changes are made
by Junio applying patches, to the Linux kernel
(http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=summary)
where Linus pulls from many (trusted) people you can see that while the
commits in git are all committed by Junio, the kernel commits are made by a
wide variety of people.
quoted
I don't think this is a github issue. If I am wrong, please let me know.
If I want to track not only who authored the commit but also who
pushed it into the repo (like you see at
http://github.com/grails/grails/commit/8ac450c37d16b0468ba0f92d3008968fd6a41a75),
what is the procedure for making that happen?
This easiest way is to not pull from people who "don't have commit rights"
but to apply a patch series instead, as by pulling you are basically
trusting them - possibly more that you intend/want?
HTH,
--
Julian
I understand all of that but now I am not sure what the best procedure
is. This is what I have been doing.
- create an integration branch
- pull changes from someones repo into my integration branch
- do whatever testing/reviewing/etc. necessary and if I want their
changes, continue...
- merge integration branch (which contains their changes) into my
master branch (test etc...)
- push my master to my origin
I expect there is a simple way to do what I want without having to
create patch files, but I don't know what that is.
Thanks for any suggestions.
Rebase instead of merging, or rebase interactively onto the mergebase
of your integration branch and master if you want to preserve the
merge commits. Since rebase is basically implemented as either
format-patch + am, or cherry-pick (depending on the invocation used),
it will create new commits where you become the committer.
To preserve the merge-commits when integrating you should use a
command such as this. I'm assuming assuming your integration branch
is named 'integrate' and your primary release branch is called
master:
GIT_EDITOR=: git rebase -i --onto $(git merge-base integrate master) \
integrate
Mind the continued line, please.
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
Register now for Nordic Meet on Nagios, June 3-4 in Stockholm
http://nordicmeetonnagios.op5.org/
Considering the successes of the wars on alcohol, poverty, drugs and
terror, I think we should give some serious thought to declaring war
on peace.