Re: [PATCH] sha1_file: use access(), not lstat(), if possible

Hi, On Sat, 22 Jul 2017, Junio C Hamano wrote: > Johannes Schindelin writes: > > > But this whole thread taps into a gripe I have with parts of Git's code > > base: part of the code is not clear at all in its intent by virtue of > > calling whatever POSIX function

Re: [PATCH] PRItime: wrap PRItime for better l10n compatibility

Hi Junio, On Sat, 22 Jul 2017, Junio C Hamano wrote: > Johannes Schindelin writes: > > > On Fri, 21 Jul 2017, Junio C Hamano wrote: > > > >> Jean-Noël Avila writes: > >> > >> > Le 20/07/2017 à 20:57, Junio C Hamano a écrit : > >> >> > >> >> +

[PATCH] git-gui (MinGW): make use of MSys2's msgfmt

When Git for Windows was still based on MSys1, we had no gettext, ergo no msgfmt, either. Therefore, we introduced a small and simple Tcl script to perform the same task. However, with MSys2, we no longer need that because we have a proper msgfmt executable. Plus, the po2msg.sh script somehow

Re: [PATCH] PRItime: wrap PRItime for better l10n compatibility

Hi, On Sat, 22 Jul 2017, Junio C Hamano wrote: > Johannes Schindelin writes: > > >> >> A very small hack on gettext. > > > > I am 100% opposed to this hack. It is already cumbersome enough to find > > out what is involved in i18n (it took *me* five minutes to find

Deceptive site ahead Waring

Greetings folks, Just tried to download your windows version app and a warning from chrome popped up saying "Deceptive site ahead", maybe you wonna check it if you haven't done it already. Cheers.

Re: [PATCH] PRItime: wrap PRItime for better l10n compatibility

Hi, On Mon, 24 Jul 2017, Jiang Xin wrote: > 2017-07-22 19:28 GMT+08:00 Johannes Schindelin : > > > > On Sat, 22 Jul 2017, Jiang Xin wrote: > > > >> 2017-07-22 7:34 GMT+08:00 Junio C Hamano : > >> > Jiang Xin writes: > >> >

Re: [PATCH v3] merge: add a --signoff flag.

Hi, can You take a look at my newest patch version (v3)? > On 24 Jul 2017, at 22:42, Junio C Hamano wrote: > > Junio C Hamano writes: > >> lukaszgryglicki writes: >> >>> Hi, what is the state of this patch? >> >> I was expecting

Re: requesting permission to use some Git for Windows code

Hi Philippe, I am not quite certain whether I have replied to this earlier or not. Under the assumption that I did not, I'll send this mail; Cc:ed to the mailing lists as discussed privately. On Fri, 23 Jun 2017, Philippe Joyez wrote: > This message is to request the permission to use code

[PATCH/RFC] contrib: rerere-train overwrites existing resolutions

>From 41116889f7eb2ddd590d165d9ca89646f7b15aaf Mon Sep 17 00:00:00 2001 From: Raman Gupta Date: Tue, 25 Jul 2017 10:28:35 -0400 Subject: [PATCH] contrib: rerere-train overwrites existing resolutions When running rerere-train, the user is explicitly asking the training to

[PATCH] fmt-merge-msg: fix coding style

Align argument list and place opening brace on its own line. Signed-off-by: Dimitrios Christidis --- builtin/fmt-merge-msg.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/builtin/fmt-merge-msg.c b/builtin/fmt-merge-msg.c index

Re: Deceptive site ahead Waring

Hi Christos, On Tue, 25 Jul 2017, Christos Angelidis wrote: > Just tried to download your windows version app and a warning from chrome > popped up saying > "Deceptive site ahead", maybe you wonna check it if you haven't done it > already. Kindly provide details. I am really certain that

Re: [PATCH] sub-process: refactor handshake to common function

On 7/24/2017 5:38 PM, Jonathan Tan wrote: Refactor, into a common function, the version and capability negotiation done when invoking a long-running process as a clean or smudge filter. This will be useful for other Git code that needs to interact similarly with a long-running process.

[PATCH] branch: change the error messages to be more meaningful

The error messages shown when the branch command is misused by supplying it wrong number of parameters wasn't meaningful as it used the the phrase, "too many branches" which is not meaningful in the following case, $ git branch foo * master $ git branch -m foo

Re: [RFC PATCH v2 2/4] promised-object, fsck: introduce promised objects

On 7/21/2017 4:33 PM, Jonathan Tan wrote: On Fri, 21 Jul 2017 12:24:52 -0400 Ben Peart wrote: Today we have 3.5 million objects * 30 bytes per entry = 105 MB of promises. Given the average developer only hydrates 56K files (2 MB promises) that is 103 MB to download that

[RFC] Git rerere and non-conflicting changes during conflict resolution

I had an interesting situation today: resolving a merge conflict required modification in other files that were not themselves conflicting. I just realized that rerere does not remember any changes to these additional files -- only changes to the conflicting files. This makes the end result of

[PATCH/RFC] setup: update error message to be more meaningful

The error message shown when a flag is found when expecting a filename wasn't clear as it didn't communicate what was wrong using the 'suitable' words in *all* cases. Correct case, $ git rev-parse commit.c --flags commit.c --flags fatal: bad flag '--flags' used

Re: Deceptive site ahead Waring

> On 25 Jul 2017, at 16:01, Johannes Schindelin > wrote: > > Hi Christos, > > On Tue, 25 Jul 2017, Christos Angelidis wrote: > >> Just tried to download your windows version app and a warning from chrome >> popped up saying >> "Deceptive site ahead", maybe you

[PATCH v2 2/2] sub-process: refactor handshake to common function

Refactor, into a common function, the version and capability negotiation done when invoking a long-running process as a clean or smudge filter. This will be useful for other Git code that needs to interact similarly with a long-running process. As you can see in the change to t0021, this commit

[PATCH v2 1/2] Documentation: migrate sub-process docs to header

Move the documentation for the sub-process API from a separate txt file to its header file. Signed-off-by: Jonathan Tan --- Documentation/technical/api-sub-process.txt | 59 - sub-process.h | 25 +++- 2

[PATCH v2 0/2] sub-process: refactor handshake to common function

Changes from v1: - Moved API docs to header file - Updated documentation - Updated commit message of patch 2 to explain why the error message changed Jonathan Tan (2): Documentation: migrate sub-process docs to header sub-process: refactor handshake to common function

Re: [PATCH] branch: change the error messages to be more meaningful

The second patch differs from the first one only in the commit message. -- Kaartic

Re: [PATCH/RFC] setup: update error message to be more meaningful

I've added RFC to this patch's subject as I'm not sure if the new message is suitable. Suggestions for messages that are more suitable are welcome. It seems that the function "verify_filename" is invoked by plumbing commands like 'rev-parse', let me know if I've missed something about them. I

[PATCH] branch: change the error messages to be more meaningful

The error messages shown when the branch command is misused by supplying it wrong number of parameters wasn't meaningful. That's because it used the the phrase "too many branches" assuming all parameters to be "valid" branch names. It's not always the case as exemplified below, $ git

Re: [PATCH v3] merge: add a --signoff flag.

Łukasz Gryglicki writes: > Some projects require every commit to be signed off. > Our workflow is to create feature branches and require every commit to > be signed off. When feature is finally approved we need to merge it into > master. Merge itself is usually trivial and

Re: [PATCH] sub-process: refactor handshake to common function

On Tue, 25 Jul 2017 10:38:51 -0400 Ben Peart wrote: > Christian Couder has been working on a similar refactoring for the perl > versions of very similar helper functions. They can be found in the > following patch series: > >

Re: Change in output as a result of patch

Let me see if I got everything correctly. Correct me if any of the below observations are wrong. On Mon, 2017-07-24 at 14:25 -0700, Junio C Hamano wrote: > Imagine this scenario instead, which I think is more realistic > example of making a typo. The set of existing branches are like > this: >

Re: [PATCH] recursive submodules: detach HEAD from new state

On Mon, Jul 24, 2017 at 3:23 PM, Junio C Hamano wrote: > Junio C Hamano writes: > >> Also, while I do agree with you that the problem exists, it is >> unclear why this patch is a solution and not a hack that sweeps a >> problem under the rug. >> >> It is

[PATCH v2] contrib/rerere-train: optionally overwrite existing resolutions

Provide the user an option to overwrite existing resolutions using an `--overwrite` flag. This might be used, for example, if the user knows that they already have an entry in their rerere cache for a conflict, but wish to drop it and retrain based on the merge commit(s) passed to the rerere-train

Re: [PATCH 03/15] add, reset: ensure submodules can be added or reset

On Tue, Jul 25, 2017 at 2:39 PM, Brandon Williams wrote: > Commit aee9c7d65 (Submodules: Add the new "ignore" config option for > diff and status) ... introduced in 2010, so quite widely spread. > ... introduced the ignore configuration option for > submodules so that

Re: [PATCH 04/15] submodule--helper: don't overlay config in remote_submodule_branch

On Tue, Jul 25, 2017 at 2:39 PM, Brandon Williams wrote: > Don't rely on overlaying the repository's config on top of the > submodule-config, instead query the repository's config directly for the > branch field. > > Signed-off-by: Brandon Williams

Re: [PATCH 03/15] add, reset: ensure submodules can be added or reset

On 07/25, Stefan Beller wrote: > On Tue, Jul 25, 2017 at 2:39 PM, Brandon Williams wrote: > > Commit aee9c7d65 (Submodules: Add the new "ignore" config option for > > diff and status) ... > > introduced in 2010, so quite widely spread. > > > ... introduced the ignore

Re: [PATCH 05/15] submodule--helper: don't overlay config in update-clone

On Tue, Jul 25, 2017 at 2:39 PM, Brandon Williams wrote: > Don't rely on overlaying the repository's config on top of the > submodule-config, instead query the repository's config directly for the > url and the update strategy configuration. > > Signed-off-by: Brandon Williams

Re: [PATCH 05/15] submodule--helper: don't overlay config in update-clone

On 07/25, Stefan Beller wrote: > On Tue, Jul 25, 2017 at 2:39 PM, Brandon Williams wrote: > > Don't rely on overlaying the repository's config on top of the > > submodule-config, instead query the repository's config directly for the > > url and the update strategy

Re: [PATCH 06/15] fetch: don't overlay config with submodule-config

On Tue, Jul 25, 2017 at 2:39 PM, Brandon Williams wrote: > Don't rely on overlaying the repository's config on top of the > submodule-config, instead query the repository's config directly for the > fetch_recurse field. > > Signed-off-by: Brandon Williams

Re: [PATCH 07/15] submodule: don't rely on overlayed config when setting diffopts

On Tue, Jul 25, 2017 at 2:39 PM, Brandon Williams wrote: > Don't rely on overlaying the repository's config on top of the > submodule-config, instead query the repository's config directory for > the ignore field. > > Signed-off-by: Brandon Williams > --- >

Re: [PATCH 06/15] fetch: don't overlay config with submodule-config

On 07/25, Stefan Beller wrote: > On Tue, Jul 25, 2017 at 2:39 PM, Brandon Williams wrote: > > Don't rely on overlaying the repository's config on top of the > > submodule-config, instead query the repository's config directly for the > > fetch_recurse field. > > > >

Re: Should I store large text files on Git LFS?

On 25 July 2017 at 04:11, Jeff King wrote: > On Mon, Jul 24, 2017 at 02:58:38PM +1000, Andrew Ardill wrote: > >> On 24 July 2017 at 13:45, Farshid Zavareh wrote: >> > I'll probably test this myself, but would modifying and committing a 4GB >> > text file

Re: [RFC] Git rerere and non-conflicting changes during conflict resolution

On 25/07/17 01:52 PM, Jeff King wrote: > On Tue, Jul 25, 2017 at 11:09:55AM -0400, Raman Gupta wrote: > >> I had an interesting situation today: resolving a merge conflict >> required modification in other files that were not themselves conflicting. >> >> I just realized that rerere does not

Re: [PATCH v2 2/2] sub-process: refactor handshake to common function

On 07/25, Jonathan Tan wrote: > Refactor, into a common function, the version and capability negotiation > done when invoking a long-running process as a clean or smudge filter. > This will be useful for other Git code that needs to interact similarly > with a long-running process. > > As you can

Re: What's cooking in git.git (Jul 2017, #07; Mon, 24)

Hi Junio, On Mon, 24 Jul 2017, Junio C Hamano wrote: > * js/blame-lib (2017-07-24) 1 commit > - blame: fix memory corruption scrambling revision name in error message > > A hotfix to a topic already in 'master'. > > Will merge to 'next'. This sounds more critical than `next`, in particular

Re: [RFC] Git rerere and non-conflicting changes during conflict resolution

Jeff King writes: >> 1) Is this a known limitation or is there a reason rerere works in >> this manner? > > Yes, it's known. Rerere works by storing a mapping of conflicted hunks > to their resolutions. If there's no conflicted hunk, I'm not sure how > we'd decide what to feed

