[wishlist] submodule.update config

Relates (but orthogonal) to my other thread [wishlist] git submodule update --reset-hard ATM, it possible to specify per submodule update strategy via configuration variable submodule.SUBMODULE.update where SUBMODULE is the name of the corresponding submodule. But I see no way to specify

Re: [wishlist] git submodule update --reset-hard

On Fri, 07 Dec 2018, Yaroslav Halchenko wrote: > On Fri, 07 Dec 2018, Stefan Beller wrote: > > > the initial "git submodule update --reset-hard" is pretty much a > > > crude workaround for some of those cases, so I would just go earlier in > > > the h

Re: [wishlist] git submodule update --reset-hard

On Fri, 07 Dec 2018, Stefan Beller wrote: > > the initial "git submodule update --reset-hard" is pretty much a > > crude workaround for some of those cases, so I would just go earlier in > > the history, and redo some things, whenever I could just drop or revert > > some selected set of commits.

Re: [wishlist] git submodule update --reset-hard

Hi Stefan, Thanks for the dialogue! Replies are embedded below. On Thu, 06 Dec 2018, Stefan Beller wrote: > ... > > > What if the branch differs from the sha1 recorded in the superproject? > > git reset --hard itself is an operation which should be done with some > > level of competence in

Re: [wishlist] git submodule update --reset-hard

On Thu, 06 Dec 2018, Stefan Beller wrote: > On Thu, Dec 6, 2018 at 10:02 AM Yaroslav Halchenko > wrote: > > Dear Git Gurus, > > I wondered what would be your take on my wishlist request to add > > --reset-hard option, which would be very similar to regular "

[wishlist] git submodule update --reset-hard

Dear Git Gurus, I wondered what would be your take on my wishlist request to add --reset-hard option, which would be very similar to regular "update" which checks out necessary commit, but I want it to remain in the branch. Rationale: In DataLad we heavily rely on submodules, and we have

Re: wishlist: "--cached|--staged" to "git commit file(s)"

On Mon, 13 Aug 2018, Junio C Hamano wrote: > > command. ATM there is no non-interactive (via --patch/--interactive I > > think it is possible) way to commit selected subset of staged files not > > from the worktree (as it is done with "git commit file(s)") but from the > > index. > Hmph, so >

wishlist: "--cached|--staged" to "git commit file(s)"

Dear Git developers, Following up on my quick question/discussion on IRC a few days back: Please consider adding --cached or --staged option for git commit file(s) command. ATM there is no non-interactive (via --patch/--interactive I think it is possible) way to commit selected subset of

please resolve a mystery for me: what is j-c-diff exactly? ;)

Hi Junio et al, j-c-diff is "used" in the docs within git, git-annex, and other places discussing git. But I failed to find it to seek for an ultimate prototypical example of the diff command used by git ppl ;) $> git log -Sj-c-diff -p Documentation/gitattributes.txt commit

external diff driver is not used for diff --stat?

Dear Git Peoples, I am torturing git and git-annex here trying to compare some logs from a run of a software recorded in two different branches. As many other tools, software often logs its version, elapsed times etc, so diff becomes not of interest to me: $>

Re: [PATCH] merge: teach -Xours/-Xtheirs to symbolic link merge

look obviously correct to me, and > the testcase looks good too. > Reviewed-by: Elijah Newren <new...@gmail.com> > (and perhaps we should also add in "Tested-by: Yaroslav Halchenko > <y...@onerussian.com>" ? At least, that was my thought based

Re: Q: rational for $XDG_CONFIG_HOME/git/config to be "non global" or just a bug?

On Mon, 18 Dec 2017, Jeff King wrote: > To complete that abstraction it seems like reading via "--global" should > read from both (in the same precedence order that normal config lookup > uses). FWIW +1 from me on that ;) -- Yaroslav O. Halchenko Center for Open Neuroscience

Re: [PATCH] doc: clarify usage of XDG_CONFIG_HOME config file

On Tue, 12 Dec 2017, Jacob Keller wrote: > > And then "and the other files will not be read" can be dropped from > > the first sentence of this paragraph? > > Yaroslav on the original thread mentioned that reading codepath > > without --file or --global does not limit to one of the three, and >

Re: Q: rational for $XDG_CONFIG_HOME/git/config to be "non global" or just a bug?

On Mon, 11 Dec 2017, Junio C Hamano wrote: > Jonathan Nieder writes: > > I think the documentation > > ~/.gitconfig > > User-specific configuration file. Also called "global" > > configuration file. > > should be clarified --- e.g. it could say

