Re: your mail
On Friday, May 17, 2013 at 14:02 EDT, ASHISH VERMA ashunew1...@gmail.com wrote: Hi, i am using git to push my code from eclipse to heroku , but recently iam getting error like:: master:master rejected:non fast forward and i am not able to resolve it .I tried a git pull but that says - conflicts shud be resolved before git pull can be implemented.I can;t find the solution Please help ASAP... Resolve the conflicts by either hand-editing the files (you'll see the markers where the conflicts are) add running 'git add' to tell git that you're done resolving them, or set up Git to use a graphical tool like kdiff3. When you're done, run 'git commit' to create the merge commit. After that you'll be able to push to your upstream (unless things have moved again while you were resolving the initial conflict). This guide to merge conflicts looks pretty good: http://gitguru.com/2009/02/22/integrating-git-with-a-visual-merge-tool/ -- Magnus Bäck ba...@google.com -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Workflow Help
On Monday, May 20, 2013 at 20:59 EDT, Quilkey, Tony t...@thorpesystems.com wrote: I am looking at formulating and then documenting our vcs workflow using Git at work. I have an idea of how I want things to work, but am a little hazy on some of the details. Our basic workflow will be based around: http://nvie.com/posts/a-successful-git-branching-model, with a few exceptions. We would like to create our release-* branches from the last release tag. From there, we would like the ability to cherry pick (or take the complete diff) commits from the develop branch. It would probably be easier to comment on your proposal if you motivated why you want to diverge. So, we are after is: 1) Create topic (feature) branches from develop, and merge back into develop when complete. 2) Once it is decided we are packaging a release, make a release-* branch from the previous release tag. 3) Cherry pick/merge/whatever any commits we want from develop into the new release-* until it is complete. The point of having a release branch is typically to slow down the development pace and reduce risk by only adding changes that you really need. By starting the branch for release N+1 from the branch for release N it seems you have three ways forward: - Cherrypick a small number of commits from develop. That'll give you release N+0.1 rather than N+1. - Cherrypick many (if not most) commits from develop. That might give you a real release, but with a lot of work. Who should select which commits to cherrypick? How do you keep track of dependencies? Why would you want to move from a known state (develop, where people spend most of their time) to an unknown state? - Merge from develop to the release branch. What's the benefit compared to cutting the release branch directly from develop? As another poster has pointed out, with merging instead of cherrypicking the standard Git tools will be able to do a better job at helping you track which corrections are made where. [...] -- Magnus Bäck ba...@google.com -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Is there a library for monitoring a git repository for any changes?
On Thursday, June 06, 2013 at 23:16 EDT, Robert Martin rdmart...@gmail.com wrote: I want to work on a visualization program for git. I was hoping there was a library that would allow me to monitor a git repo for changes. Consider it like inotify, but for a git repository (in fact, I think it would probably have inotify under the hood). This hypothetical library would trigger an event any time the repository was modified, i.e. any time the graph that represents history was changed. Is there such a library? If not, is there a better way to monitor the repository so that I wouldn't need to write it myself? Would anyone else be interested if I wrote it myself? 'git ls-remote'? Either run periodically or, if the monitored git is local, triggered via inotify. If you have control over the git perhaps a post-receive hook would be useful too. -- Magnus Bäck ba...@google.com -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Teams of people using signed commits...
On Friday, June 14, 2013 at 15:02 EDT, Eric Fleischman efleisch...@gmail.com wrote: We're very interested in using signed commits but are struggling to figure out how to use it in the real world. Would love some advice from those who know more. What do you expect to gain from using signed commits? I'm not saying they don't have a place, but depending on why you find them attractive there might be alternatives. For example, won't signed tags do? We think we know how to deal with signed commits auto-reject such commits at build time, as well as clean up. But we're worried that folks won't sign on the way in accidentally. We don't know of a good way to force the team to always sign commits yet, especially as they get new machines and what hav eyou. Hooks? A pre-commit hook that runs on the machine and/or a server-side hook (pre-receive or update?) should be able to enforce this. Well, a client hook is trivially bypassed so it would just be useful against mistakes and forgetfullness. Is there a way to add something to the repo config to force, or at least default, this? I don't believe you can configure Git to sign commits by default, but if you control the machine of your machines (assuming a corporate) environment you can set up a template directory for hook distribution. Again, that's only for client hooks that are okay to be circumventable. [...] -- Magnus Bäck ba...@google.com -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: how the commit ID come from in GIT?
On Monday, November 05, 2012 at 15:04 EST, hong zhang henryzhan...@yahoo.com wrote: Could anyone explain how the git commit ID will include all the files that devloper makes changes on? How git commit ID works? In short, a Git commit points to a tree object that describes the full state of the source tree plus metadata like the commit author, date, description, and a pointer to the commit object(s) that preceded the commit. The commit id itself is the SHA-1 of the contents of the commit object. Any change of the source tree will affect the top-level tree object's SHA-1 which in turn affects the SHA-1 of the commit. Also, because a commit contains the timestamp of the commit object's creation even two commits that are content-wise identical will have different SHA-1s. If you haven't read it, the Pro Git books explains Git's object model in detail: http://git-scm.com/book/en/Git-Internals-Git-Objects That description is quite detailed, and most users don't need to go that deep. -- Magnus Bäck ba...@google.com -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Python extension commands in git - request for policy change
On Sunday, November 25, 2012 at 06:40 EST, Felipe Contreras felipe.contre...@gmail.com wrote: On Sun, Nov 25, 2012 at 11:44 AM, Michael Haggerty mhag...@alum.mit.edu wrote: [...] On the contrary, there is *constant* traffic on the mailing list about incompatibilities between different shell implementations (sh, dash, bash, etc), not to mention those in other utilities (sed, grep, etc) that one is forced to work with in shell scripts. Compatibility is a *huge* pain when developing shell code for git. The fact that users typically don't encounter such problems is due to the hard work of POSIX lawyers on the mailing list correcting the compatibility errors of mortal programmers. *Theoretical* incompatibilities on probably obscure systems. *I* have never seen such compatibility issues *in practice*. While constant traffic probably overstates the issue, these are not theoretical problems. I recall at least three cases in the last year or so where Git has seen breakage with Solaris or Mac OS X because of sed or tr incompatibilities, and I don't even read this list that thoroughly. [...] -- Magnus Bäck ba...@google.com -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Python extension commands in git - request for policy change
On Tuesday, November 27, 2012 at 19:10 EST, Felipe Contreras felipe.contre...@gmail.com wrote: On Tue, Nov 27, 2012 at 3:35 PM, Magnus Bäck ba...@google.com wrote: While constant traffic probably overstates the issue, these are not theoretical problems. I recall at least three cases in the last year or so where Git has seen breakage with Solaris or Mac OS X because of sed or tr incompatibilities, and I don't even read this list that thoroughly. Most of the *constant* traffic is about *theoretical* incompatibilities, how much of that are real incompatibilities, it's not known. _Some_ of the traffic is about real incompatibilities, sure, but you could count only three cases *in a year*. It's not a huge amount. And then, how man this year? Also, I would like references to those incompatibilities. I don't remember the details of the Mac OS X problem, but just searching the archives for xpg4 revealed the following Solaris problems since April: http://article.gmane.org/gmane.comp.version-control.git/195010 http://article.gmane.org/gmane.comp.version-control.git/195966 http://article.gmane.org/gmane.comp.version-control.git/207944 -- Magnus Bäck ba...@google.com -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: inotify to minimize stat() calls
On Sunday, February 10, 2013 at 08:26 EST,
demerphq demer...@gmail.com wrote:
Is windows stat really so slow?
Well, the problem is that there is no such thing as Windows stat :-)
I encountered this perception in windows Perl in the past, and I know
that on windows Perl stat *appears* slow compared to *nix, because in
order to satisfy the full *nix stat interface, specifically the nlink
field, it must open and close the file*. As of 5.10 this can be
disabled by setting a magic var ${^WIN32_SLOPPY_STAT} to a true value,
which makes a significant improvement to the performance of the Perl
level stat implementation. I would not be surprised if the cygwin
implementation of stat() has the same issue as Perl did, and that stat
appears much slower than it actually need be if you don't care about
the nlink field.
I suggested a few years ago that FindFirstFile() be used to implement
stat() since it's way faster than opening and closing the file, but
FindFirstFile() apparently produces unreliable mtime results when DST
shifts are involved.
http://thread.gmane.org/gmane.comp.version-control.git/114041
(The reference link in Johannes Sixt's first email is broken, but I'm
sure the information can be dug up.)
Based on a quick look it seems GetFileAttributesEx() is still used for
mingw and cygwin Git.
--
Magnus Bäck
ba...@google.com
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: building git ; need suggestion
On Friday, March 15, 2013 at 08:52 EDT, Joydeep Bakshi joydeep.bak...@infoservices.in wrote: On 15-Mar-2013, at 6:14 PM, Fredrik Gustafsson iv...@iveqy.com wrote: gitolite have a more fine ACL. Check it out. However it doesn't really meet your needs with web-interface (and I'm not even sure about the ACL thing is fine enough for you). You can read more about ACL in the git book: http://git-scm.com/book/ch7-4.html The webgui that's most populair is cgit and git-web. They don't do ACL afaik. Why would you need ACL? Why not don't share the branches that are going to be secret? Or are you looking for some branches to be read only? Actually the branches have to be dedicated to a group of users. developer branch --- developers bug fixed branch --- bug fixer and specific group don't need to RW permission on other branch. Obviously the admin must have the full permission on all these branches and merge as per requirement. Right, but that's R/W permissions. Almost any piece of Git hosting software supports restriction of pushes. Discriminating *read* access between developers and maintenance people sounds like a disaster if it's the same organization. Well, it sounds like a disaster even if there are two different organizations working on development and maintenance, but at least it's a reason. Anyway, Gerrit supports per-branch read ACLs. As long as all changes go through code review, perhaps Gerrit web interface works sufficiently well as a repository viewer? Pushes that bypass code review won't show up there. http://gerrit-documentation.googlecode.com/svn/Documentation/2.5/access-control.html#category_read The web-interface is required for checking the history by the users themselves and for code review. I don't know any web interface which can show repo/branch based on authentication. I have tried gitweb but it can handle a single repo or multiple repo with single authentication. NO ACL If you just have two levels of access you could have two separate Gitweb sites and use Gerrit to replicate a subset of the branches to each site. You could e.g. have gitweb-dev.example.com and gitweb-maint.example.com and grant access to those sites accordingly. -- Magnus Bäck ba...@google.com -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: git branch based hook desigh
On Monday, March 18, 2013 at 00:27 EDT, Joydeep Bakshi joydeep.bak...@infoservices.in wrote: I have implemented git pre-received hook successfully. And it works on the repo level. Could anyone suggest how to call branch level hook please ?-- If you need to have different hook behaviors depending on the ref that's about to be updated, just put a conditional in the hook. You get the name(s) of ref(s) to be updated on stdin. -- Magnus Bäck ba...@google.com -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: merge help
On Tuesday, March 26, 2013 at 18:07 EDT, J.V. jvsr...@gmail.com wrote: I have a branch for which I have made 0 (nada) changes. I did the following: $git pull --rebase --no-stat -v --progress origin mybranch I get the following U java/Profile.java Pull is not possible because you have unmerged files. Please, fix them up in the work tree, and then use 'git add/rm file' as appropriate to mark resolution, or use 'git commit -a'. -- (there is no local master branch), because of the conflict I was put on (no branch) * (no branch) branch1 dev tmpWork Question 1) Why did I get a merge conflict if I have not changed any files? The error message indicates that you already had a pending merge conflict when you initiated the pull. Why you had that is impossible to tell. Question 2) What is the command to show the difference between the files? (is there a visual tool that would let me merge)? You're looking for this form of git diff: git diff [options] commit commit [--] [path...] Example: git diff origin/master HEAD -- file.c file.h There are many graphical diff and merge tools that you can configure for use with Git, e.g. kdiff3 and meld. See git-difftool(1) and git-mergetool(1). [...] -- Magnus Bäck ba...@google.com -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: which files will have conflicts between two branches?
On Wednesday, March 27, 2013 at 17:48 EDT, J.V. jvsr...@gmail.com wrote: I have two local branches (tracked to remote) that are in sync (did a git pull on both branches from their corresponding remote). Is this the best way to merge? I would be merging local/branch1 = local/branch2 (test this branch) and then push local/branch2 = origin/branch1 (and would expect no merge conflicts if anyone has not checked in anything. Except for maybe unusual corner cases I don't see how the merge order (branch1 into branch2 or vice versa) makes any difference. If nothing has happened with origin/branch1 since you merged from it to your local branches the push will succeed. If there have been upstream commits you'll have to update your local branch first (which might result in conflicts) before you'll be able to push. Also with two local branches, Is there a way to get a list of files (one line per file) of files that would have merge conflicts that would need to be resolved? You'd have to perform an actual merge for that, perhaps with --no-commit to avoid creating the actual commit object. Inspect the git status output to find the files with conflicts. In a script, use git ls-files -u instead. -- Magnus Bäck ba...@google.com -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Selectively commit/publish files to GIT
On Friday, November 08, 2013 at 05:52 EST, Thomas Manson dev.mansontho...@gmail.com wrote: [...] How can I search git history for big files and remove them, or mark them to be not published ? I've tryed this solution found on the link in the error: git filter-branch --force --index-filter 'git rm --cached --ignore-unmatch giant_file' --prune-empty --tag-name-filter cat -- --all git commit --amend -CHEAD [...] here is the error I have using the GitHub application on Mac : (after that I intend to use Eclipse) File Ressources/dwr/dwr-3.0.0.110.dev-src.zip is 67.69 MB; this is larger than GitHub's recommended maximum file size of 50 MB GH001: Large files detected. Trace: 8f0259b29260f0c4d7ae4d4ae70e0306 See http://git.io/iEPt8g for more information. File .bzr/repository/packs/a7bcd6ba235114ab88c80fe8a97adcfa.pack is 178.76 MB; this exceeds GitHub's file size limit of 100 MB Did you actually replace the 'giant_file' placeholder with the path to *your* giant file? The error message indicates that you didn't, or that something else went wrong during the filtering. You can use 'git log' to look for commits touching particular pathnames, making it easy to verify that a file has been eradicated. git log --all -- path/to/big-honking-file.zip -- Magnus Bäck ba...@google.com -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
