On Fri, Apr 19, 2013 at 06:44:48PM +0200, Michael J Gruber wrote:
> From: Jeff King
>
> Recently and not so recently, we made sure that log/grep type operations
> use textconv filters when a userfacing diff would do the same:
>
> ef90ab6 (pickaxe: use textconv for -S counting, 2012-10-28)
> b1c
On Fri, Apr 19, 2013 at 11:24:16AM -0700, Junio C Hamano wrote:
> > grep: allow to use textconv filters
>
> This looked mostly sensible except for one minor "eh, do we really
> need to assume textconv output is text, or wouldn't using the same
> codepath for raw blob and textconv result to make
On Fri, Apr 19, 2013 at 06:44:49PM +0200, Michael J Gruber wrote:
> @@ -820,12 +820,13 @@ int cmd_grep(int argc, const char **argv, const char
> *prefix)
> for (i = 0; i < argc; i++) {
> const char *arg = argv[i];
> unsigned char sha1[20];
> + struct
On Fri, Apr 19, 2013 at 06:44:46PM +0200, Michael J Gruber wrote:
> - die("git cat-file --textconv: unable to run textconv on
> %s",
> - obj_name);
> - break;
> + if (textconv_object(obj_context.path, obj_context.mode, sha1,
> 1
On Fri, Apr 19, 2013 at 06:44:45PM +0200, Michael J Gruber wrote:
> Currently, "diff" and "cat-file" for blobs obey "--textconv" options
> (with the former defaulting to "--textconv" and the latter to
> "--no-textconv") whereas "show" does not obey this option, even though
> it takes diff options.
On Fri, Apr 19, 2013 at 06:44:44PM +0200, Michael J Gruber wrote:
> "git show " obeys the textconc setting while "git show "
> does not. Demonstrate this in the test.
s/textconc/textconv
> diff --git a/t/t4030-diff-textconv.sh b/t/t4030-diff-textconv.sh
> index 53ec330..f314ced 100755
> --- a/t/
On Thu, Apr 11, 2013 at 01:02:48AM +0600, Tair Sabirgaliev wrote:
> On OSX Tcl/Tk application windows are created behind all
> the applications down the stack of windows. This is very
> annoying, because once a gitk window appears, it's the
> downmost window and switching to it is pain.
>
> The pa
On Fri, Apr 19, 2013 at 8:16 PM, Duy Nguyen wrote:
> On Sat, Apr 20, 2013 at 5:30 AM, Felipe Contreras
> wrote:
>> This script allows you to get a list of relevant persons to Cc when sending a
>> patch series.
>>
>> % git cc-cmd v1.8.1.6^^1..v1.8.1.6^^2
>> "Nguyễn Thái Ngọc Duy" (author: 30%
On Fri, Apr 19, 2013 at 4:07 PM, Phil Hord wrote:
> On Thu, Apr 18, 2013 at 7:48 PM, Felipe Contreras
> wrote:
>> If something is not hypothetical, it's real, which means it actually
>> happened, but then you said you never made the claim that it did. So
>> what is it?
>
> My claim:
>
>I bis
On Sat, Apr 20, 2013 at 5:30 AM, Felipe Contreras
wrote:
> This script allows you to get a list of relevant persons to Cc when sending a
> patch series.
>
> % git cc-cmd v1.8.1.6^^1..v1.8.1.6^^2
> "Nguyễn Thái Ngọc Duy" (author: 30%, signer: 7%)
> Duy Nguyen (author: 7%)
You see, I like t
Jeff King writes:
> This was triggered in the real world by attempting to push a ref from
> a corrupted repository. pack-objects dies on the local end, we get an
> eof on the receive-pack end without any data, notice that it's a bogus
> packfile, and hit the deadlock.
>
> The bug was introduced b
Felipe Contreras writes:
> This script find people that might be interesting in a patch, by going
> back through the history for each single hunk modified, and finding
> people that reviewed, acknowledge, signed, or authored the code the
> patch is modifying.
>
> It does this by running 'git blam
Jeff King writes:
> On Fri, Apr 19, 2013 at 10:25:46AM -0700, Junio C Hamano wrote:
>
>> Jonathan Nieder writes:
>>
>> > Junio C Hamano wrote:
>> >
>> >> You ran 'git add' with neither '-A (--all)' or '--no-all', whose
>> >> behaviour will change in Git 2.0 with respect to paths you
>>
On Fri, Apr 19, 2013 at 10:25:46AM -0700, Junio C Hamano wrote:
> Jonathan Nieder writes:
>
> > Junio C Hamano wrote:
> >
> >> You ran 'git add' with neither '-A (--all)' or '--no-all', whose
> >> behaviour will change in Git 2.0 with respect to paths you
> >> removed from your worki
Since commit a22e6f8 (receive-pack: send pack-processing
stderr over sideband, 2012-09-21), receive-pack will start
an async sideband thread to copy the stderr from our
index-pack or unpack-objects child to the client. We hand
the thread's input descriptor to unpack(), which puts it in
the "err" me
Johannes Sixt writes:
> A patch auther whose first instinct is to write 'foo=/' will never write
> 'foo=x', let alone 'foo="""/"""'. Someone will have to discover the
> issue eventually and write a patch to fix it, and someone will have to
> apply it.
That is a separate issue. Didn't I say I'll
On Thu, Apr 18, 2013 at 7:48 PM, Felipe Contreras
wrote:
> On Thu, Apr 18, 2013 at 3:06 PM, Phil Hord wrote:
>> On Wed, Apr 17, 2013 at 2:50 PM, Felipe Contreras
>
>>> Yes please. Show me one of the instances where you hit a bisect with
>>> any of the remote-hg commits mentioned above by Thomas R
Johannes Sixt writes:
> Why not just replace the six-liner by this one-liner:
>
> target=${target#"$curdir"/}
Simple enough ;-)
--
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://vge
Felipe Contreras writes:
>>> +File.open(file) do |f|
>>> + f.each do |line|
>>> +case line
>>> +when /^From (\h+) (.+)$/
>>> + from = $1
>>> +when /^---\s+(\S+)/
>>> + source = $1 != '/dev/null' ? $1[2..-1] : nil
>>
>> This may need to be tighten
Am 19.04.2013 21:24, schrieb Junio C Hamano:
> Felipe Contreras writes:
>
>> On Fri, Apr 19, 2013 at 12:08 PM, Junio C Hamano wrote:
>>> Felipe Contreras writes:
The code finds the changes of a commit, runs 'git blame' for each chunk
to see which other commits are relevant, and then r
Felipe Contreras writes:
> Suggested-by: Junio C Hamano
> Signed-off-by: Felipe Contreras
> ---
> contrib/cc-cmd/git-cc-cmd | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/contrib/cc-cmd/git-cc-cmd b/contrib/cc-cmd/git-cc-cmd
> index 9a2d2fd..02841c4 100755
> --- a/con
Jeff King writes:
> On Fri, Apr 19, 2013 at 12:50:48PM -0500, Jed Brown wrote:
>
>> Jeff King writes:
>>
>> > Try "git branch --merged master" to get a list of branches that have
>> > already been merged.
>>
>> That's what I use, but I was hoping for something more precise. For
>> example, a
Felipe Contreras writes:
>> If this were _only_ to be used within send-email (i.e. replacing the
>> "then send it out" above with "then use send-email" to limit the
>> usecase), "git cc-cmd" would be a reasonable name. But if that is
>> the intended use case, it would even be more reasonable to
Johan Herland writes:
> The previous patch adds validation of upstream remote-tracking branches by
> parsing the configured refspecs, and making sure that the candidate upstream
> (if not already matching refs/heads/* or refs/remotes/*) is indeed a
> remote-tracking branch according to some remot
Am 19.04.2013 18:33, schrieb Junio C Hamano:
> Johannes Sixt writes:
>
>> Am 4/18/2013 19:05, schrieb Junio C Hamano:
>>> Johannes Sixt writes:
>>>
From: Johannes Sixt
MSYS bash interprets the slash in the argument core.commentchar="/"
as root directory and mangles it into a
Johan Herland writes:
> The DWIM mode of checkout allows you to run "git checkout foo" when there is
> no existing local ref or path called "foo", and there is exactly one remote
> with a remote-tracking branch called "foo". Git will then automatically
> create a new local branch called "foo" usi
This script find people that might be interesting in a patch, by going
back through the history for each single hunk modified, and finding
people that reviewed, acknowledge, signed, or authored the code the
patch is modifying.
It does this by running 'git blame' incrementally on each hunk, and the
On Fri, Apr 19, 2013 at 2:30 PM, Felipe Contreras
wrote:
> This script find people that might be interesting in a patch, by going
> back through the history for each single hunk modified, and finding
> people that reviewed, acknowledge, signed, or authored the code the
> patch is modifying.
>
> It
On Fri, Apr 19, 2013 at 2:24 PM, Junio C Hamano wrote:
> Felipe Contreras writes:
>
>> On Fri, Apr 19, 2013 at 12:08 PM, Junio C Hamano wrote:
>>> Felipe Contreras writes:
The code finds the changes of a commit, runs 'git blame' for each chunk
to see which other commits are relevant,
Currently only the roles of 'author' and 'signer' and handler, but now
there's also 'reviewer' and 'acker'.
Signed-off-by: Felipe Contreras
---
contrib/cc-cmd/git-cc-cmd | 29 -
1 file changed, 20 insertions(+), 9 deletions(-)
diff --git a/contrib/cc-cmd/git-cc-cmd b
Signed-off-by: Felipe Contreras
---
contrib/cc-cmd/git-cc-cmd | 7 ++-
1 file changed, 6 insertions(+), 1 deletion(-)
diff --git a/contrib/cc-cmd/git-cc-cmd b/contrib/cc-cmd/git-cc-cmd
index 67a276d..9a2d2fd 100755
--- a/contrib/cc-cmd/git-cc-cmd
+++ b/contrib/cc-cmd/git-cc-cmd
@@ -237,7 +23
Suggested-by: Junio C Hamano
Signed-off-by: Felipe Contreras
---
contrib/cc-cmd/git-cc-cmd | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/contrib/cc-cmd/git-cc-cmd b/contrib/cc-cmd/git-cc-cmd
index 9a2d2fd..02841c4 100755
--- a/contrib/cc-cmd/git-cc-cmd
+++ b/contrib/cc-cmd/
For example '-1'.
Signed-off-by: Felipe Contreras
---
contrib/cc-cmd/git-cc-cmd | 9 ++---
1 file changed, 6 insertions(+), 3 deletions(-)
diff --git a/contrib/cc-cmd/git-cc-cmd b/contrib/cc-cmd/git-cc-cmd
index 4bca7f1..4fad030 100755
--- a/contrib/cc-cmd/git-cc-cmd
+++ b/contrib/cc-cmd/gi
Signed-off-by: Felipe Contreras
---
contrib/cc-cmd/git-cc-cmd | 14 ++
1 file changed, 14 insertions(+)
diff --git a/contrib/cc-cmd/git-cc-cmd b/contrib/cc-cmd/git-cc-cmd
index aecfa45..4bca7f1 100755
--- a/contrib/cc-cmd/git-cc-cmd
+++ b/contrib/cc-cmd/git-cc-cmd
@@ -126,6 +126,20 @
Only the mutt format is supported for now.
Signed-off-by: Felipe Contreras
---
contrib/cc-cmd/git-cc-cmd | 25 +
1 file changed, 25 insertions(+)
diff --git a/contrib/cc-cmd/git-cc-cmd b/contrib/cc-cmd/git-cc-cmd
index 4fad030..200da0d 100755
--- a/contrib/cc-cmd/git-cc-
For example master..feature-a.
Signed-off-by: Felipe Contreras
---
contrib/cc-cmd/git-cc-cmd | 36 ++--
1 file changed, 34 insertions(+), 2 deletions(-)
diff --git a/contrib/cc-cmd/git-cc-cmd b/contrib/cc-cmd/git-cc-cmd
index c49225f..aecfa45 100755
--- a/contrib
Instead of showing the authors and signers, show the commits themselves.
Signed-off-by: Felipe Contreras
---
contrib/cc-cmd/git-cc-cmd | 18 ++
1 file changed, 18 insertions(+)
diff --git a/contrib/cc-cmd/git-cc-cmd b/contrib/cc-cmd/git-cc-cmd
index 3a9c70e..c49225f 100755
--- a
Signed-off-by: Felipe Contreras
---
contrib/cc-cmd/git-cc-cmd | 34 ++
1 file changed, 18 insertions(+), 16 deletions(-)
diff --git a/contrib/cc-cmd/git-cc-cmd b/contrib/cc-cmd/git-cc-cmd
index d78759d..3a9c70e 100755
--- a/contrib/cc-cmd/git-cc-cmd
+++ b/contrib/
Signed-off-by: Felipe Contreras
---
contrib/cc-cmd/git-cc-cmd | 17 +
1 file changed, 17 insertions(+)
diff --git a/contrib/cc-cmd/git-cc-cmd b/contrib/cc-cmd/git-cc-cmd
index aa83a1a..d78759d 100755
--- a/contrib/cc-cmd/git-cc-cmd
+++ b/contrib/cc-cmd/git-cc-cmd
@@ -1,8 +1,25 @@
Hi,
Here goes another try, I made some changes based on comments, and should be
simpler now. Plus a few improvements. The interdiff will be on the patches, but
only the first one changed substantially.
This script allows you to get a list of relevant persons to Cc when sending a
patch series.
Felipe Contreras writes:
> On Fri, Apr 19, 2013 at 12:08 PM, Junio C Hamano wrote:
>> Felipe Contreras writes:
>>> The code finds the changes of a commit, runs 'git blame' for each chunk
>>> to see which other commits are relevant, and then reports the author and
>>> signers.
>>
>> In general,
Am 19.04.2013 18:45, schrieb Junio C Hamano:
> John Keeping writes:
>
>> On Thu, Apr 18, 2013 at 03:40:41PM -0700, Junio C Hamano wrote:
>>> John Keeping writes:
>>>
+relative_path ()
+{
+ local target curdir result
+ target=$1
+ curdir=${2-$wt_prefix}
+ curdir=
Ramkumar Ramachandra writes:
> Junio C Hamano wrote:
>> The risk of actually closing the door for future developers. That
>> is a downside of this patch, if we were to apply it.
>
> Okay, no issues. Drop it.
>
> Consider documenting the fact that IS_STASH_LIKE is merely a
> contextual synonym f
On Fri, Apr 19, 2013 at 12:59 PM, Junio C Hamano wrote:
> Felipe Contreras writes:
>
>> For example master..feature-a.
>>
>> Signed-off-by: Felipe Contreras
>> ---
>> contrib/cc-cmd/git-cc-cmd | 36 ++--
>> 1 file changed, 34 insertions(+), 2 deletions(-)
>>
>> d
Michael J Gruber writes:
> This series teaches show and grep to obey textconv: show by
> default (like diff), grep only on request (--textconv). We might
> switch the default for the latter also, of course. I'd actually
> like that.
>
> Compared to an earlier (historic) series this one comes wi
Junio C Hamano wrote:
> The risk of actually closing the door for future developers. That
> is a downside of this patch, if we were to apply it.
Okay, no issues. Drop it.
Consider documenting the fact that IS_STASH_LIKE is merely a
contextual synonym for IS_MERGE_COMMIT somewhere though.
--
To
Michael J Gruber writes:
> When a command is supposed to use textconv filters (by default or with
> "--textconv") and none are configured then the blob is output without
> conversion; the only exception to this rule is "cat-file --textconv".
I am of two minds. Because cat-file is mostly a low-l
On Fri, Apr 19, 2013 at 12:50:48PM -0500, Jed Brown wrote:
> Jeff King writes:
>
> > Try "git branch --merged master" to get a list of branches that have
> > already been merged.
>
> That's what I use, but I was hoping for something more precise. For
> example, a branch that started at 'maint'
Felipe Contreras writes:
> For example master..feature-a.
>
> Signed-off-by: Felipe Contreras
> ---
> contrib/cc-cmd/git-cc-cmd | 36 ++--
> 1 file changed, 34 insertions(+), 2 deletions(-)
>
> diff --git a/contrib/cc-cmd/git-cc-cmd b/contrib/cc-cmd/git-cc-cmd
>
Ramkumar Ramachandra writes:
> Junio C Hamano wrote:
>> peel_committish () {
>> case "$1" in
>> :/*)
>> peeltmp=$(git rev-parse --verify "$1") &&
>> git rev-parse --verify "$peeltmp^0"
>>
Jeff King writes:
> Try "git branch --merged master" to get a list of branches that have
> already been merged.
That's what I use, but I was hoping for something more precise. For
example, a branch that started at 'maint' would show up there, but its
integration hasn't completed until it makes
Ramkumar Ramachandra writes:
> My patch is not solving an end-user problem. Think of it as a source
> code comment: to answer the question "what kind of commit does stash
> create make?",
There already is sufficient comment that explains how a stash commit
is constructed, isn't it?
I may have
On Fri, Apr 19, 2013 at 12:11:38PM -0500, Jed Brown wrote:
> Consider this workflow:
>
> $ git checkout -b my/branch
> hack, commit, ...
> $ git push -u origin my/branch
>
> The branch gets reviewed, merged, and eventually deleted upstream. The
> remote tracking branch gets pruned via 'git fetc
On Fri, Apr 19, 2013 at 12:08 PM, Junio C Hamano wrote:
> Felipe Contreras writes:
>> The code finds the changes of a commit, runs 'git blame' for each chunk
>> to see which other commits are relevant, and then reports the author and
>> signers.
>
> In general, I am not all that interested in add
Junio C Hamano writes:
> That would make this
>
> ":/!(a=Ramkumar)(s=move diff.wordRegex)~4"
>
> a way to find the fourth-generation parent of ...
... 0b830ac52137 (Documentation: move diff.wordRegex from config.txt
to diff-config.txt, 2012-11-13)
I had a log output on another terminal an
Jonathan Nieder writes:
> Junio C Hamano wrote:
>
>> You ran 'git add' with neither '-A (--all)' or '--no-all', whose
>> behaviour will change in Git 2.0 with respect to paths you
>> removed from your working tree.
>>
>> * 'git add --no-all ', which is the current default,
>>
Consider this workflow:
$ git checkout -b my/branch
hack, commit, ...
$ git push -u origin my/branch
The branch gets reviewed, merged, and eventually deleted upstream. The
remote tracking branch gets pruned via 'git fetch --prune' or 'git
remote prune', but that leaves my local branch with an up
Am 18.04.2013 01:17, schrieb Philip Oakley:
> Would it be possible to summarise the key points and proposals of where the
> subject is now?
Here you go, time to post our third iteration of the comparison
list, containing two updates:
- "easier coding" was removed from the advantages
- "git subm
Felipe Contreras writes:
> The code finds the changes of a commit, runs 'git blame' for each chunk
> to see which other commits are relevant, and then reports the author and
> signers.
In general, I am not all that interested in adding anything new to
contrib/ as git.git has matured enough, but e
Make "grep" obey the "--textconv" option also for the object case, i.e.
when used with an argument "rev:path".
Signed-off-by: Michael J Gruber
---
builtin/grep.c | 11 ++-
object.c | 26 --
object.h | 2 ++
t/t7008-grep-binary.
John Keeping writes:
> On Thu, Apr 18, 2013 at 03:40:41PM -0700, Junio C Hamano wrote:
>> John Keeping writes:
>>
>> > +relative_path ()
>> > +{
>> > + local target curdir result
>> > + target=$1
>> > + curdir=${2-$wt_prefix}
>> > + curdir=${curdir%/}
>> > + result=
>> > +
>> > + while te
From: Jeff King
Recently and not so recently, we made sure that log/grep type operations
use textconv filters when a userfacing diff would do the same:
ef90ab6 (pickaxe: use textconv for -S counting, 2012-10-28)
b1c2f57 (diff_grep: use textconv buffers for add/deleted files, 2012-10-28)
0508fe5
Currently, "git grep" does not invoke any textconv filters. Demonstrate
this in the tests.
Signed-off-by: Michael J Gruber
---
t/t7008-grep-binary.sh | 19 +++
1 file changed, 19 insertions(+)
diff --git a/t/t7008-grep-binary.sh b/t/t7008-grep-binary.sh
index 26f8319..a1fd0b2 10
Currently, "diff" and "cat-file" for blobs obey "--textconv" options
(with the former defaulting to "--textconv" and the latter to
"--no-textconv") whereas "show" does not obey this option, even though
it takes diff options.
Make "show" on blobs behave like "diff", i.e. obey "--textconv" by
defaul
When a command is supposed to use textconv filters (by default or with
"--textconv") and none are configured then the blob is output without
conversion; the only exception to this rule is "cat-file --textconv".
Make it behave like the rest of textconv aware commands.
Signed-off-by: Michael J Grub
This series teaches show and grep to obey textconv:
show by default (like diff), grep only on request (--textconv).
We might switch the default for the latter also, of course.
I'd actually like that.
Compared to an earlier (historic) series this one comes with tests.
Besides, it has been in use si
"git show " obeys the textconc setting while "git show "
does not. Demonstrate this in the test.
Signed-off-by: Michael J Gruber
---
t/t4030-diff-textconv.sh | 12
1 file changed, 12 insertions(+)
diff --git a/t/t4030-diff-textconv.sh b/t/t4030-diff-textconv.sh
index 53ec330..f314c
Johannes Sixt writes:
> Am 4/18/2013 19:05, schrieb Junio C Hamano:
>> Johannes Sixt writes:
>>
>>> From: Johannes Sixt
>>>
>>> MSYS bash interprets the slash in the argument core.commentchar="/"
>>> as root directory and mangles it into a Windows style path. Use a
>>> different core.commentch
On Fri, Apr 19, 2013 at 8:26 AM, Ramkumar Ramachandra
wrote:
> Felipe Contreras wrote:
>> The code finds the changes of a commit, runs 'git blame' for each chunk
>> to see which other commits are relevant, and then reports the author and
>> signers.
>>
>> Finally, it calculates what percentage of
Ramkumar Ramachandra writes:
> I'm more interested in knowing what you think of my first point: is
> :/text fundamentally broken, as it can't be combined with other
> operators like the other rev specs can? If so, how do you think we
> should fix it?
The question :/string wants to ask is fundam
On Fri, Apr 19, 2013 at 08:21:48PM +0800, Nazri Ramliy wrote:
> This is similar in spirit to to "make -C dir ..." and "tar -C dir ...".
>
> Signed-off-by: Nazri Ramliy
> ---
> Often I find myself needing to find out quickly the status of a repository
> that
> is not in my currenct working direc
On Thu, 18 Apr 2013 15:46:12 -0700
Junio C Hamano wrote:
> "Philip Oakley" writes:
>
> >> So I observe pushing/fetching works OK at least for a simple case
> >> like this one.
> >>
> >> Hence I'd like to ask: if the manual page is wrong or I'm observing
> >> some corner case?
> >> --
> > The ma
On Fri, Apr 19, 2013 at 10:56:06AM +0200, Sebastian Schmidt wrote:
> I tried switching to smart http now, but have the same error, I guess I
> did something wrong. It seems like it is getting 401, but I also noticed
> that info/refs is just an empty file. This is the config of my apache2:
>
> Set
I found some symlinks in our depot that have the newline and
others that do not. It looks like p4 print just dumps whatever
is in the depot file, which of course is what you would expect
it to do. So the question (for me) is, how did some of my symlink
targets end up without the newline? Note:
Felipe Contreras wrote:
> The code finds the changes of a commit, runs 'git blame' for each chunk
> to see which other commits are relevant, and then reports the author and
> signers.
>
> Finally, it calculates what percentage of the total relevant commits
> each person was involved in, and show on
This is similar in spirit to to "make -C dir ..." and "tar -C dir ...".
Signed-off-by: Nazri Ramliy
---
Often I find myself needing to find out quickly the status of a repository that
is not in my currenct working directory, like this:
$ (cd ~/foo; git log -1)
With this patch now i can
a...@aivor.com wrote on Thu, 18 Apr 2013 20:34 -0500:
> Perhaps it is a configuration item on the server and/or client. It seems we
> are running the same version of p4. But just to be sure, check yours against
> mine:
>
> $ cksum $(which p4)
> 3254530484 2420552 /usr/bin/p4
>
> If yours if di
On Fri, Apr 19, 2013 at 5:08 PM, Yann Dirson wrote:
> git reflog, when applied to a tag, should surely bail out saying there is
> reflog
> for the requested reference. However, instead it spits out a single line of
> abbreviated sha1's of an ancestry walk:
>
> $ git reflog --decorate v1.8.2.1
>
John Keeping wrote:
> It looks to me like setup_git_directory() returns NULL if we're at the
> top of the working tree so we do need that check. I suspect that's so
> that "!prefix" does the right thing.
Ah, yes. My bad. I expected it to return "/" on the toplevel
directory actually.
--
To unsu
On Fri, Apr 19, 2013 at 04:45:38PM +0530, Ramkumar Ramachandra wrote:
> John Keeping wrote:
> > I'm not actually sure this is better. I'm more afraid of the condition
> > for outputting files changing in the future than of passing
> > output_prefix around, so I'd much rather keep that condition in
On Fri, Apr 19, 2013 at 6:27 AM, Philip Oakley wrote:
> From: "Konstantin Khomoutov"
>> So I observe pushing/fetching works OK at least for a simple case like
>> this one.
>>
>> Hence I'd like to ask: if the manual page is wrong or I'm observing
>> some corner case?
>> --
>
> The manual is delibe
John Keeping wrote:
> I'm not actually sure this is better. I'm more afraid of the condition
> for outputting files changing in the future than of passing
> output_prefix around, so I'd much rather keep that condition in one
> place.
>
> If you really feel strongly about it, I'd prefer to extract
On Fri, Apr 19, 2013 at 03:23:37PM +0530, Ramkumar Ramachandra wrote:
> John Keeping wrote:
> > Changes since v2:
> > - Rewrite commit message
> > - Add a new test for 'prefix ignored with HEAD:top'
> > - Use '<<-\EOF' where appropriate in t1513
>
> Thanks for the re-roll.
>
> In the
John Keeping wrote:
> Changes since v2:
> - Rewrite commit message
> - Add a new test for 'prefix ignored with HEAD:top'
> - Use '<<-\EOF' where appropriate in t1513
Thanks for the re-roll.
In the previous iteration, I wasn't sure this was the right approach
because I thought it would
On Thu, Apr 18, 2013 at 9:32 PM, Sivaram Kannan wrote:
> Hi,
>
>> Probably not because there are no debugging symbols. Not sure how
>> ubuntu packages these symbols..
>
> Would recompiling the source packages and debugging would give
> different results?
Yes. Please do. The reason is a backtrace
Sivaram Kannan writes:
> Hi,
>
> The git crashed during one of the commits by a developer I think, the
> remote is not even showing the working branch. The local branch of is
> all right, but the remote repo is corrupted and could not git fsck
> also. Is restoring the last night's backup is my on
On Thu, Apr 18, 2013 at 03:40:41PM -0700, Junio C Hamano wrote:
> John Keeping writes:
>
> > +relative_path ()
> > +{
> > + local target curdir result
> > + target=$1
> > + curdir=${2-$wt_prefix}
> > + curdir=${curdir%/}
> > + result=
> > +
> > + while test -n "$curdir"
> > + do
> >
Junio C Hamano wrote:
> peel_committish () {
> case "$1" in
> :/*)
> peeltmp=$(git rev-parse --verify "$1") &&
> git rev-parse --verify "$peeltmp^0"
> ;;
> *)
>
git reflog, when applied to a tag, should surely bail out saying there is reflog
for the requested reference. However, instead it spits out a single line of
abbreviated sha1's of an ancestry walk:
$ git reflog --decorate v1.8.2.1
5bda18c (tag: v1.8.2.1) 6466fbb 2137ce0 (tag: v1.8.1.6) 4bbb830 0e9
89 matches
Mail list logo
