[git-users] pull merge vs a local merge, what's different?
To start, the user that generated this error was advised to backout the resulting munge and use a standard merge to fix his problems. Following standard merging practices fixed his problems but his original approach had been nagging at me. This user was using git pull to merge from master to his personal development branch. Here are the steps he was performing and the resulting pop: git checkout -b ticket/1976 origin/master git commit -m 'As requested, renamed files to reflect their type.' git commit -m 'Added convenience alias for commands.' git commit -m 'Modifications to support "use PAW" Banner display.' git pull origin master got the following: error: merge died of signal 11 (SEGV) plus a core file I know that pull does a fetch followed by a merge but is there anything special about that merge that could explain the failure? Does pull assume that the branch your working on and the remote branch have the same lineage? I am really just interested in finding out if pulls merge is different from a standard merge and if so how. If it isn’t, then perhaps this is a bug, albeit a bug that you really should never see using standard merge practices. -- You received this message because you are subscribed to the Google Groups "Git for human beings" group. To unsubscribe from this group and stop receiving emails from it, send an email to git-users+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[git-users] Re: Malicious Coder
Hi Lucky Limey, On Thursday, July 20, 2017 at 4:46:20 PM UTC+2, Lucky Limey wrote: > > I have a private repository set up for a project. I may be heading for a > dispute with one of the coders How do I protect the repository from > vandalism? I would hate for him to delete all our work etc. etc. > By removing his write access to the repository? Or just making a clone, or a simple copy of it...? Otherwise, what are you exactly concerned with? One of the beauties of a distributed version control system, which Git is, makes for each repository clone being a full/original/authentic repository copy. So as long as at least one person has the repository (locally, or wherever), the code and its history can`t get lost/damaged, no matter if some repository you`ve declared "central" gets corrupted/deleted/lost - you would just clone it again from any other still existing repository. For example, if I have a GitHub repository, I`ll most probably have a local clone of it, the one which I`m working on, so even if my GitHub repository gets deleted/detroyed it won`t really matter as I still have everything in my local clone, and I can easily recreate GitHub repository as if the issue never happened. Only in case if I`m the only one having the GitHub clone, and I haven`t synchronized my local clone lately (through fetch/pull) and there were some changes on GitHub side which gets destroyed, I would lose those latest commits since my last synchronization, but that`s really the worst case scenario - usually more than one person would work on GitHub repo, and any of them might have a more recent clone (or s fully up to date one). Anyway, nothing beats regular/planned backups, just that Git might even save you when you (think you) don`t have one :) Regards, Buga -- You received this message because you are subscribed to the Google Groups "Git for human beings" group. To unsubscribe from this group and stop receiving emails from it, send an email to git-users+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[git-users] Re: Git Commit Sequence Issue
Hi Buddhi Nipun Mihara, On Thursday, July 20, 2017 at 7:55:08 AM UTC+2, Buddhi Nipun Mihara wrote: > > I am working on a project which maintains our code base in GitHub. > We have faced following issue > One of our developer changed his local machine date and time. after that, > he committed his changes to his fork and then his changes were merged to > master branch. > After that, I have got a pull request and then did some changes and > committed my changes to my fork. > but in my fork, my committed are shown below the above-mentioned commit. > which has data and time set to August 2017. But I did my changes in July > 2017. > You described your current situation well, but you didn`t ask any questions...? What would you want to do? No matter the commit date/time, Git won`t get confused about commit order in terms of which commit (snapshot, code state) follows the other, and commit date/time has no influence there - commit parentage does, where parent commits always come before commits they`re parents of. If commits on different branches have different timestamps, then date/time will influence the order in which they`re shown between each other, but that doesn`t mean anything other than the obvious, that later commits are commited after the former ones - at least as far as their timestamp is concerned :) Also, once your colleague`s commits got merged, if the machine where the merge was performed had correct date/time settings, the merge commit timestamp should be correct as well, no matter that it actually comes after your colleague`s commits with timestamps in the future... And note that each commit has both "auhor date" and "commit date", though I don`t know if that`s relevant for your workflow. Regards, Buga -- You received this message because you are subscribed to the Google Groups "Git for human beings" group. To unsubscribe from this group and stop receiving emails from it, send an email to git-users+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[git-users] Malicious Coder
I have a private repository set up for a project. I may be heading for a dispute with one of the coders How do I protect the repository from vandalism? I would hate for him to delete all our work etc. etc. -- You received this message because you are subscribed to the Google Groups "Git for human beings" group. To unsubscribe from this group and stop receiving emails from it, send an email to git-users+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.