Hey Johan,
> Ok, so IINM, Anders' original commit was about making "git submodule
> foreach " behave more like "" (from a naive user's
> perspective),
Ok, that makes sense.
> while you rather expect to insert quotes/escapes to finely control
> exactly when shell interpretation happens.
Well, I mo
On Tue, Mar 04, 2014 at 03:53:24PM +0100, Johan Herland wrote:
> On Tue, Mar 4, 2014 at 2:51 PM, Matthijs Kooijman wrote:
> > matthijs@grubby:~/test$ git submodule foreach echo '$name'
> > Entering 'test'
> > $name
>
> jherland@beta ~/test$ echo
Hey folks,
On Thu, Sep 26, 2013 at 04:10:15PM -0400, Anders Kaseorg wrote:
> ‘eval "$@"’ created an extra layer of shell interpretation, which was
> probably not expected by a user who passed multiple arguments to git
> submodule foreach:
It seems this patch has broken the use of $name, $path, et
Hi,
it seems git submodule supports --checkout, which is also mentioned
indirectly in the manpage. However, the option itself is not mentioned
in the synopsis or detailed option list.
Gr.
Matthijs
signature.asc
Description: Digital signature
Hi Duy,
I saw your patch series got accepted in git master a while back, great!
Since I hope to be using the fixed behaviour soon, what was the plan for
including it? Am I correct in thinking that git master will become 1.8.5
in a while? Would this series perhaps be considered for backporting to
1
Hi folks,
sometimes when I send a patch, I want to reply it to an existing e-mail,
using pretty much the same recipient list. Currently, I have to:
- copy-paste the message id for --in-reply-to header
- copy one address for --to
- copy the other addresses for the --cc's
Since I can't just chu
Hi folks,
any chance this patch can be merged?
Gr.
Matthijs
On Tue, Jun 18, 2013 at 06:38:10PM +0200, Matthijs Kooijman wrote:
> This allows git-svn to prompt for a keyring unlock password, when a
> the needed gnome keyring is locked.
>
> This requires changes in the subversion p
into account the objects already present in
the client.
The actual problem was fixed by a recent patch series by Nguyễn Thái
Ngọc Duy already.
Signed-off-by: Matthijs Kooijman
---
t/t5500-fetch-pack.sh | 11 +++
1 file changed, 11 insertions(+)
diff --git a/t/t5500-fetch-pack.sh b/t
Hi Duy,
> I thought a bit but my thoughts often get stuck if I don't write them
> down in form of code :-) so this is what I got so far. 4/6 is a good
> thing in my opinion, but I might overlook something 6/6 is about this
> thread.
The series looks good to me, though I don't know enough about t
Hi Nguy,
On Fri, Aug 16, 2013 at 04:52:05PM +0700, Nguyễn Thái Ngọc Duy wrote:
> upload-pack has a special rev walking code for shallow recipients. It
> works almost like the similar code in pack-objects except:
>
> 1. in upload-pack, graft points could be added for deepening
>
> 2. also when th
Hi Duy,
> OK. Mathijs, do you want make a patch for it?
I'm willing, but:
- I don't understand the code and all of your comments well enough yet
to start coding right away (though I haven't actually invested enough
time in this yet, either).
- I'll be on vacation for the next two weeks.
W
Hi Junio,
I haven't got a reply to my mail yet. Could you have a look, so I can
update and resubmit my patch?
On Fri, Jul 12, 2013 at 09:11:57AM +0200, Matthijs Kooijman wrote:
> > [administrivia: you seem to have mail-followup-to that points at you
> > and the list; is t
Hi Junio,
> [administrivia: you seem to have mail-followup-to that points at you
> and the list; is that really needed???]
I'm not subscribed to the list, so yes :-)
> > This happens when a client issues a fetch with a depth bigger or equal
> > to the number of commits the server is ahead of the
Hi folks,
while playing with shallow fetches, I've found that in some
circumstances running git fetch with --depth can return too many objects
(in particular, _all_ the objects for the requested revisions are
returned, even when some of those objects are already known to the
client).
This happens
others, this can cause a client to behave differently based on
the server version, which is unexpected.
To prevent this, the new, fixed, depth behaviour is advertised as a server
feature and the old behaviour is restored when the feature is not
requested by the client.
Signed-off-by: Matthijs
is one corner case: A server without the fix cannot send less than
2 commmits, so when --depth=1 is specified a warning is shown and 2
commits are fetched instead of 1.
Signed-off-by: Matthijs Kooijman
---
fetch-pack.c | 26 --
1 file changed, 24 insertions(+), 2 deletions
first check always fires first. This commit removes that check,
making the code a bit more simple again.
Signed-off-by: Matthijs Kooijman
---
shallow.c | 17 ++---
1 file changed, 6 insertions(+), 11 deletions(-)
diff --git a/shallow.c b/shallow.c
index cbe2526..8a9c96d 100644
--- a
Hi Junio,
> While implementing the above, I noticed my fix now introduced an
> off-by-one error the other way. When investigating, I found this commit:
>
> commit 682c7d2f1a2d1a5443777237450505738af2ff1a
> Author: Nguyễn Thái Ngọc Duy
> Date: Fri Jan 11 16:05:47 2013 +0700
>
Hi Junio,
> Doing it "correctly" (in the shorter term) would involve:
>
> - adding a capability on the sending side "fixed-off-by-one-depth"
>to the protocol, and teaching the sending side to advertise the
>capability;
>
> - teaching the requestor that got --depth=N from the end use
Hi folks,
On Fri, Apr 27, 2012 at 08:28:40AM +, Eric Wong wrote:
> Matthijs Kooijman wrote:
> > This allows git-svn to prompt for a keyring unlock password, when a
> > the needed gnome keyring is locked.
> >
> > This requires changes in the subversion pe
This allows git-svn to prompt for a keyring unlock password, when a
the needed gnome keyring is locked.
This requires changes in the subversion perl bindings which have been
committed to svn trunk (r1241554 and some followup commits) and are
first available in the 1.8.0 release.
---
perl/Git/SVN/
Hi Junio,
On Tue, May 28, 2013 at 10:04:46AM -0700, Junio C Hamano wrote:
> Matthijs Kooijman writes:
>
> > Did you consider how to implement this? Looking at the code, it seems
> > the "deepen" parameter in the wire protocol now means:
> > - 0: Do not cha
Hi Jonathan,
> > Did you consider how to implement this? Looking at the code, it seems
> > the "deepen" parameter in the wire protocol now means:
> > - 0: Do not change anything about the shallowness (i.e., fetch
> >everything from the shallow root to the tip).
> > - > 0: Create new shallow
Hi Junio,
I'm interested in getting a fetch tip commit only feature into git, I'll
probably look into creating a patch for this.
> >>> Sounds buggy. Would anything break if we were to make --depth=1 mean
> >>> "1 deep, including the tip commit"?
> >>
> >> As long as we do not change the meaning
Hi Junio,
> Could you explain why you think it hides the real problem, and what
> kind of future enhancement may break it?
I think the differences is mostly in the locality of the fix. In my
proposed patch, the no_pre_delete flag is never set on an interesting
line because it is checked in the lin
instead, which does not set the
no_pre_delete flag.
This commit fixes this problem by only setting the no_pre_delete flag
for changes that were previously uninteresting.
Signed-off-by: Matthijs Kooijman
---
combine-diff.c | 7 +--
t/t4038-d
Hi Junio,
> I think the coalescing of two adjacent hunks into one is painting
> leading lines "interesting to show context but not worth showing
> deletion before it" incorrectly.
Yup, that seems to be the case.
> Does this patch fix the issue?
Yes, it fixes the issue. However, I think that this
Hi folks,
> $ git diff-tree -p -c HEAD
> d945a51b6ca22e6e8e550c53980d026f11b05158
> diff --combined file
> index 3404f54,0eab113..e8c8c18
> --- a/file
> +++ b/file
> @@@ -1,7 -1,5 +1,6 @@@
> +LEFT
> BASE2
> BASE3
> BASE4
> - BASE5
> + BASE5MODIFIED
> BASE6
I found the spot in the code wh
Hi folks,
while trying to parse git diff-tree output, I found out that in some
cases it appears to generate an incorrect diff (AFAICT). I orginally
found this in a 5-way merge commit in the Linux kernel, but managed to
reduce this to something a lot more managable (an ordinary 2-way merge
on a 6-l
Hi Junio,
> - if (ce->ce_ino != (unsigned int) st->st_ino)
> + if (trust_inum && ce->ce_ino != (unsigned int) st->st_ino)
> changed |= INODE_CHANGED;
I just tried this with 1.7.10 (that is, I deleted these two lines to
mimic trust_inum being false) and it indeed fixes my pro
> So, let's see if I can fix my filesystem now ;-)
For anyone interested: turns out passing -o noforget makes fuse keep a
persistent path -> inode mapping (at the cost of memory usage, of
course).
However, it also turns out that fuse wasn't my problem: It was the aufs
mount that was overlayed over
(Please CC me, I'm not on the list)
Hi folks,
I've spent some time debugging an issue and I'd like to share the
results. The conclusion of my debugging is that git does not currently
handle changing inode numbers on files well.
I have a custom Fuse filesystem, and fuse dynamically allocates inod
32 matches
Mail list logo