Re: [PATCH] hash: Allow building with the external sha1dc library

Takashi Iwai writes: > Some distros provide SHA1 collision detect code as a shared library. > It's the very same code as we have in git tree, and git can link with > it as well; at least, it may make maintenance easier, according to our > security guys. > > This patch allows user

Re: Should I store large text files on Git LFS?

On Tue, Jul 25, 2017 at 06:06:49PM +1000, Andrew Ardill wrote: > Let's have a look: > > $ git rev-list --objects --all | > git cat-file --batch-check='%(objectsize:disk) %(objectsize) > %(deltabase) %(rest)' > 174 262 > 171 260

Re: What's cooking in git.git (Jul 2017, #07; Mon, 24)

Johannes Schindelin writes: > Hi Junio, > > On Mon, 24 Jul 2017, Junio C Hamano wrote: > >> * js/blame-lib (2017-07-24) 1 commit >> - blame: fix memory corruption scrambling revision name in error message >> >> A hotfix to a topic already in 'master'. >> >> Will

Re: [PATCH] doc: add missing "none" value for diff.wsErrorHighlight

Andreas Heiduk writes: > The value has not eluded documentation so far. I am not sure what "has not eluded" means in this context (did you mean "has eluded"?). The patch text itself is not wrong per-se, but if we are to add documentation for 'none', diff-options.txt must

