Anonymous commit (empty Author and Committer)
See http://git.savannah.gnu.org/cgit/grub.git/commit/?id=206676601eb853fc319df14cd3398fbdfde665ac
I was not even aware that this is possible. Is there anything on server side that can prevent it?
Would be good if commit were amended and force pushed to fix it.
Quoted 5 lines · On Fri, 30 Oct 2015 17:26:00 +0300 Andrei Borzenkov <[email protected]> wrote:
See
http://git.savannah.gnu.org/cgit/grub.git/commit/?id=206676601eb853fc319df14cd3398fbdfde665acI was not even aware that this is possible. Is there anything on server side that can prevent it?
A hook running on "update" event could check the commits being pushed and reject the update if some commit among those does not pass the necessary checks.
Please see the githooks(5) manual page.
A message that is not in the archive (sent off-list or not yet received): [email protected]
Quoted 15 lines
19df14cd3398fbdfde665acQuoted 10 lines
I was not even aware that this is possible. Is there anything on server side that can prevent it?
Would be good if commit were amended and force pushed to fix it.
Quoted 6 lines
Is this even a problem? I'm pretty sure Git warns you if you try to commit something before user.name and user.email are defined, and if someone wants to do so, I don't see why you should try to stop them. It wouldn't work, anyway; they would just write some simple name like "anonymous" and some nonsense email if they really want to be anonymous.
This commit just removed a line from the README:
"Please look at the GRUB Wiki <http://grub.enbug.org> for testing-procedures."
Is this change something that may justify that it's-not-me-there action? I agree that it should not be prevented to avoid some pressure situations that might be (eventually) present. Bogus random data there would be harder to track. The empty fields are easy, and if it guarantees some safety to whoever does it, should be the choice.
Signature · 1 line
http://www.fastmail.com - mmm... Fastmail...
Quoted 4 lines · Andrei Borzenkov
See http://git.savannah.gnu.org/cgit/grub.git/commit/?id=206676601eb853fc319df14cd3398fbdfde665ac
I was not even aware that this is possible. Is there anything on server side that can prevent it?
I would have thought that receive.fsckObjects would reject it, but seems that git-fsck does not complain about it at all, as it is otherwise syntactically valid (a space separating the zero-length name from the email, and <> surrounding the empty email).
We do complain during "git commit" about an empty name. We don't seem to do so for blank emails, though. The only discussion I could find mentions that should probably disallow both[1].
I wonder how this commit was created in the first place (through git-commit, and we have an empty-name case that is not covered, or using a lower-level tool that bypasses the checks).
-Peff
[1] http://article.gmane.org/gmane.comp.version-control.git/261237
Quoted 9 lines · Andrei Borzenkov
See
http://git.savannah.gnu.org/cgit/grub.git/commit/?id=206676601eb853fc319df14cd3398fbdfde665acI was not even aware that this is possible. Is there anything on server side that can prevent it?
Would be good if commit were amended and force pushed to fix it.
It is a bug in SGit. I'll investigate how it happened
Quoted 6 lines
_______________________________________________
Grub-devel mailing list
[email protected]
https://lists.gnu.org/mailman/listinfo/grub-devel
.
Quoted 19 lines · Vladimir 'φ-coder/phcoder' Serbinenko
Quoted 9 lines · Andrei Borzenkov
See
http://git.savannah.gnu.org/cgit/grub.git/commit/?id=206676601eb853fc319df14cd3398fbdfde665acI was not even aware that this is possible. Is there anything on server side that can prevent it?
Would be good if commit were amended and force pushed to fix it.
It is a bug in SGit. I'll investigate how it happened
Quoted 6 lines
_______________________________________________
Grub-devel mailing list
[email protected]
https://lists.gnu.org/mailman/listinfo/grub-devel
.
Quoted 6 lines · Vladimir 'φ-coder/phcoder' Serbinenko
Quoted 5 lines · Vladimir 'φ-coder/phcoder' Serbinenko
Quoted 4 lines · Andrei Borzenkov
See
http://git.savannah.gnu.org/cgit/grub.git/commit/?id=206676601eb853fc319df14cd3398fbdfde665ac
Quoted 6 lines
Quoted 6 lines
Quoted 5 lines
I was not even aware that this is possible. Is there anything on server side that can prevent it?
Would be good if commit were amended and force pushed to fix it.
It is a bug in SGit. I'll investigate how it happened
I don't have non-fast-forward rights. Does someone from savannah-users have them? Could he just delete this commit?
Quoted 10 lines · Vladimir 'φ-coder/phcoder' Serbinenko
Quoted 9 lines · Vladimir 'φ-coder/phcoder' Serbinenko
Quoted 8 lines · Vladimir 'φ-coder/phcoder' Serbinenko
Quoted 7 lines · Andrei Borzenkov
See
http://git.savannah.gnu.org/cgit/grub.git/commit/?id=206676601eb853fc319df14cd3398fbdfde665acI was not even aware that this is possible. Is there anything on server side that can prevent it?
Quoted 6 lines
Quoted 3 lines
Quoted 3 lines
Quoted 2 lines
Would be good if commit were amended and force pushed to fix it.
It is a bug in SGit. I'll investigate how it happened
I don't have non-fast-forward rights. Does someone from savannah-users have them? Could he just delete this commit?
If you do that, then anyone that already did a pull after it went in will have a broken tree. Rather annoying.
Signature · 1 line
Len Sorensen
30.10.2015 23:59, Lennart Sorensen пишет:
Quoted 13 lines · Vladimir 'φ-coder/phcoder' Serbinenko
Quoted 12 lines · Vladimir 'φ-coder/phcoder' Serbinenko
Quoted 11 lines · Vladimir 'φ-coder/phcoder' Serbinenko
Quoted 10 lines · Andrei Borzenkov
Quoted 9 lines
See
http://git.savannah.gnu.org/cgit/grub.git/commit/?id=206676601eb853fc319df14cd3398fbdfde665acI was not even aware that this is possible. Is there anything on server side that can prevent it?
Would be good if commit were amended and force pushed to fix it.
Quoted 8 lines
Quoted 4 lines
Quoted 1 line
Quoted 1 line
It is a bug in SGit. I'll investigate how it happened
I don't have non-fast-forward rights. Does someone from savannah-users have them? Could he just delete this commit?
If you do that, then anyone that already did a pull after it went in will have a broken tree. Rather annoying.
If we decide to fix this commit it is better done now, while it is the last one. It is annoying but do you have suggestion how it can be done differently?
Quoted 3 lines · Andrei Borzenkov
If we decide to fix this commit it is better done now, while it is the last one. It is annoying but do you have suggestion how it can be done differently?
Well the only options are:
1) Leave it alone
2) Break the tree of anyone that already pulled. (Posting instructions on how to fix it would at least be nice then).
Not sure how many people regularly pull the tree.
Signature · 1 line
Len Sorensen
Quoted 5 lines · Lennart Sorensen
Quoted 3 lines · Andrei Borzenkov
If we decide to fix this commit it is better done now, while it is the last one. It is annoying but do you have suggestion how it can be done differently?
Quoted 7 lines
Well the only options are:
1) Leave it alone
2) Break the tree of anyone that already pulled. (Posting instructions on how to fix it would at least be nice then).Not sure how many people regularly pull the tree.
This is silly FUD. There is no ever any "broken tree".
Firstly, people who have no local changes do not experience any ill effect. They just have to do
$ git fetch
# oops, upstream and local branch have diverged
# but I have absolutely no local work to preserve; # just "warp" HEAD to the new one:
$ git reset --hard origin/master
# done!
Those who have outstanding local work never have any expectation of non-breakage! *All* fetches are "non-fast-forward" with regard to unpublished local work, because they occur to a prior version of the work, underneath your changes.
In *all* cases you can do this:
# Fast-forward or not, I don't care!
$ git fetch
# Take my 13 unpublished commits (or whatever number), rebase them
over the
# latest upstream master, and make the result my local master branch:
$ git rebase HEAD~13 --onto origin/master
Quoted 5 lines · Lennart Sorensen
Quoted 3 lines · Andrei Borzenkov
If we decide to fix this commit it is better done now, while it is the last one. It is annoying but do you have suggestion how it can be done differently?
Quoted 7 lines
Well the only options are:
1) Leave it alone
2) Break the tree of anyone that already pulled. (Posting instructions on how to fix it would at least be nice then).Not sure how many people regularly pull the tree.
Is the discussion still require attention by Git folks for their help? If not, could you take this back to savannah specific mailing list?
Thanks.
Quoted 5 lines · Lennart Sorensen
Quoted 2 lines
I don't have non-fast-forward rights. Does someone from savannah-users have them? Could he just delete this commit?
If you do that, then anyone that already did a pull after it went in will have a broken tree. Rather annoying.
Nope. They will have a git in which that commit looks like their own local work. *Someone* will inadvertently do a "git push" to blast out their changes based on that deleted commit, thereby causing it to reappear.
:)
Quoted 4 lines · Kaz Kylheku
Nope. They will have a git in which that commit looks like their own local work. *Someone* will inadvertently do a "git push" to blast out their changes based on that deleted commit, thereby causing it to reappear.
Not if another one pushes something different in the mean time.
Andreas.
Signature · 3 lines
Andreas Schwab, [email protected] GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 "And now for something completely different."
31.10.2015 10:02, Andreas Schwab пишет:
Quoted 9 lines
Quoted 4 lines · Kaz Kylheku
Nope. They will have a git in which that commit looks like their own local work. *Someone* will inadvertently do a "git push" to blast out their changes based on that deleted commit, thereby causing it to reappear.
Not if another one pushes something different in the mean time.
Which is why I said "amended".
31.10.2015 16:46, Andrei Borzenkov пишет:
Quoted 8 lines
31.10.2015 10:02, Andreas Schwab пишет:
Quoted 7 lines
Quoted 4 lines · Kaz Kylheku
Nope. They will have a git in which that commit looks like their own local work. *Someone* will inadvertently do a "git push" to blast out their changes based on that deleted commit, thereby causing it to reappear.
Quoted 4 lines
Quoted 2 lines
Not if another one pushes something different in the mean time.
Which is why I said "amended".
Actually I was probably wrong. "git pull" will see non-ff case and will attempt merge of remote and local, unless merge.ff=only is set.
So we can only hope that everyone who has commit rights reads this list and will check local clone and do rebase to wipe out this commit if necessary. Otherwise it will be resurrected indeed.
May be it's not worse the trouble then to remove it.
Commit is removed upstream. Please do git reset --hard origin/master in your tree. When on master branch if you have no work on master branch and git rebase -I origin/master and remove commit manually otherwise
Quoted 32 lines · Andrei Borzenkov
31.10.2015 16:46, Andrei Borzenkov пишет:
Quoted 10 lines
31.10.2015 10:02, Andreas Schwab пишет:
Quoted 8 lines
Kaz Kylheku <[email protected]> writes:
Nope. They will have a git in which that commit looks like their own
Quoted 4 lines
local work. *Someone* will inadvertently do a "git push" to blast out their changes based on that deleted commit, thereby causing it to reappear.
Quoted 5 lines
Quoted 3 lines
Not if another one pushes something different in the mean time.
Which is why I said "amended".
Actually I was probably wrong. "git pull" will see non-ff case and will attempt merge of remote and local, unless merge.ff=only is set.
So we can only hope that everyone who has commit rights reads this list and will check local clone and do rebase to wipe out this commit if necessary. Otherwise it will be resurrected indeed.
May be it's not worse the trouble then to remove it.
_______________________________________________
Grub-devel mailing list
[email protected]
https://lists.gnu.org/mailman/listinfo/grub-devel
30.10.2015 23:19, Vladimir 'φ-coder/phcoder' Serbinenko пишет:
Quoted 10 lines · Vladimir 'φ-coder/phcoder' Serbinenko
Quoted 9 lines · Vladimir 'φ-coder/phcoder' Serbinenko
Quoted 8 lines · Andrei Borzenkov
Quoted 7 lines
See
http://git.savannah.gnu.org/cgit/grub.git/commit/?id=206676601eb853fc319df14cd3398fbdfde665acI was not even aware that this is possible. Is there anything on server side that can prevent it?
Quoted 6 lines
Quoted 3 lines
Quoted 3 lines
Quoted 2 lines
Would be good if commit were amended and force pushed to fix it.
It is a bug in SGit. I'll investigate how it happened
I don't have non-fast-forward rights. Does someone from savannah-users have them? Could he just delete this commit?
Looking at mail archives, non-fast-forward is global repository property and disabled by default. We probably need to open Savannah ticket to get it temporary enabled.
Opened Savannah support ticket
Quoted 34 lines · Andrei Borzenkov
30.10.2015 23:19, Vladimir 'φ-coder/phcoder' Serbinenko пишет:
Quoted 14 lines · Vladimir 'φ-coder/phcoder' Serbinenko
Quoted 13 lines · Vladimir 'φ-coder/phcoder' Serbinenko
Quoted 11 lines · Andrei Borzenkov
Quoted 9 lines
See
http://git.savannah.gnu.org/cgit/grub.git/commit/?id=206676601eb853fc319df14cd3398fbdfde665ac
I was not even aware that this is possible. Is there anything on server side that can prevent it?
Quoted 8 lines
Quoted 5 lines
Quoted 4 lines
Quoted 3 lines
Would be good if commit were amended and force pushed to fix it.
It is a bug in SGit. I'll investigate how it happened
I don't have non-fast-forward rights. Does someone from savannah-users have them? Could he just delete this commit?
Looking at mail archives, non-fast-forward is global repository property and disabled by default. We probably need to open Savannah ticket to get it temporary enabled.
_______________________________________________
Grub-devel mailing list
[email protected]
https://lists.gnu.org/mailman/listinfo/grub-devel
Quoted 4 lines · Vladimir 'φ-coder/phcoder' Serbinenko
Quoted 2 lines · Andrei Borzenkov
See
http://git.savannah.gnu.org/cgit/grub.git/commit/?id=206676601eb853fc319df14cd3398fbdfde665ac
Quoted 8 lines
Quoted 7 lines
I was not even aware that this is possible. Is there anything on server side that can prevent it?
Would be good if commit were amended and force pushed to fix it.
It is a bug in SGit. I'll investigate how it happened
Turns out I didn't fill out my name and email after sgit reinstall and it happily made a commit with no name rather than bailing out like normal git does. I'll make a patch for sgit
Quoted 8 lines
Quoted 6 lines
_______________________________________________
Grub-devel mailing list
[email protected]
https://lists.gnu.org/mailman/listinfo/grub-devel
.