unsibscribe git

unsibscribe git

bad error message - Not a git repository (or any of the parent directories): .git

/ubuntu/xyz/.git ty -alex -- Alexander D. Mills New cell phone # (415)730-1805 alexander.d.mi...@gmail.com www.linkedin.com/pub/alexander-mills/b/7a5/418/

help with git log --numstat

Hi all: Another question that came up for me recently. Using: git log --numstat I am seeing multiple emails attached to a single commit as described here: https://stackoverflow.com/questions/57333971/git-log-numstat-has-weird-data does anyone know what that means? -alex -- Alexander D

cannot clone --single-commit instead of --single-branch

Looking for help with this problem: https://stackoverflow.com/questions/57316783/git-clone-single-branch-does-not-work-for-sha-commit-ids Essentially looking for: git clone --single-commit since git clone --single-branch= doesn't seem to work? any help appreciated. -alex -- Alexan

BUG: Git checkout on Linux sets always CRLF regardless of core.eol

Hello, I am trying to checkout out various 3rd party Git projects on Linux and build them. Some of them have text files created under Windows with CRLF endings and it is not under my responsibility to change it. Thus I have to force LF line ending for Git checkout (regardless of which line ending

Re: [PATCH] doc: fix typos in man pages

hile I'm not a native speaker and therefore unsure how much that would matter to a reader, I think it's better to use the grammatically correct version to avoid ambiguity. The question whether that or which shouldn't matter too much, I think both can be used interchangeably her

[PATCH] doc: fix typos in man pages

Signed-off-by: Alexander Blesius --- Documentation/git-worktree.txt | 4 ++-- Documentation/gitattributes.txt | 4 ++-- 2 files changed, 4 insertions(+), 4 deletions(-) diff --git a/Documentation/git-worktree.txt b/Documentation/git-worktree.txt index cb86318f3e..fa5ec7a5dc 100644 --- a

Re: [BUG] fetching all remote branches results in failed multiple updates

Hi all, Sorry to bother one last time. After a bit more digging, I found that the problem was with my workflow. Shallow clones set `remote.origin.fetch` to one branch, so what I was doing in the past was overriding the respository-specific `remote.origin.fetch` with my global config. I've now ch

Re: [BUG] fetching all remote branches results in failed multiple updates

Hi all, I appreciate the help offered in identifying what I was doing incorrectly. Upon further investigation, I remembered why I added the original `origin.fetch` parameter: I was compensating for shallow clones not fetching all remote refs. Here's the use case that I have: [root@chabuduo

[PATCH 1/1] gitk: Update Bulgarian translation (317t)

Signed-off-by: Alexander Shopov --- po/bg.po | 660 +-- 1 file changed, 343 insertions(+), 317 deletions(-) diff --git a/po/bg.po b/po/bg.po index 407d5550b1..87ab1fac24 100644 --- a/po/bg.po +++ b/po/bg.po @@ -1,15 +1,15 @@ # Bulgarian

Update of Bulgarian translation of gitk

Hello all, I am resending the update of Bulgarina translation of Gitk that I last sent here: on 4 of March: https://marc.info/?l=git&m=155169580131311&w=2 Any idea why it is not getting merged? Perhaps I missed something or Paul Mackerras, maintaining gitk, is busy? Anything that I should impr

Re: [BUG] fetching all remote branches results in failed multiple updates

On Fri, Mar 08, 2019 at 12:40:15AM +0100, SZEDER Gábor wrote: > On Thu, Mar 07, 2019 at 09:44:47PM +0000, Alexander Huynh wrote: > > [git-test@chabuduo ~]$ cat > ~/.gitconfig > > [remote "origin"] > > fetch = +refs/heads/*:refs/remotes/origin/*

[BUG] fetching all remote branches results in failed multiple updates

Hello all, When running the latest release of git, I receive an error when attempting to fetch all remote branches from a repo: fatal: multiple updates for ref 'refs/remotes/origin/maint' not allowed The specific ref that it fails on changes depending on the repository, but the end result is

Strange behavior of `git describe`

ate somehow, and `v2.3` is instead reported. It also somehow thinks that there are 2525 commits between `v2.4` tag and the HEAD. Is this a bug in git or are we doing anything wrong? Thanks. Alexander. P.S. This has been verified both with stock git version 2.7.4 and with version 2

using --force-with-lease after git rebase

rebasing against the integration branch? -alex related question: https://stackoverflow.com/questions/52823692/git-push-force-with-lease-vs-force/53042745#53042745 -- Alexander D. Mills ¡¡¡ New cell phone number: (415)730-1805 !!! alexander.d.mi...@gmail.com www.linkedin.com/pub/alexander-mills/b/7a5/418/

wrong info from 'git remote show ' about 'git push' configuration

"git remote show " shows wrong information about not yet configured for 'git push' local ref. steps to reproduce: $ git init $ git remote add origin https://github.com/git/git # for example $ git pull origin master $ git remote show origin ... Local ref configured for 'git push': master pus

Re: t7005-editor.sh failure

2018-09-26 12:52 GMT+03:00 Martin Ågren : > On Wed, 26 Sep 2018 at 11:00, Alexander Pyhalov wrote: >> As for sign-off, do I understand correctly that you just want to know >> that I'm the original author of the code? Yes, it's so. > > Right. Plus that you agree th

Re: t7005-editor.sh failure

CLD_EXITED pid=2655 status=0x0001 error: There was a problem with the editor './e\ space.sh'. Please supply the message using either -m or -F option. Shell is bash, as you can see (GNU bash, version 4.4.23(1)-release (i386-pc-solaris2.11)) 2018-09-26 10:59 GMT+03:00 Martin Ågren

t7005-editor.sh failure

when gets file with spaces in name. The patch is simple: -- Best regards, Alexander Pyhalov, system administrator of Southern Federal University IT department --- git-2.19.0/t/t7005-editor.sh.~1~ Mon Sep 10 21:39:13 2018 +++ git-2.19.0/t/t7005-editor.sh Wed Sep 26 09:41:30 2018 @@ -112,7 +11

bug with git merge-base

The following command sequence exits with 1, and no stderr base='remotes/origin/dev'; fork_point="$(git merge-base --fork-point "$base")"; I cannot figure out why it's exiting with 1, but there is no stdout/stderr -alex -- Alexander D. Mills ¡¡¡ N

Re: Support JSON with --json flag and provide header files

s. On Mon, Aug 6, 2018 at 9:54 PM, Alexander Mills wrote: > @git > > I hear there is a movement underway to have git support JSON for the > purposes of machine readable stdio. > > That is all good and well. I want to add to that request. Imagine a > software world were serializ

Support JSON with --json flag and provide header files

ke place here. Hope this makes sense. I am looking forward to a software future where parsing stdio is easier by using machine readable JSON. Want human readable output? Use the regular command. Want machine readable output? use the --json flag. -alex -- Alexander D. Mills ¡¡¡ New cell phone numb

Re: concurrent access to multiple local git repos is error prone

To add something to the previous message, I have strong evidence that the problem occurs when *different* repos are accessed concurrency, not the same repo, as bizarre as that may be. -alex On Mon, Aug 6, 2018 at 12:36 AM, Alexander Mills wrote: > Hi Johnathan, > > Yeah this concurrenc

Re: concurrent access to multiple local git repos is error prone

have: git version 2.17.1 cpu: x86_64 no commit associated with this build sizeof-long: 8 -alex On Sun, Aug 5, 2018 at 1:11 AM, Jonathan Nieder wrote: > Alexander Mills wrote: > >> Yeah in this case what appeared to be happening is that if `git status` was >> called concurrent

Re: concurrent access to multiple local git repos is error prone

wrote: > Alexander Mills wrote: > >> Yeah in this case what appeared to be happening is that if `git status` was >> called concurrently, frequently I wouldnt get any stdout.. > > Thanks for reporting. A few questions: > > What platform are you on? What version of Git are

Re: concurrent access to multiple local git repos is error prone

Note, in my first paragraph, I should have said "If I have multiple local git repos, and I run `git status -v` on them *concurrently*"... -alex On Sat, Aug 4, 2018 at 2:47 PM, Alexander Mills wrote: > If I have multiple local git repos, and I run `git status -v` on them, > somet

concurrent access to multiple local git repos is error prone

tuitive to have to do this. -- Alexander D. Mills ¡¡¡ New cell phone number: (415)730-1805 !!! alexander.d.mi...@gmail.com www.linkedin.com/pub/alexander-mills/b/7a5/418/

shortstat / stat / numstat for git log

@git I have this question: https://stackoverflow.com/questions/49863038/get-numstat-or-stat-for-pretty-format I am looking to generage JSON with the pretty format, but apparent * stat * shortstat * numstat etc cannot be interpolated. can this be updated / improved? -alex -- Alexander D

git-log bug: --grep and -number args are at odds

$ git log -50 ### I get 50 results $ git log -50 --grep="*" ### I get a lot more than 50... shouldn't `-50` minimize the results length to 50 or fewer? -alex -- Alexander D. Mills ! New cell phone number: (415)766-8243 alexander.d.mi...@gmail.com www.linkedin.com/pub/al

[PATCH 1/1] Mark messages for translations

of tests via `make GETTEXT_POISON=1 test`. Signed-off-by: Alexander Shopov --- git.c | 38 +- setup.c| 62 +- t/t0002-gitfile.sh | 4 +-- t/t0008-ignores.sh

[PATCH 0/1] Mark messages for translation

King: 2. Fix t1506 Johannes Sixt: 3. Lower-case letters at the beginning of error messages 4. Past tense to present tense in some cases Eric Sunshine: 5. Fix `-cname=value` to say `-c =` 6. Do not translate "BUG message" Duy Nguyen: 7. Fix parentheses on `_` macro Kind r

Re: [PATCH 1/1] Mark messages for translations

Let me repeat what you said so I know how to improve the patch: @Junio: > Perhaps end each sentence with a full-stop? I should end each sentence in the *log* message with "." (rather than the translatable strings in the patch) > Shouldn't this rather be like so instead? > if test_i18ngrep ! "inval

[PATCH 1/1] Mark messages for translations

tests via `make GETTEXT_POISON=1 test` Signed-off-by: Alexander Shopov --- git.c | 38 +- setup.c| 62 +- t/t0002-gitfile.sh | 4 +-- t/t0008-ignores.sh | 2 +- t

[PATCH 0/1] Mark messages for translations

nse to present tense in some cases Eric Sunshine: 3. Fix `-cname=value` to say `-c =` 4. Do not translate "BUG message" Duy Nguyen: 5. Fix parentheses on `_` macro Kind regards: al_shopov Alexander Shopov (1): Mark messages for translations git.c

[PATCH 1/1] Mark messages for translations

Small changes in messages to fit the style and typography of rest Reuse already translated messages if possible Do not translate messages aimed at developers of git Fix unit tests depending on the original string Signed-off-by: Alexander Shopov --- git.c | 38

[PATCH 0/1] Mark messages for translations

tense to present tense in some cases Eric Sunshine: 3. Fix `-cname=value` to say `-c =` 4. Do not translate "BUG message" Duy Nguyen: 5. Fix parentheses on `_` macro Kind regards: al_shopov Alexander Shopov (1): Mark messages for translations git.c

Re: [PATCH 1/1] Mark messages for translations

And again, sigh: >> const char git_usage_string[] = >> const char git_more_info_string[] = > It is not obvious to me where git_usage_string is looked up in the > message catalog. It is used that way in builtin/help.c .. I wanted to be consistent with the current state of the file. This is

[PATCH 1/1] Mark messages for translations

Reuse already translated messages if possible Do not translate messages aimed at developers of git Signed-off-by: Alexander Shopov --- git.c | 30 +++--- setup.c | 52 ++-- 2 files changed, 41 insertions(+), 41 deletions

[PATCH 0/1] Marked end user messages for translation

uniformity of the used verb tense and will ease the work of translators. Alexander Shopov (1): Mark messages for translations git.c | 30 +++--- setup.c | 52 ++-- 2 files changed, 41 insertions(+), 41 deletions

[bug] git add -p breaks, if color.ui is set to "always"

. >From the manpage, color.ui should not have that effect and "always" should be a legal value. Regards Alexander Gehrke

Re: git svn show-externals output format

> My practical solution was to skip the man in the middle and ask the SVN > server directly for the property values Thanks, that helped a lot! Alex Beste Grüße, Alex -- Alexander Groß http://therightstuff.de/ On Sat, Aug 19, 2017 at 12:14 PM, Andreas Heiduk wrote: > Am 19.08.2017

git svn show-externals output format

ong? Thanks! Alex -- Alexander Groß http://therightstuff.de/

Bug: "git worktree add" Unable to checkout a branch with no local ref

git version 2.10.2.windows.1: If a remote branch has never been checked out locally (its ref only exists in remotes// directory), "git worktree add" command is unable to check it out by its normal short name (not prefixed by remotes/), while "git checkout" command has been able to handle such a

Different merges from translation perspective

Hi all, What is the difference between simple, fast forward, automatic and trivial merge? I am updating the translation and the only thing I am sure about is that these four are not octopus merges, Fast forward is when current state is ancestor of tip, automatic merge is when the merge algorithm is

git bug - merging JS / Node.js code with "git merge --squash"

ve difficult. I am doing a check to make sure all my files compile with "node -c" after the merge, but even then Git could create mangled code that would still pass a "node -c" check. Please let me know if this is a known bug and if there is a good strategy to avoid it.

[GIT GUI l18n 1/2] git-gui: Mark 'All' in remote.tcl for translation

Signed-off-by: Alexander Shopov --- lib/remote.tcl | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/lib/remote.tcl b/lib/remote.tcl index 4e5c784..26af8ae 100644 --- a/lib/remote.tcl +++ b/lib/remote.tcl @@ -250,12 +250,12 @@ proc update_all_remotes_menu_entry

git-subtree pull issue

When git-subtree is pulling data using the tag reference, it writes the tag's sha1 into a metadata. It could be a problem next time, since this commit object is not a part of main tree, and could be lost. Steps to reproduce: # add some stuff to a existing tree # history will refer to v0.1 tag obj

[wishlist] disable boring messages

Hi, is it possible to make git silent, when nothing interesting is happening? I have a lot of repos and a batch script to update them all, and I want to get rid of 'Fetching origin' and 'Already up-to-date.' messages leaving only new refs and tags.

Re: Feature Request: Branch-Aware Submodules

re whether to prioritize tags over branches or the other way around. Thanks for the suggestion. I hope this or a similar behavior could sometime become the default in git. Until the suggested quick fix will do for me. Best Regards, Alexander Hedges > On 29 Aug 2016, at 04:17, Jacob Keller wro

Re: Feature Request: Branch-Aware Submodules

> On 25 Aug 2016, at 19:45, Stefan Beller wrote: > > +cc Jacob and Lars who work with submodules as well. > > On Thu, Aug 25, 2016 at 2:00 AM, Hedges Alexander > wrote: >> >> Right now updating a submodule in a topic branch and merging it into master >>

Feature Request: Branch-Aware Submodules

ects with lots of submodules could weigh into the discussion. Best Regards, Alexander Hedges -- 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

[PATCH v2] pull: warn on --verify-signatures with --rebase

ned-off-by: Alexander 'z33ky' Hirsch <1ze...@gmail.com> --- The warning message was changed to make it clear that the pull (and rebase) operation still proceeds. And the commit message was amended with more reasoning about the change and why alternative approaches were not used. b

Re: [PATCH] pull: warn on --verify-signatures with --rebase

Indeed. > Something like > > warning(_("ignored --verify-signatures as it is meaningless in rebase")); > > may convey what is going on better, in that it makes it clear that > we are not failing "rebase" and instead we are ignoring "verify". > &

[PATCH] pull: warn on --verify-signatures with --rebase

Previously git-pull silently ignored the --verify-signatures option for --rebase. Signed-off-by: Alexander 'z33ky' Hirsch <1ze...@gmail.com> --- Sorry it took so long for the update. I made git-pull warn instead or error and explained why "the --verify-signatures opt

[PATCH v2] diff: run arguments through precompose_argv

I have used Junios proposal/changes for the commit message as I liked it and it is probably more in line with the usual commit messages of the git project. I hope this is ok. Let me know if you need me to do any more changes or what the next steps are if the patch is ok. Alexander Alexander

[PATCH v2] diff: run arguments through precompose_argv

change. It is not a problem per-se, as "log" family of commands already use parse_options() and call precompose_argv()--we can think of it as making the "diff" family of commands behave in a similar way as the commands in the "log" family. Signed-off-by: Alexander R

Re: [PATCH] diff: run arguments through precompose_argv

> On 12 May 2016, at 00:08, Junio C Hamano wrote: > > Alexander Rinass writes: > >>> On 05 Apr 2016, at 21:15, Johannes Sixt wrote: >>> >>> Am 05.04.2016 um 19:09 schrieb Junio C Hamano: >>>>> Thanks-to: Torsten Bögershausen >&

[PATCH v2] pull: make --rebase --verify-signatures illegal

Previously git-pull would silently ignore the --verify-signatures option. Signed-off-by: Alexander 'z33ky' Hirsch <1ze...@gmail.com> --- I made the error-message conform to the CodingGuidelines (removed capitalization and full stop). Also, in the previous mail I said that I prop

[PATCH] pull: make --rebase --verify-signatures illegal

Previously git-pull would silently ignore the --verify-signatures option. Signed-off-by: Alexander 'z33ky' Hirsch <1ze...@gmail.com> --- We had some discussion back in December about a patch that added --verify-signatures to git-pull, that was declined. I proposed making g

Re: [PATCH] diff: run arguments through precompose_argv

> On 05 Apr 2016, at 21:15, Johannes Sixt wrote: > > Am 05.04.2016 um 19:09 schrieb Junio C Hamano: >>> Thanks-to: Torsten Bögershausen > > I sense NFD disease: The combining diaresis should combine with the o, not > the g. Here is a correct line to copy-and-paste if you like: > > Thanks-to

Re: git diff does not precompose unicode file paths (OS X)

> On 15 Mar 2016, at 06:45, Torsten Bögershausen wrote: > > >I created a test case but git diff exits with 0 if it does not recognize the > >file >path so the test case always succeeds. Can you give me a hint or one > >>example test case? > > The most clean (?) is to compare "git diff" NFC an

[PATCH] diff: run arguments through precompose_argv

-tree. Signed-off-by: Alexander Rinass Thanks-to: Torsten Bögershausen Thanks-to: Junio C Hamano --- builtin/diff-files.c | 1 + builtin/diff-index.c | 1 + builtin/diff-tree.c | 2 ++ builtin/diff.c | 1 + t/t3910-mac-os-precompose.sh | 42

[PATCH] diff: run arguments through precompose_argv

issue. Alexander Rinass (1): diff: run arguments through precompose_argv builtin/diff-files.c | 1 + builtin/diff-index.c | 1 + builtin/diff-tree.c | 2 ++ builtin/diff.c | 1 + t/t3910-mac-os-precompose.sh | 42

[RFC PATCH] hashmap API: introduce for_each_hashmap_entry() helper macro

of this pattern. It encapsulates loop over a hashmap, some related variables and makes bypass of a hashmap more readable. This patch has not functioal changes, so behaviour still the same as before. Signed-off-by: Alexander Kuleshov --- Documentation/technical/api-hashmap.txt | 5 + builtin/de

[PATCH] help.c: strip suffix only if the STRIP_EXTENSION defined

We stripping extension in the list_commands_in_dir() to get commands without '.exe' suffix. Let's do it only if STRIP_EXTENSION is defined to not spend time for unnecessary strip_suffix() call in this case. Signed-off-by: Alexander Kuleshov --- help.c | 5 +++-- 1 file change

[PATCH v2] hashmap API: introduce for_each_hashmap_entry() helper macro

of this pattern. It encapsulates loop over a hashmap and makes bypass of a hashmap more readable. This patch has not functioal changes, so behaviour still the same as before. Signed-off-by: Alexander Kuleshov --- Documentation/technical/api-hashmap.txt | 5 + builtin/describe.c

Re: [PATCH] help.c: strip suffix only if the STRIP_EXTENSION defined

Hello Jeff, On Wed, Mar 16, 2016 at 11:31 PM, Jeff King wrote: > This is billed as an optimization in the commit message, but these two > pieces of code are not the same. The original always strips ".exe", > whether or not STRIP_EXTENSION is defined, and whether or not it is > ".exe". > > In prac

Re: [PATCH] help.c: strip suffix only if the STRIP_EXTENSION defined

On Wed, Mar 16, 2016 at 8:47 PM, Duy Nguyen wrote: > On Wed, Mar 16, 2016 at 9:27 PM, Alexander Kuleshov > wrote: >> We stripping extension in the list_commands_in_dir() to get >> commands without '.exe' suffix. Let's do it only if STRIP_EXTENSION >> is de

Re: [RFC PATCH] hashmap API: introduce for_each_hashmap_entry() helper macro

Hello Junio, On Thu, Mar 17, 2016 at 12:09 AM, Junio C Hamano wrote: > Alexander Kuleshov writes: > >> diff --git a/hashmap.h b/hashmap.h >> index ab7958a..b8b158c 100644 >> --- a/hashmap.h >> +++ b/hashmap.h >> @@ -95,4 +95,11 @@ static inline cons

[PATCH v3] submodule-config: use hashmap_iter_first()

The hashmap API provides hashmap_iter_first() helper for initialion and getting the first entry of a hashmap. Let's use it instead of doing initialization manually and then get the first entry. There are no functional changes, just cleanup. Signed-off-by: Alexander Kuleshov Reviewed-by: S

[PATCH v2] submodule-config: use hashmap_iter_first()

from the for simplification. Signed-off-by: Alexander Kuleshov Reviewed-by: Stefan Beller --- Changelog: added missed Signof-off-by and function name fixed in the commit message. submodule-config.c | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/submodule-config.c b

Re: [PATCH] submodule-config: use hashmap_iter_init()

On Wed, Mar 16, 2016 at 1:08 AM, Stefan Beller wrote: > The change looks correct to me. But as Eric said, the commit message > needs work and a sign off. With that, > Reviewed-by: Stefan Beller Ah, yes, forgot to pass `-s` to commit command. Sorry for noise guys, will resend the patch. -- To uns

[PATCH] submodule-config: use hashmap_iter_init()

from the for simplification. --- submodule-config.c | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/submodule-config.c b/submodule-config.c index b82d1fb..8ac5031 100644 --- a/submodule-config.c +++ b/submodule-config.c @@ -405,8 +405,7 @@ static const struct submodule *conf

Re: git diff does not precompose unicode file paths (OS X)

> On 08 Mar 2016, at 13:30, Torsten Bögershausen wrote: > >>> And if not, I can put it on my TODO-stack. >> I have read through the official contribution guidelines and I think I can >> send an official patch. >> >> In this case, would you prefer to have a single commit since the change >> is r

Re: git diff does not precompose unicode file paths (OS X)

> On 04 Mar 2016, at 19:49, Ramsay Jones wrote: > > > > On 04/03/16 14:37, Alexander Rinass wrote: >> >>> On 04 Mar 2016, at 13:16, Torsten Bögershausen wrote: >>> >>> On 03/04/2016 10:07 AM, Alexander Rinass wrote: > [snip] > >&

Re: git diff does not precompose unicode file paths (OS X)

> On 04 Mar 2016, at 13:16, Torsten Bögershausen wrote: > > On 03/04/2016 10:07 AM, Alexander Rinass wrote: >> Hallo, >> >> It appears that the git diff command does not precompose file path >> arguments, even if the option core.precomposeunicode is set to tru

git diff does not precompose unicode file paths (OS X)

$(iconv -f utf-8 -t utf-8-mac <<< Ä) [...shows NO diff...] I took a look at the Git source code, and the builtin/diff*.c do not contain the parse_options call (which does the precompose_argv call) that the other builtins use. But I am not really familiar with either C or the Git pr

[PATCH] environment.c: introduce DECLARE_GIT_GETTER helper macro

ff-by: Alexander Kuleshov --- environment.c | 49 ++--- 1 file changed, 14 insertions(+), 35 deletions(-) diff --git a/environment.c b/environment.c index 6dec9d0..f10fc7a 100644 --- a/environment.c +++ b/environment.c @@ -126,6 +126,14 @@ const char *

Re: [PATCH] environment.c: introduce SETUP_GIT_ENV helper macro

Hello Junio, On Sun, Feb 28, 2016 at 12:50 AM, Junio C Hamano wrote: > Junio C Hamano writes: > > >> Please don't. A macro that hides "return" makes things harder to >> follow, not easier. I will consider it next time. > Having said that, I do think a higher-level macro that encapulates > the

[PATCH] environment.c: introduce SETUP_GIT_ENV helper macro

The environment.c contans a couple of functions which are consist from the following pattern: if (!env) setup_git_env(); return env; Let's move this to the SETUP_GIT_ENV helper macro to prevent code duplication in these functions. Signed-off-by: Alex

[PATCH v2] git.c: simplify stripping extension of a file in handle_builtin()

. Signed-off-by: Alexander Kuleshov Helped-by: Jeff King --- Changelog: v2: typos fixed in commit message. git-compat-util.h | 4 git.c | 26 +++--- 2 files changed, 15 insertions(+), 15 deletions(-) diff --git a/git-compat-util.h b/git-compat-util.h

[PATCH] git.c: simplify striping extension of a file in handle_builtin()

. Signed-off-by: Alexander Kuleshov Helped-by: Jeff King --- git-compat-util.h | 4 git.c | 26 +++--- 2 files changed, 15 insertions(+), 15 deletions(-) diff --git a/git-compat-util.h b/git-compat-util.h index 8f0e76b..b35251c 100644 --- a/git-compat-util.h

Re: [PATCH] git-compat-util.h: move extension stripping from handle_builtin()

Hello Jeff, On 02-20-16, Jeff King wrote: > On Sat, Feb 20, 2016 at 02:10:58PM +0600, Alexander Kuleshov wrote: > > I'm not convinced that moving the functions inline into git-compat-util > is actually cleaner. We've expanded the interface that is visible to the > whol

[PATCH] git-compat-util.h: move extension stripping from handle_builtin()

The handle_builtin() starts from striping of command extension if STRIP_EXTENSION is enabled. As this is an OS dependent, let's move to the git-compat-util.h as all similar functions to do handle_builtin() more cleaner. --- git-compat-util.h | 18 ++ git.c | 13 +---

[PATCH] exec_cmd.c: use find_last_dir_sep() for code simplification

We are trying to extract dirname from argv0 in the git_extract_argv0_path(). But in the same time, the provides find_last_dir_sep() to get dirname from a given path. Let's use it instead of loop for the code simplification. Signed-off-by: Alexander Kuleshov --- exec_cmd.c | 6 ++ 1

Bug: Wrong GitHub API result when retrieving repository information

mbers are different. Example: ... "size": 5279, "stargazers_count": 51, "watchers_count": 51, "language": "Java", ... The actual count on the website, however, are 51 for stargazers and 20 for watchers. Any idea what could be the problem

Re: [PATCH] rebase: add --verify-signatures

Sorry, I didn't do a group-reply in my last mail. On Mon, Dec 21, 2015 at 03:46:54PM -0800, Junio C Hamano wrote: > Alexander 'z33ky' Hirsch <1ze...@gmail.com> writes: > > > On Thu, Dec 17, 2015 at 10:22:20AM -0800, Junio C Hamano wrote: > >> I suspec

[PATCH] gitk: Update Bulgarian translation (311t)

Signed-off-by: Alexander Shopov --- po/bg.po | 656 --- 1 file changed, 336 insertions(+), 320 deletions(-) diff --git a/po/bg.po b/po/bg.po index 909a564..99aa77a 100644 --- a/po/bg.po +++ b/po/bg.po @@ -8,8 +8,8 @@ msgid "&quo

RE: CruiseControl.NET hangs on git-submodule bad file descriptor

OK, no problem I have workaround :) Thanks a lot for your help Best wishes -- Alexander Skrinnik -Original Message- From: Johannes Schindelin [mailto:johannes.schinde...@gmx.de] Sent: Thursday, December 17, 2015 3:55 PM To: Alexander Skrinnik Cc: git@vger.kernel.org Subject: RE

RE: CruiseControl.NET hangs on git-submodule bad file descriptor

Hi Johannes, Thank you for your answer. Yes, this is the same issue. I found workaround, CC.NET invokes bat-file with command: git submodule foreach git checkout "myBranch" mailto:johannes.schinde...@gmx.de] Sent: Thursday, December 17, 2015 11:46 AM To: Alexander Skrinn

CruiseControl.NET hangs on git-submodule bad file descriptor

it\mingw32/libexec/git-core\git-submodule: line 544: 0: Bad file descriptor When I run the same command from cmd window all works without error For now I have to return to 1.9.5 version. Could you, please, help to fix the issue? Thank you in advance -- Alexander Skrinnik -- To unsubscribe from this

Re: [PATCH] rebase: add --verify-signatures

On Wed, Dec 16, 2015 at 10:12:12AM -0800, Junio C Hamano wrote: > I do not quite understand how that would help anything. I do not > personally believe in projects that wants to sign each and every > commit, but to them, "an empty signed commit on top" would not fix > anything once they have an un

Re: [PATCH] rebase: add --verify-signatures

On Thu, Dec 10, 2015 at 11:53:45AM -0800, Junio C Hamano wrote: > Junio C Hamano writes: > > > Alexander 'z33ky' Hirsch <1ze...@gmail.com> writes: > > > >> + if test -n "$rebase_root" > >> + then >

[PATCH] rebase: add --verify-signatures

This option works analogous to --verify-signatures for git-merge by checking that the commits, that are rebased onto, have good GPG signatures. Additionally, git-pull now forwards --verify-signatures to rebase as well. Signed-off-by: Alexander 'z33ky' Hirsch <1ze...@gmail.com> --

Re: rebase has no --verify-signatures

On Tue, Dec 08, 2015 at 01:21:25AM +, brian m. carlson wrote: > On Mon, Dec 07, 2015 at 03:00:15PM +0100, Alexander 'z33ky' Hirsch wrote: > > Is there any technical reason why rebase should not have a > > --verify-signatures flag? I have written a patch to git-rebase

rebase has no --verify-signatures

it it. Otherwise I think git pull should warn, or even die with an error, if both --rebase and --verify-signatures are passed. Regards, Alexander Hirsch -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordom

Re: Git 'pre-receive' hook and 'git-clang-format' script to reliably reject pushes that violate code style conventions

I don't want to smell like a nasty bumper here, but assuming that my questions were posted not in appropriate time (Saturday evening), I would like to call for help one last time. Thank you. Kind regards, Alexander -- To unsubscribe from this list: send the line "unsubscribe git&qu

Git 'pre-receive' hook and 'git-clang-format' script to reliably reject pushes that violate code style conventions

Hello, I have posted a question on Stack Overflow [1]. I would like to post it here as well since nobody has answered it yet. Let's immediately start with a scrap of the `pre-receive` hook that I've already written: #!/bin/sh ## format_bold='\e[1m' format_red='\e[31m'

Re: [PATCH] Consider object stores in alternates during a dissociating clone

On 10/22/2015 07:50 PM, Junio C Hamano wrote: Alexander Riesen writes: Content-Type: text/plain; charset=windows-1252; format=flowed I had to hand-munge it as the above lost all tabs and made the patch unusable for machines X-<. I'm very sorry. I don't know why Icedove does t

Re: [PATCH] Consider object stores in alternates during a dissociating clone

y from, before it is really independent. Signed-off-by: Alex Riesen --- On 10/22/2015 06:12 PM, Junio C Hamano wrote: Alexander Riesen writes: >> +if (access(alts, F_OK) < 0) >> +return; > > You leak alts here. Fixed. Perhaps you would want a new test somewhere

  1   2   3   >