Re: [PATCH v2 1/2] Documentation: migrate sub-process docs to header

On 07/25, Jonathan Tan wrote: > Move the documentation for the sub-process API from a separate txt file > to its header file. > > Signed-off-by: Jonathan Tan I really like this change! > --- > Documentation/technical/api-sub-process.txt | 59 >

Re: [RFC] Git rerere and non-conflicting changes during conflict resolution

On Tue, Jul 25, 2017 at 03:54:32PM -0400, Raman Gupta wrote: > > That said, I'm far from an expert on how rerere works. Junio might have > > ideas on how we could handle this better. But I do note that for > > repeated integration runs (like we do for topics in git.git, as they get > > merged to

Re: Should I store large text files on Git LFS?

Jeff King writes: > As you can see, core.bigfilethreshold is a pretty blunt instrument. It > might be nice if .gitattributes understood other types of patterns > besides filenames, so you could do something like: > > echo '[size > 500MB] delta -diff' >.gitattributes > > or

Re: Should I store large text files on Git LFS?

On Tue, Jul 25, 2017 at 01:52:46PM -0700, Junio C Hamano wrote: > Jeff King writes: > > > As you can see, core.bigfilethreshold is a pretty blunt instrument. It > > might be nice if .gitattributes understood other types of patterns > > besides filenames, so you could do something

