git objects
Hi, When ever I make a commit (assume I'm changing a single file) and do a 'git push origin master', git says 'Counting objects: 6, done.' Does git makes 6 objects everytime? What are those objects? -- Thiago Farina -- 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 with HTTPS support: avoiding libcurl?
On Tue, Dec 22, 2015 at 1:39 PM, Paul Smith <p...@mad-scientist.net> wrote: > I'm trying to build Git (2.6.4) on GNU/Linux, but without any > requirements (other than basic libc etc.) on the local system. This > works fine except for one thing: git-remote-https. > > In order to build this I need to have libcurl, but libcurl is a MONSTER > library with an enormous number of prerequisites (see below). > I think Git would have to be changed to use raw sockets and implement everything it needs on top of that, like libgit2 already does. Certainly this won't be a trivial task. -- Thiago Farina -- 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: CURLOPT_NOBODY
The same logic you apply to CURLOPT_FILE - CURLOPT_WRITEDATA? Bye! -- Thiago Farina -- 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
curl
Hi, Is it right that git uses libcurl to download while libgit2 does without it? -- Thiago Farina -- 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: About my git workflow; maybe it's useful for others
On Mon, Dec 29, 2014 at 10:22 PM, Stefan Beller sbel...@google.com wrote: Hi, so I have been sending commits to the git mailing list occasionally for quite some time. In the last couple of weeks I send more and more patches to the mailing list as it's part of my job now. Here is a collection of practices I am following (or want to follow) and they seem to be effective. Most of this is already documented in various documents in Documentation/* and this email is no news for the regular contributors. It may help new comers though. * Split patches up into logical pieces as you go. It's easy to go wild and after hours of hacking you have implemented a cool new feature. This the natural flow of hacking as it's the most fun. But this approach is not easy to be reviewed. So let me explain how reviewing works in the git project. Reviewing works in the git project is quite liberal, anybody is encouraged to comment on patches flying by. Junio, the maintainer then decides which patches he picks up and merges them into the various stages of git (pu, next, master, maint). The decision which patches are worth for inclusion is based on the amount of discussion by the community and generally a patch only makes it if a concensus is met. * git send-email is the only email client I trust for sending patches IMO, sending email is the easiest part. The hard begins when you have to edit your patch and resend with the reviewers' feedback incorporated. For me that is the most tricky and hard part to get right, specially when using GMail as an email client. How do you handle that part of the process? -- Thiago Farina -- 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: About my git workflow; maybe it's useful for others
On Wed, Apr 22, 2015 at 4:50 PM, Stefan Beller sbel...@google.com wrote: On Wed, Apr 22, 2015 at 12:38 PM, Thiago Farina tfrans...@gmail.com wrote: IMO, sending email is the easiest part. The hard begins when you have to edit your patch and resend with the reviewers' feedback incorporated. For me that is the most tricky and hard part to get right, specially when using GMail as an email client. How do you handle that part of the process? I try to have as much in git as possible. So when the reviews trickle in, I change my commits (in git) accordingly via rebase and edit and lots of fixup commits. I use git notes to keep track of changes from one version to another. Having the changes of the changes in the git notes, I am (in theory) always able to kick out a new version of the patch series with rm 00* # delete old patches git format-patch --notes --coverletter somebranch...HEAD edit -cover-letter.patch git send-email 00* --to=mailing list --to=j...@doe.org --cc=m...@mustermann.de Is that capable of keeping the next patch set in the same thread that started when you sent the initial patch? Otherwise things get disconnected. -- Thiago Farina -- 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: socket_perror() bug?
On Mon, Mar 31, 2014 at 5:50 PM, Junio C Hamano gits...@pobox.com wrote: Thiago Farina tfrans...@gmail.com writes: In imap-send.c:socket_perror() we pass |func| as a parameter, which I think it is the name of the function that called socket_perror, or the name of the function which generated an error. But at line 184 and 187 it always assume it was SSL_connect. Should we instead call perror() and ssl_socket_error() with func? Looks that way to me, at least from a cursory look. Would you accept such a patch? diff --git a/imap-send.c b/imap-send.c index 0bc6f7f..bb04768 100644 --- a/imap-send.c +++ b/imap-send.c @@ -181,10 +181,10 @@ static void socket_perror(const char *func, struct imap_socket *sock, int ret) case SSL_ERROR_NONE: break; case SSL_ERROR_SYSCALL: - perror(SSL_connect); + perror(func); break; default: - ssl_socket_perror(SSL_connect); + ssl_socket_perror(func); break; } } else -- Thiago Farina -- 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
SSL_CTX leak?
Hi, Do we leak the context we allocate in imap-send.c:280 intentionally? Regards, -- Thiago Farina -- 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] gc: notice gc processes run by other users
On Tue, Dec 31, 2013 at 10:07 AM, Kyle J. McKay mack...@gmail.com wrote: Since 64a99eb4 git gc refuses to run without the --force option if another gc process on the same repository is already running. However, if the repository is shared and user A runs git gc on the repository and while that gc is still running user B runs git gc on the same repository the gc process run by user A will not be noticed and the gc run by user B will go ahead and run. The problem is that the kill(pid, 0) test fails with an EPERM error since user B is not allowed to signal processes owned by user A (unless user B is root). Update the test to recognize an EPERM error as meaning the process exists and another gc should not be run (unless --force is given). Looks like you are missing your Signed-off-by: line. -- Thiago Farina -- 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 2/2] Move sequencer to builtin
May be because they (LKM) are more open to such architectural and organization refactorings? Some maintainers, like Greg Kroah-Hartman and possibly others accept clean up patches, such thing seems to be unacceptable here on git. Looks like there is space here only for features and bug fixes. Nothing else. I'm not saying that is bad at all. -- 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
reverting changes
Hi, When I want to revert a change to a file that is already committed what is the best way? The way I found was: $ git checkout HEAD /path/to/my/file $ git reset HEAD /path/to/my/file Is this the canonical/best way or there other (easier-faster) ways? Thanks, -- 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 6/8] imap-send: change msg_data from storing (char *, len) to storing strbuf
On Sat, Dec 1, 2012 at 11:48 PM, Junio C Hamano gits...@pobox.com wrote: I suggest a separate patch series dedicated to deleting *all* the extra imap infrastructure at once. That being said, I'm not committing to do so. (We could add it to an straightforward projects for aspiring git developers list, if we had such a thing.) A low-hanging fruit and/or janitorial work stack may be worth having. That would be good for not so versed developers, I think. Do we have a place for listing janitor projects? -- 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: gitk: Portuguese Ignore space change translation
Hi Joao, On Tue, Nov 20, 2012 at 8:03 AM, Joao Vitor P. Moraes jvl...@gmail.com wrote: Inside gitk there's a checkbox which says: Ignore space change It was translated to portuguese (pt-br) as: Ignorar mudanças de caixa But that message in portuguese means: Ignore case changes that checkbox does not ignore case changes, but instead it ignores space changes, a better translation would be Ignorar mudanças de espaço or As a native speaker I'd say go with that one. Although 'Ignorar espaçamentos' sounds more succinct. -- 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: Reviews on mailing-list
On Sun, Nov 11, 2012 at 10:14 AM, Felipe Contreras felipe.contre...@gmail.com wrote: Requiring everyone to use a web browser would limit the amount of ways people can review patches. I don't see that as a limitation as I think everyone has access to a web browser these days, don't have? How come that can be an impediment to move forward way of this awkward way of reviewing patches through email? It's not awkward, it's the most sensible way. The most harder way I think? Look at this: https://gerrit.chromium.org/gerrit/#/q/status:open+project:chromiumos/platform/power_manager,n,z There I can go and see many informations that through this mailing list I can't or have to do much more work in order to archive this. If you open one of the 'patches' you can see some relevant information: - Who is the owner/author - Was it verified? - Is it ready for landing? - If I click on Side-by-side I get a nice diff view interface that plan text email does NOT give me. - Was it reviewed/approved (+1, +2)? - It can be merged by one click. - The interface also provide the command line to download/apply the patch for me. - Isn't there a reason (implicit there) for Google being using tools like Gerrit/CodeReview(rietveld)/Mondrian for handling his code reviews rather than solely by 'email'? You just replied to my mail the same way I would reply to a patch. I replied through a web browser by the Gmail interface. ;) There are a lot of issues of having to use email for reviewing patches that I think Gerrit is a superior alternative. There are no issues. It works for Linux, qemu, libav, ffmpeg, git, and many other projects. And many people are arguing for it! Nope, they are not. If they weren't then nobody would be suggesting to use Gerrit for handling the review of git patches. But I think the big resistance comes from the fact that the core developers handle/review the git patches through Gnus/Emacs, so that is enough for them and they don't want to make the switch because of that? -- 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: Reviews on mailing-list
On Sat, Nov 10, 2012 at 9:40 PM, Felipe Contreras felipe.contre...@gmail.com wrote: On Sun, Nov 11, 2012 at 12:19 AM, Deniz Türkoglu de...@spotify.com wrote: This is my first mail to the git mailing list. I have been following the list for some time now and I would like to suggest moving the reviews out of the mailing list, for example to a gerrit instance, I believe it would improve the commits and the mailing list. I have a filter on 'PATCH', but I feel I miss some of the discussion, and things that I would be interested in. I have spoken to Shawn Pearce (gerrit project lead, google) and he said he is OK with hosting the gerrit instance. I would like to hear your thoughts on this. Personally I think reviews on the mailing list is far superior than any other review methods. I've even blogged about it and all the reasons[1]. Gerrit is better than bugzilla, but it still requires a web browser, and logging in. Requiring a web browser is a huge requirement, ham?? How come that can be an impediment to move forward way of this awkward way of reviewing patches through email? Switching to Gerrit would mean everyone would be using the same tool instead of anyone using its own email client (gmail, mutt, thunderbird, whatever...) and having to figure out git format-patch, git send-email (--reply-to where?). There are a lot of issues of having to use email for reviewing patches that I think Gerrit is a superior alternative. And many people are arguing for it! Let's move on... -- 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: build deps
On Mon, Oct 15, 2012 at 12:44 PM, Michael J Gruber g...@drmicha.warpmail.net wrote: clang reported this: combine-diff.c:1006:19: warning: adding 'int' to a string does not append to the string [-Wstring-plus-int] prefix = COLONS + offset; ~~~^~~~ combine-diff.c:1006:19: note: use array indexing to silence this warning prefix = COLONS + offset; ^ [ ] 1 warning generated. Does COLONS[offset] silence that? Yes. -- 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: build deps
On Mon, Oct 8, 2012 at 7:52 PM, Andrew Wong andrew.k...@gmail.com wrote: On 10/08/12 17:36, Thiago Farina wrote: OK, after running ./configure I tried the make command again. CC credential-store.o /bin/sh: clang: not found make: *** [credential-store.o] Error 127 $ which clang /home/tfarina/chromium/src/third_party/llvm-build/Release+Asserts/bin/clang $ clang --version clang version 3.2 (trunk 163674) Target: x86_64-unknown-linux-gnu Thread model: posix Looks like something went wrong with make setting PATH. I wonder if the + sign in your path is somehow messing things up. Would be something that could be fixed in git? Are you trying to compile specifically with clang? Nope, it just happen that I switched to clang because I use it to compile chromium and I need it to use the chrome_plugin[1]. If not, maybe try unsetting the CC env var, and run configure again? Just setting CC to gcc works for me. But still, I'd like to be able to build with clang (may be as you noted is just something with the + in my PATH). [1] http://git.chromium.org/gitweb/?p=chromium.git;a=tree;f=tools/clang/plugins;h=8e79d8f35d5ccfee82b6ab8f27ea8b5d820c772d;hb=HEAD -- 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: build deps
On Thu, Oct 11, 2012 at 10:06 PM, Andrew Wong andrew.kw.w.li...@gmail.com wrote: On 10/11/12 16:54, Thiago Farina wrote: Just setting CC to gcc works for me. But still, I'd like to be able to build with clang (may be as you noted is just something with the + in my PATH). Oh, I just realized you were using sudo. The PATH environment was probably not inherited when you use sudo to run make. So the subsequent shells statred by make' were not able to find clang. Interesting, thank you for your observation. This worked for me now: $ git clone https://github.com/gitster/git $ cd git $ make configure $ ./configure $ make $ ./git version git version 1.8.0.rc2 clang reported this: combine-diff.c:1006:19: warning: adding 'int' to a string does not append to the string [-Wstring-plus-int] prefix = COLONS + offset; ~~~^~~~ combine-diff.c:1006:19: note: use array indexing to silence this warning prefix = COLONS + offset; ^ [ ] 1 warning generated. grep.c:451:16: warning: comparison of unsigned enum expression 0 is always false [-Wtautological-compare] if (p-field 0 || GREP_HEADER_FIELD_MAX = p-field) ^ ~ 1 warning generated. -- 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: build deps
On Mon, Oct 8, 2012 at 6:36 PM, Thiago Farina tfrans...@gmail.com wrote: On Mon, Oct 8, 2012 at 1:09 PM, Andrew Wong andrew.k...@gmail.com wrote: On 10/07/12 20:39, Thiago Farina wrote: When trying to build from source but it's failing: $ sudo make prefix=/usr/local all LINK git-credential-store gcc: @CHARSET_LIB@: No such file or directory make: *** [git-credential-store] Error 1 Did you run the configure script? Hum, I haven't. Now I did. In the source folder, do you have either file config.mak or config.mak.autogen ? After running ./configure, now I have. If you do, try removing them, and compile again. Which version are you compiling? $ cat GIT-VERSION-FILE GIT_VERSION = 1.7.12.84.gefa6462 Did you get the source files from tar? Or from git? From git (git://git.kernel.org/pub/scm/git/git.git). OK, after running ./configure I tried the make command again. CC credential-store.o /bin/sh: clang: not found make: *** [credential-store.o] Error 127 $ which clang /home/tfarina/chromium/src/third_party/llvm-build/Release+Asserts/bin/clang $ clang --version clang version 3.2 (trunk 163674) Target: x86_64-unknown-linux-gnu Thread model: posix Also: $ echo $CC clang -B/usr/local/gold/bin -- 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 08/10] Integrate wildmatch to git
On Fri, Oct 5, 2012 at 1:41 AM, Nguyễn Thái Ngọc Duy pclo...@gmail.com wrote:
This makes wildmatch.c part of libgit.a and builds test-wildmatch; the
dependency on libpopt in the original has been replaced with the use
of our parse-options. Global variables in test-wildmatch are marked
static to avoid sparse warnings.
Signed-off-by: Nguyễn Thái Ngọc Duy pclo...@gmail.com
Signed-off-by: Ramsay Jones ram...@ramsay1.demon.co.uk
Signed-off-by: Junio C Hamano gits...@pobox.com
---
.gitignore | 1 +
Makefile | 3 ++
t/t3070-wildmatch.sh | 27
test-wildmatch.c | 88
++--
wildmatch.c | 26 +---
5 files changed, 75 insertions(+), 70 deletions(-)
create mode 100755 t/t3070-wildmatch.sh
diff --git a/test-wildmatch.c b/test-wildmatch.c
index 88585c2..bb726c8 100644
--- a/test-wildmatch.c
+++ b/test-wildmatch.c
@@ -19,34 +19,38 @@
/*#define COMPARE_WITH_FNMATCH*/
-#define WILD_TEST_ITERATIONS
-#include lib/wildmatch.c
+#include cache.h
+#include parse-options.h
+#include wildmatch.h
-#include popt.h
+#ifndef MAXPATHLEN
+#define MAXPATHLEN 1024
+#endif
+#ifdef NO_STRLCPY
+#include compat/strlcpy.c
+#define strlcpy gitstrlcpy
+#endif
#ifdef COMPARE_WITH_FNMATCH
#include fnmatch.h
-int fnmatch_errors = 0;
+static int fnmatch_errors = 0;
#endif
-int wildmatch_errors = 0;
-char number_separator = ',';
+static int wildmatch_errors = 0;
typedef char bool;
-int output_iterations = 0;
-int explode_mod = 0;
-int empties_mod = 0;
-int empty_at_start = 0;
-int empty_at_end = 0;
-
-static struct poptOption long_options[] = {
- /* longName, shortName, argInfo, argPtr, value, descrip, argDesc */
- {iterations, 'i', POPT_ARG_NONE, output_iterations, 0, 0, 0},
- {empties,'e', POPT_ARG_STRING, 0, 'e', 0, 0},
- {explode,'x', POPT_ARG_INT,explode_mod, 0, 0, 0},
- {0,0,0,0, 0, 0, 0}
+static int explode_mod = 0;
Isn't static variables like this initialized to zero by default? There
is a high chance that I might be wrong though.
--
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 5/9] Refactor excluded and path_excluded
On Thu, Sep 6, 2012 at 9:13 AM, Nguyen Thai Ngoc Duy pclo...@gmail.com wrote: On Thu, Sep 6, 2012 at 10:21 AM, Junio C Hamano gits...@pobox.com wrote: Nguyen Thai Ngoc Duy pclo...@gmail.com writes: We could introduce exclude_path() and kill path_excluded() then. There are just about 5-6 call sites to replace. The name path_excluded(... path ...) sounds like it is asking a yes/no question is this path excluded?, which actually is what is going on. The name exclude_path(... path ...) sounds as if you are requesting somebody to exclude the path. Does that meaning match the semantics of the function? I'm not great at naming. And path_excluded() cannot be reused to avoid problems with other ongoing series if any. So path_is_excluded()? is_path_excluded()? -- 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: pushing branches
On Sat, Jul 21, 2012 at 4:33 PM, Junio C Hamano gits...@pobox.com wrote: Yes. Hence does not make sense to ask git to do push origin master while inside feature-work branch. No. As long as you know your master is ready and suitable to be published when you ask push, the command perfectly makes sense; it does not matter on what branch you are on. You may say $ git checkout master ... work work work ... $ make test ... ahh, perfection! ... $ git checkout -b feature ... let's build a bit more .. ... while I am having fun, let's not forget to push the ... part that is already solid out $ git push origin master and that is perfectly fine without git checkout master before pushing (and git checkout feature after to come back to what you were doing). In my case it wouldn't because I do not modify my master branch, I just fetch upstream, merge upstream/master into my local master branch and switch to feature-work, then git push origin master will always give me Everything up-to-date I suppose (that is what always happen in my case/workflow). And just learned, the answer to my question is, while in feature-work branch, 'git push origin feature-work'. Which does what I wanted. -- 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
pushing branches
Hi, How can I push a working branch to github inside it? E.g: # On master: $ git checkout -b feature-work # On feature-work # vi, hack, commit, ready to push $ git push origin master # here I expected it would working pushing my commits to a feature-work branch in github. Or if I omit master it gives me a [rejected] error. Everything up-to-date. $ git checkout master $ git push origin feature-work # Now the branch is pushed. Thanks, -- 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: pushing branches
On Fri, Jul 20, 2012 at 12:46 PM, Junio C Hamano gits...@pobox.com wrote: Thiago Farina tfrans...@gmail.com writes: How can I push a working branch to github inside it? E.g: # On master: $ git checkout -b feature-work # On feature-work # vi, hack, commit, ready to push $ git push origin master # here I expected it would working pushing my git push origin master is a short-hand for git push origin refs/heads/master:refs/heads/master to update their master branch with what you have in your master branch. See output from $ git push --help for details. I think you are trying to update, while on your feature-work branch, their master with your feature-work branch (or more generally, the current HEAD), so $ git push origin HEAD:master is perhaps what you are looking for? What I'm looking for is to upload/create the remote branch in github from inside my local branch, without having to checkout master in order to do so. -- 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: pushing branches
On Fri, Jul 20, 2012 at 4:19 PM, PJ Weisberg p...@irregularexpressions.net wrote: On Fri, Jul 20, 2012 at 8:49 AM, Thiago Farina tfrans...@gmail.com wrote: What I'm looking for is to upload/create the remote branch in github from inside my local branch, without having to checkout master in order to do so. In that case, do exactly what you did, except don't checkout master. Why you suggest that? If I demonstrated that origin master or just origin in the current branch doesn't do what I want, i.e, push it to github. -- 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: Extract Git classes from git-svn (1/10)
On Wed, Jul 18, 2012 at 2:49 AM, Junio C Hamano gits...@pobox.com wrote: There may be a hosting site with better code review features, but all the code review of Git happens on this mailing list, and that is not likely to change in the near future. For me, you know, it's codereview, aka rietveld. [1] [1] code.google.com/p/rietveld/ -- 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 can I append authentication with git push ?
On Thu, Jul 12, 2012 at 5:18 AM, J. Bakshi joydeep.bak...@infoservices.in wrote: Or any repo wise configuration file where I can save the info, so that it doesn't ask the credential before every push ? I'd like to know how to do that too. It's a pain to have to type username and password every time I need to push to github. (Linux here btw). -- 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
