Re: [git-users] git apply doesn't add new files...?
On Thu, 2013-03-28 at 16:43 -0400, Dale R. Worley wrote: If you think about it, in many situations git commit -a is what a software developer wants to use. Various trash files can accumulate in a working copy; you usually only want to commit files that have been specially pointed out as being valuable. Sure. I'm not in any way saying git commit -a is doing the wrong thing or should be modified...? I'm talking about the behavior of git apply. I don't really see many situations where you want to apply a patch and have all the modifications and deletes be processed but not the adds. As an example of the kind of problem this creates, if I have a workspace with some untracked files in it and then I run git apply, I now have no way to tell which files were created as part of the git apply and should be added to my commit with git add, and which were there before and should not be added. You really, really shouldn't use git apply unless the working copy is clean. (Unless you want to combine the changes that git apply makes with all the changes that are already present to make one commit.) I agree with you if by working copy is clean you mean there are no modifications to Git-controlled files... that would be a problem. And in my case there are none. I don't agree if by clean you mean that I should be deleting the various trash files that can accumulate in a working copy; these files may be important even though they shouldn't be added to Git. Since they're not known by Git, stash doesn't help. It is a real PITA to move them outside of the repository while dealing with patches, then move them back. I don't want to require everyone to do that just to apply patches. The risk that some added file in the patch will overlap with a local file already in my workspace is very small, and if it happens then the patch will simply fail to apply. Anyway, git apply --index, while not quite what I wanted, is working OK for me. Cheers! -- 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/groups/opt_out.
Re: [git-users] git apply doesn't add new files...?
On Fri, 29 Mar 2013 08:49:55 -0400 Paul Smith p...@mad-scientist.net wrote: On Thu, 2013-03-28 at 16:43 -0400, Dale R. Worley wrote: If you think about it, in many situations git commit -a is what a software developer wants to use. Various trash files can accumulate in a working copy; you usually only want to commit files that have been specially pointed out as being valuable. Sure. I'm not in any way saying git commit -a is doing the wrong thing or should be modified...? I'm talking about the behavior of git apply. I don't really see many situations where you want to apply a patch and have all the modifications and deletes be processed but not the adds. I think you did not get the point Dale was making. The issue here not with `git apply` but with `git commit -a`. I'll try to present a chain of reasoning to try to explain his point better: * New commits in Git are cut from the staging area. There's no way to do this otherwise. * `git apply` itself does not modify the staging area (unless --index is passed to it). Therefore a plain invocation of `git apply` is rather the same as just `patch -p1`, just `git apply` is able to use certain Git-specific information while reading the patch file. Notice that applying a patch file (no matter using which tool exactly) is just making changes to local files; instead of running a patch tool you could have just applied all the changes by hand. * Now you have a pretty regular situation: `git apply` applied your patch to your work tree, and that is all -- to prepare the next commit, you have to decide what changes should go to it. You do this by using regular tools like `git add`, `git rm`, `git reset` etc. Finally, when you're happy with your staging area, you run `git commit`. * But you're using `git commit -a` instead, which, as Dale pointed out does not do what you possibly meant: if only automatically stages the local changes made to the *tracked* files. Tracked is the key point here: since `git add` only messes with the work tree, the files it adds there are no different from those you could create using your text editor. To cite the `git commit` manual: -a --all Tell the command to automatically stage files that have been modified and deleted, but new files you have not told git about are not affected. Do you see the point now? What `git apply` created in your work tree are those new files, and you did not tell git to track them so `git commit -a` ignores them. * As Dale also pointed out, since `git commit -a` is roughly the same as `git add -u` followed by `git commit`, you could do what you need using `git add -A` followed by `git commit`. I think you could even create an alias for this, like $ git config --add alias.patch '!git apply $1 git add --all git commit' [...] -- 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/groups/opt_out.
[git-users] Re: Using Git to track system file customizations
On Thursday, March 28, 2013 6:22:24 PM UTC+1, Dale Worley wrote: I'm considering using Git to track the customizations I make to the system files of my Linux box. Has anyone done that and has hints on how to make it work well? Actually, I have two Linux boxes, and I need to track both sets of customizations. It looks easy enough to have one repository on each, and each has a tracking branch for the other repository. But I'm not clear on how to do the bookkeeping for cross-merging customizations that are first inserted on one machine to the other. I have a feeling that I want something that tracks which deltas from one lineage have been merged into the other lineage, along the lines of the bookkeeping that svn merge does. Dale, from my perspective it's fairly obvious that a tool like Puppet, Chef, or CFEngine is the way to go about here. Use Puppet to script setup and custom files for your two machines. You can keep the puppet recipes in a Git repo, of course, and use Git to sync each machine with the latest versions of the puppet files. -- 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/groups/opt_out.
[git-users] Re: Custom git mergetool on .gitattributes
On Thursday, March 28, 2013 12:41:49 PM UTC+1, Jaume Casado Ruiz wrote: Hi all! With *Git 1.7.9.5*, I am trying to configure a merge tool that should apply only on .po/.pot (gettext) files. I have this config for acomplish the same for merge/diff: In .gitattributes: *.po merge=pofile *.pot merge=pofile *.po diff=pofile *.pot diff=pofile In .gitconfig: [merge pofile] name = Gettext merge driver driver = git merge-po %O %A %B [diff pofile] textconv = git diff-po Where git-merge-po and git-diff-po are custom scripts located in ~/bin. Is it possible to do the same for the mergetool configs? I don't know wether this is implemented or not, neither I need to configure this in another manner. For exemple, I'm trying: In .gitattributes: *.pomergetool=pofile *.pot mergetool=pofile In .gitconfig: [mergetool pofile] cmd = git mergetool-po \$BASE\ \$LOCAL\ \$REMOTE\ \$MERGED\ But it doesn't work. Now I'm using manually this command git mergetool -t pofile for resolving conflicts between .po files, but I thought that could just type git mergetool and the git itself will launch automatically my pofile mergetool for .po/.pot files and the project/globally defined mergetool for the rest of files. Any idea? This sounds like a question for the Git developer list: https://gist.github.com/tfnico/4441562 -- 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/groups/opt_out.
[git-users] Re: Deleted by us while cherry-picking a gerrit in the same project
On Tuesday, March 26, 2013 12:38:55 AM UTC+1, python...@gmail.com wrote: I am trying to cherry-pick a gerrit based on git project test.git ,for some gerrits I see it tries to delete as below by creating one more test folder inside the test directory..any idea what could be wrong here?please let me know if you need more details. Unmerged paths: # (use git add/rm file... as appropriate to mark resolution) # # deleted by us: test/ROE/SEME/src/cmpc/cmpc.c When you cherry-pick, it's basically trying to apply a commit to your working branch. In this case, it's not possible to cleanly apply the commit, because there are conflicts - there are changes in the commit you are cherry-picking, that conflict with recent changes in your working branch. Git tells you which files are affected by the conflict, and hints that it has been deleted by us. I figure that goes to say, that the commit being cherry-picked includes changes in a file which has been since deleted in your working branch. If this makes sense, and the changes to the now-deleted file are irrelevant, then doing a git rm test/ROE/SEME/src/cmpc/cmpc.c is the right thing to do (and then commit to complete the cherry-pick). If you do indeed need to keep the semantics of the changes that were made in the deleted file, perhaps some new tests that should be moved to another file, then you should do this manually, then git add all the changed files before committing. -- 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/groups/opt_out.
