Re: [PATCH 1/2] Fixes _is_git
On Wed, Feb 4, 2015 at 4:52 AM, Rémi Rampin remiram...@gmail.com wrote:
2015-02-02 12:24 UTC-05:00, Remi Rampin remiram...@gmail.com:
proc _is_git {path} {
+ if {[file isfile $path]} {
+ set fp [open $path r]
+ gets $fp line
+ close $fp
+ if {[regexp ^gitdir: (.+)$ $line line link_target]} {
2015-02-03 3:44 UTC-05:00, Chris Packham judge.pack...@gmail.com:
It might be simpler to use one of the 'string' commands e.g. string
wordend gitdir: I also suspect the string functions would be faster
than regexp but that probably doesn't matter.
I want to check that the file actually begins with gitdir: and then
extract the path, so I'm not sure if using string functions is that
simple/fast.
Makes sense.
+ return [_is_git [file join [file dirname $path]
$link_target]]
Do we want to avoid pathological cases of infinite recursion? Someone
would have to maliciously create such a situation.
Limiting the recursion is very simple, but I'm not sure people are
supposed to stumble on that. More importantly this probably calls for a
different error message, thus a new error result that I am not ready to
implement. But it could be another patch.
But I suppose I can add a simple return 0 limit to the recursion if
needed, let me know.
It'd have to be fairly intentional to cause any real problems. The one
thing I was thinking was to factor out the part that checks for HEAD
info objects etc into a __is_git that _is_git could call thus
eliminating recursion but I don't see it really being anything more
than a theoretical issue.
--
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] decimal_width: avoid integer overflow
The decimal_width function originally appeared in blame.c as
lineno_width, and was designed for calculating the
print-width of small-ish integer values (line numbers in
text files). In ec7ff5b, it was made into a reusable
function, and in dc801e7, we started using it to align
diffstats.
Binary files in a diffstat show byte counts rather than line
numbers, meaning they can be quite large (e.g., consider
adding or removing a 2GB file). decimal_width is not up to
the challenge for two reasons:
1. It takes the value as an int, whereas large files may
easily surpass this. The value may be truncated, in
which case we will produce an incorrect value.
2. It counts up by repeatedly multiplying another
integer by 10 until it surpasses the value. This can
cause an infinite loop when the value is close to the
largest representable integer.
For example, consider using a 32-bit signed integer,
and a value of 2,140,000,000 (just shy of 2^31-1).
We will count up and eventually see that 1,000,000,000
is smaller than our value. The next step would be to
multiply by 10 and see that 10,000,000,000 is too
large, ending the loop. But we can't represent that
value, and we have signed overflow.
This is technically undefined behavior, but a common
behavior is to lose the high bits, in which case our
iterator will certainly be less than the number. So
we'll keep multiplying, overflow again, and so on.
This patch changes the argument to a uintmax_t (the same
type we use to store the diffstat information for binary
filese), and counts down by repeatedly dividing our value
by 10.
Signed-off-by: Jeff King p...@peff.net
---
Note that besides taking a larger type, we also switch to an unsigned
type. I don't think a signed value makes any sense here (do we include
the - or not?), and certainly would not have behaved correctly with
the old code. I did a quick look over all the callers, and they all look
to be conceptually unsigned.
cache.h | 2 +-
pager.c | 8
2 files changed, 5 insertions(+), 5 deletions(-)
diff --git a/cache.h b/cache.h
index f704af5..04951dd 100644
--- a/cache.h
+++ b/cache.h
@@ -1498,7 +1498,7 @@ extern const char *pager_program;
extern int pager_in_use(void);
extern int pager_use_color;
extern int term_columns(void);
-extern int decimal_width(int);
+extern int decimal_width(uintmax_t);
extern int check_pager_config(const char *cmd);
extern const char *editor_program;
diff --git a/pager.c b/pager.c
index f6e8c33..98b2682 100644
--- a/pager.c
+++ b/pager.c
@@ -133,12 +133,12 @@ int term_columns(void)
/*
* How many columns do we need to show this number in decimal?
*/
-int decimal_width(int number)
+int decimal_width(uintmax_t number)
{
- int i, width;
+ int width;
- for (width = 1, i = 10; i = number; width++)
- i *= 10;
+ for (width = 1; number = 10; width++)
+ number /= 10;
return width;
}
--
2.3.0.rc1.287.g761fd19
--
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
Re: [PATCH] Correction to git-p4 exclude change
(Resending as plain text). I could be wrong about this, but my correction above doesn't seem to be in 'next'. Does that mean (reading your last what's cooking) that the broken version is going to go out to 'master' soon? Thanks, Luke On 5 February 2015 at 08:19, Luke Diamand l...@diamand.org wrote: I could be wrong about this, but my correction above doesn't seem to be in 'next'. Does that mean (reading your last what's cooking) that the broken version is going to go out to 'master' soon? Thanks, Luke On 28 January 2015 at 20:49, Junio C Hamano gits...@pobox.com wrote: Luke Diamand l...@diamand.org writes: My previous change for adding support for exclude to git-p4 sync was incorrect, missing out a comma, which stopped git-p4 from working. This change fixes that. I've also noticed that t9814-git-p4-rename.sh has stopped working; I'm going to follow up with a fix for that once I've worked out what's wrong with it. There's a small shell syntax problem (missing esac) but after fixing that it still fails, so I'm not sure what's happening yet. It was discussed a while back. Luke Diamand (1): git-p4: correct exclude change git-p4.py | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) Thanks. Will keep out of 'master' for now. It may not be a bad idea to squash this fix (and any futher ones if needed) into a single patch when we rewind 'next' after 2.3 final is tagged. -- 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 2/2] check-builtins: Strip any executable suffix to make it work on Windows
Signed-off-by: Sebastian Schuberth sschube...@gmail.com
---
check-builtins.sh | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/check-builtins.sh b/check-builtins.sh
index 07cff69..a0aaf3a 100755
--- a/check-builtins.sh
+++ b/check-builtins.sh
@@ -3,7 +3,7 @@
{
cat \EOF
sayIt:
-$(foreach b,$(BUILT_INS),echo XXX $b YYY;)
+$(foreach b,$(BUILT_INS),echo XXX $(b:$X=) YYY;)
EOF
cat Makefile
} |
--
2.1.2-mingw-1
--
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 1/2] Makefile: Improve wording in a comment
Signed-off-by: Sebastian Schuberth sschube...@gmail.com --- Makefile | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/Makefile b/Makefile index c44eb3a..6f8ae23 100644 --- a/Makefile +++ b/Makefile @@ -2447,7 +2447,7 @@ check-docs:: esac; \ done ) | sort -### Make sure built-ins do not have dups and listed in git.c +### Make sure built-ins do not have dupes and are listed in git.c # check-builtins:: ./check-builtins.sh -- 2.1.2-mingw-1 -- 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 1/2] Makefile: Use the same source directory for ln -s as for ln / cp
For consistency, we should use the same source for symbolic links as for hard links and copies. Signed-off-by: Sebastian Schuberth sschube...@gmail.com --- Makefile | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/Makefile b/Makefile index c44eb3a..21f23cb 100644 --- a/Makefile +++ b/Makefile @@ -2265,14 +2265,14 @@ endif $(RM) $$bindir/$$p \ test -z $(NO_INSTALL_HARDLINKS) \ ln $$bindir/git$X $$bindir/$$p 2/dev/null || \ -ln -s git$X $$bindir/$$p 2/dev/null || \ +ln -s $$bindir/git$X $$bindir/$$p 2/dev/null || \ cp $$bindir/git$X $$bindir/$$p || exit; \ done \ for p in $(BUILT_INS); do \ $(RM) $$execdir/$$p \ test -z $(NO_INSTALL_HARDLINKS) \ ln $$execdir/git$X $$execdir/$$p 2/dev/null || \ -ln -s git$X $$execdir/$$p 2/dev/null || \ +ln -s $$execdir/git$X $$execdir/$$p 2/dev/null || \ cp $$execdir/git$X $$execdir/$$p || exit; \ done \ remote_curl_aliases=$(REMOTE_CURL_ALIASES) \ @@ -2280,7 +2280,7 @@ endif $(RM) $$execdir/$$p \ test -z $(NO_INSTALL_HARDLINKS) \ ln $$execdir/git-remote-http$X $$execdir/$$p 2/dev/null || \ -ln -s git-remote-http$X $$execdir/$$p 2/dev/null || \ +ln -s $$execdir/git-remote-http$X $$execdir/$$p 2/dev/null || \ cp $$execdir/git-remote-http$X $$execdir/$$p || exit; \ done \ ./check_bindir z$$bindir z$$execdir $$bindir/git-add$X -- 2.1.2-mingw-1 -- 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 2/2] Makefile: Also add a symlink fallback to installing ALL_PROGRAMS
We do this for BUILT_INS and REMOTE_CURL_ALIASES, so we should do so here, too. Signed-off-by: Sebastian Schuberth sschube...@gmail.com --- Makefile | 1 + 1 file changed, 1 insertion(+) diff --git a/Makefile b/Makefile index 21f23cb..d2849c3 100644 --- a/Makefile +++ b/Makefile @@ -2258,6 +2258,7 @@ endif $(RM) $$execdir/$$p \ test -z $(NO_INSTALL_HARDLINKS)$(NO_CROSS_DIRECTORY_HARDLINKS) \ ln $$bindir/$$p $$execdir/$$p 2/dev/null || \ +ln -s $$bindir/$$p $$execdir/$$p 2/dev/null || \ cp $$bindir/$$p $$execdir/$$p || exit; \ done; \ } \ -- 2.1.2-mingw-1 -- 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
Bug report: Folder and files are deleted by git stash -u
Hello. I noticed some bizarre behaviour when using: git stash -u. It deletes folders which contain files configured to be ignored. I actually lost files by this which I could not restore. Here is how you can reproduce the case. 1. Create a project folder to act as the root of the repository. `cd` into the directory 2. Create a folder `tracked-folder` with a file `tracked-file` in it. Add some content to the file. 3. Create a folder `untracked-folder` with a file `untracked-file` in it. Add some content to the file. 4. Create a file `to-be-stashed`, add some content to the file. 5. Create a `.gitignore` file with the following content: `untracked-file`. 6. Initialize the Git repository: `git init .` 7. Add all files to be tracked: `git add . git commit` 8. List the current content of the repository: `tree`. It should show the following: ├── to-be-stashed ├── tracked-folder │ └── tracked-file └── untracked-folder └── untracked-file 9. Run `git stash -u` and inspect the folder again: . └── tracked-folder └── tracked-file 10. Run `git stash pop` and inspect the folder once again: . ├── to-be-stashed └── tracked-folder └── tracked-file There you are - you just lost the whole folder. Can you please confirm or deny if this is a bug? Thank you. Best regards, Tobias -- 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
Re: [PATCH] config: do not ungetc EOF
On Thu, Feb 05, 2015 at 01:53:27AM -0500, Jeff King wrote:
I also notice that config_buf_ungetc does not actually ungetc the
character we give it; it just rewinds one character in the stream. This
is fine, because we always feed the last-retrieved character. I dunno if
it is worth fixing (it also would have fixed this infinite loop, but for
the wrong reason; we would have stuck -1 back into the stream, and
retrieved it on the next fgetc rather than the same '\r' over and over).
Here's a patch to deal with that. I'm not sure if it's worth doing or
not.
-- 8 --
Subject: [PATCH] config_buf_ungetc: warn when pushing back a random character
Our config code simulates a stdio stream around a buffer,
but our fake ungetc() does not behave quite like the real
one. In particular, we only rewind the position by one
character, but do _not_ actually put the character from the
caller into position.
It turns out that this does not matter, because we only ever
push back the character we just read. In other words, such
an assignment would be a noop. But because the function is
called ungetc, and because it takes a character parameter,
it is a mistake waiting to happen.
Actually assigning the character into the buffer would be
ideal, but our pointer is actually a const copy of the
buffer. We do not know who the real owner of the buffer is
in this code, and would not want to munge their contents.
Instead, we can simply add an assertion that matches what
the current caller does, and will let us know if new callers
are added that violate the contract.
Signed-off-by: Jeff King p...@peff.net
---
config.c | 8 ++--
1 file changed, 6 insertions(+), 2 deletions(-)
diff --git a/config.c b/config.c
index 2c63099..b74cc47 100644
--- a/config.c
+++ b/config.c
@@ -73,8 +73,12 @@ static int config_buf_fgetc(struct config_source *conf)
static int config_buf_ungetc(int c, struct config_source *conf)
{
- if (conf-u.buf.pos 0)
- return conf-u.buf.buf[--conf-u.buf.pos];
+ if (conf-u.buf.pos 0) {
+ conf-u.buf.pos--;
+ if (conf-u.buf.buf[conf-u.buf.pos] != c)
+ die(BUG: config_buf can only ungetc the same
character);
+ return c;
+ }
return EOF;
}
--
2.3.0.rc1.287.g761fd19
--
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
Re: [PATCH 1/2] Makefile: Use the same source directory for ln -s as for ln / cp
Kyle J. McKay mack...@gmail.com writes: Now, can you do that easily in a Makefile? ;) Or is it worth doing it? I do not mind a full symbolic link as long as it points at the correct place (Sebastian's version did not under DESTDIR which was the only issue I had against it), but is there a good reason why we would prefer a relative one (or we would want to avoid a full one)? I'm not sure exactly why, but I think: On Jan 30, 2015, at 13:10, Junio C Hamano wrote: That would make me feel dirty. That is a confusing style of quoting. I suspect that I said the above in a totally different context. Having a user-facing binary that is actually a symlink can potentially cause problems on OS X if the binary it refers to locates its libraries using a relative path. I am not sure what problem you are trying to single out by repeating user-facing here. As doing this is still fully supported: $ PATH=$(git --exec-path):$PATH $ export PATH $ git-cat-file -t HEAD You can arrange things in different ways: - /usr/libexec/git-core/git-cat-file can a symbolic link to /usr/bin/git (cross directory) - /usr/libexec/git-core/git-cat-file can a symbolic link to git (in the same directory) and then /usr/bin/git may be a symbolic link to /usr/libexec/git-core/git (cross directory) No matter what, as long as you have these two directories, you would have the issue that a symbolic link that is given to execv(2) might misbehave somewhere anyway, no? I do not know (and I am not quite sure if I want to know) how serious your potential problems would be, and I do not doubt you know OS X quirks much better than I do and do not intend to argue there aren't such problems. I am just curious how user-facing comes into the picture. -- 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
Re: [PATCH 1/2] Makefile: Use the same source directory for ln -s as for ln / cp
On Thu, Feb 5, 2015 at 9:45 PM, Jeff King p...@peff.net wrote: endif $(RM)·$$execdir/$$p··\ test·-z·$(NO_INSTALL_HARDLINKS)$(NO_CROSS_DIRECTORY_HARDLINKS)··\ ln·$$bindir/$$p·$$execdir/$$p·2/dev/null·||·\ +ln·-s·../$$p·$$execdir/$$p·2/dev/null·||·\ cp·$$bindir/$$p·$$execdir/$$p·||·exit;·\ ··done;·\ }··\ --· does not seem to be correct in all cases. Ah, I see. Yeah, you'd have to calculate that relative path between $bindir and $execdir. We have C code already to do that (see relative_path() in path.c), so in theory you could build a wrapper during the build phase and then run: ln -s $(./my-wrapper $bindir $execdir)/$p $execdir/$p or something during the install phase. Thanks for pointing out the C code to do that. But IMO creating and using such a wrapper is not worth the effort. -- Sebastian Schuberth -- 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
Re: [PATCH] config: do not ungetc EOF
Jeff King p...@peff.net writes:
On Thu, Feb 05, 2015 at 01:53:27AM -0500, Jeff King wrote:
I also notice that config_buf_ungetc does not actually ungetc the
character we give it; it just rewinds one character in the stream. This
is fine, because we always feed the last-retrieved character. I dunno if
it is worth fixing (it also would have fixed this infinite loop, but for
the wrong reason; we would have stuck -1 back into the stream, and
retrieved it on the next fgetc rather than the same '\r' over and over).
Here's a patch to deal with that. I'm not sure if it's worth doing or
not.
I am not sure, either. If this were to become stdio emulator over
random in-core data used throughout the system, perhaps.
But in its current form it is tied to the implementation of config.c
very strongly, so...
-- 8 --
Subject: [PATCH] config_buf_ungetc: warn when pushing back a random character
Our config code simulates a stdio stream around a buffer,
but our fake ungetc() does not behave quite like the real
one. In particular, we only rewind the position by one
character, but do _not_ actually put the character from the
caller into position.
It turns out that this does not matter, because we only ever
push back the character we just read. In other words, such
an assignment would be a noop. But because the function is
called ungetc, and because it takes a character parameter,
it is a mistake waiting to happen.
Actually assigning the character into the buffer would be
ideal, but our pointer is actually a const copy of the
buffer. We do not know who the real owner of the buffer is
in this code, and would not want to munge their contents.
Instead, we can simply add an assertion that matches what
the current caller does, and will let us know if new callers
are added that violate the contract.
Signed-off-by: Jeff King p...@peff.net
---
config.c | 8 ++--
1 file changed, 6 insertions(+), 2 deletions(-)
diff --git a/config.c b/config.c
index 2c63099..b74cc47 100644
--- a/config.c
+++ b/config.c
@@ -73,8 +73,12 @@ static int config_buf_fgetc(struct config_source *conf)
static int config_buf_ungetc(int c, struct config_source *conf)
{
- if (conf-u.buf.pos 0)
- return conf-u.buf.buf[--conf-u.buf.pos];
+ if (conf-u.buf.pos 0) {
+ conf-u.buf.pos--;
+ if (conf-u.buf.buf[conf-u.buf.pos] != c)
+ die(BUG: config_buf can only ungetc the same
character);
+ return c;
+ }
return EOF;
}
--
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
Re: Advice on edits to git-rebase man page
Matthieu Moy matthieu@grenoble-inp.fr writes: Junio C Hamano gits...@pobox.com writes: Perhaps something like this instead? git-rebase - Rebuild a branch on top of a different commit I would say Replay history on top of a different commit instead. Rebuild may be misleading (it's not build as in compile link), and the rebased history does not technically have to be a branch. I am fine if the description were replay history and repoint the branch tip to the result; the fact that branch tip moves is an important part of the semantics of the command. Otherwise, you cannot cleanly capture why we have rebase and cherry-pick (which can do ranges these days). -- 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
Re: Advice on edits to git-rebase man page
Junio C Hamano gits...@pobox.com writes: Perhaps something like this instead? git-rebase - Rebuild a branch on top of a different commit I would say Replay history on top of a different commit instead. Rebuild may be misleading (it's not build as in compile link), and the rebased history does not technically have to be a branch. But both are far better than what we have IMHO. -- Matthieu Moy http://www-verimag.imag.fr/~moy/ -- 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
Re: [PATCH] config: do not ungetc EOF
On Thu, Feb 05, 2015 at 01:16:36PM -0800, Junio C Hamano wrote:
Jeff King p...@peff.net writes:
On Thu, Feb 05, 2015 at 01:53:27AM -0500, Jeff King wrote:
I also notice that config_buf_ungetc does not actually ungetc the
character we give it; it just rewinds one character in the stream. This
is fine, because we always feed the last-retrieved character. I dunno if
it is worth fixing (it also would have fixed this infinite loop, but for
the wrong reason; we would have stuck -1 back into the stream, and
retrieved it on the next fgetc rather than the same '\r' over and over).
Here's a patch to deal with that. I'm not sure if it's worth doing or
not.
I am not sure, either. If this were to become stdio emulator over
random in-core data used throughout the system, perhaps.
But in its current form it is tied to the implementation of config.c
very strongly, so...
Yeah, that was my thinking, and why I have doubts. Maybe a comment would
make more sense, like the patch below. I am also OK with just leaving
it as-is.
-- 8 --
Subject: [PATCH] config_buf_ungetc: document quirks in a comment
Our config_buf_ungetc implements just enough for the config
code to work. That's OK, but we would not want anyone to
mistakenly move it elsewhere as a general purpose ungetc.
Signed-off-by: Jeff King p...@peff.net
---
config.c | 6 ++
1 file changed, 6 insertions(+)
diff --git a/config.c b/config.c
index 2c63099..089a94f 100644
--- a/config.c
+++ b/config.c
@@ -71,6 +71,12 @@ static int config_buf_fgetc(struct config_source *conf)
return EOF;
}
+/*
+ * Note that this is not a real ungetc replacement. It only rewinds
+ * the position, and ignores the c parameter, rather than
+ * putting it into our (const) buffer. That's good enough for
+ * the callers here, though.
+ */
static int config_buf_ungetc(int c, struct config_source *conf)
{
if (conf-u.buf.pos 0)
--
2.3.0.rc1.287.g761fd19
--
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
Re: [BUG] Move tracking in git diff is not as good as in git status
Kyle J. McKay mack...@gmail.com writes: On Feb 4, 2015, at 22:11, Scott Schmit wrote: In my use of git, I've noticed that git status is a lot better at tracking moves and renames than git diff, and this has recently caused me a lot of headaches because a large number of moves were made in a single commit, and it was very difficult to figure out which moves were right and which were wrong. I was using a fairly old version of git (1.7.11), but was able to reproduce it on git 2.2.1. Here's a reproduction recipe: [...] # Now shift the files git mv 2 3 git mv 1 2 [...] git commit -m 2=1;3=2; # Neither of these commands get it (but -C gets a glimmer of the truth) git diff -M --stat --summary HEAD~.. git diff -C --stat --summary HEAD~.. Ah, but did you try this: git diff -B -M --stat --summary HEAD~.. Yes, since f714fb84 (Enable rewrite as well as rename detection in git-status, 2007-12-02) git status internally uses -B -M. -- 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
Re: [PATCH] Correction to git-p4 exclude change
Luke Diamand l...@diamand.org writes: (Resending as plain text). I could be wrong about this, but my correction above doesn't seem to be in 'next'. Does that mean (reading your last what's cooking) that the broken version is going to go out to 'master' soon? The current copy of What's cooking I have reads like so: * ld/p4-exclude-in-sync (2015-01-28) 2 commits - git-p4: correct exclude change (merged to 'next' on 2015-01-22 at f6f1fc7) + git-p4: support excluding paths on sync Will squash into one after 2.3 final. As we are too late to merge anything new to 'master', and the broken one is not in 'master', I have been playing lazy to make time to tend to other issues ;-) After 2.3 final, we would rewind the tip of 'next' and will rebuild, and when that happens, I am hoping that we can make these two into one commit that does not have the oops, I forgot a comma and broke the entire command fix-up as a separate commit. Or did I mis-read you? Do we have broken code already in 'master' that this hot-fix needs to be applied to unbreak? -- 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
Re: Bug report: Folder and files are deleted by git stash -u
Tobias Preuss tobias.pre...@googlemail.com writes: I noticed some bizarre behaviour when using: git stash -u. It deletes folders which contain files configured to be ignored. The files you mark as ignored are expendable and this is not limited to stash. $ git init Initialized empty Git repository in /var/tmp/x/ignore/.git/ $ echo \*.o .gitignore $ git add .gitignore $ git commit -m void [master (root-commit) 457b70e] void 1 file changed, 1 insertion(+) create mode 100644 .gitignore $ echo a regular file a $ git add a $ git commit -m a regular file [master df839f0] a regular file 1 file changed, 1 insertion(+) create mode 100644 a We have two regular files, .gitignore and a, on 'master' branch. $ git checkout -b side HEAD^ Switched to a new branch 'side' $ mkdir a $ a/file.c $ a/file.o $ git add . $ git commit -m 'a/file.c' [side 3199d63] a/file.c 1 file changed, 0 insertions(+), 0 deletions(-) create mode 100644 a/file.c We have two regular files, .gitignore and a/file.c, on 'side' branch, which is checked out. The object files that would be created by compiling source files are set to be ignored by .gitignore rule. Here is what should happen when you go to 'master': $ git checkout master Switched to branch 'master' $ /bin/ls -AF a .git/ .gitignore That is, a/file.c that is safely stored in 'side' branch is removed, a/file.o that is expendable is deleted, and the empty directory 'a' now can be replaced with the regular file 'a' the 'master' branch wants to have. -- 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
Re: [PATCH 1/2] Makefile: Improve wording in a comment
Sebastian Schuberth sschube...@gmail.com writes: Signed-off-by: Sebastian Schuberth sschube...@gmail.com --- Is that an improvement? Is the plural of dup (used as an abbreviation of duplicate) dupes not dups? Makefile | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/Makefile b/Makefile index c44eb3a..6f8ae23 100644 --- a/Makefile +++ b/Makefile @@ -2447,7 +2447,7 @@ check-docs:: esac; \ done ) | sort -### Make sure built-ins do not have dups and listed in git.c +### Make sure built-ins do not have dupes and are listed in git.c # check-builtins:: ./check-builtins.sh -- 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
Re: [PATCH 1/2] Makefile: Improve wording in a comment
On Thu, Feb 5, 2015 at 8:17 PM, Junio C Hamano gits...@pobox.com wrote: Sebastian Schuberth sschube...@gmail.com writes: Signed-off-by: Sebastian Schuberth sschube...@gmail.com --- Is that an improvement? Is the plural of dup (used as an abbreviation of duplicate) dupes not dups? My view is that the abbreviation of duplicate is not dup but dupe, hence the plural dupes. -- Sebastian Schuberth -- 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
Re: [PATCH 1/2] Makefile: Improve wording in a comment
On Thu, Feb 5, 2015 at 8:19 PM, Sebastian Schuberth sschube...@gmail.com wrote: Is that an improvement? Is the plural of dup (used as an abbreviation of duplicate) dupes not dups? My view is that the abbreviation of duplicate is not dup but dupe, hence the plural dupes. For duplicate the noun, that is. For duplicate the verb I'd be ok with dup as the abbreviation. to dup sounds and looks better than to dupe :-) -- Sebastian Schuberth -- 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
Re: [PATCH 1/2] Makefile: Use the same source directory for ln -s as for ln / cp
Kyle J. McKay mack...@gmail.com writes: -ln -s git$X $$bindir/$$p 2/dev/null || \ +ln -s $$bindir/git$X $$bindir/$$p 2/dev/null || \ This is wrong. Currently with symlinks you will get installed into bindir something like this: git git-tag - git git-show - git etc. With your change you would have git git-tag - /usr/local/libexec/git-core/git git-show - /usr/local/libexec/git-core/git And I don't think we want that. While those absolute path symlinks are technically correct,... It is not even correct, is it? When DESTDIR is set to allow you to install into a temporary place only so that you can tar up the resulting filesystem tree, bindir points at the location we need to cp the built programs into, i.e. inside DESTDIR. -- 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
Re: [PATCH 1/2] Makefile: Use the same source directory for ln -s as for ln / cp
On Thu, Feb 5, 2015 at 8:23 PM, Junio C Hamano gits...@pobox.com wrote: This is wrong. Currently with symlinks you will get installed into bindir something like this: git git-tag - git git-show - git etc. With your change you would have git git-tag - /usr/local/libexec/git-core/git git-show - /usr/local/libexec/git-core/git And I don't think we want that. While those absolute path symlinks are technically correct,... It is not even correct, is it? When DESTDIR is set to allow you to install into a temporary place only so that you can tar up the resulting filesystem tree, bindir points at the location we need to cp the built programs into, i.e. inside DESTDIR. Agreed folks, please disregard this as well as 2/2 of this series. -- Sebastian Schuberth -- 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
Git gc removes all packs
Hi, I'm experiencing a strange behavior of automatic git gc which corrupts a local repository. Git version 2.2.2 on Mac OS X 10.10.1. I'm using git p4 for synchronization with perforce. Sometimes after 'git p4 rebase' git starts a garbage collection. When gc finishes a local repository contains no pack files only loose objects, so I have to re-import repository from perforce. It also doesn't contain a temporary pack git gc was creating. Command line history looks like this: git p4 rebase Performing incremental import into refs/remotes/p4/master git branch Depot paths: //XXX/YYY/ Import destination: refs/remotes/p4/master Importing revision 352157 (100%) Rebasing the current branch onto remotes/p4/master First, rewinding head to replay your work on top of it... Fast-forwarded master to remotes/p4/master. Auto packing the repository in background for optimum performance. See git help gc for manual housekeeping. ps aux | grep git nd 14335 95.0 1.4 4643292 114788 ?? R 8:52PM 0:05.79 git pack-objects --keep-true-parents --honor-pack-keep --non-empty --all --reflog --indexed-objects --unpack-unreachable=2.weeks.ago --local --delta-base-offset /path/to/repo/.git/objects/pack/.tmp-14333-pack nd 14333 0.0 0.0 2452420920 ?? S 8:52PM 0:00.00 git repack -d -l -A --unpack-unreachable=2.weeks.ago nd 14331 0.0 0.0 2436036744 ?? Ss8:52PM 0:00.00 git gc --auto After the 14331 process termination all packs are gone. One more thing about my setup: since git p4 promotes a use of a linear history I use a separate repository for another branch in perforce. In order to be able to cherry-pick between repositories I added this another repo objects dir as an alternate and also added a ref which is a symbolic link to a branch in another repo (so I don't have to do any fetches). How do I troubleshoot the problem? Is there any way to enable a some kind of logging for automatic git gc? Can use of alternates or symbolic links in refs cause such a behavior? -- Dmitry -- 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
What's cooking in git.git (Feb 2015, #02; Thu, 5)
Here are the topics that have been cooking. Commits prefixed with
'-' are only in 'pu' (proposed updates) while commits prefixed with
'+' are in 'next'.
Git 2.3 is out. I'll wait for some time for the dust to settle and
then rewind and rebuild 'next'.
You can find the changes described here in the integration branches
of the repositories listed at
http://git-blame.blogspot.com/p/git-public-repositories.html
--
[New Topics]
* jc/diff-files-ita (2015-02-04) 1 commit
- run_diff_files(): clarify computation of sha1 validity
Will merge to 'next'.
* jk/config-no-ungetc-eof (2015-02-05) 2 commits
- config_buf_ungetc: warn when pushing back a random character
- config: do not ungetc EOF
Will merge to 'next'.
* jk/decimal-width-for-uintmax (2015-02-05) 1 commit
- decimal_width: avoid integer overflow
Will merge to 'next'.
* ss/check-builtins-on-windows (2015-02-05) 1 commit
- check-builtins: strip executable suffix $X when enumerating builtins
Will merge to 'next'.
--
[Stalled]
* jn/doc-api-errors (2014-12-04) 1 commit
- doc: document error handling functions and conventions
For discussion.
* pw/remote-set-url-fetch (2014-11-26) 1 commit
- remote: add --fetch and --both options to set-url
Expecting a reroll.
* ms/submodule-update-config-doc (2014-11-03) 1 commit
- submodule: clarify documentation for update subcommand
Needs a reroll ($gmane/259037).
* je/quiltimport-no-fuzz (2014-10-21) 2 commits
- git-quiltimport: flip the default not to allow fuzz
- git-quiltimport.sh: allow declining fuzz with --exact option
quiltimport drove git apply always with -C1 option to reduce
context of the patch in order to give more chance to somewhat stale
patches to apply. Add an --exact option to disable, and also
-C$n option to customize this behaviour. The top patch
optionally flips the default to --exact.
Tired of waiting for an Ack; will discard.
* tr/remerge-diff (2014-11-10) 9 commits
- t4213: avoid | in sed regexp
- log --remerge-diff: show what the conflict resolution changed
- name-hash: allow dir hashing even when !ignore_case
- merge-recursive: allow storing conflict hunks in index
- merge_diff_mode: fold all merge diff variants into an enum
- combine-diff: do not pass revs-dense_combined_merges redundantly
- merge-recursive: -Xindex-only to leave worktree unchanged
- merge-recursive: internal flag to avoid touching the worktree
- merge-recursive: remove dead conditional in update_stages()
log -p output learns a new way to let users inspect a merge
commit by showing the differences between the automerged result
with conflicts the person who recorded the merge would have seen
and the final conflict resolution that was recorded in the merge.
Waiting for a reroll ($gmane/256591).
* hv/submodule-config (2014-11-11) 4 commits
- do not die on error of parsing fetchrecursesubmodules option
- use new config API for worktree configurations of submodules
- extract functions for submodule config set and lookup
- implement submodule config cache for lookup of submodule names
Kicked back to 'pu' per request ($gmane/255610).
* ab/add-interactive-show-diff-func-name (2014-05-12) 2 commits
- SQUASH??? git-add--interactive: Preserve diff heading when splitting hunks
- git-add--interactive: Preserve diff heading when splitting hunks
Waiting for a reroll.
* jn/gitweb-utf8-in-links (2014-05-27) 1 commit
- gitweb: Harden UTF-8 handling in generated links
$gmane/250758?
* ss/userdiff-update-csharp-java (2014-06-02) 2 commits
- userdiff: support Java try keyword
- userdiff: support C# async methods and correct C# keywords
Reviews sent; waiting for a response.
* bg/rebase-off-of-previous-branch (2014-04-16) 1 commit
- git-rebase: print name of rev when using shorthand
Teach git rebase - to report the concrete name of the branch
(i.e. the previous one).
But it stops short and does not do the same for git rebase @{-1}.
Expecting a reroll.
* rb/merge-prepare-commit-msg-hook (2014-01-10) 4 commits
- merge: drop unused arg from abort_commit method signature
- merge: make prepare_to_commit responsible for write_merge_state
- t7505: ensure cleanup after hook blocks merge
- t7505: add missing
Expose more merge states (e.g. $GIT_DIR/MERGE_MODE) to hooks that
run during git merge. The log message stresses too much on one
hook, prepare-commit-msg, but it would equally apply to other hooks
like post-merge, I think.
Waiting for a reroll.
* jc/graph-post-root-gap (2013-12-30) 3 commits
- WIP: document what we want at the end
- graph: remove unused code a bit
- graph: stuff the current commit into graph-columns[]
This was primarily a RFH ($gmane/239580).
* tg/perf-lib-test-perf-cleanup (2013-09-19) 2 commits
- perf-lib: add test_perf_cleanup target
- perf-lib: split starting the test from the execution
Add test_perf_cleanup
A note from the maintainer
Welcome to the Git development community.
This message is written by the maintainer and talks about how Git
project is managed, and how you can work with it.
* Mailing list and the community
The development is primarily done on the Git mailing list. Help
requests, feature proposals, bug reports and patches should be sent to
the list address git@vger.kernel.org. You don't have to be
subscribed to send messages. The convention on the list is to keep
everybody involved on Cc:, so it is unnecessary to say Please Cc: me,
I am not subscribed.
Before sending patches, please read Documentation/SubmittingPatches
and Documentation/CodingGuidelines to familiarize yourself with the
project convention.
If you sent a patch and you did not hear any response from anybody for
several days, it could be that your patch was totally uninteresting,
but it also is possible that it was simply lost in the noise. Please
do not hesitate to send a reminder message in such a case. Messages
getting lost in the noise may be a sign that those who can evaluate
your patch don't have enough mental/time bandwidth to process them
right at the moment, and it often helps to wait until the list traffic
becomes calmer before sending such a reminder.
The list archive is available at a few public sites:
http://news.gmane.org/gmane.comp.version-control.git/
http://marc.theaimsgroup.com/?l=git
http://www.spinics.net/lists/git/
For those who prefer to read it over NNTP:
nntp://news.gmane.org/gmane.comp.version-control.git
When you point at a message in a mailing list archive, using
gmane is often the easiest to follow by readers, like this:
http://thread.gmane.org/gmane.comp.version-control.git/27/focus=217
as it also allows people who subscribe to the mailing list as gmane
newsgroup to jump to the article.
Some members of the development community can sometimes be found on
the #git and #git-devel IRC channels on Freenode. Their logs are
available at:
http://colabti.org/irclogger/irclogger_log/git
http://colabti.org/irclogger/irclogger_log/git-devel
* Reporting bugs
When you think git does not behave as you expect, please do not stop
your bug report with just git does not work. I used git in this
way, but it did not work is not much better, neither is I used git
in this way, and X happend, which is broken. It often is that git is
correct to cause X happen in such a case, and it is your expectation
that is broken. People would not know what other result Y you expected
to see instead of X, if you left it unsaid.
Please remember to always state
- what you wanted to achieve;
- what you did (the version of git and the command sequence to reproduce
the behavior);
- what you saw happen (X above);
- what you expected to see (Y above); and
- how the last two are different.
See http://www.chiark.greenend.org.uk/~sgtatham/bugs.html for further
hints.
* Repositories, branches and documentation.
My public git.git repositories are at:
git://git.kernel.org/pub/scm/git/git.git/
https://kernel.googlesource.com/pub/scm/git/git
git://repo.or.cz/alt-git.git/
https://github.com/git/git/
https://code.google.com/p/git-core/
git://git.sourceforge.jp/gitroot/git-core/git.git/
git://git-core.git.sourceforge.net/gitroot/git-core/git-core/
A few web interfaces are found at:
http://git.kernel.org/?p=git/git.git
https://kernel.googlesource.com/pub/scm/git/git
http://repo.or.cz/w/alt-git.git
Preformatted documentation from the tip of the master branch can be
found in:
git://git.kernel.org/pub/scm/git/git-{htmldocs,manpages}.git/
git://repo.or.cz/git-{htmldocs,manpages}.git/
https://code.google.com/p/git-{htmldocs,manpages}.git/
https://github.com/gitster/git-{htmldocs,manpages}.git/
You can browse the HTML manual pages at:
http://git-htmldocs.googlecode.com/git/git.html
There are four branches in git.git repository that track the source tree
of git: master, maint, next, and pu.
The master branch is meant to contain what are very well tested and
ready to be used in a production setting. Every now and then, a
feature release is cut from the tip of this branch. They used to be
named with three dotted decimal digits (e.g. 1.8.5), but recently we
switched the versioning scheme and feature releases are named with
three-dotted decimal digits that ends with .0 (e.g. 1.9.0).
The last such release was 2.3.0 done on Feb 5th, 2015. You can expect
that the tip of the master branch is always more stable than any of
the released versions.
Whenever a feature release is made, maint branch is forked off from
master at that point. Obvious, safe and urgent fixes after a
feature release are applied to this branch and maintenance releases
are cut from it. The maintenance releases used to be named with four
dotted decimal, named after the feature release they are updates to
Re: [PATCH 1/2] Makefile: Use the same source directory for ln -s as for ln / cp
On Feb 5, 2015, at 12:59, Junio C Hamano wrote: I do not know (and I am not quite sure if I want to know) how serious your potential problems would be, and I do not doubt you know OS X quirks much better than I do and do not intend to argue there aren't such problems. I am just curious how user-facing comes into the picture. Suppose you have built and installed some software to /usr/local and it's ended up in the usual subdirectories, /usr/local/bin, /usr/local/ lib, etc. Now you get an installer for package X, and to avoid stepping on things it installs to /opt/XYZ with the usual suspects /opt/XYZ/bin, / opt/XYZ/lib. There are several of these that I'm aware of where XYZ is whatever package you're installing. Now since /opt/XYZ/bin is not usually in one's PATH it installs a few select symlinks from /usr/local/bin/whatever to /opt/XYZ/bin/ whatever. Not all of the /opt/XYZ installers do this, for some of them it's a selectable option. So now we have: # This one can be a relative or absolute symlink, doesn't matter /usr/local/bin/foo - /opt/XYZ/bin/foo And we also now have this: # A real binary, not a symlink # Uses and locates libfoo with ../lib/libfoo.dylib /opt/XYZ/bin/foo # A real library binary, not a symlink /opt/XYZ/lib/libfoo.dylib So /opt/XYZ/bin/foo locates libfoo.dylib by using a relative path embedded within it (in this case it would be @loader_path/../lib/ libfoo.dylib). So far, so good, right? Nothing complicated going on. But the user has built and installed an older version of libfoo already to /usr/local/lib/libfoo.dylib. Ah-oh. User attempts to run foo. Shell finds foo at /usr/local/bin/foo and runs it. The dynamic linker correctly loads /opt/XYZ/bin/foo and starts to resolve the dynamic library links embedded in it. For the @loader_path/../lib/libfoo.dylib one it first tries /usr/ local/bin/../lib/libfoo.dylib rather than /opt/XYZ/bin/foo/../lib/ libfoo.dylib because /usr/local/bin/foo was the executable that was run and since the user has installed an older version of libfoo.dylib in /usr/local/lib, it finds and loads that instead of the intended one. If it didn't find that it would then try /opt/XYZ/bin/foo/../lib/ libfoo.dylib and get the right one. Sometimes you get an immediate error if the unintended library version is just too old to be compatible. On the other hand, if it's just old enough to be buggy but not version incompatible now you're running with a buggy library or some other incompatibility that doesn't show up right away. I think this is a nasty bug specific to OS X, the fact that it tries both paths though suggests it was deliberate. I have not tested all versions of OS X to see if it might have been fixed in the latest, but there it is. If you put /opt/XYZ/bin directly in the PATH this can't happen (provided /opt/XYZ/bin/foo is not itself a symlink). So that's how a user-facing binary that is a symlink can cause problems. I suppose it's not just limited to user-facing binaries, but that's where it tends to show up as it seems the non-user-facing, non-executable stuff usually has a sufficiently controlled surrounds that they're not vulnerable. I say user-facing because the binary is found in the user's $PATH. I do not consider the libexec/git-core binaries to be user-facing since they are not normally in the user's $PATH but rather normally accessed via the git binary which is likely in the user's $PATH. In the case of Git, a /usr/local/bin/git - ../libexec/git-core/git symlink should not be vulnerable to this problem, because even if the executable ends up with some relative dylib paths in it (usually not the case) when applied to /usr/local/bin they're unlikely to lead anywhere with user-installed libraries since git-core is one directory deeper than bin. Anyhow, that's why I tend to avoid putting symlink-to-binary stuff in PATH. In any case a packager can make adjustments to avoid the problem before creating an installer. -Kyle P.S. On Feb 5, 2015, at 12:59, Junio C Hamano wrote: I'm not sure exactly why, but I think: On Jan 30, 2015, at 13:10, Junio C Hamano wrote: That would make me feel dirty. That is a confusing style of quoting. I suspect that I said the above in a totally different context. But I've been dying to work that in somehow ever since I saw that. ;) -- 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
[ANNOUNCE] Git v2.3.0
The latest feature release Git v2.3.0 is now available at the usual places. This one ended up to be a release with lots of small corrections and improvements without big uncomfortably exciting features. It is a lot smaller release than other recent feature releases, consisting of 255 non-merge commits (version 2.0, 2.1 and 2.2 had 475, 698 and 556 commits, respectively) by 61 contributors (among which 19 are new people--welcome!). The tarballs are found at: https://www.kernel.org/pub/software/scm/git/ The following public repositories all have a copy of the 'v2.3.0' tag and the 'master' branch that the tag points at: url = https://kernel.googlesource.com/pub/scm/git/git url = git://repo.or.cz/alt-git.git url = https://code.google.com/p/git-core/ url = git://git.sourceforge.jp/gitroot/git-core/git.git url = git://git-core.git.sourceforge.net/gitroot/git-core/git-core url = https://github.com/gitster/git Git v2.3 Release Notes == This one ended up to be a release with lots of small corrections and improvements without big uncomfortably exciting features. The recent security fix that went to 2.2.1 and older maintenance tracks is also contained in this update. Updates since v2.2 -- Ports * Recent gcc toolchain on Cygwin started throwing compilation warning, which has been squelched. * A few updates to build on platforms that lack tv_nsec, clock_gettime, CLOCK_MONOTONIC and HMAC_CTX_cleanup (e.g. older RHEL) have been added. UI, Workflows Features * It was cumbersome to use GIT_SSH mechanism when the user wanted to pass an extra set of arguments to the underlying ssh. A new environment variable GIT_SSH_COMMAND can be used for this. * A request to store an empty note via git notes meant to remove note from the object but with --allow-empty we will store a (surprise!) note that is empty. * git interpret-trailers learned to properly handle the Conflicts: block at the end. * git am learned --message-id option to copy the message ID of the incoming e-mail to the log message of resulting commit. * git clone --reference=over there learned the --dissociate option to go with it; it borrows objects from the reference object store while cloning only to reduce network traffic and then dissociates the resulting clone from the reference by performing local copies of borrowed objects. * git send-email learned --transfer-encoding option to force a non-fault Content-Transfer-Encoding header (e.g. base64). * git send-email normally identifies itself via X-Mailer: header in the message it sends out. A new command line flag --no-xmailer allows the user to squelch the header. * git push into a repository with a working tree normally refuses to modify the branch that is checked out. The command learned to optionally do an equivalent of git reset --hard only when there is no change to the working tree and the index instead, which would be useful to deploy by pushing into a repository. * git new-workdir (in contrib/) can be used to populate an empty and existing directory now. * Credential helpers are asked in turn until one of them give positive response, which is cumbersome to turn off when you need to run Git in an automated setting. The credential helper interface learned to allow a helper to say stop, don't ask other helpers. Also GIT_TERMINAL_PROMPT environment can be set to false to disable our built-in prompt mechanism for passwords. * git branch -d (delete) and git branch -m (move) learned to honor -f (force) flag; unlike many other subcommands, the way to force these have been with separate -D/-M options, which was inconsistent. * diff-highlight filter (in contrib/) allows its color output to be customized via configuration variables. * git imap-send learned to take -v (verbose) and -q (quiet) command line options. * git remote add $name $URL is now allowed when url.$URL.insteadOf is already defined. * git imap-send now can be built to use cURL library to talk to IMAP servers (if the library is recent enough, of course). This allows you to use authenticate method other than CRAM-MD5, among other things. * git imap-send now allows GIT_CURL_VERBOSE environment variable to control the verbosity when talking via the cURL library. * The prompt script (in contrib/) learned to optionally hide prompt when in an ignored directory by setting GIT_PS1_HIDE_IF_PWD_IGNORED shell variable. Performance, Internal Implementation, Development Support etc. * Earlier we made rev-list --object-edge more aggressively list the objects at the edge commits, in order to reduce number of objects fetched into a shallow repository, but the change affected cases other than fetching into a shallow repository and made it unusably slow (e.g. fetching into a normal repository should not have to suffer the overhead from
[PATCH 0/2] gitfile support git git-gui
New patch series. I hadn't realized Git doesn't recurse on gitdir: ... links itself, it only follows one. Also normalizes the path to the Git repository as requested. Remi Rampin (2): Fixes chooser not accepting gitfiles Makes chooser set 'gitdir' to the resolved path lib/choose_repository.tcl | 21 ++--- 1 file changed, 18 insertions(+), 3 deletions(-) -- 1.9.5.msysgit.0 -- 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 1/2] Fixes chooser not accepting gitfiles
Makes _is_git handle the case where the path is a gitdir: ... file.
---
lib/choose_repository.tcl | 10 ++
1 file changed, 10 insertions(+)
diff --git a/lib/choose_repository.tcl b/lib/choose_repository.tcl
index 92d6022..abc6b1d 100644
--- a/lib/choose_repository.tcl
+++ b/lib/choose_repository.tcl
@@ -339,6 +339,16 @@ method _git_init {} {
}
proc _is_git {path} {
+ if {[file isfile $path]} {
+ set fp [open $path r]
+ gets $fp line
+ close $fp
+ if {[regexp ^gitdir: (.+)$ $line line link_target]} {
+ set path [file join [file dirname $path] $link_target]
+ set path [file normalize $path]
+ }
+ }
+
if {[file exists [file join $path HEAD]]
[file exists [file join $path objects]]
[file exists [file join $path config]]} {
--
1.9.5.msysgit.0
--
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 2/2] Makes chooser set 'gitdir' to the resolved path
If _is_git follows a gitdir: ... file link to get to the actual
repository, we want _gitdir to be set to that final path.
---
lib/choose_repository.tcl | 11 ---
1 file changed, 8 insertions(+), 3 deletions(-)
diff --git a/lib/choose_repository.tcl b/lib/choose_repository.tcl
index abc6b1d..75d1da8 100644
--- a/lib/choose_repository.tcl
+++ b/lib/choose_repository.tcl
@@ -338,7 +338,10 @@ method _git_init {} {
return 1
}
-proc _is_git {path} {
+proc _is_git {path {outdir_var }} {
+ if {$outdir_var ne } {
+ upvar 1 $outdir_var outdir
+ }
if {[file isfile $path]} {
set fp [open $path r]
gets $fp line
@@ -352,12 +355,14 @@ proc _is_git {path} {
if {[file exists [file join $path HEAD]]
[file exists [file join $path objects]]
[file exists [file join $path config]]} {
+ set outdir $path
return 1
}
if {[is_Cygwin]} {
if {[file exists [file join $path HEAD]]
[file exists [file join $path objects.lnk]]
[file exists [file join $path config.lnk]]} {
+ set outdir $path
return 1
}
}
@@ -1103,7 +1108,7 @@ method _open_local_path {} {
}
method _do_open2 {} {
- if {![_is_git [file join $local_path .git]]} {
+ if {![_is_git [file join $local_path .git] actualgit]} {
error_popup [mc Not a Git repository: %s [file tail
$local_path]]
return
}
@@ -1116,7 +1121,7 @@ method _do_open2 {} {
}
_append_recentrepos [pwd]
- set ::_gitdir .git
+ set ::_gitdir $actualgit
set ::_prefix {}
set done 1
}
--
1.9.5.msysgit.0
--
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
Re: [Qemu-devel] [PATCH v3 0/7] cpu: add device_add foo-x86_64-cpu support
[adding git list to cc] On 02/05/2015 04:49 AM, Stefan Hajnoczi wrote: On Wed, Jan 14, 2015 at 03:27:23PM +0800, Zhu Guihua wrote: This series is based on the previous patchset from Chen Fan: https://lists.nongnu.org/archive/html/qemu-devel/2014-05/msg02360.html This email has an invalid charset: Content-Type: text/plain; charset=y I guess you entered y when asked how the message was encoded. Please don't do that, it means we can only guess at the charset. In the past, people made a similar problem when 'git send-email' was asking if a message was in-reply-to something else (the number of messages incorrectly threaded to a message-id of 'y' or 'n' was evidence of the poor quality of the question). git.git commit 51bbccfd1b4a corrected that problem. Sounds like charset encoding is another case where the interactive parser should be taught to balk at nonsense encoding answers? -- Eric Blake eblake redhat com+1-919-301-3266 Libvirt virtualization library http://libvirt.org signature.asc Description: OpenPGP digital signature
Re: git tag --no-merged?
Kyle J. McKay:
I think something like this might do what you want:
git for-each-ref --format='%(refname)' refs/tags | \
while read t; do
if ! git merge-base --is-ancestor $t HEAD; then
echo ${t#refs/tags/}
fi
done
That works like a charm, thank you!
--
\\// Peter - http://www.softwolves.pp.se/
--
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
Re: Advice on edits to git-rebase man page
Matthew Brett matthew.br...@gmail.com writes: Obviously my page as it is now is very different in tone from the git-rebase page, but I think there are some aspects that could be fruitfully merged. Would you be interested in patches of this sort, or does the page seem too far from the intention of the man page? I think it is deliberate that manpages are not written as tutorial, but as more advanced technical documentation. Just like learning Unix can hardly be done by reading man ls, man cd, ... the best entry point to learn Git is not the manpages. OTOH, I usually like Git's manpages when I know what I'm looking for. All that being said, there's a lot of room for improvement in our manpages, event remaining in a technical-style. I'm not a good juge because I already learnt how rebase works long ago, but the git rebase man page does seem terrible for bare mortals: NAME git-rebase - Forward-port local commits to the updated upstream head = Quite technical already. DESCRIPTION If branch is specified, git rebase will perform an automatic git checkout branch before doing anything else. Otherwise it remains on the current branch. = Ouch, do we really want to start a documentation like this? So, the DESCRIPTION part can definitely be improved IMHO. Your notation graft-point, exclude-from and include-from may be an improvement already. Some concrete examples may help too, like I started developing against origin/foo, on local branch bar, and now want to rebase my work on top of origin/boz. My 2 cents, -- Matthieu Moy http://www-verimag.imag.fr/~moy/ -- 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
Re: Advice on edits to git-rebase man page
Matthieu Moy matthieu@grenoble-inp.fr writes: NAME git-rebase - Forward-port local commits to the updated upstream head = Quite technical already. Very much true, and I would say the description is technically correct in the sense that it is not wrong per-se. There are a few points that this fails to state and some that this overspecifies. - Rebase is about changing the base of an existing branch, but the description does not even mention the word branch [*1*]. - There is nothing forward about it. I often see myself applying (tentatively) incoming patches on top of whatever commit I happen to have checked out, review it and then rebasing it to apply to older maintenance track if the topic is about fixing an old bug. - There is no point stressing local commits; all the operations you do to munge commits are local. Perhaps something like this instead? git-rebase - Rebuild a branch on top of a different commit DESCRIPTION If branch is specified, git rebase will perform an automatic git checkout branch before doing anything else. Otherwise it remains on the current branch. = Ouch, do we really want to start a documentation like this? No. We should say what the command does and what the command is for in more general terms first and then describe how arguments can be used to affect it. So, the DESCRIPTION part can definitely be improved IMHO. Your notation graft-point, exclude-from and include-from may be an improvement already. graft-point, exclude-from and include-from aren't technically wrong per-se, but I do not think bulk-replacing the words currently used in the manual page with these is an improvement at all, unless the mental picture the explanation draws is also updated to match these new words. reBASE is about changing the base of the affected branch, and the mental picture the current documentation draws is there is a plant, from which you cut a branch, scion. Then you graft the scion onto understock. It calls the original tree (that the branch being transplanted is part of) the old-base, and the understock (that the scion is going to be grafted onto) the new-base. The word graft in graft point may better convey that we are doing a transplanting than the current wording, but the word point makes it unclear to the readers if it refers to the point where the scion was cut from or where it is going to transplanted to, I am afraid. Also exclude-from and include-from is probably too operational, and describing the command with only these two words would miss the point that the command is about transplanting a branch. It is true that in order to transplant a branch, you first need to figure out the set of commits whose effects are to be replayed, you would need exclude-from..include-from range computation, but it is an lower-level implemention detail. Some concrete examples may help too, like I started developing against origin/foo, on local branch bar, and now want to rebase my work on top of origin/boz. Very much so, but I wonder if it would be better to just refer to examples in the tutorial (and if we do not have good examples there, we should add some). [Footnote] *1* Yes, git rebase $newbase $commit^0 form can be used to transplant a part of history leading to the $commit that does not sit at the tip of a branch (nor repoint a branch to point at the result at the end) as if $commit^0 were at the tip of some branch, but the key word here is as if. The user is allowed to use the command pretending something that is not a branch is a branch, but what it tells us is that the command *is* about a branch. -- 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
Re: [PATCH 1/2] Makefile: Use the same source directory for ln -s as for ln / cp
On Feb 5, 2015, at 07:51, Sebastian Schuberth wrote: For consistency, we should use the same source for symbolic links as for hard links and copies. Signed-off-by: Sebastian Schuberth sschube...@gmail.com --- Makefile | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/Makefile b/Makefile index c44eb3a..21f23cb 100644 --- a/Makefile +++ b/Makefile @@ -2265,14 +2265,14 @@ endif $(RM) $$bindir/$$p \ test -z $(NO_INSTALL_HARDLINKS) \ ln $$bindir/git$X $$bindir/$$p 2/dev/null || \ -ln -s git$X $$bindir/$$p 2/dev/null || \ +ln -s $$bindir/git$X $$bindir/$$p 2/dev/null || \ This is wrong. Currently with symlinks you will get installed into bindir something like this: git git-tag - git git-show - git etc. With your change you would have git git-tag - /usr/local/libexec/git-core/git git-show - /usr/local/libexec/git-core/git And I don't think we want that. While those absolute path symlinks are technically correct, what we have now is much simpler. While there are a number of build-time paths hard-coded into the executables, the binaries work for the most part if you relocate them as a whole. Your change totally breaks that. -Kyle -- 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
Re: [PATCH 2/2] Makefile: Also add a symlink fallback to installing ALL_PROGRAMS
On Feb 5, 2015, at 07:52, Sebastian Schuberth wrote: We do this for BUILT_INS and REMOTE_CURL_ALIASES, so we should do so here, too. Signed-off-by: Sebastian Schuberth sschube...@gmail.com --- Makefile | 1 + 1 file changed, 1 insertion(+) diff --git a/Makefile b/Makefile index 21f23cb..d2849c3 100644 --- a/Makefile +++ b/Makefile @@ -2258,6 +2258,7 @@ endif $(RM) $$execdir/$$p \ test -z $(NO_INSTALL_HARDLINKS)$ (NO_CROSS_DIRECTORY_HARDLINKS) \ ln $$bindir/$$p $$execdir/$$p 2/dev/null || \ +ln -s $$bindir/$$p $$execdir/$$p 2/dev/null || \ Can we not start installing absolute path symlinks please. -Kyle -- 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
Re: [Qemu-devel] [PATCH v3 0/7] cpu: add device_add foo-x86_64-cpu support
Eric Blake ebl...@redhat.com writes: On 02/05/2015 04:49 AM, Stefan Hajnoczi wrote: On Wed, Jan 14, 2015 at 03:27:23PM +0800, Zhu Guihua wrote: This series is based on the previous patchset from Chen Fan: https://lists.nongnu.org/archive/html/qemu-devel/2014-05/msg02360.html This email has an invalid charset: Content-Type: text/plain; charset=y I guess you entered y when asked how the message was encoded. Please don't do that, it means we can only guess at the charset. In the past, people made a similar problem when 'git send-email' was asking if a message was in-reply-to something else (the number of messages incorrectly threaded to a message-id of 'y' or 'n' was evidence of the poor quality of the question). git.git commit 51bbccfd1b4a corrected that problem. Sounds like charset encoding is another case where the interactive parser should be taught to balk at nonsense encoding answers? I think I answered this in $gmane/263354; care to come up with a plausible valid_re? It is inpractical to attempt to cover all valid charset names, so whatever you do I'd imagine you would want to pass the confirm_only parameter set to true. -- 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
Re: Git gc removes all packs
On Thu, Feb 05, 2015 at 04:13:03PM +0100, Dmitry Neverov wrote: I'm using git p4 for synchronization with perforce. Sometimes after 'git p4 rebase' git starts a garbage collection. When gc finishes a local repository contains no pack files only loose objects, so I have to re-import repository from perforce. It also doesn't contain a temporary pack git gc was creating. It sounds like git didn't find any refs; it will pack only objects which are reachable. Unreachable objects are either: 1. Exploded into loose objects if the mtime on the pack they contain is less than 2 weeks old (and will eventually expire when they become 2 weeks old). 2. Dropped completely if older than 2 weeks. One more thing about my setup: since git p4 promotes a use of a linear history I use a separate repository for another branch in perforce. In order to be able to cherry-pick between repositories I added this another repo objects dir as an alternate and also added a ref which is a symbolic link to a branch in another repo (so I don't have to do any fetches). You can't symlink refs like this. The loose refs in the filesystem may be migrated into the packed-refs file, at which point your symlink will be broken. That is a likely reason why git would not find any refs. So your setup will not ever work reliably. But IMHO, it is a bug that git does not notice the broken symlink and abort an operation which is computing reachability in order to drop objects. As you noticed, it means a misconfiguration or filesystem error results in data loss. -Peff -- 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
Re: Bug report: Folder and files are deleted by git stash -u
Junio C Hamano gits...@pobox.com writes: Tobias Preuss tobias.pre...@googlemail.com writes: I noticed some bizarre behaviour when using: git stash -u. It deletes folders which contain files configured to be ignored. The files you mark as ignored are expendable and this is not limited to stash. ... Here is what should happen when you go to 'master': $ git checkout master Switched to branch 'master' $ /bin/ls -AF a .git/ .gitignore That is, a/file.c that is safely stored in 'side' branch is removed, a/file.o that is expendable is deleted, and the empty directory 'a' now can be replaced with the regular file 'a' the 'master' branch wants to have. Addendum 1. If *.o files are not treated expendable, you would be forced to make clean every time you switch between these two branches, which is unacceptable. Addendum 2. There was an old wishlist item to introduce another class of paths (in addition to the tracked, untracked and ignored) that are ignored-but-precious. Then *.o would still be expendable while a directory that must become a regular file with ignored-but-precious files in it would prevent switching from branch 'side' to 'master' in the illustration in the previous message in order to keep that ignored-but-precious file. But nobody needed such a feature badly enough to step up and implement it. cf. http://article.gmane.org/gmane.comp.version-control.git/185746 -- 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
Re: [PATCH 1/2] Makefile: Use the same source directory for ln -s as for ln / cp
On Thu, Feb 05, 2015 at 08:26:08PM +0100, Sebastian Schuberth wrote: It is not even correct, is it? When DESTDIR is set to allow you to install into a temporary place only so that you can tar up the resulting filesystem tree, bindir points at the location we need to cp the built programs into, i.e. inside DESTDIR. Agreed folks, please disregard this as well as 2/2 of this series. We would still want an equivalent to 2/2 to set up a relative symlink for $(ALL_PROGRAMS), though, right? -Peff -- 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
Re: [Qemu-devel] [PATCH v3 0/7] cpu: add device_add foo-x86_64-cpu support
On Thu, Feb 05, 2015 at 11:29:07AM -0800, Junio C Hamano wrote: Eric Blake ebl...@redhat.com writes: On 02/05/2015 04:49 AM, Stefan Hajnoczi wrote: On Wed, Jan 14, 2015 at 03:27:23PM +0800, Zhu Guihua wrote: This series is based on the previous patchset from Chen Fan: https://lists.nongnu.org/archive/html/qemu-devel/2014-05/msg02360.html This email has an invalid charset: Content-Type: text/plain; charset=y I guess you entered y when asked how the message was encoded. Please don't do that, it means we can only guess at the charset. In the past, people made a similar problem when 'git send-email' was asking if a message was in-reply-to something else (the number of messages incorrectly threaded to a message-id of 'y' or 'n' was evidence of the poor quality of the question). git.git commit 51bbccfd1b4a corrected that problem. Sounds like charset encoding is another case where the interactive parser should be taught to balk at nonsense encoding answers? I think I answered this in $gmane/263354; care to come up with a plausible valid_re? It is inpractical to attempt to cover all valid charset names, so whatever you do I'd imagine you would want to pass the confirm_only parameter set to true. Would length() 1 be enough[1]? Or are people really typing yes and not just y? I cannot imagine a charset name that is smaller than two characters. It may be that there are none smaller than 4, and we could cut it off there. Googling around for some lists of common charsets, it seems like that might be plausible (but not any larger; big5 is 4 characters, and people may spell utf8 without the hyphen). -Peff [1] Of course, to match the existing regex code, we may want to spell this as /../ or //. -- 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
Re: [PATCH 2/2] check-builtins: Strip any executable suffix to make it work on Windows
Sebastian Schuberth sschube...@gmail.com writes:
Signed-off-by: Sebastian Schuberth sschube...@gmail.com
---
check-builtins.sh | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/check-builtins.sh b/check-builtins.sh
index 07cff69..a0aaf3a 100755
--- a/check-builtins.sh
+++ b/check-builtins.sh
@@ -3,7 +3,7 @@
{
cat \EOF
sayIt:
-$(foreach b,$(BUILT_INS),echo XXX $b YYY;)
+$(foreach b,$(BUILT_INS),echo XXX $(b:$X=) YYY;)
EOF
Makes sense; thanks.
--
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
Re: [PATCH 1/2] Makefile: Improve wording in a comment
On Thu, Feb 5, 2015 at 11:22 AM, Sebastian Schuberth sschube...@gmail.com wrote: On Thu, Feb 5, 2015 at 8:19 PM, Sebastian Schuberth sschube...@gmail.com wrote: Is that an improvement? Is the plural of dup (used as an abbreviation of duplicate) dupes not dups? My view is that the abbreviation of duplicate is not dup but dupe, hence the plural dupes. For duplicate the noun, that is. For duplicate the verb I'd be ok with dup as the abbreviation. to dup sounds and looks better than to dupe :-) We could also not abbreviate that word to avoid discussion there. -- 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
Re: [Qemu-devel] [PATCH v3 0/7] cpu: add device_add foo-x86_64-cpu support
Jeff King p...@peff.net writes:
On Thu, Feb 05, 2015 at 11:29:07AM -0800, Junio C Hamano wrote:
Eric Blake ebl...@redhat.com writes:
On 02/05/2015 04:49 AM, Stefan Hajnoczi wrote:
On Wed, Jan 14, 2015 at 03:27:23PM +0800, Zhu Guihua wrote:
This series is based on the previous patchset from Chen Fan:
https://lists.nongnu.org/archive/html/qemu-devel/2014-05/msg02360.html
This email has an invalid charset:
Content-Type: text/plain; charset=y
I guess you entered y when asked how the message was encoded.
Please don't do that, it means we can only guess at the charset.
In the past, people made a similar problem when 'git send-email' was
asking if a message was in-reply-to something else (the number of
messages incorrectly threaded to a message-id of 'y' or 'n' was evidence
of the poor quality of the question). git.git commit 51bbccfd1b4a
corrected that problem. Sounds like charset encoding is another case
where the interactive parser should be taught to balk at nonsense
encoding answers?
I think I answered this in $gmane/263354; care to come up with a
plausible valid_re? It is inpractical to attempt to cover all valid
charset names, so whatever you do I'd imagine you would want to pass
the confirm_only parameter set to true.
Would length() 1 be enough[1]? Or are people really typing yes and
not just y?
I cannot imagine a charset name that is smaller than two characters. It
may be that there are none smaller than 4, and we could cut it off
there. Googling around for some lists of common charsets, it seems like
that might be plausible (but not any larger; big5 is 4 characters, and
people may spell utf8 without the hyphen).
-Peff
[1] Of course, to match the existing regex code, we may want to spell
this as /../ or //.
Perhaps. Just in case there were shorter ones, something like this
with confirm_only to allow them to say Yes, I do mean 'xx'?
git-send-email.perl | 1 +
1 file changed, 1 insertion(+)
diff --git a/git-send-email.perl b/git-send-email.perl
index 3092ab3..848f176 100755
--- a/git-send-email.perl
+++ b/git-send-email.perl
@@ -752,6 +752,7 @@ sub file_declares_8bit_cte {
print $f\n;
}
$auto_8bit_encoding = ask(Which 8bit encoding should I declare
[UTF-8]? ,
+ valid_re = qr/.{4}/, confirm_only = 1,
default = UTF-8);
}
--
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
Re: [PATCH 1/2] Makefile: Use the same source directory for ln -s as for ln / cp
On Thu, Feb 5, 2015 at 8:51 PM, Jeff King p...@peff.net wrote: On Thu, Feb 05, 2015 at 08:26:08PM +0100, Sebastian Schuberth wrote: It is not even correct, is it? When DESTDIR is set to allow you to install into a temporary place only so that you can tar up the resulting filesystem tree, bindir points at the location we need to cp the built programs into, i.e. inside DESTDIR. Agreed folks, please disregard this as well as 2/2 of this series. We would still want an equivalent to 2/2 to set up a relative symlink for $(ALL_PROGRAMS), though, right? Probably. But I'm not sure how to calculate the relative path correctly so that it'll work with all possible bin / execdir combinations. A simple diff --git a/Makefile b/Makefile index 21f23cb..d2849c3 100644 --- a/Makefile +++ b/Makefile @@ -2258,8 +2258,8 @@ endif $(RM)·$$execdir/$$p··\ test·-z·$(NO_INSTALL_HARDLINKS)$(NO_CROSS_DIRECTORY_HARDLINKS)··\ ln·$$bindir/$$p·$$execdir/$$p·2/dev/null·||·\ +ln·-s·../$$p·$$execdir/$$p·2/dev/null·||·\ cp·$$bindir/$$p·$$execdir/$$p·||·exit;·\ ··done;·\ }··\ --· does not seem to be correct in all cases. -- Sebastian Schuberth -- 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
Re: [PATCH 1/2] Makefile: Use the same source directory for ln -s as for ln / cp
On Feb 5, 2015, at 11:51, Jeff King wrote: On Thu, Feb 05, 2015 at 08:26:08PM +0100, Sebastian Schuberth wrote: It is not even correct, is it? When DESTDIR is set to allow you to install into a temporary place only so that you can tar up the resulting filesystem tree, bindir points at the location we need to cp the built programs into, i.e. inside DESTDIR. Agreed folks, please disregard this as well as 2/2 of this series. We would still want an equivalent to 2/2 to set up a relative symlink for $(ALL_PROGRAMS), though, right? It's this line here: ln $$bindir/$$p $$execdir/$$p 2/dev/null || \ But since bindir and execdir can be configured to be arbitrary paths you must compute the relative path between them in order to create a relative symlink. In principle you just remove the common directory prefix, remove the non-directory part from the destination, change any remaining directories in the destination to '..' and then append what's left of the source to get the new source. So if you have bindir=/usr/local/bin execdir=/usr/local/libexec/git-core And the ln line would be: ln /usr/local/bin/git /usr/local/libexec/git-core/git 1) Strip the common prefix which is /usr/local/ source = bin/git dest = libexec/git-core/git 2) remove non-directory part of dest (the basename part) and replace remaining dirs with '..' source = bin/git dest = ../../ 3) append source to dest and you get ../../bin/git So the symlink line becomes: ln -s ../../bin/git /usr/local/libexec/git-core/git Now, can you do that easily in a Makefile? ;) And lastly there's the issue of which should be the symlink and which should be the binary? Should /usr/local/bin/git be the symlink or the binary? If it's the binary, then /usr/local/libexec/git-core/git will be a symlink to it. But we're already installing several other symlinks to 'git' in /usr/local/libexec/git-core so they will need to traverse two symlinks to get to the binary rather than just the one. That seems suboptimal. On the other hand if /usr/local/bin/git becomes the symlink then we have a user-facing binary that's a symlink. As generally it's the bindir that ends up in the PATH. I'm not sure exactly why, but I think: On Jan 30, 2015, at 13:10, Junio C Hamano wrote: That would make me feel dirty. Having a user-facing binary that is actually a symlink can potentially cause problems on OS X if the binary it refers to locates its libraries using a relative path. Not sure if that's the case on other systems or not. Neither of these is probably a show-stopper (two-symlinks-to-binary or user-facing-symlink-binary) assuming the magic relative symlink computation can be worked out. But it does not surprise me that those items were allowed to skip making a symlink and just go directly to cp. -Kyle -- 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
Re: [PATCH] decimal_width: avoid integer overflow
Thanks (and thanks for ungetc one, too). -- 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
Re: [PATCH 1/2] Makefile: Use the same source directory for ln -s as for ln / cp
On Thu, Feb 05, 2015 at 09:29:04PM +0100, Sebastian Schuberth wrote: We would still want an equivalent to 2/2 to set up a relative symlink for $(ALL_PROGRAMS), though, right? Probably. But I'm not sure how to calculate the relative path correctly so that it'll work with all possible bin / execdir combinations. A simple diff --git a/Makefile b/Makefile index 21f23cb..d2849c3 100644 --- a/Makefile +++ b/Makefile @@ -2258,8 +2258,8 @@ endif $(RM)·$$execdir/$$p··\ test·-z·$(NO_INSTALL_HARDLINKS)$(NO_CROSS_DIRECTORY_HARDLINKS)··\ ln·$$bindir/$$p·$$execdir/$$p·2/dev/null·||·\ +ln·-s·../$$p·$$execdir/$$p·2/dev/null·||·\ cp·$$bindir/$$p·$$execdir/$$p·||·exit;·\ ··done;·\ }··\ --· does not seem to be correct in all cases. Ah, I see. Yeah, you'd have to calculate that relative path between $bindir and $execdir. We have C code already to do that (see relative_path() in path.c), so in theory you could build a wrapper during the build phase and then run: ln -s $(./my-wrapper $bindir $execdir)/$p $execdir/$p or something during the install phase. -Peff -- 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
