FW: FeatureRequest: Build improvements for Windows
Hmm, it is already happening, isn't it? There is already a support of MSVCR in git's code base. I am referring to replacing that current support of 'older' MSVCR in favor of the latest one, so to make the git's code base comparatively coherent and organized (as some/many instances of #ifdef _MSC_VER and #if define (_MSC_VER) _MSC_VER xxx etc. will be gone, for instance we don't need fallback for sprint or snprintf since C99 std support for those is provisioned). From: jacob.kel...@gmail.com Date: Sun, 26 Jul 2015 00:15:10 -0700 Subject: Re: FeatureRequest: Build improvements for Windows To: danglingpoin...@outlook.com CC: git@vger.kernel.org On Sat, Jul 25, 2015 at 11:23 PM, Dangling Pointer danglingpoin...@outlook.com wrote: Hello, In my understanding, the ratio between the mere consumers of git on Windows vs. people who compile git for Windows is 100,000 : 1. If there is a breaking change in the workflow of the latter set, who use Visual Studio to build git from source, I assume that is doable given a good reason, hence this post. With VS 2015, C99 support is finally added with some C11 features as well. See this blog: http://blogs.msdn.com/b/vcblog/archive/2015/06/19/c-11-14-17-features-in-vs-2015-rtm.aspx. One of the edition of new VS is Community edition, which is like professional edition but is free (also much superior than Express edition) and meant for open source projects. VS2015 also has the ability to target compiler for Wind-XP. I think the big issue is whether it has support for the various unix interfaces and unix shell commands we use. MinGW/MSYS comes with support for the unix interface, which I don't believe is that actually supported via MSYS and I don't know if VS2015 is supported? I don't think it's due to the C99 but due to need of posix interface which is not normally (fully) provided by Windows. Regards, Jake -- 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: FeatureRequest: Build improvements for Windows
(In-line posting preferred; top-posting deprecated ;-) (retain all cc's) Hmm, it is already happening, isn't it? There is already a support of MSVCR in git's code base. I am referring to replacing that current support of 'older' MSVCR in favor of the latest one, so to make the git's code base comparatively coherent and organized (as some/many instances of #ifdef _MSC_VER and #if define (_MSC_VER) _MSC_VER xxx etc. will be gone, for instance we don't need fallback for sprint or snprintf since C99 std support for those is provisioned). It's not clear if you (DP) are asking about using being able to use the Visual Studio IDE and gui to help visualise and develop the code, or to simply use the underlying MS compiler when making (using the Makefile) the Git code base. One can compile the codebase using the MS compiler (given a suitable environment, and setting the right Makefile flags), but that may not be what you were thinking of. The Windows team recently decided that the older Msysgit approach should be retired (can't find the link just now) and a new approach based on Msys2 started (http://git-for-windows.github.io/ and https://github.com/git-for-windows/git/wiki/FAQ). This is nearing completion. Meanwhile I have been working on fixing the msvc-build script, which can produce a git.sln and associated files (targeted originally at VS2008), and is now at the 'Validate this with the Windows guys' stage (http://marc.info/?l=gitm=143750907804881w=2 et.seq.). My code, for the new G4W SDK, has been rebased from the msygit version, and is now at https://github.com/git-for-windows/git/pull/256 Does that help for creating an IDE compilable version? Also, many thanks for yournote about the new VS Community edition (I'm still mainly working on an XP notebook for ease of carry). As an open community of independently minded folks it can tae a time to gel around a reasonably common approach, especially as Git will always be primarily focussed on Linux (it **is** the Linux (Linus's) VCS!). From: jacob.kel...@gmail.com On Sat, Jul 25, 2015 at 11:23 PM, Dangling Pointer danglingpoin...@outlook.com wrote: Hello, In my understanding, the ratio between the mere consumers of git on Windows vs. people who compile git for Windows is 100,000 : 1. If there is a breaking change in the workflow of the latter set, who use Visual Studio to build git from source, I assume that is doable given a good reason, hence this post. With VS 2015, C99 support is finally added with some C11 features as well. See this blog: http://blogs.msdn.com/b/vcblog/archive/2015/06/19/c-11-14-17-features-in-vs-2015-rtm.aspx. One of the edition of new VS is Community edition, which is like professional edition but is free (also much superior than Express edition) and meant for open source projects. VS2015 also has the ability to target compiler for Wind-XP. I think the big issue is whether it has support for the various unix interfaces and unix shell commands we use. MinGW/MSYS comes with support for the unix interface, which I don't believe is that actually supported via MSYS and I don't know if VS2015 is supported? I don't think it's due to the C99 but due to need of posix interface which is not normally (fully) provided by Windows. Git's code retains a C89 compatibility (IIUC). Regards, Jake -- -- Philip -- 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: FeatureRequest: Build improvements for Windows
I searched in code and found instances of #ifdef _MSC_VER in https://github.com/git/git (original repository, not the fork). I am coming from github, where I have found many native lib repositories have two build files, build.sh and build.cmd with some windows-specific code turds like #ifdef _MSC_VER etc. which nobody appreciate because CL.exe up until last VS release wasn't C99 complaint. This has changed with VS2015. If git/git does not share this philosophy of having a build file for both nix and win, then I wonder why do we even have MS compiler directives in git codebase in first place? That was the main source of confusion. If the repo owner is willing to drop the old compiler support for Windows, since many windows users do not build from source and tend to download the compiled binaries anyway. If they want, they can always use MinGW and VS2015 to build. The idea is to keep the codebase clean from outdated _MSC_VER conditions. In this age, free CI service (like AppVeyor) will build your code with latest compiler (MinGW GCC and MSVCR 2015) in a matter of minutes and then make the release artifacts available for download. I really don't see any point in still using 8 years old compiler on a 15 years old OS when we can just throw a .yml (appveyor config) file in the repo root and let the cloud handle the build business and verify the build by running tests. (well we are still using mailing lists, aren't we ;-) Besides, I had no idea about this fork: https://github.com/msysgit/git but it seems to be falling behind significantly from the upstream master (git/git). From: philipoak...@iee.org To: danglingpoin...@outlook.com CC: jacob.kel...@gmail.com; git@vger.kernel.org Subject: Re: FeatureRequest: Build improvements for Windows Date: Sun, 26 Jul 2015 12:27:19 +0100 (In-line posting preferred; top-posting deprecated ;-) (retain all cc's) Hmm, it is already happening, isn't it? There is already a support of MSVCR in git's code base. I am referring to replacing that current support of 'older' MSVCR in favor of the latest one, so to make the git's code base comparatively coherent and organized (as some/many instances of #ifdef _MSC_VER and #if define (_MSC_VER) _MSC_VER xxx etc. will be gone, for instance we don't need fallback for sprint or snprintf since C99 std support for those is provisioned). It's not clear if you (DP) are asking about using being able to use the Visual Studio IDE and gui to help visualise and develop the code, or to simply use the underlying MS compiler when making (using the Makefile) the Git code base. One can compile the codebase using the MS compiler (given a suitable environment, and setting the right Makefile flags), but that may not be what you were thinking of. The Windows team recently decided that the older Msysgit approach should be retired (can't find the link just now) and a new approach based on Msys2 started (http://git-for-windows.github.io/ and https://github.com/git-for-windows/git/wiki/FAQ). This is nearing completion. Meanwhile I have been working on fixing the msvc-build script, which can produce a git.sln and associated files (targeted originally at VS2008), and is now at the 'Validate this with the Windows guys' stage (http://marc.info/?l=gitm=143750907804881w=2 et.seq.). My code, for the new G4W SDK, has been rebased from the msygit version, and is now at https://github.com/git-for-windows/git/pull/256 Does that help for creating an IDE compilable version? Also, many thanks for yournote about the new VS Community edition (I'm still mainly working on an XP notebook for ease of carry). As an open community of independently minded folks it can tae a time to gel around a reasonably common approach, especially as Git will always be primarily focussed on Linux (it **is** the Linux (Linus's) VCS!). From: jacob.kel...@gmail.com On Sat, Jul 25, 2015 at 11:23 PM, Dangling Pointer danglingpoin...@outlook.com wrote: Hello, In my understanding, the ratio between the mere consumers of git on Windows vs. people who compile git for Windows is 100,000 : 1. If there is a breaking change in the workflow of the latter set, who use Visual Studio to build git from source, I assume that is doable given a good reason, hence this post. With VS 2015, C99 support is finally added with some C11 features as well. See this blog: http://blogs.msdn.com/b/vcblog/archive/2015/06/19/c-11-14-17-features-in-vs-2015-rtm.aspx. One of the edition of new VS is Community edition, which is like professional edition but is free (also much superior than Express edition) and meant for open source projects. VS2015 also has the ability to target compiler for Wind-XP. I think the big issue is whether it has support for the various unix interfaces and unix shell commands we use. MinGW/MSYS comes with support for the unix interface, which I don't believe is
Re: FeatureRequest: Build improvements for Windows
Hi, From: Dangling Pointer danglingpoin...@outlook.com I searched in code and found instances of #ifdef _MSC_VER in https://github.com/git/git (original repository, not the fork). I am coming from github, where I have found many native lib repositories have two build files, build.sh and build.cmd with Git is a *nix code base so rather than using build.*, it obviously uses a Makefile. The makefile can be slightly convoluted because it seeks to have maximum backward compatibility. some windows-specific code turds like #ifdef _MSC_VER etc. which nobody appreciate because CL.exe up until last VS release wasn't C99 complaint. This has changed with VS2015. https://github.com/git/git/blob/master/Documentation/CodingGuidelines#L174 The C89 compatibility came up recently (2015-04-30). It's still a live issue. If git/git does not share this philosophy of having a build file for both nix and win, then I wonder why do we even have MS compiler The git/git philosophy is maximum backward compatibility, with Gnu/Linux as a given. directives in git codebase in first place? That was the main source of confusion. If the repo owner is willing to drop the old compiler support for Windows, since many windows users do not build from source Surely it's a case of building on the shoulders of former giants. Many are still using VS200* out in the real world (my work uses V2008 and VS2006 commonly because of the need to support older embedded equipment) and tend to download the compiled binaries anyway. If they want, they can always use MinGW and VS2015 to build. The G4W projects do provide binaries as well as source code, and support older compilers... It's the choice here. The idea is to keep the codebase clean from outdated _MSC_VER conditions. In this age, free CI service (like AppVeyor) will build your code with latest compiler (MinGW GCC and MSVCR 2015) in a matter of minutes and then make the release artifacts available for download. I really don't see any point in still using 8 years old compiler on a 15 years old OS That's only a third of my coding life ;-). It's nice to use the latest and greatest, but sometimes if it ain't broke, don't fix it applies to choosing what to spend one's free hours on. when we can just throw a .yml (appveyor config) file in the repo root and let the cloud handle the build business and verify the build by running tests. (well we are still using mailing lists, aren't we ;-) Besides, I had no idea about this fork: https://github.com/msysgit/git but it seems to be falling behind significantly from the upstream master (git/git). If you look at the home page of the https://github.com/git-for-windows/git/wiki/ I provided, you'll be able to see why/how the team decided to leave that fork behind (though it did get a major security fix applied). Folks on the *nix side can be using v1.7.x and still have it all work, so there is no shame in using the msysgit1.9.5. The main point being that Git seeks to maintain backward compatibility and is careful about how code is introduced. It can be frustrating when one's latest and greatest idea is not as readily picked up as hoped, but a moment (or two's) reflection will help understand the broader issues that may pertain. That said useful new fetures (with justification, code, documentation, and review ;-) are welcome. Do have a look at the https://github.com/git-for-windows/git/wiki/How-to-participate From: philipoak...@iee.org (In-line posting preferred; top-posting deprecated ;-) (retain all cc's) Hmm, it is already happening, isn't it? There is already a support of MSVCR in git's code base. I am referring to replacing that current support of 'older' MSVCR in favor of the latest one, so to make the git's code base comparatively coherent and organized (as some/many instances of #ifdef _MSC_VER and #if define (_MSC_VER) _MSC_VER xxx etc. will be gone, for instance we don't need fallback for sprint or snprintf since C99 std support for those is provisioned). It's not clear if you (DP) are asking about using being able to use the Visual Studio IDE and gui to help visualise and develop the code, or to simply use the underlying MS compiler when making (using the Makefile) the Git code base. One can compile the codebase using the MS compiler (given a suitable environment, and setting the right Makefile flags), but that may not be what you were thinking of. The Windows team recently decided that the older Msysgit approach should be retired (can't find the link just now) and a new approach based on Msys2 started (http://git-for-windows.github.io/ and https://github.com/git-for-windows/git/wiki/FAQ). This is nearing completion. Meanwhile I have been working on fixing the msvc-build script, which can produce a git.sln and associated files (targeted originally at VS2008), and is now at the 'Validate this with the Windows guys' stage
Re: FeatureRequest: Build improvements for Windows
On Sat, Jul 25, 2015 at 11:23 PM, Dangling Pointer danglingpoin...@outlook.com wrote: Hello, In my understanding, the ratio between the mere consumers of git on Windows vs. people who compile git for Windows is 100,000 : 1. If there is a breaking change in the workflow of the latter set, who use Visual Studio to build git from source, I assume that is doable given a good reason, hence this post. With VS 2015, C99 support is finally added with some C11 features as well. See this blog: http://blogs.msdn.com/b/vcblog/archive/2015/06/19/c-11-14-17-features-in-vs-2015-rtm.aspx. One of the edition of new VS is Community edition, which is like professional edition but is free (also much superior than Express edition) and meant for open source projects. VS2015 also has the ability to target compiler for Wind-XP. I think the big issue is whether it has support for the various unix interfaces and unix shell commands we use. MinGW/MSYS comes with support for the unix interface, which I don't believe is that actually supported via MSYS and I don't know if VS2015 is supported? I don't think it's due to the C99 but due to need of posix interface which is not normally (fully) provided by Windows. Regards, Jake -- 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 v4 06/10] ref-filter: add option to match literal pattern
On Sun, Jul 26, 2015 at 10:45 AM, Eric Sunshine sunsh...@sunshineco.com wrote:
On Fri, Jul 24, 2015 at 3:04 PM, Karthik Nayak karthik@gmail.com wrote:
Since 'ref-filter' only has an option to match path names add an
option for plain fnmatch pattern-matching.
This is to support the pattern matching options which are used in `git
tag -l` and `git branch -l` where we can match patterns like `git tag
-l foo*` which would match all tags which has a foo* pattern.
Signed-off-by: Karthik Nayak karthik@gmail.com
---
diff --git a/ref-filter.c b/ref-filter.c
index 8f2148f..0a64b84 100644
--- a/ref-filter.c
+++ b/ref-filter.c
@@ -951,6 +951,31 @@ static int commit_contains(struct ref_filter *filter,
struct commit *commit)
/*
* Return 1 if the refname matches one of the patterns, otherwise 0.
+ * A pattern can be a literal prefix (e.g. a refname refs/heads/master
+ * matches a pattern refs/heads/mas) or a wildcard (e.g. the same ref
+ * matches refs/heads/mas*, too).
+ */
+static int match_pattern(const char **patterns, const char *refname)
+{
+ for (; *patterns; patterns++) {
+ /*
+* When no '--format' option is given we need to skip the
prefix
+* for matching refs of tags and branches.
+*/
+ if (!starts_with(*patterns, refs/tags/))
+ skip_prefix(refname, refs/tags/, refname);
+ if (!starts_with(*patterns, refs/heads/))
+ skip_prefix(refname, refs/heads/, refname);
+ if (!starts_with(*patterns, refs/remotes/))
+ skip_prefix(refname, refs/remotes/, refname);
Note the inefficiency here: You're performing an expensive
starts_with() on each pattern for each refname even though the
patterns will never change. You could instead compute starts_with()
for each pattern just once, in a preprocessing step, and remember each
result as a boolean, and then use the computed booleans here in place
of starts_with(). For a few refnames, this may not make a difference,
but for a project with a huge number, it could. Whether such an
optimization is worth the complexity (at this time or ever) is
something that can be answered by taking measurements.
Also, the repetition in the code is not all that pretty. You could
instead place refs/tags/, refs/heads/, and refs/remotes/ in a
table and then loop over them rather than repeating the code for each
one, though whether that would be an improvement is likely a judgment
call (so not something I'd insist upon).
I just put the starts_with() code so as to ensure that its only used when
we don't say refs/heads/, refs/remotes/ or refs/tags/ in the pattern.
But looking at the tag.c and branch.c implementations this should always be
done. Hence I think Ill move it outside the loop and make it mandatory as this
pattern matching is only used by tag and branch and as they by default
remove the
path of the ref. I think it'd make sense to remove it here also.
--
Regards,
Karthik Nayak
--
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: [RFC/PATCH] log: add log.firstparent option
On Sat, Jul 25, 2015 at 10:41:21AM -0700, Junio C Hamano wrote: I'm still on the fence to have the config kick in only for HEAD. Hmm, I cannot tell offhand if the confusion factor is worth it (I didn't say I don't think it is worth it). [...] I've snipped most of your response because it all seemed pretty reasonable to me. At this point I think I am of the opinion that the decision to use --first-parent is sufficiently nuanced that it the config option is not really a drop-in solution for people, even if their projects follow the matching workflow. Like you, I am not really _against_ it, but since nobody in this thread is saying yes, I would turn that on, that may be a sign. The patch is out there on the list, and I'd encourage people who think it might be useful to apply the patch and report back in a few weeks or months if they find it useful. We _could_ merge the patch to make that experimentation easier for users. The downside is we will be stuck supporting the log.firstParent option forever, but I don't think it is actively _wrong_ to have. Just possibly useless. And poor Josh, who so nicely came to the Git table at OSCON and talked to me about his project's workflow, has now had to put up with a slew of emails and no applied patch. :) But maybe this discussion is of some use; it has not been fruitless, as I think the best answer so far is encourage awareness and appropriate use of --first-parent. I admit I may be minority, but two common things I do everyday are log --first-parent v2.5.0-rc0.. and log --first-parent master..pu; I could certainly use a short-hand there. I already have alias for it, so this is not to help me personally, but log -FO to trigger first-parent one-line would make the alias unnecessary. I do not have an alias, but I spell it --firTAB. :) -Peff -- 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/6] Documentation/config: mention now and never for 'expire' settings
On 07/23/2015 09:00 PM, Eric Sunshine wrote: In addition to approxidate-style values (2.months.ago, yesterday), consumers of 'gc.*expire*' configuration variables also accept and respect 'now'/'all' (do it immediately) and 'never'/'false' (suppress entirely). Suggested-by: Michael Haggerty mhag...@alum.mit.edu Signed-off-by: Eric Sunshine sunsh...@sunshineco.com --- Reference: http://article.gmane.org/gmane.comp.version-control.git/274325 I sneaked in a minor whitespace fix. Documentation/config.txt | 13 - 1 file changed, 8 insertions(+), 5 deletions(-) diff --git a/Documentation/config.txt b/Documentation/config.txt index 1a8a399..cc920c0 100644 --- a/Documentation/config.txt +++ b/Documentation/config.txt @@ -1307,20 +1307,22 @@ gc.packRefs:: gc.pruneExpire:: When 'git gc' is run, it will call 'prune --expire 2.weeks.ago'. Override the grace period with this config variable. The value - now may be used to disable this grace period and always prune - unreachable objects immediately. + now may be used to disable this grace period and always prune + unreachable objects immediately; or never to suppress pruning. A semicolon should be used without a conjunction, and the parts of a sentence joined by a semicolon should be independent clauses. So this should probably be [...] The value now may be used to disable this grace period and always prune unreachable objects immediately, or never may be used to suppress pruning. gc.worktreePruneExpire:: When 'git gc' is run, it calls 'git worktree prune --expire 3.months.ago'. This config variable can be used to set a different grace period. The value now may be used to disable the grace - period and prune $GIT_DIR/worktrees immediately. + period and prune $GIT_DIR/worktrees immediately; or never to + suppress pruning. The same here. gc.reflogExpire:: gc.pattern.reflogExpire:: 'git reflog expire' removes reflog entries older than - this time; defaults to 90 days. With pattern (e.g. + this time; defaults to 90 days. The value all expires all + entries; and false disables expiration. With pattern (e.g. refs/stash) in the middle the setting applies only to the refs that match the pattern. Similarly, this could be fixed to [...] The value all expires all entries; false disables expiration. [...] @@ -1328,7 +1330,8 @@ gc.reflogExpireUnreachable:: gc.ref.reflogExpireUnreachable:: 'git reflog expire' removes reflog entries older than this time and are not reachable from the current tip; - defaults to 30 days. With pattern (e.g. refs/stash) + defaults to 30 days. The value all expires all entries; and + false disables expiration. With pattern (e.g. refs/stash) in the middle, the setting applies only to the refs that match the pattern. The same here. Also, I wonder why you suggest now/never for the first two settings, but all/false for the second two. Wouldn't it be less confusing to be consistent? Michael -- Michael Haggerty mhag...@alum.mit.edu -- 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 v4 01/10] ref-filter: add option to align atoms to the left
On Sun, Jul 26, 2015 at 11:08 AM, Eric Sunshine sunsh...@sunshineco.com wrote:
You can generate an interdiff with git diff branchname-v4
branchname-v5, for instance.
Off topic. But what stops me from doing this often is it creates a big
mess in git tag -l. Do we have an option to hide away some
insignificant: tags? reflog might be an option if we have something
like foo@{/v2} to quickly retrieve the reflog entry whose message
contains v2.
--
Duy
--
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: [RFC/PATCH] log: add log.firstparent option
On Sat, Jul 25, 2015 at 10:18:45AM -0700, Junio C Hamano wrote: [1] While reading the old git commit --notes thread recently, Johan Herland gave a plausible confusing example: ... Why --- To show that --- can be part of a commit message. :) That is all true, but such a commit already is problematic when used as an input to am, regardless of where the sign-off goes. Right, and that is why I think there is no problem at all with treating --- specially as part of format-patch. What I was trying to say here is that doing it for git commit is less obviously OK. Many people do not use am at all, and are otherwise fine with a message like the one above (tools like rebase used to eat their message, but I think that was fixed long ago). We could invent a new and more prominent delimiter, teach format-patch to add that between the log and patch if and only if the log has a three-dashes line in it (with an option to override that if and only if default), and teach mailsplit to pay attention to it. People who are relying on the fact that a three-dashes line in the local log message will be stripped off at the receiving end have to pass that The commit has three-dash in it as a cut-mark on purpose; don't add that prominent delimiter option when formatting their patches out for submission. But I somehow think it is not worth the effort. It is fairly well established that three-dash lines are cut marks and Johan's example log message above deliberately violates only to spite itself. My knee-jerk advice is that people can just rephrase s/Why/Reason/ and be done with it. Yeah, I agree it is not worth the effort. Three-dash is a totally fine micro-format for email messages, and I do not see anybody complaining about it. I just think that people who do not use am should not have to care about it. -Peff -- 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 v4 01/10] ref-filter: add option to align atoms to the left
On Sun, Jul 26, 2015 at 11:28 AM, Eric Sunshine sunsh...@sunshineco.com wrote: On Sun, Jul 26, 2015 at 12:36 AM, Karthik Nayak karthik@gmail.com wrote: On Sun, Jul 26, 2015 at 9:38 AM, Eric Sunshine sunsh...@sunshineco.com wrote: Also, it is helpful to reviewers if you include an interdiff at the bottom of your cover letter showing the changes from one version to another. You can generate an interdiff with git diff branchname-v4 branchname-v5, for instance. I've been working on the same branch, and that's why I didn't really provide interdiff's, and I kinda worked on the same branch again, so I wont be giving an interdiff for the next series either, but I'll keep this in mind and follow it from the forthcoming patch series. Thanks You can still provide an interdiff. It is quite likely that you can find the commit corresponding to v4 in the reflog for that branch (see git-reflog). Failing that, an easy way to recover the state at v4 is to create a new branch (from the parent of your current working branch) and apply the v4 patches which you sent to the mailing list. If Junio queued v4 in his 'pu' branch, then you can also recover from there. Once you've recovered the state of v4 using one of the methods mentioned here (or some other), you can make an interdiff when sending out v5. Haha, I was just thinking about applying my patches and doing it, will definitely provide an interdiff. Reviewers do appreciate that you provide a URL to the previous version and take the time to explain in your cover letter what changed (and why). Including an interdiff is one more way to ease the review process, and is also appreciated, so it may be worthwhile to put in the effort to recover the state of v4 so that you can include an interdiff with v5. Doing so does require a bit of extra work for you, but that's work you only need to do *once*, whereas if you don't do it, then you place the burden on *each* reviewer for *each* version, which quickly adds up to a lot more work for those reviewing your submissions. Yes! definitely, I'll make sure that I provide the interdiff, I'll look at reflog, thanks a lot. I appreciate how reviewers take time to review code, its a wonderful process. I will be glad to put in any time to make their process easier -- Regards, Karthik Nayak -- 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
FeatureRequest: Build improvements for Windows
Hello, In my understanding, the ratio between the mere consumers of git on Windows vs. people who compile git for Windows is 100,000 : 1. If there is a breaking change in the workflow of the latter set, who use Visual Studio to build git from source, I assume that is doable given a good reason, hence this post. With VS 2015, C99 support is finally added with some C11 features as well. See this blog: http://blogs.msdn.com/b/vcblog/archive/2015/06/19/c-11-14-17-features-in-vs-2015-rtm.aspx. One of the edition of new VS is Community edition, which is like professional edition but is free (also much superior than Express edition) and meant for open source projects. VS2015 also has the ability to target compiler for Wind-XP. If all the instances of fallback code guarded by #ifdef _MSC_VER and #if defined(_MSC_VER) _MSC_VER xxx etc. are removed from git's source code in favor of VS2015, it will help the code maintainability in future and standard C code will thrive. The very few enthusiasts who were building Windows code can download the said free edition of VS2015 and build the project the same way as they were building before (I.e. using CLI . Update to docs will look like: To build on Windows, you need to use MinGW or VS2015 (community, express desktop, professional or enterprise editions). I think this is choice for those few, who were building from source. Also, Clang and LLVM are also now available on Windows. So many options if someone is looking hard. What I am trying to say is dropping some century old version of VS support for a lazy user should not be an excuse for a deal-breaker anymore. World is moving at much faster pace to care about lazy. :) In addition to Jenkins, there is also a free-for-OSS and easy-to-configure CI service called AppVeyor, which let you build using VS2015 and MInGW machineries (http://www.appveyor.com/updates/2015/07/21) and saves the artifacts for download or upload to somewhere. If git repo is configured with AppVeyor, it will automate the process of building releases for Windows, and there will be no version disparity like present (the current released version of git on Mac is v2.4.3 while that on misfortunate Windows is v1.9.5). In future if CMake (http://www.cmake.org/) is used in this repo to automate and unify all build systems, that is also available on AppVeyor, Jenkins, Travis etc. Thank you for the patience and I hope someone will consider and approve these changes at some near point in future. -- 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