Re: Q: rational for $XDG_CONFIG_HOME/git/config to be "non global" or just a bug?

On Mon, 11 Dec 2017, Jonathan Nieder wrote: > > Example to show that TFM outlines precedence and --global correctly: > > $> grep xdg .gitconfig .config/git/config > > .gitconfig:xdg-and-user = user > > .config/git/config: xdg = xdg > > .config/git/config: xdg-and-user = xdg > > $> git config

Q: rational for $XDG_CONFIG_HOME/git/config to be "non global" or just a bug?

Dear Git Gurus, We [1] have got confused a bit about this recent addition of handling $XDG_CONFIG_HOME/git/config -- is it --global or not? ;) According to the man git-config (v 2.15.0 in debian) --global For writing options: write to global ~/.gitconfig file rather than

Re: -s theirs use-case(s) Was: BUG: merge -s theirs is not in effect

On Wed, 27 Sep 2017, Yaroslav Halchenko wrote: > > And at that point, use of "-s ours" is no longer a workaround for > > lack of "-s theirs". It is a proper part of the desired semantics, > > i.e. from the point of view of the surviving canonical histo

Re: -s theirs use-case(s) Was: BUG: merge -s theirs is not in effect

On Wed, 27 Sep 2017, Junio C Hamano wrote: > > and that is where the gotcha comes -- what if "my" changes were already > > published? then I would like to avoid the rebase, and would -s theirs > > to choose "their" solution in favor of mine and be able to push so > > others could still

Re: -X theirs does not resolve symlink conflict Was: BUG: merge -s theirs is not in effect

On Tue, 26 Sep 2017, Junio C Hamano wrote: > >> I do not recall people talking about symbolic links but the case of > >> binary files has been on the wishlist for a long time, and I do not > >> know of anybody who is working on (or is planning to work on) it. > > Ah, I misremembered. > > We've

Re: -s theirs use-case(s) Was: BUG: merge -s theirs is not in effect

On Tue, 26 Sep 2017, Junio C Hamano wrote: > Yaroslav Halchenko <y...@onerussian.com> writes: > > 1. As a workaround for absence of -m theirs I using mtheirs git alias: > > (I believe provided to me awhile back here on the list): > > mtheirs = !sh -c 'git m

-s theirs use-case(s) Was: BUG: merge -s theirs is not in effect

On Mon, 25 Sep 2017, Junio C Hamano wrote: >It is a different matter to resurrect the age old discussion that >happend in the summer of 2008 if '-s theirs' should or should not >exist. In short, the previous discussion can be summarised to >"we don't want '-s theirs' as it

-X theirs does not resolve symlink conflict Was: BUG: merge -s theirs is not in effect

On Mon, 25 Sep 2017, Junio C Hamano wrote: > Yaroslav Halchenko <y...@onerussian.com> writes: > > d'oh, indeed there is no git-merge-theirs neither in debian pkg or a > > freshly > > built git and I found a rogue script in the PATH (which did nothing >

Re: BUG: merge -s theirs is not in effect (does the same as -s ours)

On Mon, 25 Sep 2017, Junio C Hamano wrote: > Yaroslav Halchenko <y...@onerussian.com> writes: > > My interest was to get remote branch "merge" the changes in the > > branch taking the branch's version (primarily alternative symlinks > > for git-annex'e

BUG: merge -s theirs is not in effect (does the same as -s ours)

My interest was to get remote branch "merge" the changes in the branch taking the branch's version (primarily alternative symlinks for git-annex'ed content) over the version in master (previous merge of a similar branch). Unfortunately -s theirs seems to do actually -s ours -- symlinks and

Re: [PATCH] strbuf: clear errno before calling getdelim(3)

On Thu, 10 Aug 2017, Jeff King wrote: > On Thu, Aug 10, 2017 at 10:56:40PM +0200, René Scharfe wrote: > > getdelim(3) returns -1 at the end of the file and if it encounters an > > error, but sets errno only in the latter case. Set errno to zero before > > calling it to avoid misdiagnosing an

Re: fatal: Out of memory, getdelim failed under NFS mounts

On Thu, 10 Aug 2017, Jeff King wrote: > On Thu, Aug 10, 2017 at 09:58:37PM +0200, René Scharfe wrote: > > > So the function is returning -1 and leaving ENOMEM in errno on > > > Yaroslav's system. > > > I wonder if we are truly hitting out of memory, though. The same > > > symptom could bee

