using multiple version of git simultaneously
Hi, I'm trying to use different version of git simultaneously. So how can i append some suffix (like "--program-suffix=git1.8) so that i can distinguish between different versions. -- Cheers arif -- 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: using multiple version of git simultaneously
On 11/17/2012 10:16 PM, Jeff King wrote: > On Sat, Nov 17, 2012 at 02:50:31PM +, Tomas Carnecky wrote: > >> On Sat, 17 Nov 2012 20:25:21 +0600, arif wrote: > >> Install each version into its own prefix (~/git/1.8.0/, ~/git/1.7.0/ etc). > > Once you have done that, you can also symlink the binary from each into > your regular PATH (e.g., ln -s ~/git/1.8.0/bin/git ~/bin/git.v1.8) to > make it easy to switch between them. The installed exec-path is baked in > at compile-time, so it finds the correct git sub-programs properly. > > I keep a couple dozen built versions of git around like this for quick > regression testing of bugs we see on the list. > > -Peff > So what you are saying that, making a symlink for "git" is sufficient. I don't need to make symlinks for ever git subbinaries. Is that correct? -- Cheers arif -- 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
Know how much to download before clonig
Hi, Is there any way so that i can tell how much i have to download to obtain a full clone (not a shallow one) of a respository? -- Cheers arif -- 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: Working with public-inbox.org [Was: [PATCH] rev-parse: respect core.hooksPath in --git-path]
On 02/10/2017 11:10 AM, Johannes Schindelin wrote: Hi Arif, On Wed, 24 Aug 2016, Johannes Schindelin wrote: I recently adapted an old script I had to apply an entire patch series given the GMane link to its cover letter: https://github.com/git-for-windows/build-extra/blob/master/apply-from-gmane.sh Maybe you find it in you to adapt that to work with public-inbox.org? Oh well. That would have been too easy a task, right? As it happens, I needed this functionality myself (when reworking my git-path-in-subdir patch to include Mike Rappazzo's previous patch series that tried to fix the same bug). I copy-edited the script to work with public-inbox.org, it accepts a Message-ID or URL or GMane URL and will try to apply the patch (or patch series) on top of the current revision: https://github.com/git-for-windows/build-extra/blob/2268850552c7/apply-from-public-inbox.sh Thanks for the link. One thing that comes to mind that is that it may be better to just download the patches and then manually apply them afterwords rather than doing it in the script itself. Or at least add an option to the script to not automatically invoke git am. Getting back to the point I made when this thread was still active, I still think it would be better to be able to list the message-id values in the header or body of the cover letter message of a patch series (preferably the former) in order to facilitate downloading the patches via NNTP from gmane or public-inbox.org. That would make it easier compared to the different, ad-hoc, methods that exist for each email client. Alternatively, or perhaps in addition to the list of message-ids, a list of URLs to public-inbox.org or gmane messages could also be provided for those who prefer to download patches via HTTP.
Re: Working with public-inbox.org [Was: [PATCH] rev-parse: respect core.hooksPath in --git-path]
On 02/13/2017 02:21 PM, Junio C Hamano wrote: Arif Khokar writes: ... I still think it would be better to be able to list the message-id values in the header or body of the cover letter message of a patch series (preferably the former) in order to facilitate downloading the patches via NNTP from gmane or public-inbox.org. You are looking at builtin/log.c::make_cover_letter()? Patches welcome, but I think you'd need a bit of preparatory refactoring to allow gen_message_id() be called for all messages _before_ this function is called, as currently we generate them as we emit each patch. Thank you for the advice; I'll look into it. One concern I have regarding this idea is whether or not SMTP servers typically replace a Message-Id header set by the client. If that's the case, then this approach may unexpectedly fail for some people depending on what email provider they use (if they don't maintain their own MTA setup). Alternatively, or perhaps in addition to the list of message-ids, a list of URLs to public-inbox.org or gmane messages could also be provided for those who prefer to download patches via HTTP. Many people around here do not want to repeat the mistake of relying too much on one provider. Listing Message-IDs may be a good idea, listing URLs that are tied to one provider is less so. I agree. I've actually thought that it would be useful to mirror a read-only copy of the mailing list on a public newsgroup that could be accessed through a free provider such as eternal-september.org or the Google groups interface. It certainly would reduce the potential losing easy access to the archives of this email list if gmane and public-inbox.org fail. But I suspect doing something like that would potentially increase the spam volume substantially for regular participants/contributors.
Re: Working with public-inbox.org [Was: [PATCH] rev-parse: respect core.hooksPath in --git-path]
On 02/13/2017 09:37 AM, Johannes Schindelin wrote: Hi Arif, On Mon, 13 Feb 2017, Arif Khokar wrote: Thanks for the link. One thing that comes to mind that is that it may be better to just download the patches and then manually apply them afterwords rather than doing it in the script itself. Or at least add an option to the script to not automatically invoke git am. I actually had expected *you* to put in a little bit of an effort, too. In fact, I was very disappointed that you did not even look into porting that script to use public-inbox instead of GMane. I wasn't aware of that expectation. My idea was to use NNTP as a way to facilitate the development of a new git utility that would serve as the inverse of git-send-email (sort of like the relationship between git format-patch and git am), rather than using a IIRC, I had posted some proof-of-concept Perl code to do so back in August in Looking at public-inbox now at the archives of this group, it appears that several of the messages I sent weren't archived for some reason (and I didn't see any more responses to what I posted at the time). The messages are accessible via NNTP when connecting to gmane though. Also, looking at the source of the message I referenced, it appears that my MUA decided to base64 encode the message for some reason (which may have resulted in it getting filtered by those who I sent the message to). I will look into this more now (given yours and Junio's responses). Getting back to the point I made when this thread was still active, I still think it would be better to be able to list the message-id values in the header or body of the cover letter message of a patch series (preferably the former) in order to facilitate downloading the patches via NNTP from gmane or public-inbox.org. That would make it easier compared to the different, ad-hoc, methods that exist for each email client. You can always do that yourself: you can modify your cover letter to include that information. Certainly, but it would be nice to be able to have it done automatically by git format-patch (which I'll look into). Note that doing this automatically in format-patch may not be appropriate, as 1) the Message-ID could be modified depending on the mail client used to send the mails I think the best approach would be not to make including the message-id values the default behavior. Specifying a new command-line option to enable that behavior should address those concerns I think. and 2) it is not unheard of that a developer finds a bug in the middle of sending a patch series, fixes that bug, and regenerates the remainder of the patch series, completely rewriting those Message-IDs. Perhaps, but should something like that not warrant a re-roll of sorts. That is, one should reply to the partial patch series stating that there is a bug that renders this particular patch (series) un-usable and the re-roll could be posted as a reply to the original cover letter? Alternatively, or perhaps in addition to the list of message-ids, a list of URLs to public-inbox.org or gmane messages could also be provided for those who prefer to download patches via HTTP. At this point, I am a little disinterested in a discussion without code. I brought some code to the table, after all. If you have the time, please take a look at the message-id I referenced. If you need, I can re-post the proof-of-concept code.
Re: Working with public-inbox.org [Was: [PATCH] rev-parse: respect core.hooksPath in --git-path]
On 02/13/2017 10:56 PM, Arif Khokar wrote: I wasn't aware of that expectation. My idea was to use NNTP as a way to facilitate the development of a new git utility that would serve as the inverse of git-send-email (sort of like the relationship between git format-patch and git am), rather than using a ...custom script that's tightly coupled to gmane and public-inbox.org
Re: Working with public-inbox.org [Was: [PATCH] rev-parse: respect core.hooksPath in --git-path]
On 02/13/2017 11:41 PM, Junio C Hamano wrote: Arif Khokar writes: One concern I have regarding this idea is whether or not SMTP servers typically replace a Message-Id header set by the client. The clients are supposed to give Message-IDs, but because some clients fail to do so, SMTP server implementations are allowed to add an ID to avoid leaving a message nameless (IIRC, 6.3 in RFC2821). So "replace" would be in violation. But some parts of the world ignore RFCs, so... Based on my testing, gmail and comcast (and my work email) will preserve the Message-Id header set by the client, but hotmail.com/live.com/outlook.com will replace it with their generated value. Based on a small sample of email addresses of those who post to this list, it appears that most people are using their own MTA to send email, or are using gmail, so they probably wouldn't be affected by the issue.
