Re: [Feature REQ]Add CURLOPT_SSL_CIPHER_LIST to git for allowing custom cipher usages
On Mon, Apr 06, 2015 at 09:27:53AM -0300, Steven Huang wrote: Hi, We know git uses cURL to grab https repositories from the Internet. Nowadays the SSL-enabled git repos are getting more and more, especially self-hosted ones. Some of the websites including those enabled by CloudFlare, however, does not support common encryption ciphers provided by cURL. For example, TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 will not be support by default in both cURL or git, and it is not a common cipher, Debian/RHEL does not even support it by default (but Fedora does, maybe others, didn't test). Is it possible to add this feature (this opt is set by calling by curl --cipher cipher_name) to git, allowing custom cipher usage? Thank you very much. curl through git will honor settings in ~/.curlrc. So you can just add the cipher to your ~/.curlrc, and it should work. -- 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 to make full copy of a repo
On Sun, Mar 29, 2015 at 04:21:26AM +0200, Christoph Anton Mitterer wrote: On Sat, 2015-03-28 at 15:31 +0100, Kevin D wrote: [..] * reflog (history of refs, though, by default disabled for bare repositories) is there a way to get this copied? No, the reflog is considered something private to the repository, so there is no way to git it through git clone. [..] git clone --mirror is used for repositories that regularly get updates from the repositories they were cloned from. Though this is not what you want, it's not difficult to reset the refspecs to the default refspecs. What do you mean here? What would I need to reset exactly? git clone --mirror sets up the fetch refspec in such a way that local refs would get reset to whatever upstream has: +refs/*:refs/* So every time you would fetch / pull, all your branches would reflect the way they are on the mirrored repo (which is why it's called mirror). The default refspec is: +refs/heads/*:refs/remotes/origin/* Which would only fetch heads (branches), and maps them as remote tracking branches, so that your local branches are left alone. git clone --mirror is the closest you are going to get by only using git. I see, thanks :) So to summarize, git clone is only used for cloning history, which means objects and refs, the rest is not part of cloning. To get more, you have to go outside git. Thanks :) Chris. -- 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 Rev News edition 1 published
On Wed, Mar 25, 2015 at 11:00:21AM +0100, Christian Couder wrote: Hi, Git Rev News edition 1 is now available: http://git.github.io/rev_news/edition-1.html Thanks a lot to all the contributors and helpers, especially Junio! Enjoy, Christian and Thomas. Thank you for your work on this. -- 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 to make full copy of a repo
On Sat, Mar 28, 2015 at 03:56:37AM +0100, Christoph Anton Mitterer wrote: Hey. I was looking for an ideally simple way to make a full copy of a git repo. Many howtos are floating around on this on the web, with also lots of voodoo. First, it shouldn't be just a clone, i.o.w. - I want to have all refs (local/remote branches/tags) and of course all objects from the source repo copied as is. So it's local branches should become my local branches and not remote branches as well - and so on. Basically I want to be able to delete the source afterwards (and all backups ;) ) and not having anything lost. - It shouldn't set the source repo as origin or it's branches as remote tracking branches, as said it should be identical the source repo, just freshly copied via the Git aware transport mechanisms. - Whether GC or repacking happens, I don't care, as long as nothing that is still reachable in the source repo wouldn't get lost (or get lost once I run a GC in the copied repo). - Whether anything that other tools have added to .git (e.g. git-svn stuff) get's lost, I don't care. - It should work for both, bare and non-bare repos, but it's okay when it doesn't copy anything that is not committed or stashed. I'd have said that either: $ git clone --mirror URl-to-source-repo copy for the direction from outside the source to a copy, or alternatively: $ cd source-repo $ git push --mirror URl-to-copy for the direction from within the source to a copy with copy being an empty bare or non-bare repo, would do the job. But: a) but the git-clone(1) part for --mirror: and sets up a refspec configuration such that all these refs are overwritten by a git remote update in the target repository. kinda confuses me since I wanted to get independent of the source repo and this ssems to set up a remote to it? b) do I need --all --tags for the push as well? c) When following https://help.github.com/articles/duplicating-a-repository/ it doesn't seem as if --mirror is what I want because they seem to advertise it rather as having the copy tracking the source repo. Of course I read about just using git-clone --bare, but that seems to not copy everything that --mirror does (remote-tracking branches, notes). So I'm a bit confused... 1) Is it working like I assumed above? 2) Does that also copy things like git-config, hooks, etc.? 3) Does it copy the configured remotes from the source? 4) What else is not copied by that? I'd assume anything that is not tracked by git and the stash of the source? Thanks a lot, Chris. Git clone is never going to get you a copy where nothing is lost. What you are losing on clone is: * config settings (this includes the configures remotes) * hooks * reflog (history of refs, though, by default disabled for bare repositories) * Stashes, because the reference to them is stored in the reflog * unreferenced objects (though you said those are not a requirement, it is still something that is lost) git clone --mirror is used for repositories that regularly get updates from the repositories they were cloned from. Though this is not what you want, it's not difficult to reset the refspecs to the default refspecs. Because it fetches all refs, it's not necessary to add --all --tags (because tags are also refs). git clone --mirror is the closest you are going to get by only using git. I guess you are aware of this, but if you want to retain more information, you have to rely on other means, like scp to get the other things So to summarize, git clone is only used for cloning history, which means objects and refs, the rest is not part of cloning. To get more, you have to go outside git. Hope this helps to clear some confussion. Kevin -- 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: [PATCH] clone: Warn if clone lacks LICENSE or COPYING file
On Sat, Mar 21, 2015 at 02:06:33PM -0400, David A. Wheeler wrote: Warn cloners if there is no LICENSE* or COPYING* file that makes the license clear. This is a useful warning, because if there is no license somewhere, then local copyright laws (which forbid many uses) and terms of service apply - and the cloner may not be expecting that. Many projects accidentally omit a license, so this is common enough to note. For more info on the issue, feel free to see: http://choosealicense.com/no-license/ http://www.wired.com/2013/07/github-licenses/ https://twitter.com/stephenrwalli/status/247597785069789184 LWN article that lead to this patch: https://lwn.net/Articles/636261/ -- 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: [v3 PATCH 2/2] reset: add tests for git reset -
On Fri, Mar 20, 2015 at 04:02:38AM +0530, Sundararajan R wrote: Yes. I made a mistake while framing the sentence. I should have proof read the commit message more thoroughly. Should I submit a new patch with the corrected commit message? Yeah, you can combine that with the comments from Matthieu. -- 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: [v3 PATCH 2/2] reset: add tests for git reset -
On Wed, Mar 18, 2015 at 02:05:09PM +0530, Sundararajan R wrote:
The failure case which occurs on teaching git is taught the '-' shorthand
is when there exists no branch pointed to by '@{-1}'. But, if there is a file
named - in the working tree, the user can be unambiguously assumed to be
referring to it while issuing this command.
The first line is hard to read. I think the is taught part is
redundant.
--
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 with Lader logic
On Thu, Mar 19, 2015 at 07:14:52AM +, Bharat Suvarna wrote: Thanks all .. I will have a look. But could I just set this up on my laptop and checking this works on system first before installing one of Git on server Sure, that's no problem. Git happily runs just locally on your own machine and does not depend on a server. -- 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 with Lader logic
On Tue, Mar 17, 2015 at 11:33:54PM +, Bharat Suvarna wrote: Hi I am trying to find a way of using version control on PLC programmers like Allen Bradley PLC. I can't find a way of this. Could you please give me an idea if it will work with Plc programs. Which are basically Ladder logic. I'm not familiar with these programs, so I can't give you specific advice about this. Although git is not very picky about the contents, it is optimized to track text files. Things like showing diffs and merging files only works on text files. Git can track binary files, but there are some disadvantages: - Diff / merge doesn't work well - Compression is often difficult, so the repository size may grow depending on the size of the things stored These disadvantages are not limited to only git, other SCM systems also have to deal with these problems. So if the Ladder logic is represented as text source, there is no problem with it. If it'sbinary, there might be other sollutions better suited. Kevin -- 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: fatal: Unable to mark file .ruby-version
On Sun, Mar 15, 2015 at 05:58:19PM +0100, t.gumme...@gmail.com wrote: On 03/15, Arup Rakshit wrote: On Sunday, March 15, 2015 01:30:04 PM you wrote: With --assume-unchanged you're promising git that you will not change a file that is already in the repository. Git doesn't check those files for changes anymore, which can improve performance. I didn't understand your point. Could you please elaborate more on it ? --assume-unchanged only works on files that you added on the repository, not on untracked files. Because you don't seem to want these files in the repository, update-index --assume-unchanged will not work for you. And to elaborate what on what t.gummerer meant earlier: git update-index --assume-unchanged is often abused to ignore already tracked files, thinking that they can change the file while git happily ignores it. --assume-unchanged was neaver built for this purpose, it's built for large code bases where parts of the code base never changes, and git checking this part would only slow it down. So that's why it's called a promise to git that the file never changes, because git doesn't check the status of the file everytime you run git status. But because the file is still tracked, any commit that changes the file causes git to still update that file, but git will then protest, because it found it the file actually changed in the mean time, and you broke that promise. But also already said, this only applies to tracked files, so not to files that aren't being tracked in the first place. Kevin -- 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: [PATCH] forbid log --graph --no-walk
Subject is usually prefixed with the part that is changed, in this case log. For example: log: forbid log --graph --no-walk On Sat, Mar 14, 2015 at 11:31:59PM +0200, epilys wrote: In git-log, --graph shows a graphical representation of a continuous commit history, and --no-walk shows discrete specified commits without continuity. This doesn't make sense, so we forbid the combined use of these flags. Signed-off-by: Manos Pitsidianakis epi...@norn.io --- builtin/log.c | 2 ++ t/t4202-log.sh | 4 2 files changed, 6 insertions(+) diff --git a/builtin/log.c b/builtin/log.c index dd8f3fc..0194133 100644 --- a/builtin/log.c +++ b/builtin/log.c @@ -155,6 +155,8 @@ static void cmd_log_init_finish(int argc, const char **argv, const char *prefix, memset(w, 0, sizeof(w)); userformat_find_requirements(NULL, w); +if (rev-graph rev-no_walk) Patch got corrupted here (Space before +) +die(--graph and --no-walk are incompatible); if (!rev-show_notes_given (!rev-pretty_given || w.notes)) rev-show_notes = 1; if (rev-show_notes) diff --git a/t/t4202-log.sh b/t/t4202-log.sh index 5f2b290..4dd939b 100755 --- a/t/t4202-log.sh +++ b/t/t4202-log.sh @@ -887,4 +887,8 @@ test_expect_success GPG 'log --graph --show-signature for merged tag' ' grep ^| | gpg: Good signature actual ' +test_expect_success 'forbid log --graph --no-walk' ' Here also +test_must_fail git log --graph --no-walk +' + test_done -- 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 very slow ?
On Sat, Mar 07, 2015 at 01:30:07AM +, Ken Moffat wrote: Hi, please CC me if that is not your usual fashion, because I am not subscribed. I use git for my build scripts - those are accessed over nfs. Since I started using 2.1 and later (I don't think I used 2.0) commands such as 'commit' take a long time before anything happens. I assumed that the newer version meant this would take longer. But today^Wyesterday I was bisecting the kernel on a local filesystem - even when the number of revisions left to test was in the single digits, git bisect took a long time to decide which revision should be the next one to test. The filesystems are ext4. Is this sort of delay normal now? What really prompted me to ask is that I ran git blame on a script, to see when I made a particular change so that I could add that information to a ticket, and almost gave up waiting because it felt as if it was taking for ever. What kind of repository are we talking about? How many files, how big? Git should not have become significantly slower recently. Also, might there be anti-virus software that slows down file access? -- 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: Checkout --force without complete overwrite?
On Fri, Mar 06, 2015 at 02:39:58AM +, Phil Hord (hordp) wrote: I have a repo whose workdir tends to get pretty dirty as I jump around from branch to branch tending weeds and whatnot. Sometimes when I try to switch branches git refuses because of local file changes. git checkout otherbranch error: Your local changes to the following files would be overwritten by checkout: foo.txt bar.c Please, commit your changes or stash them before you can switch branches. Aborting I resolve this by examining my local changes and deciding if I want to keep them or not. I keep the changes in the conflicting files that I want, and then I discard the rest. One way to discard the rest is to say git checkout HEAD -- foo.txt bar.c git checkout otherbranch But sometimes the list of local-change conflicts I want to discard is too long and this recipe seems like a good alternative to me: git checkout -f otherbranch But this is disastrous, because I have been focused on examining the conflicting local changes in foo.txt and bar.c, but I forgot about my non-conflicting changes to baz.c, lost as it is in a sea of untracked files making up the majority of my workdir local changes. So all my untracked files make the leap unscathed, but my precious forgotten changes in baz.c get wiped out by the checkout --force, even though the baz.c in index and in otherbranch are the same. I've read the documentation for 'git checkout --force' several times and I have a hard time deciding what it means to do. But I'm sure it's doing what it's designed to do and what the man page says it will. (English is my first language, btw.) Git normally refuses to overwrite uncomitted changes when checking out complete commits (so not when you check out individual files). --force overrides that behaviour. What I am seeking is some way to checkout the other branch and replace my conflicted local changes while ignoring my non-conflicting local changes in tracked files. Something like --force-gently, maybe. Does such an option exist? I could script something, but it comes up only often enough to bite me, so I'm sure I'd forget I had scripted it. Thanks, Phil What about git checkout -m otherbranch. This will try to merge the commit you checkout in the working tree, creating conflicts when they happen. This way, you can decide per conflict what you want to do, while non-conflicting changes are just kept. -- 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