Re: [PATCH] PRItime: wrap PRItime for better l10n compatibility

Johannes Schindelin writes: > Hi Junio, > > On Sat, 22 Jul 2017, Junio C Hamano wrote: > >> Johannes Schindelin writes: >> >> > On Fri, 21 Jul 2017, Junio C Hamano wrote: >> > >> >> Jean-Noël Avila writes: >> >> >> >>

Re: [RFC PATCH 0/3] Partial clone: promised blobs (formerly "missing blobs")

Sorry for the delay - been away... From: "Ben Peart" Sent: Monday, July 17, 2017 6:43 PM On 7/16/2017 11:23 AM, Philip Oakley wrote: From: "Jonathan Tan" Sent: Tuesday, July 11, 2017 8:48 PM These patches are part of a set of patches

Re: Should I store large text files on Git LFS?

On Tue, Jul 25, 2017 at 2:13 PM, Jeff King wrote: > On Tue, Jul 25, 2017 at 01:52:46PM -0700, Junio C Hamano wrote: > >> Jeff King writes: >> >> > As you can see, core.bigfilethreshold is a pretty blunt instrument. It >> > might be nice if .gitattributes understood

Re: [RFC] Git rerere and non-conflicting changes during conflict resolution

Junio C Hamano writes: > To populate the database, we'd need a reverse. > ... > * Then the user tells Git that semantic conflicts were resolved and >need to be recorded (just like running "git rerere" manually, >before "git commit" automatically does it for them these

Re: [PATCH] PRItime: wrap PRItime for better l10n compatibility

Johannes Schindelin writes: > On Sat, 22 Jul 2017, Junio C Hamano wrote: > >> Johannes Schindelin writes: >> >> >> >> A very small hack on gettext. >> > >> > I am 100% opposed to this hack. It is already cumbersome enough to find >> > out

Re: [PATCH] git-gui (MinGW): make use of MSys2's msgfmt

Johannes Schindelin writes: > Pat, I still have a couple of Pull Request open in your repository > at https://github.com/patthoyts/git-gui/pulls/dscho that await any > reaction since October 14th last year. Please let me know when you > are

