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, etc.
On Tue, Mar 04, 2014 at 03:53:24PM +0100, Johan Herland wrote:
On Tue, Mar 4, 2014 at 2:51 PM, Matthijs Kooijman matth...@stdin.nl wrote:
matthijs@grubby:~/test$ git submodule foreach echo '$name'
Entering 'test'
$name
jherland@beta ~/test$ echo '$name'
$name
What would you expect
Hey Johan,
Ok, so IINM, Anders' original commit was about making git submodule
foreach command behave more like command (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.
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
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
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 perl bindings
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 the
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 the
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 matth...@stdin.nl
---
t/t5500-fetch-pack.sh | 11 +++
1 file changed, 11 insertions(+)
diff --git a/t/t5500
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.
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 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 pclo...@gmail.com
Date: Fri Jan 11 16:05:47
the first check always fires first. This commit removes that check,
making the code a bit more simple again.
Signed-off-by: Matthijs Kooijman matth...@stdin.nl
---
shallow.c | 17 ++---
1 file changed, 6 insertions(+), 11 deletions(-)
diff --git a/shallow.c b/shallow.c
index cbe2526
but not 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
.
There 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 matth...@stdin.nl
---
fetch-pack.c | 26 --
1 file changed, 24
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
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 user to
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.
---
Hi folks,
On Fri, Apr 27, 2012 at 08:28:40AM +, Eric Wong wrote:
Matthijs Kooijman matth...@stdin.nl 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 perl bindings which have been
Hi Junio,
On Tue, May 28, 2013 at 10:04:46AM -0700, Junio C Hamano wrote:
Matthijs Kooijman matth...@stdin.nl 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 change anything about
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 of the shallow
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 commits at
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
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 where this is
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
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 matth...@stdin.nl
---
combine-diff.c | 7 +--
t/t4038-diff-combined.sh | 47
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 line
(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
29 matches
Mail list logo