Re: fatal: Out of memory, getdelim failed under NFS mounts

Thank you Junio On Thu, 10 Aug 2017, Junio C Hamano wrote: > There is only one getdelim() call, which was introduced in v2.5.0 > timeframe, and it is used like this: > r = getdelim(>buf, >alloc, term, fp); > if (r > 0) { > sb->len = r; > return 0; >

Re: fatal: Out of memory, getdelim failed under NFS mounts

Thank you René! comments/answers embedded below On Thu, 10 Aug 2017, René Scharfe wrote: > Am 09.08.2017 um 19:39 schrieb Yaroslav Halchenko: > > More context (may be different issue(s)) could be found at > > http://git-annex.branchable.com/forum/git-annex_add_out_

fatal: Out of memory, getdelim failed under NFS mounts

Dear Git gurus, More context (may be different issue(s)) could be found at http://git-annex.branchable.com/forum/git-annex_add_out_of_memory_error/ but currently I am consistently reproducing it while running git (1:2.11.0-3 debian stretch build) within debian stretch singularity environment

Re: in case you want a use-case with lots of submodules

On Mon, 19 Jun 2017, Stefan Beller wrote: > On Mon, Jun 19, 2017 at 8:59 AM, Yaroslav Halchenko <y...@onerussian.com> > wrote: > > Hi All, > > On a recent trip I've listened to the git minutes podcast episode and > > got excited to hear Stefan Beller (CCed just i

in case you want a use-case with lots of submodules

Hi All, On a recent trip I've listened to the git minutes podcast episode and got excited to hear Stefan Beller (CCed just in case) describing ongoing work on submodules mechanism. I got excited, since e.g. performance improvements would be of great benefit to us too. In our project,

inconsistent output from git add about ignored files

Dear Git gurus, It seems that there is some inconsistency in output of git while it is ignoring files: if a single path within ignored directory is provided -- git outputs the file path. If multiple files are provided (some of which aren't ignored) -- git outputs only the ignored directory

Re: [wishlist?] make submodule commands robust to having non-submodule Subprojects

On Thu, 15 Sep 2016, Junio C Hamano wrote: > >> which then stops without even looking at other submodules. > >> I think it would be more logical to make it a 'warning:' not a 'fatal:' and > >> proceed. > Making "git submodule" listing to continue from that point may be > one thing, but do we

Re: [wishlist?] make submodule commands robust to having non-submodule Subprojects

On Thu, 15 Sep 2016, Stefan Beller wrote: > > I think it would be more logical to make it a 'warning:' not a 'fatal:' and > > proceed. > So maybe we would want to introduce a switch > `--existing-but-unconfigure-gitlinks=(warn|ignore)` > as well as > `git config

[wishlist?] make submodule commands robust to having non-submodule Subprojects

NB echos some questions of mine a few days back on IRC about Subprojects and submodules If e.g. you just 'git add' a subdirectory which is a git repository, git adds it as a subproject but doesn't initiate any entry in .gitmodules since it is the job done by submodule and git core itself is

Re: git submodule add spits unrelated to actual problem error msg about .gitignore

On September 14, 2016 3:32:11 PM EDT, Stefan Beller wrote: ! >I think we could chop off "2>&1" as that would have exposed the >underlying error. > >Another way to go would be to use verbose git-add and grep for >the string "add '$sm_path'". > > if test -z "$force" && ! git

git submodule add spits unrelated to actual problem error msg about .gitignore

I have spent some time chasing the wild goose (well - the .gitignore file) after getting: $> git-submodule add --name fcx-1 ./fcx-1/ ./fcx-1/ The following path is ignored by one of your .gitignore files: fcx-1 Use -f if you really want to add it. long story short -- the culprit

Re: [RFC 0/3] http: avoid repeatedly adding curl easy to curlm

On Tue, 13 Sep 2016, Eric Wong wrote: > What is unclear to me is how only Yaroslav's repository seems to > trigger this bug after all these years... Thank you Eric very much for tracking down this issue! Since issue is intermittent, I guess people just didn't bother going through reporting if

git clone http:// fails some times with "Request for d53.. aborted"

even when (v 2.7.0) ran on the box where the server is, so unlikely to be network issue or from my laptop (v 2.9.3) with ok but wifi with a weakish signal to the access point: $> ( set -e; for s in {1..100}; do rm -rf fbirn_phaseIII ; git clone

Re: wishlist; unify behavior while cloning non-bare repos over http to be in line with ssh/local

On Tue, 10 May 2016, Junio C Hamano wrote: > >> The necessary update to the client might be as simple as using > >> $GIVEN_URL/.git/ and attempting the request again after seeing the > >> probe for $GIVEN_URL/info/refs fails. > > Sure -- workarounds are possible,... > Just so that there is no

Re: wishlist; unify behavior while cloning non-bare repos over http to be in line with ssh/local

On Tue, 10 May 2016, Jacob Keller wrote: > > The necessary update to the client might as simple as using > > $GIVEN_URL/.git/ and attempting the request again after seeing the > > probe for $GIVEN_URL/info/refs fails. > I know at least Jenkin's Git plugin has a workaround to solve this > issue

Re: wishlist; unify behavior while cloning non-bare repos over http to be in line with ssh/local

On Fri, 06 May 2016, Yaroslav Halchenko wrote: > Dear Git Folks, > Originally this issue was mentioned in previous thread [1], and I have decided > to bring it into a separate thread. ATM there is a dichotomy in git behavior > between cloning non-bare repos: if I clone over

wishlist; unify behavior while cloning non-bare repos over http to be in line with ssh/local

Dear Git Folks, Originally this issue was mentioned in previous thread [1], and I have decided to bring it into a separate thread. ATM there is a dichotomy in git behavior between cloning non-bare repos: if I clone over ssh or just locally by providing url without trailing /.git, git senses for

Re: 'next'ed --allow-unrelated-histories could cause lots of grief

On Thu, 21 Apr 2016, Junio C Hamano wrote: > >> It is not very productive to make such an emotional statement > >> without substantiating _why_ a merge that adds a new root, which was > >> declared in the thread above as "crap" (in the context of the kernel > >> project), > > Sorry if my

Re: 'next'ed --allow-unrelated-histories could cause lots of grief

On Thu, 21 Apr 2016, Junio C Hamano wrote: > Yaroslav Halchenko <y...@onerussian.com> writes: > > I have decided to try 2.8.1.369.geae769a available from debian > > experimental and through our (datalad) tests failing I became > > aware of the > > > &

'next'ed --allow-unrelated-histories could cause lots of grief

Dear Git Gurus, I guess whenever it rains it indeed pours, so it is me whining again. I have decided to try 2.8.1.369.geae769a available from debian experimental and through our (datalad) tests failing I became aware of the

Re: problems serving non-bare repos with submodules over http

NB Thank you for the lively discussion! On Wed, 20 Apr 2016, Stefan Beller wrote: > >> So currently the protocol doesn't allow to even specify the submodules > >> directories. > > Depends on what you exactly mean by "the protocol", but the > > networking protocol is about accessing a single

Re: problems serving non-bare repos with submodules over http

On Wed, 20 Apr 2016, Stefan Beller wrote: > > I do realize that the situation is quite uncommon, partially I guess due > > to git submodules mechanism flexibility and power on one hand and > > under-use (imho) on the other, which leads to discovery of regressions > > [e.g. 1] and corner cases as

problems serving non-bare repos with submodules over http

Dear Git Folks, I do realize that the situation is quite uncommon, partially I guess due to git submodules mechanism flexibility and power on one hand and under-use (imho) on the other, which leads to discovery of regressions [e.g. 1] and corner cases as mine. [1]

Re: git leaves behind .git/COMMIT_EDITMSG non-shared in --shared non-bare repo

fwiw that file is created not only by interactive tasks by with a regular commit -m msg as well. On December 19, 2015 5:40:43 AM EST, Johannes Schindelin <johannes.schinde...@gmx.de> wrote: >Hi Yaroslav, > >On Fri, 18 Dec 2015, Yaroslav Halchenko wrote: > >> Not sure f

git leaves behind .git/COMMIT_EDITMSG non-shared in --shared non-bare repo

Not sure for what batch operations that file is actually useful, but the story is that if we have a shared git repo (I know -- might not be as common of a situation but possible and allowed to happen), then if one from the shared group commits within that repository, it becomes impossible for

gitk: highlighting commits touching path with globs doesn't work for files list

Hi GIT Gurus, Highlighting files (in patch view) and commits which modified those files is a really nice feature to have. Often it is needed to highlight based on a glob expression for files, e.g. '*Makefile*' -- that seems to highlight the commits but files in the patch view are no longer