[PATCH v2] doc: add missing values "none" and "default" for diff.wsErrorHighlight

The values have eluded documentation so far. While at it streamline the wording by grouping relevant parts together. Signed-off-by: Andreas Heiduk --- Documentation/diff-config.txt | 11 +++ Documentation/diff-options.txt | 17 - 2 files changed, 15

Re: [RFC] Git rerere and non-conflicting changes during conflict resolution

On Tue, Jul 25, 2017 at 01:26:34PM -0700, Junio C Hamano wrote: > This is not even a limitation but is outside the scope of rerere. > Let's understand that first. > [...] > If we wanted to port the "merge-fix" logic, and I do wish it would > happen some day, the update belongs to "git merge".

Re: [PATCH/RFC] contrib: rerere-train overwrites existing resolutions

Raman Gupta writes: > From 41116889f7eb2ddd590d165d9ca89646f7b15aaf Mon Sep 17 00:00:00 2001 > From: Raman Gupta > Date: Tue, 25 Jul 2017 10:28:35 -0400 > Subject: [PATCH] contrib: rerere-train overwrites existing resolutions These do not belong to

Re: [PATCH v3 0/3] interpret-trailers: add --where, --if-exists, --if-missing

Paolo Bonzini writes: > From: Paolo Bonzini > > These options are useful to experiment with "git interpret-trailers" > without having to tinker with .gitconfig (Junio said git should ahve > done this first and only added configuration afterwards). It can >

Re: [PATCH/RFC] setup: update error message to be more meaningful

Hi, Kaartic Sivaraam wrote: > The error message shown when a flag is found when expecting a > filename wasn't clear as it didn't communicate what was wrong > using the 'suitable' words in *all* cases. > > Correct case, > > $ git rev-parse commit.c --flags > commit.c >

Re: [PATCH v2] doc: add missing values "none" and "default" for diff.wsErrorHighlight

Andreas Heiduk writes: > The values have eluded documentation so far. While at it streamline > the wording by grouping relevant parts together. > > Signed-off-by: Andreas Heiduk > --- > Documentation/diff-config.txt | 11 +++ >

[PATCH 02/15] submodule: don't use submodule_from_name

The function 'submodule_from_name()' is being used incorrectly here as a submodule path is being used instead of a submodule name. Since the correct function to use with a path to a submodule is already being used ('submodule_from_path()') let's remove the call to 'submodule_from_name()'.

[PATCH 00/15] submodule-config cleanup

The aim of this series is to cleanup the submodule-config and make it simpler to use. The two main parts to this series are: (1) removing the ability to overlay the repository's config over the submodule-config. This makes the API clunky as you don't really know when you want to overlay

[PATCH 04/15] submodule--helper: don't overlay config in remote_submodule_branch

Don't rely on overlaying the repository's config on top of the submodule-config, instead query the repository's config directly for the branch field. Signed-off-by: Brandon Williams --- builtin/submodule--helper.c | 15 +++ 1 file changed, 11 insertions(+), 4

[PATCH 09/15] submodule: remove submodule_config callback routine

Remove the last remaining caller of 'submodule_config()' as well as the function itself. With 'submodule_config()' being removed the submodule-config API can be a little simpler as callers don't need to worry about whether or not they need to overlay the repository's config on top of the

[PATCH 08/15] unpack-trees: don't rely on overlayed config

Don't rely on overlaying the repository's config on top of the submodule-config, instead query the repository's config directory for the submodule's update strategy. Also remove the overlaying of the repository's config (via using 'submodule_config()') from the commands which use the unpack-trees

[PATCH 15/15] submodule: remove gitmodules_config

Now that the submodule-config subsystem can lazily read the gitmodules file we no longer need to explicitly pre-read the gitmodules by calling 'gitmodules_config()' so let's remove it. Signed-off-by: Brandon Williams --- builtin/checkout.c | 1 -

[PATCH 05/15] submodule--helper: don't overlay config in update-clone

Don't rely on overlaying the repository's config on top of the submodule-config, instead query the repository's config directly for the url and the update strategy configuration. Signed-off-by: Brandon Williams --- builtin/submodule--helper.c | 14 ++ submodule.c

[PATCH 12/15] submodule-config: move submodule-config functions to submodule-config.c

Migrate the functions used to initialize the submodule-config to submodule-config.c so that the callback routine used in the initialization process can be static and prevent it from being used outside of initializing the submodule-config through the main API. Signed-off-by: Brandon Williams

