Re: [git-users] gitignore change for tracked / untracked files
On Friday, January 31, 2014 7:36:52 AM UTC+1, Philipp Kraus wrote: Hello, sorry for the late answer. Am Mittwoch, 22. Januar 2014 21:27:18 UTC+1 schrieb Magnus Therning: I'm not 100% sure I understand what you wish to do, but you might want to look at `git clean`. By default it just lists the files it would delete, you have to pass it '-f' to actually remove stuff. You can also control whether you want it to deal with ignored files or not. I'm using gitignore like a black list, so my git ignore defines all files which are not allowed. If I switch this to a white list, I need a check if everything is all right. git clean works only with untracked files, but in my case I have got tracked files, which can be after the gitignore changing also ignored. Did you have got an idea, in which way I can change my gitignores, so that I do not forget some files? So, you want to change .gitignore and then see which already checked-in files would have been ignored had they not been added already.. Well.. Here's a pragmatic approach: cd repo mv .git .. # move .git somewhere else temporarily git init git status --ignored # behold, all ignored files! rm -r .git mv ../.git . #revert to old state If you don't want to toss your .git dir around, you can achieve the same by using the GIT_DIR variable: cd repo git --git-dir /tmp/foo.git init #just init an empty repo somewhere git --git-dir /tmp/foo.git --work-tree . status --ignored -- 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] ignore files with hard definition
Hello, I don't know of any method built into git, but how about denying commits that modify the .gitignore file(s)? This way your hook must only check if the commit has modifications to any files called .gitignore. Cheers, Gergely On 31 January 2014 08:25, Philipp Kraus philipp.kr...@flashpixx.de wrote: Hello, can I define on my server repository, that the ignored file patterns are hard defined. My problem is, that each use can modify the gitignore, but I get with this modification files into the server repo, which should not be there, so I would like to define in the server (bare) repo files patterns, which should be never pushed into the repo. I would like to do this with a hook, check the pushed filelist and reject the push, if some filepattern is found Is this the correct way or is there a better solution? Philipp -- 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. -- 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: ignore files with hard definition
On Friday, January 31, 2014 8:25:00 AM UTC+1, Philipp Kraus wrote: Hello, can I define on my server repository, that the ignored file patterns are hard defined. My problem is, that each use can modify the gitignore, but I get with this modification files into the server repo, which should not be there, so I would like to define in the server (bare) repo files patterns, which should be never pushed into the repo. I would like to do this with a hook, check the pushed filelist and reject the push, if some filepattern is found Is this the correct way or is there a better solution? I think the best way is to keep a clear and well-made .gitignore file, and foster a culture that respects not changing it without good reason. Hard constraints on contributors are usually counter-productive in the long run. However, you can make pre-receive hooks in repositories that reject pushes based on anything you can express in a script. Example: http://stackoverflow.com/questions/2569960/git-pre-receive-hook -- 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] Submodules and clobbering history
From: Eric Reischer To: git-users@googlegroups.com Sent: Tuesday, January 28, 2014 11:16 PM Subject: [git-users] Submodules and clobbering history I have a fairly esoteric situation, but I suspect I'm probably not the only one who is attempting to do something along these lines. I have a software product that consists of a number of Git repositories, each with its own group of engineers working on it (think of MATLAB (R) with its plethora of toolboxes). When we deliver software to customers, we ideally would have a superproject that references each repo such that we can just have bare repositories that are delivered (i.e. zip up the superproject after removing all source code), and then on-site the customer runs a program that performs a reset --hard to get all the source code back. Easy enough. (Before everyone asks, it's because the source code occupies several hundred megabytes, so having everything compressed in the repo is convenient for keeping the media count low.) The rub comes in that we do not want our customers to see all of our development history (and our sometimes not-so-professional commit remarks). I've read about a shallow clone (i.e. --depth 1), but it is my understanding these types of repos cannot be used with git-bundle. It does seem to follow everything else though, in that updates that occur upstream (i.e. bugfixes to a major revision) will be successfully applied with a pull or fetch. The other issue is the --depth flag doesn't seem to be supported with the submodule command. Anyone have any thoughts on how to accomplish all this? Eric Have a look at 'git archive' as a mechanism for generating a zip file of the latest and greatest that excludes history. The other option is that 'git shallow' is about to become a first class participant, but your concerns about potentially exposing history to clients would still be a concern. (i.e. accidently fetching more than you wanted into their repo) You also have the option (assuming an XY problem) of using 'git archive' and then starting a new repo from that initial point, and then using grafts if you have on-site developments that you want to return to base (though careful use of shallow may be just as effective) Philip -- 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] gitk: file name too long
Op donderdag 30 januari 2014 11:40:13 UTC+1 schreef Konstantin Khomoutov: Still, could you please disclose what is the full pathname of your repository and what is the pathname of the offending file in the repository? If you can't detect the offending file, you could try to infer what it is--I presume you should have been looking at that file's diff or commit log in gitk. You might consider to not post this data here but rather do the calculation yourself: the length of the name of the file in your repo must be under MAX_PATH characters which is 260 [1]. As to different behaviour of gitk between your development workstations... does the situation change if you set the knob patch / files atop of the bottom-right window to files? 1. http://msdn.microsoft.com/en-us/library/aa365247 Hi, I tried seeing what the knob patch/files was set to but in my view it only showed patch/tree as options. Trying either setting did not solve the problem but it did cause me to try and search for a 'files' like setting. In the view menu I have the option to select All files/Command line/All branches. This option was set to Command line for me and once I set it to 'All branches' the problem did not occur again. I have no idea what exactly these settings mean but I consider my problem solved. Thanks for the pointers. -- 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] Subsequent signing of tags, is it possible?
Am Freitag, 31. Januar 2014 08:28:03 UTC+1 schrieb Konstantin Khomoutov: On Thu, 30 Jan 2014 22:59:12 -0800 (PST) Tom Wieczorek t...@bibbu.net javascript: wrote: I'd like to sign git commits with my GPG key after they have been committed. I know that I can sign them at commit time using git -S. But, is it possible to sign a single commit afterwards? I use an IDE that doesn't support signing. So I'd like to add my signature to those commits from the command line. I also know that there is an autosign git config value, but this one scares me a bit. I'd like to sign commits proactively, not just by accident. IIRC, you can't sign a commit after it has been created because, well, it has been created already, and objects in the Git database are immutable. I already expected, that, bud didn't find any reference when searching the internet. Thanks for clarifying. I wasn't sure of how commit signing is implemented. If the signature would have been some sort of metadata attached to the actual commit, it could have been added after the commit, without changing its hash. But it seems to be part of the commit itself, if I understand correctly. So, basically, I'd say you have two possibilities: * You should be able to amend the tip commit. This would essentially replace it (that's what `git amend` does). This should work for unpushed commits, and obviously only works for the tip commit (what HEAD points at). * You might attach an annotated tag to any commit you like. Annotated tags may be signed, and that's what, say, Git project does to do releases: a signed annotated tag is attached to a commit which designates a released state. Use `git tag -a` for this. I think the latter option is the most sensible. The idea is that there's no need to sign *each* commit because once you signed a tag, you authenticated the whole subgraph of commits reachable from this tag--simply because the tag references its commit by its SHA-1 name, it, in turn, reference all the objects comprising the committed state by the SHA-1 names of those objects, and its parent commits--by their SHA-1 names as well. Since we take SHA-1 names to be cryptographically strong (exploitation of a collision attack for injection of sensible malicious data into the repository is infeasible), by attaching a signed annotated tag to a commit you effectively sign all objects reachable from that one--even though they're not signed directly. I was already aware of that. The idea was to prove that some distinct changeset has been made by me, and just me, but I assume you got that already. If I sign a tag, I sign all ancestors transitively. However, I cannot guarantee that there was a bad/spoofed commit pushed by someone else, without reviewing the whole history between HEAD and the first signed commit/tag. I have to think about it. Perhaps I just sign the tip commit of my branch just before opening a pull request, or something like that. Anyway, thank you for your detailed explanation. Much appreciated. Note that the Git repo even has the maintainer's public key injected into it--for easier verification; it's done like this: $ git tag gpg-key $(git hash-object -w my-gpg-pub.key) $ git push hub gpg-key -- 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 and SVN Repo sharing possible ?
On Thu, Jan 30, 2014 at 10:04 PM, Zk W mpc8...@gmail.com wrote: Hi All We are tasked to move a code branch named A within SVN repo to Git. We also have trunk merges going on between A and trunk in SVN. Is it possible to set up with Git and SVN such that 1) Trunk changes in SVN could be propagated to Git version control ? If not, how can we resolve this need with an efficient setup ? We don't think it is possible but we like to confirm. There's `git-svn`[1], but it can be a bit of work to set up the automatic propagation from SVN to git (and back again I guess). You might also want to have a look at subgit[2], it's a commercial tool but it has a rather generous license last time I looked (free for small projects, even in commercial settings). For one-off conversions there's also reposurgeon[3]. /M [1]: Thomas Ferris Nicolaisen has written extensively about using `git-svn`: http://www.tfnico.com/presentations/git-and-subversion [2]: http://www.subgit.com/ [3]: http://www.catb.org/esr/reposurgeon/ and if you are interested there's a Git Minutes episode on Blender's use of it http://episodes.gitminutes.com/2013/12/gitminutes-26-campbell-barton-on-tricky.html -- Magnus Therning OpenPGP: 0xAB4DFBA4 email: mag...@therning.org jabber: mag...@therning.org twitter: magthe http://therning.org/magnus -- 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] Avoid commit error when using attribute filters for Variable expansion
Hi, i'm using the .gitattributes with a script filter to expand the SHA1 and last commit date with the smudge and clean actions of the filter. The clean filter removes this changes and makes the file exactly like the one already in the repository. This makes the git commit action to return an error since there are no changes to include. Do you know of a way to avoid this issue ? thanks -- 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] Avoid commit error when using attribute filters for Variable expansion
On Fri, 31 Jan 2014 08:16:05 -0800 (PST) GS_gitnew neldo...@gmail.com wrote: i'm using the .gitattributes with a script filter to expand the SHA1 and last commit date with the smudge and clean actions of the filter. The clean filter removes this changes and makes the file exactly like the one already in the repository. This makes the git commit action to return an error since there are no changes to include. Do you know of a way to avoid this issue ? What is the essense of the problem? Do you mean Git fails to record a commit even if there really are changes in files other than that one handled by the filters? -- 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: Avoid commit error when using attribute filters for Variable expansion
Not exactly. There are indeed changes in the files since we use an attribute filter to modify the file ( smudge action of the filter). The clean action of the filter however clean the file to restore it to its original state ( as in the repository) so basically we have a modification notification ( which is correct ) but we get an error when commiting the file since there are no changes to commit. I do realise it is a bit strange as setup though. I use the info on the substition on commit/checkout http://git-scm.com/book/ch7-2.html -- 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] Git differences between repository and project
I would like to know the difference between repository and project because I am having a hard time setting a Solaris box with SSH access to be a repository for several projects I have. The thing is, I do a init --bare on a folder to hold a project. I make the changes, add, commit, push to the server and everything is OK. Now, that server is the same one that runs the java SE (cli) applications, so I want to be able to do a checkout to the working folder of the application of a tag, lets say v1.0. I make some updates, create tag v1.1, push updates. The thing is that with the --bare option I can't do a checkout of an specific tag, the only way to do a checkout with a --bare option is using checkout-index and I have no flexibility on what to checkout using checkout-index. If I create a repository without --bare, I cannot make push, I receive all type of errors, about NOT_AUTH, or NOT_ATTEMPTED, all kinds of error. I was looking on the internet for those errors and I get to use --bare option, but I get also errors when doing a checkout of a specific tag. I don't know what needs to be done to be able to create a repository, add projects to those repositories, and each project should have their own tag(v1.0, v.1.1, etc.) and I want to be able to clone a project, work on it, add a tag, upload via SSH to my server, then do a checkout of the current tag and that's it. I have been looking everywhere and there is no place that explain using Git as simple as I mention. I appreciate if someone can help me with this. Regards. -- 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.