[PATCH 06/15] fetch: don't overlay config with submodule-config

Don't rely on overlaying the repository's config on top of the submodule-config, instead query the repository's config directly for the fetch_recurse field. Signed-off-by: Brandon Williams --- builtin/fetch.c | 1 - submodule.c | 24 +--- 2 files

[PATCH 03/15] add, reset: ensure submodules can be added or reset

Commit aee9c7d65 (Submodules: Add the new "ignore" config option for diff and status) introduced the ignore configuration option for submodules so that configured submodules could be omitted from the status and diff commands. Because this flag is respected in the diff machinery it has the

[PATCH 01/15] t7411: check configuration parsing errors

Check for configuration parsing errors in '.gitmodules' in t7411, which is explicitly testing the submodule-config subsystem, instead of in t7400. Also explicitly use the test helper instead of relying on the gitmodules file from being read in status. Signed-off-by: Brandon Williams

[PATCH 07/15] submodule: don't rely on overlayed config when setting diffopts

Don't rely on overlaying the repository's config on top of the submodule-config, instead query the repository's config directory for the ignore field. Signed-off-by: Brandon Williams --- submodule.c | 12 ++-- 1 file changed, 10 insertions(+), 2 deletions(-) diff

[PATCH 10/15] diff: stop allowing diff to have submodules configured in .git/config

Traditionally a submodule is comprised of a gitlink as well as a corresponding entry in the .gitmodules file. Diff doesn't follow this paradigm as its config callback routine falls back to populating the submodule-config if a config entry starts with 'submodule.'. Remove this behavior in order

[PATCH 13/15] submodule-config: lazy-load a repository's .gitmodules file

In order to use the submodule-config subsystem, callers first need to initialize it by calling 'repo_read_gitmodules()' or 'gitmodules_config()' (which just redirects to 'repo_read_gitmodules()'). There are a couple of callers who need to load an explicit revision of the repository's .gitmodules

[PATCH 11/15] submodule-config: remove support for overlaying repository config

All callers have been migrated to explicitly read any configuration they need. The support for handling it automatically in submodule-config is no longer needed. Signed-off-by: Brandon Williams --- submodule-config.h | 1 - t/helper/test-submodule-config.c |

[PATCH 14/15] unpack-trees: improve loading of .gitmodules

When recursing submodules 'check_updates()' needs to have strict control over the submodule-config subsystem to ensure that the gitmodules file has been read before checking cache entries which are marked for removal as well ensuring the proper gitmodules file is read before updating cache

Re: [RFC] Git rerere and non-conflicting changes during conflict resolution

On Tue, Jul 25, 2017 at 11:09:55AM -0400, Raman Gupta wrote: > I had an interesting situation today: resolving a merge conflict > required modification in other files that were not themselves conflicting. > > I just realized that rerere does not remember any changes to these > additional files

Re: [PATCH v2 2/2] sub-process: refactor handshake to common function

Jonathan Tan writes: > Refactor, into a common function, the version and capability negotiation > done when invoking a long-running process as a clean or smudge filter. > This will be useful for other Git code that needs to interact similarly > with a long-running

Re: [PATCH 02/15] submodule: don't use submodule_from_name

On Tue, Jul 25, 2017 at 2:39 PM, Brandon Williams wrote: > The function 'submodule_from_name()' is being used incorrectly here as a > submodule path is being used instead of a submodule name. Since the > correct function to use with a path to a submodule is already being used

Re: git gc seems to break --symbolic-full-name

24.07.2017 07:02, Jacob Keller пишет: generally, I'd suggest using "git describe" to output a version based on tag, and as part of your build system set that in some sort of --version output of some kind. I came to the following solution which looks quite simple (avoids comparing the output of

Re: git gc seems to break --symbolic-full-name

On Sun, Jul 23, 2017 at 12:23 PM, Stas Sergeev wrote: > 23.07.2017 11:40, Jacob Keller пишет: >> >> On Fri, Jul 21, 2017 at 12:03 PM, Stas Sergeev wrote: >>> >>> I wanted some kind of file to use it as a >>> build dependency for the files that needs >>> to be re-built

[PATCH] fsck: cleanup unused variable

Remove the unused variable "heads" from cmd_fsck(). This variable was made unused in commit c3271a0 ("fsck: do not fallback "git fsck " to "git fsck"", 2017-01-17). Signed-off-by: Jonathan Tan --- While working on fsck, I noticed one more possible cleanup. ---