Re: [BUG] [PATCH] infinite loop due to broken symlink
On 25.3.2015 23:53 Michael Haggerty wrote:
On 03/23/2015 05:04 PM, Petr Stodulka wrote:
git goes into an infinite loop due to broken symlink (minimal reproducer
[0]). Affected code is in function
resolve_ref_unsafe in file refs.c - notice 'stat_ref'. There is comment
about problem with race condition, hovewer in that case it's regular broken
symlink which cause infinite loop.
Thanks for the bug report. I can confirm the problem. In fact, I noticed
the same problem when I was working on a refactoring in the area, but I
still haven't submitted those patches. Luckily, modern Git doesn't use
symlinks in the loose reference hierarchy, so most users will never
encounter this problem.
In fact I think it is only the open() call that can lead to the infinite
loop. Meanwhile, there is another problem caused by falling through the
symlink-handling code, namely that st reflects the lstat() of the
symlink rather than the stat() of the file that it points to.
My approach was to run stat() on the path if the symlink-handling code
falls through. You can see my work in progress in my GitHub repo [1].
Yes, I thought up about similar solution, but I wasn't sure about this way
because of race condition (I don't know well code of git yet). In the case
of approved lstat/stat patch, I am more familiar with this solution.
Possible patch could be something
like this:
---
diff --git a/refs.c b/refs.c
index e23542b..9efe8d2 100644
--- a/refs.c
+++ b/refs.c
@@ -1356,6 +1356,7 @@ static struct ref_dir *get_loose_refs(struct
ref_cache *refs)
/* We allow recursive symbolic refs. Only within reason, though */
#define MAXDEPTH 5
#define MAXREFLEN (1024)
+#define MAXLOOP 1024
/*
* Called by resolve_gitlink_ref_recursive() after it failed to read
@@ -1482,6 +1483,7 @@ const char *resolve_ref_unsafe(const char
*refname, int resolve_flags, unsigned
char buffer[256];
static char refname_buffer[256];
int bad_name = 0;
+int loop_counter = 0;
if (flags)
*flags = 0;
@@ -1546,7 +1548,8 @@ const char *resolve_ref_unsafe(const char
*refname, int resolve_flags, unsigned
if (S_ISLNK(st.st_mode)) {
len = readlink(path, buffer, sizeof(buffer)-1);
if (len 0) {
- if (errno == ENOENT || errno == EINVAL)
+ if (loop_counter++ MAXLOOP
+(errno == ENOENT || errno == EINVAL))
/* inconsistent with lstat;
retry */
goto stat_ref;
else
@@ -1579,7 +1582,7 @@ const char *resolve_ref_unsafe(const char
*refname, int resolve_flags, unsigned
*/
fd = open(path, O_RDONLY);
if (fd 0) {
- if (errno == ENOENT)
+ if (loop_counter++ MAXLOOP errno == ENOENT)
/* inconsistent with lstat; retry */
goto stat_ref;
else
---
If I understand well that simple check of broken symlink is not possible
due to race conditions.
This change also prevents the infinite loop, in fact in a more failproof
way that doesn't depend on errno values being interpreted correctly. I
would suggest a few stylistic changes, like for example here [2]. On the
other hand, this change doesn't solve the lstat()/stat() problem.
Nevertheless, I wouldn't object to a fix like this being accepted in
addition to the stat() fix when it's ready. It doesn't hurt to wear both
a belt *and* suspenders.
Michael
[1] https://github.com/mhagger/git, branch wip/refactor-resolve-ref.
See especially commit d2425d8ac8cf73494b318078b92f5b1c510a68fb.
[2] https://github.com/mhagger/git, branch ref-broken-symlinks
When stat/lstat is ready, probably this will not be valuable anymore,
but it
could be reliable 'stop' for some unexpected/unknown possibly ways in
future.
Petr.
--
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 v2] config.c: split some variables to $GIT_DIR/config.worktree
When you define $GIT_DIR/info/config.worktree, which contains of
gitignore-style patterns (*), config variables that match these
patterns will be saved in $GIT_DIR/config.worktree instead of
$GIT_DIR/config.
On the surface, they are just like any other variables. You can read
or modify them with `git config` command, or config_* API. Underneath,
they are always stored in $GIT_DIR/config.worktree instead of
$GIT_DIR/config (and never in $HOME/.gitconfig or /etc/gitconfig)
The reason for this split is, as the name implies, for
worktree-specific configuration. When the same repo is attached to
more than one worktree, we can't use $GIT_DIR/config to store worktree
specific stuff because it's shared across worktrees.
(*) Config variable names are separated by dots. However as this is a
quick and dirty patch to experiment with submodules and multiple
worktrees, you must substitute dots with slashes when writing these
patterns, for now. E.g. write remote/*/foo instead of remote.*.foo
Signed-off-by: Nguyễn Thái Ngọc Duy pclo...@gmail.com
---
Something for Max to play with if he's still experimenting with
multiple worktree support for submodules :-) It's far from perfect,
but good enough for this purpose.
Documentation/config.txt | 6 -
builtin/config.c | 8 ++
config.c | 67
t/t1300-repo-config.sh | 34
4 files changed, 114 insertions(+), 1 deletion(-)
diff --git a/Documentation/config.txt b/Documentation/config.txt
index 2700a1b..6d00f49 100644
--- a/Documentation/config.txt
+++ b/Documentation/config.txt
@@ -2,11 +2,15 @@ CONFIGURATION FILE
--
The Git configuration file contains a number of variables that affect
-the Git commands' behavior. The `.git/config` file in each repository
+the Git commands' behavior. The `.git/config` and `.git/config.worktree`
+files in each repository
is used to store the configuration for that repository, and
`$HOME/.gitconfig` is used to store a per-user configuration as
fallback values for the `.git/config` file. The file `/etc/gitconfig`
can be used to store a system-wide default configuration.
+If `.git/info/core.worktree` exists, it contains gitignore-style
+patterns. Variables that match these patterns can only be contained in
+`.git/config.worktree`.
The configuration variables are used by both the Git plumbing
and the porcelains. The variables are divided into sections, wherein
diff --git a/builtin/config.c b/builtin/config.c
index 8cc2604..4ca8fc2 100644
--- a/builtin/config.c
+++ b/builtin/config.c
@@ -555,6 +555,14 @@ int cmd_config(int argc, const char **argv, const char
*prefix)
usage_with_options(builtin_config_usage,
builtin_config_options);
}
+ /*
+* For set operations, --local could be either config or
+* config.worktree. Let config.c determine the path based on
+* config keys.
+*/
+ if (use_local_config actions != ACTION_LIST)
+ given_config_source.file = NULL;
+
if (actions == ACTION_LIST) {
check_argc(argc, 0, 0);
if (git_config_with_options(show_all_config, NULL,
diff --git a/config.c b/config.c
index 15a2983..f68eb6a 100644
--- a/config.c
+++ b/config.c
@@ -12,6 +12,7 @@
#include quote.h
#include hashmap.h
#include string-list.h
+#include dir.h
struct config_source {
struct config_source *prev;
@@ -37,6 +38,7 @@ struct config_source {
};
static struct config_source *cf;
+static struct exclude_list config_local;
static int zlib_compression_seen;
@@ -84,6 +86,34 @@ static long config_buf_ftell(struct config_source *conf)
return conf-u.buf.pos;
}
+static int is_config_local(const char *key_)
+{
+ static struct strbuf key = STRBUF_INIT;
+ static int loaded;
+ int i, dtype;
+
+ if (!loaded) {
+ add_excludes_from_file_to_list(git_path(info/config.worktree),
+ , 0, config_local, 0);
+ loaded = 1;
+ }
+
+ if (!config_local.nr)
+ return 0;
+
+ strbuf_reset(key);
+ strbuf_addstr(key, key_);
+ for (i = 0; i key.len; i++) {
+ if (key.buf[i] == '.')
+ key.buf[i] = '/';
+ else
+ key.buf[i] = tolower(key.buf[i]);
+ }
+ dtype = DT_REG;
+ return is_excluded_from_list(key.buf, key.len, , dtype,
+config_local) 0;
+}
+
#define MAX_INCLUDE_DEPTH 10
static const char include_depth_advice[] =
exceeded maximum include depth (%d) while including\n
@@ -1167,6 +1197,15 @@ int git_config_system(void)
return !git_env_bool(GIT_CONFIG_NOSYSTEM, 0);
}
+static int config_local_filter(const char *var, const char *value, void *data)
+{
+ struct config_include_data *inc = data;
+
+ if
[PATCH v2] gc: save log from daemonized gc --auto and print it next time
While commit 9f673f9 (gc: config option for running --auto in
background - 2014-02-08) helps reduce some complaints about 'gc
--auto' hogging the terminal, it creates another set of problems.
The latest in this set is, as the result of daemonizing, stderr is
closed and all warnings are lost. This warning at the end of cmd_gc()
is particularly important because it tells the user how to avoid gc
--auto running repeatedly. Because stderr is closed, the user does
not know, naturally they complain about 'gc --auto' wasting CPU.
Besides reverting 9f673f9 and looking at the problem from another
angle, we could save the stderr in $GIT_DIR/gc.log. Next time, 'gc
--auto' will print the saved warnings, delete gc.log and exit.
Signed-off-by: Nguyễn Thái Ngọc Duy pclo...@gmail.com
---
The test is dropped. It does not feel good enough.. The rest of
changes is minor
diff --git a/builtin/gc.c b/builtin/gc.c
index 07769a9..3886937 100644
--- a/builtin/gc.c
+++ b/builtin/gc.c
@@ -32,8 +32,6 @@ static int aggressive_window = 250;
static int gc_auto_threshold = 6700;
static int gc_auto_pack_limit = 50;
static int detach_auto = 1;
-static struct strbuf log_filename = STRBUF_INIT;
-static int daemonized;
static const char *prune_expire = 2.weeks.ago;
static struct argv_array pack_refs_cmd = ARGV_ARRAY_INIT;
@@ -43,6 +41,8 @@ static struct argv_array prune = ARGV_ARRAY_INIT;
static struct argv_array rerere = ARGV_ARRAY_INIT;
static char *pidfile;
+static struct strbuf log_filename = STRBUF_INIT;
+static int daemonized;
static void remove_pidfile(void)
{
@@ -338,7 +338,7 @@ int cmd_gc(int argc, const char **argv, const char
*prefix)
struct strbuf sb = STRBUF_INIT;
if (strbuf_read_file(sb, git_path(gc.log), 0) 0) {
- warning(_(Last gc run reported the following,
gc skipped));
+ warning(_(skipping gc; last gc reported:));
fputs(sb.buf, stderr);
strbuf_release(sb);
/* let the next gc --auto run as usual */
@@ -352,8 +352,7 @@ int cmd_gc(int argc, const char **argv, const char
*prefix)
* failure to daemonize is ok, we'll continue
* in foreground
*/
- if (!daemonize())
- daemonized = 1;
+ daemonized = !daemonize();
}
} else
add_repack_all_option();
builtin/gc.c | 36 +++-
1 file changed, 35 insertions(+), 1 deletion(-)
diff --git a/builtin/gc.c b/builtin/gc.c
index 5c634af..3886937 100644
--- a/builtin/gc.c
+++ b/builtin/gc.c
@@ -41,9 +41,20 @@ static struct argv_array prune = ARGV_ARRAY_INIT;
static struct argv_array rerere = ARGV_ARRAY_INIT;
static char *pidfile;
+static struct strbuf log_filename = STRBUF_INIT;
+static int daemonized;
static void remove_pidfile(void)
{
+ if (daemonized log_filename.len) {
+ struct stat st;
+
+ close(2);
+ if (stat(log_filename.buf, st) ||
+ !st.st_size ||
+ rename(log_filename.buf, git_path(gc.log)))
+ unlink(log_filename.buf);
+ }
if (pidfile)
unlink(pidfile);
}
@@ -324,13 +335,24 @@ int cmd_gc(int argc, const char **argv, const char
*prefix)
fprintf(stderr, _(See \git help gc\ for manual
housekeeping.\n));
}
if (detach_auto) {
+ struct strbuf sb = STRBUF_INIT;
+
+ if (strbuf_read_file(sb, git_path(gc.log), 0) 0) {
+ warning(_(skipping gc; last gc reported:));
+ fputs(sb.buf, stderr);
+ strbuf_release(sb);
+ /* let the next gc --auto run as usual */
+ unlink(git_path(gc.log));
+ return 0;
+ }
+
if (gc_before_repack())
return -1;
/*
* failure to daemonize is ok, we'll continue
* in foreground
*/
- daemonize();
+ daemonized = !daemonize();
}
} else
add_repack_all_option();
@@ -343,6 +365,18 @@ int cmd_gc(int argc, const char **argv, const char *prefix)
name, (uintmax_t)pid);
}
+ if (daemonized) {
+ int fd;
+
+ strbuf_addstr(log_filename, git_path(gc.log_XX));
+ fd = xmkstemp(log_filename.buf);
+ if (fd = 0) {
+
[PATCH] docs: Clarify preserve option wording for git-pull
Before this path, the also sounded as if preserve was doing a rebase as additional work that true would not do. Clarify this by saying still instead of also. Signed-off-by: Sebastian Schuberth sschube...@gmail.com --- Documentation/git-pull.txt | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/Documentation/git-pull.txt b/Documentation/git-pull.txt index d3d236c..96829be 100644 --- a/Documentation/git-pull.txt +++ b/Documentation/git-pull.txt @@ -111,8 +111,8 @@ include::merge-options.txt[] was rebased since last fetched, the rebase uses that information to avoid rebasing non-local changes. + -When preserve, also rebase the current branch on top of the upstream -branch, but pass `--preserve-merges` along to `git rebase` so that +When preserve, still rebase the current branch on top of the upstream +branch, but also pass `--preserve-merges` along to `git rebase` so that locally created merge commits will not be flattened. + When false, merge the current branch into the upstream branch. -- 1.9.5.msysgit.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
Re: very weird behaviour with
Kirill Marchuk 62mkv at mail.ru writes: Hi everyone I'm totally stuck with a following problem: (censor cut) ... But I believe that it might be due to my total misunderstanding of something Anyway, I totally appreciate your help ! Thanks a lot Kirill, frustrated unexperienced git user... Hi Again With git subtree today I have had even worse experience: 1) git checkout test 2) git branch test-tmp 3) mv adminUI adminUI2 (because otherwise errors..) 4) git commit -a -m Renamed adminUI 5) git subtree add --prefix=adminUI adminui-origin/test --squash 6) mv adminUI adminUI2 (because I don't want here the deploy versions) 7) git commit -a -m Added adminui as subtree 8) git merge develop (!! it went smoothly, but... see below) 9) git checkout adminui-test 10) git subtree merge --prefix=adminUI test-tmp 11) git push adminui-origin test-adminui:test (instead of 9-11 I've tried to use git subtree push, it's basically the same, I believe, only takes FAR more time to complete) I was very glad and happy. Unless I've realized that, in fact, step 7 did not proceed as it was intended to (by me, at least) It has 2 parents, and 2 diffs, and one of them shows exactly what it has to show (i.e. diff between tips of develop and test-tmp), but the files on the commit snapshot were left unchanged (I cannot imagine how could that happen, but that did) If I modify files and commit them RIGHT INTO test-tmp branch, all the rest goes fine (so far), but that unability to merge from develop is something that's killing the whole point of it :(( I believe I am not the only one on this mailing list, so pleeease... Kirill -- 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] merge: deprecate 'git merge message HEAD commit' syntax
On Wed, Mar 25, 2015 at 09:58:45PM -0700, Junio C Hamano wrote: We had this in git merge manual for eternity: 'git merge' msg HEAD commit... [This] syntax (msg `HEAD` commit...) is supported for historical reasons. Do not use it from the command line or in new scripts. It is the same as `git merge -m msg commit...`. It would be nice to see this ancient wart ago. I agree we need a deprecation period, though, as you've outlined here. builtin/merge.c | 1 + git-cvsimport.perl| 2 +- git-pull.sh | 2 +- t/t3402-rebase-merge.sh | 2 +- t/t6021-merge-criss-cross.sh | 6 +++--- t/t9402-git-cvsserver-refs.sh | 2 +- 6 files changed, 8 insertions(+), 7 deletions(-) Maybe squash in: diff --git a/t/t6020-merge-df.sh b/t/t6020-merge-df.sh index 27c3d73..2af1bee 100755 --- a/t/t6020-merge-df.sh +++ b/t/t6020-merge-df.sh @@ -24,7 +24,7 @@ test_expect_success 'prepare repository' ' ' test_expect_success 'Merge with d/f conflicts' ' - test_expect_code 1 git merge merge msg B master + test_expect_code 1 git merge -m merge msg master ' test_expect_success 'F/D conflict' ' We do not call it HEAD here, but the setup test just before has put us on branch B, so I think it is equivalent. -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: [PATCH v5 3/3] t0302: test credential-store support for XDG_CONFIG_HOME
Paul Tan pyoka...@gmail.com writes: On Wed, Mar 25, 2015 at 01:25:07PM -0700, Junio C Hamano wrote: Junio C Hamano gits...@pobox.com writes: I've already queued the following and merged it to 'next'. Thanks Matthieu and Eric for your reviews, and Johannes for following up on this. Will keep in view XDG support for ~/.git-credential-cache next because I don't like to leave things unfinished, unless we want to keep it around as a microproject. Perhaps home_config_paths() can also be simplified/removed because it hardcodes '~/.gitconfig'. I may be able to get some students to work on it in May-June (I teach in Ensimag, a french computer-science school and offer contribute to open-source as an end-of-year project), but no guarantee. If you want to do it before, just do it. -- 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: [RFC] git submodule purge
On Wed, Mar 25, 2015 at 08:47:59PM +0100, Jens Lehmann wrote: Am 25.03.2015 um 10:06 schrieb Patrick Steinhardt: On Mon, Mar 23, 2015 at 10:32:27PM +0100, Jens Lehmann wrote: Am 17.03.2015 um 08:56 schrieb Patrick Steinhardt: [snip] Hmm, cmd_deinit() seems to cope with submodules removed by the user just fine (as long as they are still present in the index). To me it feels natural to extend deinit to remove the repo from .git/modules too when --purge is given (as long as no unpushed commits are present or -f is given). `git gc` feels saner in that regard, but I don't think it would be easy to spot for users as this command is in general not used very frequently by them. One could argue though that it does not need to be discoverable. The error message of git submodule deinit --purge for a submodule that isn't recorded in the index anymore could point the user to the appropriate gc command. But how do we tell gc which submodule it should purge? --purge=submodule-name maybe? This might work, but at least the option would need to provide a hint to the user that it has something to do with submodules. So if the feature was implemented by `git gc` I'd rather name the parameter --purge-submodule=submodule-name which in my opinion clearly states its intention, even though it is longer to type. But with working bash-completion this should be non-issue, especially as this command would not need to be run frequently. Agreed. That said, I think by now I agree with the common (?) opinion that the command is best placed in `git submodule deinit --purge` and I will likely implement it there. Me thinks that makes sense. But be aware that this will only work for those submodules that are still present in the current index. Optionally I could implement `git gc --purge-submodule=submodule-name` as a second way to access the feature so that we have a way of purging them without using the submodules-interface. I doubt though that this will provide much of a benefit as the user still has to be aware that he is working with submodules as he has to provide the `--purge-submodule` option, so there is not much to be gained by this. Hmm, I still believe cleaning up a submodule repo which is already deinited makes sense. Using 'rm -rf .git/modules/submodulename' will work just fine, but is missing any safeguards. The deinit command takes submodule paths, not submodule names. So it looks to me like 'git gc --purge-submodule=submodule-name' would make sense here (and this command should check that the submodule has already been deinited and fail otherwise telling the user so). Ah, okay. I thought your intention was to provide `git gc --purge-sm` _instead_ of `git sm deinit --purge`. Guess it makes sense to have both available for the different use cases (explicitly removing a submodule vs removing unreferenced ones). I guess one could even provide another option `--purge-submodules` in addition to `--purge-sm=smname` that will remove all deinitialized submodules without local commits. Maybe its desirable to have a `--dry-run` flag as well that would print which repositories would be deleted by `--purge-sms`. Patrick signature.asc Description: PGP signature
[PATCH] docs: Clarify what git-rebase's --preserve-merges does
Ignoring a merge sounds like ignoring the changes a merge commit introduces altogether, as if the merge commit was skipped or dropped from history. But that is not what happens if this options is not specified. Instead, what happens is that the separate commits a merge commit introduces are replayed in order, and only any possible merge conflict resolutions are ignored. Get this straight in the docs. Also, do not say that merge commits are *tried* to be recreated. They are recreated, but possibly with conflicts, which in turn are likely to be different from any original conflicts. Still recreating a merge commit does not just silently fail in any case, which is how try to recreate might sound. Signed-off-by: Sebastian Schuberth sschube...@gmail.com --- Documentation/git-rebase.txt | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/Documentation/git-rebase.txt b/Documentation/git-rebase.txt index d728030..3a6d139 100644 --- a/Documentation/git-rebase.txt +++ b/Documentation/git-rebase.txt @@ -362,7 +362,7 @@ default is `--no-fork-point`, otherwise the default is `--fork-point`. -p:: --preserve-merges:: -Instead of ignoring merges, try to recreate them. +Recreate merge commits instead of replaying commits a merge commit introduces. + This uses the `--interactive` machinery internally, but combining it with the `--interactive` option explicitly is generally not a good -- 1.9.5.msysgit.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
Re: What's cooking in git.git (Mar 2015, #08; Mon, 23)
On Tue, Mar 24, 2015 at 03:21:24PM -0700, Junio C Hamano wrote: * pw/remote-set-url-fetch (2014-11-26) 1 commit - remote: add --fetch and --both options to set-url This has not seen any activity for a few months since $gmane/261483; is anybody still interested in resurrecting it? I actually thought this had been merged. I was happy enough with the v4 you linked above, though it looks like you had some minor-ish comments. I do not personally have a big interest in it and wasn't planning anything else on it. But if Peter is still interested, I think it is close to ready, and I'd be happy to do another round of review. -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: [PATCH v2] gc: save log from daemonized gc --auto and print it next time
Nguyễn Thái Ngọc Duy pclo...@gmail.com writes:
While commit 9f673f9 (gc: config option for running --auto in
background - 2014-02-08) helps reduce some complaints about 'gc
--auto' hogging the terminal, it creates another set of problems.
The latest in this set is, as the result of daemonizing, stderr is
closed and all warnings are lost. This warning at the end of cmd_gc()
is particularly important because it tells the user how to avoid gc
--auto running repeatedly. Because stderr is closed, the user does
not know, naturally they complain about 'gc --auto' wasting CPU.
Besides reverting 9f673f9 and looking at the problem from another
angle, we could save the stderr in $GIT_DIR/gc.log. Next time, 'gc
--auto' will print the saved warnings, delete gc.log and exit.
Signed-off-by: Nguyễn Thái Ngọc Duy pclo...@gmail.com
---
The test is dropped. It does not feel good enough.. The rest of
changes is minor
I still wonder what this buys us if multiple auto-gc's are triggered,
because the user is running a long svn import or something similar.
I cannot tell what problem this is trying to solve.
(1) If the error output from the previous gc --auto indicates a
grave error condition that further re-running of gc --auto is
pointless, why is it a good idea to blindly remove the log and
let the next one run as usual?
(2) If the problem it is trying to solve is that gc --auto
sometimes gives a good suggestion but that is lost when
daemonized, why not address that problem in a more direct way,
e.g. introduce a new option gc --probe-auto that only checks
and reports if gc --auto would spend actual cycles to do its
work, and then run the daemonized version of gc --auto when
necessary? Either gc --probe-auto itself or the caller of
gc --probe-auto can give the you should do this to avoid
repeated auto-gc when this happens.
Also the same issue I have with (1) above applies; I do not see
much linkage with solving this issue with halving the frequency
of running gc --auto which is what this patch does.
In other words, I would understand what the change is trying to
achieve if it were to always stop, instruct the user to take
corrective action, and never remove the .log file itself (naturally,
the corrective action would include remove the .log when you are
done). I do not necessarily agree that it would be a good change
for the overall system, but at least such a change is internally
consistent between its perception of a problem and its approach to
solve it.
I would also understand, and I suspect I would prefer it if I see
the result, if the change were to allow gc --auto to report
severity of its findings (i.e. nothing wrong in your repository but
you should do X to avoid triggering me too often vs no point
running me again and again), do something similar to what this
patch does and after showing the message and (1) stop without
removing the log but give instruction when the situation is grave,
or (2) show the message, remove the .log, and continue to go ahead
with gc --auto when the situation is *not* grave.
But the approach taken by this patch looks very confused about its
own purpose to me and I cannot quite tell what it is trying to
solve.
diff --git a/builtin/gc.c b/builtin/gc.c
index 07769a9..3886937 100644
--- a/builtin/gc.c
+++ b/builtin/gc.c
@@ -32,8 +32,6 @@ static int aggressive_window = 250;
static int gc_auto_threshold = 6700;
static int gc_auto_pack_limit = 50;
static int detach_auto = 1;
-static struct strbuf log_filename = STRBUF_INIT;
-static int daemonized;
static const char *prune_expire = 2.weeks.ago;
static struct argv_array pack_refs_cmd = ARGV_ARRAY_INIT;
@@ -43,6 +41,8 @@ static struct argv_array prune = ARGV_ARRAY_INIT;
static struct argv_array rerere = ARGV_ARRAY_INIT;
static char *pidfile;
+static struct strbuf log_filename = STRBUF_INIT;
+static int daemonized;
static void remove_pidfile(void)
{
@@ -338,7 +338,7 @@ int cmd_gc(int argc, const char **argv, const char
*prefix)
struct strbuf sb = STRBUF_INIT;
if (strbuf_read_file(sb, git_path(gc.log), 0) 0) {
- warning(_(Last gc run reported the following,
gc skipped));
+ warning(_(skipping gc; last gc reported:));
fputs(sb.buf, stderr);
strbuf_release(sb);
/* let the next gc --auto run as usual */
@@ -352,8 +352,7 @@ int cmd_gc(int argc, const char **argv, const char
*prefix)
* failure to daemonize is ok, we'll continue
* in foreground
*/
- if (!daemonize())
- daemonized = 1;
+ daemonized = !daemonize();
Re: [PATCH] docs: Clarify preserve option wording for git-pull
Sebastian Schuberth sschube...@gmail.com writes: Before this path, the also sounded as if preserve was doing a rebase as additional work that true would not do. Clarify this by saying still instead of also. I agree that the original also is confusing. I however wonder if we even want still, though. For that matter, I doubt if we even want also in front of pass. When set to preserve, rebase and pass the extra flag sounds as clear as, if not clearer than, When set to preserve, still rebase and also pass the extra flag, at least to me. Thanks. Signed-off-by: Sebastian Schuberth sschube...@gmail.com --- Documentation/git-pull.txt | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/Documentation/git-pull.txt b/Documentation/git-pull.txt index d3d236c..96829be 100644 --- a/Documentation/git-pull.txt +++ b/Documentation/git-pull.txt @@ -111,8 +111,8 @@ include::merge-options.txt[] was rebased since last fetched, the rebase uses that information to avoid rebasing non-local changes. + -When preserve, also rebase the current branch on top of the upstream -branch, but pass `--preserve-merges` along to `git rebase` so that +When preserve, still rebase the current branch on top of the upstream +branch, but also pass `--preserve-merges` along to `git rebase` so that locally created merge commits will not be flattened. + When false, merge the current branch into the upstream 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: [RFC/GSoC] Proposal Draft: Unifying git branch -l, git tag -l, and git for-each-ref
On Mon, Mar 23, 2015 at 06:39:20PM +0530, karthik nayak wrote: All three commands select a subset of the repository’s refs and print the result. There has been an attempt to unify these commands by Jeff King[3]. I plan on continuing his work[4] and using his approach to tackle this project. I would be cautious about the work in my for-each-ref-contains-wip branch. At one point it was reasonably solid, but it's now a year and a half old, and I've been rebasing it without paying _too_ much attention to correctness. I think some subtle bugs have been introduced as it has been carried forward. Also, the very first patch (factoring out the contains traversal) is probably better served by this series: http://thread.gmane.org/gmane.comp.version-control.git/252472 I don't remember all of the issues offhand that need to be addressed in it, but there were plenty of review comments. For extended selection behaviour such as ‘--contains’ or ‘--merged’ we could implement these within the library by providing functions which closely mimic the current methods used individually by ‘branch -l’ and ‘tag -l’. For eg to implement ‘--merged’ we implement a ‘compute_merge()’ function, which with the help of the revision API’s will be able to perform the same function as ‘branch -l --merged’. One trick with making a library-like interface is that some of the selection routines can work on a streaming list of refs (i.e., as we see each ref we can say yes or no) and some must wait until the end (e.g., --merged does a single big merge traversal). It's probably not the end of the world to just always collect all the refs, then filter them, then sort them, then print them. It may delay the start of output in some minor cases, but I doubt that's a big deal (and anyway, the packed-refs code will load them all into an array anyway, so collecting them in a second array is probably not a big deal). For formatting functionality provided by ‘for-each-ref’ we replicate the ‘show_ref’ function in ‘for-each-ref.c’ where the format is given to the function and the function uses the format to obtain atom values and prints the corresponding atom values to the screen. This feature would allow us to provide format functionality which could act as a base for the ‘-v’ option also. Yeah, I'd really like to see --format for git branch, and have -v just feed that a hard-coded format string (or even a configurable one). Although Jeff has built a really good base to build upon, I shall use his work as more of a reference and work on unification of the three commands from scratch. Good. :) -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: [PATCH] clone: Warn if clone lacks LICENSE or COPYING file
On Sat, Mar 21, 2015 at 02:06:33PM -0400, David A. Wheeler wrote: Warn cloners if there is no LICENSE* or COPYING* file that makes the license clear. This is a useful warning, because if there is no license somewhere, then local copyright laws (which forbid many uses) and terms of service apply - and the cloner may not be expecting that. Many projects accidentally omit a license, so this is common enough to note. For more info on the issue, feel free to see: http://choosealicense.com/no-license/ http://www.wired.com/2013/07/github-licenses/ https://twitter.com/stephenrwalli/status/247597785069789184 LWN article that lead to this patch: https://lwn.net/Articles/636261/ -- 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 5/5] gitweb: make category headings into links when they are directories
Any comments from those who use or have their own code in Gitweb on this topic? * tf/gitweb-project-listing (2015-03-19) 5 commits - gitweb: make category headings into links when they are directories - gitweb: optionally set project category from its pathname - gitweb: add a link under the search box to clear a project filter - gitweb: if the PATH_INFO is incomplete, use it as a project_filter - gitweb: fix typo in man page Update gitweb to make it more pleasant to deal with a hierarchical forest of repositories. -- 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] docs: Clarify preserve option wording for git-pull
Thanks; this time I do not see whitespace breakages ;-) Will queue with a minimum tweak of the log message. -- 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] docs: Clarify what git-rebase's --preserve-merges does
On 26.03.2015 19:18, Junio C Hamano wrote: Also, do not say that merge commits are *tried* to be recreated. Good point. We will try but it might fail is better left unsaid as that is true almost everywhere. Exactly. -p:: --preserve-merges:: -Instead of ignoring merges, try to recreate them. +Recreate merge commits instead of replaying commits a merge commit introduces. Hmm, is this line-wrapped? Probably, I had to send this via GMail. Although I fully agree that the new text is better than the original, I think the new text fails to point out one major aspect by not mentioning linear or flatten anywhere. The point of git rebase without -p is not just to replay but to flatten Instead of flattening the history by replaying each non-merge commit to be rebased, preserve the shape of the rebased history by recreating merge commits as well. or something along that line, perhaps? Hm, I'm not sure about the as well here. Non-merge commits basically are just picked, not recreated in the same sense as merge commits. I'll come up with another proposal. I think the current preserve-merges considers everything between upstream and branch as commits to be rebased, and recreate merges across these rebased tips of branches that are merged. There however were repeated wishes (or wishful misunderstandings ;-) that there were a mode to rebuild the trunk, considering only the commits on the first-parent chain as commits to be rebased, recreating the history by replaying the merge commits (whose first parent might be rewritten during the rebase, but the tips of side branches these merges bring into the history are kept intact). I guess I'm a victim of that wishful misunderstanding then, as I indeed though that's exactly what the current -p is doing. Well, modulo the special case where the second parent is the tip of a branch whose fork-point with the trunk is part of the rebase, see Example 1 at [1]. In other word, you're saying that the current preserve-merges does not keep the tips of side branches intact. If that's so, what is is doing with the tips of the side branches? without such a feature in the system, I would be happier if we made sure that the description we are discussing to update makes it clear that the current behaviour is everything between upstream and branch, and cannot be misread as do not touch side branches instead of dropping merged commits. Agreed. As soon as I understand the difference between the two :-) [1] http://stackoverflow.com/a/15915431/1127485 -- 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] docs: Clarify preserve option wording for git-pull
Before this path, the also sounded as if preserve was doing a rebase as additional work that true would not do. Clarify this by omitting the also and rewording the sentence a bit. Signed-off-by: Sebastian Schuberth sschube...@gmail.com --- Documentation/git-pull.txt | 5 ++--- 1 file changed, 2 insertions(+), 3 deletions(-) diff --git a/Documentation/git-pull.txt b/Documentation/git-pull.txt index d3d236c..712ab4b 100644 --- a/Documentation/git-pull.txt +++ b/Documentation/git-pull.txt @@ -111,9 +111,8 @@ include::merge-options.txt[] was rebased since last fetched, the rebase uses that information to avoid rebasing non-local changes. + -When preserve, also rebase the current branch on top of the upstream -branch, but pass `--preserve-merges` along to `git rebase` so that -locally created merge commits will not be flattened. +When set to preserve, rebase with the `--preserve-merges` option passed +to `git rebase` so that locally created merge commits will not be flattened. + When false, merge the current branch into the upstream branch. + -- 1.9.5.msysgit.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
Re: About GSoc idea.
On Wed, Mar 25, 2015 at 08:36:41PM +0530, Shanti Swarup Tunga wrote: Duy Nguyen and Stephen Robin , the two developers worked on converting git-pull.sh to C code . But in the idea page it is written that we should start with git-pull.sh. Should I worked on git-pull.sh or other shell script for the GSoc. You don't have to start with git-pull; the ideas page is mostly about suggesting a direction. However, my impression was that the work that has been done so far on git-pull is far from complete (I didn't look at it closely, though). So there may be more to do there, too. -Peff PS You may try cc-ing people relevant to what you're posting, which is a good way of making sure you get their attention. -- 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] docs: Clarify what git-rebase's --preserve-merges does
Sebastian Schuberth sschube...@gmail.com writes: Also, do not say that merge commits are *tried* to be recreated. Good point. We will try but it might fail is better left unsaid as that is true almost everywhere. Signed-off-by: Sebastian Schuberth sschube...@gmail.com --- Documentation/git-rebase.txt | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/Documentation/git-rebase.txt b/Documentation/git-rebase.txt index d728030..3a6d139 100644 --- a/Documentation/git-rebase.txt +++ b/Documentation/git-rebase.txt @@ -362,7 +362,7 @@ default is `--no-fork-point`, otherwise the default is `--fork-point`. -p:: --preserve-merges:: -Instead of ignoring merges, try to recreate them. +Recreate merge commits instead of replaying commits a merge commit introduces. Hmm, is this line-wrapped? Although I fully agree that the new text is better than the original, I think the new text fails to point out one major aspect by not mentioning linear or flatten anywhere. The point of git rebase without -p is not just to replay but to flatten Instead of flattening the history by replaying each non-merge commit to be rebased, preserve the shape of the rebased history by recreating merge commits as well. or something along that line, perhaps? This reminds me a related tangent discussion we had long time ago (I thought j6t was involved hence a new Cc:, but my apologies to j6t if I am misremembering), about what exactly is recreate merges instead of replaying commits. I think the current preserve-merges considers everything between upstream and branch as commits to be rebased, and recreate merges across these rebased tips of branches that are merged. There however were repeated wishes (or wishful misunderstandings ;-) that there were a mode to rebuild the trunk, considering only the commits on the first-parent chain as commits to be rebased, recreating the history by replaying the merge commits (whose first parent might be rewritten during the rebase, but the tips of side branches these merges bring into the history are kept intact). Surely there is no such mode right now, but I am fairly sure that I wouldn't have any objection against a patch to implement such a feature (perhaps --first-parent --preserve-merges?), and with or without such a feature in the system, I would be happier if we made sure that the description we are discussing to update makes it clear that the current behaviour is everything between upstream and branch, and cannot be misread as do not touch side branches instead of dropping merged commits. + This uses the `--interactive` machinery internally, but combining it with the `--interactive` option explicitly is generally not a good -- 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] git-push.txt: clean up force-with-lease wording
Phil Hord ho...@cisco.com writes: The help text for the --force-with-lease option to git-push does not parse cleanly. Clean up the wording and syntax to be more sensible. Also remove redundant information in the --force-with-lease alone description. Signed-off-by: Phil Hord ho...@cisco.com --- Thanks. The updated text reads well. Will queue. Documentation/git-push.txt | 14 ++ 1 file changed, 6 insertions(+), 8 deletions(-) diff --git a/Documentation/git-push.txt b/Documentation/git-push.txt index 5171086..863c30c 100644 --- a/Documentation/git-push.txt +++ b/Documentation/git-push.txt @@ -157,9 +157,8 @@ already exists on the remote side. Usually, git push refuses to update a remote ref that is not an ancestor of the local ref used to overwrite it. + -This option bypasses the check, but instead requires that the -current value of the ref to be the expected value. git push -fails otherwise. +This option overrides this restriction if the current value of the +remote ref is the expected value. git push fails otherwise. + Imagine that you have to rebase what you have already published. You will have to bypass the must fast-forward rule in order to @@ -171,15 +170,14 @@ commit, and blindly pushing with `--force` will lose her work. This option allows you to say that you expect the history you are updating is what you rebased and want to replace. If the remote ref still points at the commit you specified, you can be sure that no -other people did anything to the ref (it is like taking a lease on -the ref without explicitly locking it, and you update the ref while -making sure that your earlier lease is still valid). +other people did anything to the ref. It is like taking a lease on +the ref without explicitly locking it, and the remote ref is updated +only if the lease is still valid. + `--force-with-lease` alone, without specifying the details, will protect all remote refs that are going to be updated by requiring their current value to be the same as the remote-tracking branch we have -for them, unless specified with a `--force-with-lease=refname:expect` -option that explicitly states what the expected value is. +for them. + `--force-with-lease=refname`, without specifying the expected value, will protect the named ref (alone), if it is going to be updated, by -- 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 5/5] gitweb: make category headings into links when they are directories
On 26 Mar 2015, at 19:49, Junio C Hamano gits...@pobox.com wrote: Any comments from those who use or have their own code in Gitweb on this topic? Thanks for chasing up my patches. I should have written a covering letter, to say that you can see these patches in action at https://git.csx.cam.ac.uk/x/ucs/ - try clicking on the category headings, and observe the pathinfo, breadcrumbs, and links under the search box. Tony. -- f.anthony.n.finch d...@dotat.at http://dotat.at-- 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: What's cooking in git.git (Sep 2014, #01; Tue, 2)
That’s great dear, can you share link for those cooking videos http://grokker.com/cooking too. Actually I am a new learner and I need detailed information to execute everything properly. Thanks in advance for your help. -- View this message in context: http://git.661346.n2.nabble.com/What-s-cooking-in-git-git-Sep-2014-01-Tue-2-tp7617955p7627922.html Sent from the git mailing list archive at Nabble.com. -- 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] merge: deprecate 'git merge message HEAD commit' syntax
On Thu, Mar 26, 2015 at 12:58 AM, Junio C Hamano gits...@pobox.com wrote:
We had this in git merge manual for eternity:
'git merge' msg HEAD commit...
[This] syntax (msg `HEAD` commit...) is supported for
historical reasons. Do not use it from the command line or in
new scripts. It is the same as `git merge -m msg commit...`.
I wanted to see how much damage we would incur to people by checking
what the damage to _our_ system, including the test scripts, if we
dropped the support for the syntax. The last time I tried this, I
thought that replacing the use of this syntax in git pull with its
obvious and trivial rewrite 'git merge -m msg commit' broke some
output, and that is the primary reason why I stayed away from trying
this again, but it no longer seems to be the case with today's code
for some reason.
There are quite a few fallouts in the test scripts, and it turns out
that git cvsimport also uses this old syntax to record a merge.
Judging from this result, I would not be surprised if dropping the
support of the old syntax broke scripts people have written and been
relying on for the past ten years. But at least we can start the
deprecation process by throwing a warning message when the syntax is
used.
With luck, we might be able to drop the support in a few years.
Signed-off-by: Junio C Hamano gits...@pobox.com
---
diff --git a/builtin/merge.c b/builtin/merge.c
index 3b0f8f9..0795358 100644
--- a/builtin/merge.c
+++ b/builtin/merge.c
@@ -1182,6 +1182,7 @@ int cmd_merge(int argc, const char **argv, const char
*prefix)
if (!have_message head_commit
is_old_style_invocation(argc, argv, head_commit-object.sha1)) {
+ warning(old-style 'git merge msg HEAD commit' is
deprecated.);
To be a bit more helpful, perhaps point the user at git merge -m
msg commit... as the recommended replacement?
strbuf_addstr(merge_msg, argv[0]);
head_arg = argv[1];
argv += 2;
--
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: A good time to pull from your gitk tree?
On 15-03-24 07:06 PM, Paul Mackerras wrote: On Mon, Mar 23, 2015 at 12:03:37PM -0700, Junio C Hamano wrote: Is it a good time for me to pull from you, or do you recommend me to wait for a bit, expecting more? We'll go in the pre-release freeze soon-ish, so I thought I should ping. Now is a good time to pull from the usual place, thanks. Paul, could you react to the gitk window-title patches I've posted: http://news.gmane.org/find-root.php?group=gmane.comp.version-control.gitarticle=262080 Thanks! 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
[PATCH] Fix two typos
Signed-off-by: Thomas Ackermann th.ac...@arcor.de --- Documentation/RelNotes/2.4.0.txt | 2 +- Documentation/technical/api-error-handling.txt | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-) diff --git a/Documentation/RelNotes/2.4.0.txt b/Documentation/RelNotes/2.4.0.txt index 386c75d..cdfd578 100644 --- a/Documentation/RelNotes/2.4.0.txt +++ b/Documentation/RelNotes/2.4.0.txt @@ -296,7 +296,7 @@ notes for details). (merge 35840a3 jc/conf-var-doc later to maint). * An earlier workaround to squelch unhelpful deprecation warnings - from the complier on Mac OSX unnecessarily set minimum required + from the compiler on Mac OSX unnecessarily set minimum required version of the OS, which the user might want to raise (or lower) for other reasons. (merge 88c03eb es/squelch-openssl-warnings-on-macosx later to maint). diff --git a/Documentation/technical/api-error-handling.txt b/Documentation/technical/api-error-handling.txt index fc68db1..ceeedd4 100644 --- a/Documentation/technical/api-error-handling.txt +++ b/Documentation/technical/api-error-handling.txt @@ -58,7 +58,7 @@ to `die` or `error` as-is. For example: if (ref_transaction_commit(transaction, err)) die(%s, err.buf); -The 'err' parameter will be untouched if no error occured, so multiple +The 'err' parameter will be untouched if no error occurred, so multiple function calls can be chained: t = ref_transaction_begin(err); -- 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: [RFC] git submodule purge
Am 26.03.2015 um 14:30 schrieb Patrick Steinhardt: On Wed, Mar 25, 2015 at 08:47:59PM +0100, Jens Lehmann wrote: Am 25.03.2015 um 10:06 schrieb Patrick Steinhardt: Optionally I could implement `git gc --purge-submodule=submodule-name` as a second way to access the feature so that we have a way of purging them without using the submodules-interface. I doubt though that this will provide much of a benefit as the user still has to be aware that he is working with submodules as he has to provide the `--purge-submodule` option, so there is not much to be gained by this. Hmm, I still believe cleaning up a submodule repo which is already deinited makes sense. Using 'rm -rf .git/modules/submodulename' will work just fine, but is missing any safeguards. The deinit command takes submodule paths, not submodule names. So it looks to me like 'git gc --purge-submodule=submodule-name' would make sense here (and this command should check that the submodule has already been deinited and fail otherwise telling the user so). Ah, okay. I thought your intention was to provide `git gc --purge-sm` _instead_ of `git sm deinit --purge`. Guess it makes sense to have both available for the different use cases (explicitly removing a submodule vs removing unreferenced ones). Yup. And I wonder if `--purge` should be the default for deinit if no unpushed commits will be lost ... but let's hear what others think about this one. I guess one could even provide another option `--purge-submodules` in addition to `--purge-sm=smname` that will remove all deinitialized submodules without local commits. Maybe its desirable to have a `--dry-run` flag as well that would print which repositories would be deleted by `--purge-sms`. Hmm, thinking about that some more maybe we might wanna simplify this a bit. Adding a `--prune-submodules` option to gc which will remove all deinitialized submodules repos that don't have any unpushed commits should be sufficient to do the housekeeping. If people demand to be able to prune specific submodules later we could still add a `--prune-submodule=name`, but I suspect we might not need 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
[PATCH V2/RFC][GSoC] diff-no-index: transform $directory $file args to $directory/$file $file
git diff --no-index refuses to compare if args are directory and file,
instead of usual diff.
Now git diff --no-index modifies args, if they're directory and file,
and diffs files, as usual diff does.
Changes are done in diff_no_index().
Helped-by: Junio C Hamano gits...@pobox.com
Signed-off-by: Yurii Shevtsov unge...@gmail.com
---
diff-no-index.c | 31 +--
1 files changed, 29 insertions(+), 2 deletions(-)
diff --git a/diff-no-index.c b/diff-no-index.c
index 265709b..ecff15e 100644
--- a/diff-no-index.c
+++ b/diff-no-index.c
@@ -186,7 +186,7 @@ void diff_no_index(struct rev_info *revs,
int argc, const char **argv,
const char *prefix)
{
-int i, prefixlen;
+int i, prefixlen, mode1 = 0, mode2 = 0;
const char *paths[2];
diff_setup(revs-diffopt);
@@ -229,8 +229,35 @@ void diff_no_index(struct rev_info *revs,
setup_diff_pager(revs-diffopt);
DIFF_OPT_SET(revs-diffopt, EXIT_WITH_STATUS);
-if (queue_diff(revs-diffopt, paths[0], paths[1]))
+if (get_mode(paths[0], mode1) || get_mode(paths[1], mode2))
+exit(2);
+
+if (mode1 mode2 S_ISDIR(mode1) != S_ISDIR(mode2)) {
+struct strbuf pathtofile;
+const char *dir, *file;
+char *filename;
+int ret;
+
+dir = S_ISDIR(mode1) ? paths[0] : paths[1];
+file = (dir == paths[0]) ? paths[1] : paths[0];
+strbuf_init(pathtofile, strlen(paths[0]) + strlen(paths[1]) + 1);
+strbuf_addstr(pathtofile, dir);
+if (pathtofile.len pathtofile.buf[pathtofile.len - 1] != '/')
+ strbuf_addch(pathtofile, '/');
+filename = strrchr(file, '/');
+strbuf_addstr(pathtofile, filename ? (filename + 1) : file);
+
+if (file == paths[0])
+ret = queue_diff(revs-diffopt, file, pathtofile.buf);
+else
+ret = queue_diff(revs-diffopt, pathtofile.buf, file);
+strbuf_release(pathtofile);
+if (ret)
+exit(1);
+}
+else if (queue_diff(revs-diffopt, paths[0], paths[1]))
exit(1);
+
diff_set_mnemonic_prefix(revs-diffopt, 1/, 2/);
diffcore_std(revs-diffopt);
diff_flush(revs-diffopt);
--
Attached patch file because gmail always replaces tabs with spaces and
refuses to authorize 'git send-email'
0001-git-diff-no-index-refuses-to-compare-if-args-are-dir.patch
Description: Binary data
What's cooking in git.git (Mar 2015, #09; Thu, 26)
Here are the topics that have been cooking. Commits prefixed with '-' are only in 'pu' (proposed updates) while commits prefixed with '+' are in 'next'. Good news is that a few GSoC Microprojects have been merged already to 'master'; from my vague recollection of past years, perhaps this year's batch of students are of better quality? I dunno, but it that is the case, it is a welcome change. A preview release 2.4-rc0 has been tagged. I do not expect no major topics to graduate to 'master' before the final; many topics in 'next' touch important issues and crucial code paths and I'd prefer to see them cooked in 'next' for a few more weeks, rather than merging them early and having to make last-minute reverts for the upcoming release. I'll also start dropping stalled topics from 'pu' as part of spring cleaning. 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 -- [Graduated to master] * ct/prompt-untracked-fix (2015-03-15) 1 commit (merged to 'next' on 2015-03-20 at 0d57eaf) + git prompt: use toplevel to find untracked files The prompt script (in contrib/) did not show the untracked sign when working in a subdirectory without any untracked files. * dj/log-graph-with-no-walk (2015-03-19) 1 commit (merged to 'next' on 2015-03-20 at cb636c0) + revision: forbid combining --graph and --no-walk git log --graph --no-walk A B... is a otcnflicting request that asks nonsense; no-walk tells us show discrete points in the history, while graph asks to draw connections between these discrete points. Forbid the combination. * jc/report-path-error-to-dir (2015-03-24) 1 commit (merged to 'next' on 2015-03-24 at 6e97221) + report_path_error(): move to dir.c Code clean-up. * jc/submitting-patches-mention-send-email (2015-03-15) 1 commit (merged to 'next' on 2015-03-23 at a9581fd) + SubmittingPatches: encourage users to use format-patch and send-email Recommend format-patch and send-email for those who want to submit patches to this project. * jk/cleanup-failed-clone (2015-03-19) 2 commits (merged to 'next' on 2015-03-23 at 1f26d93) + clone: drop period from end of die_errno message + clone: initialize atexit cleanup handler earlier An failure early in the git clone that started creating the working tree and repository could have resulted in some directories and files left without getting cleaned up. * jk/fetch-pack (2015-03-19) 4 commits (merged to 'next' on 2015-03-23 at 4357f3d) + fetch-pack: remove dead assignment to ref-new_sha1 + fetch_refs_via_pack: free extra copy of refs + filter_ref: make a copy of extra sought entries + filter_ref: avoid overwriting ref-old_sha1 with garbage git fetch that fetches a commit using the allow-tip-sha1-in-want extension could have failed to fetch all the requested refs. * jk/prune-with-corrupt-refs (2015-03-20) 5 commits (merged to 'next' on 2015-03-23 at 68af8a9) + refs.c: drop curate_packed_refs + repack: turn on ref paranoia when doing a destructive repack + prune: turn on ref_paranoia flag + refs: introduce a ref paranoia flag + t5312: test object deletion code paths in a corrupted repository git prune used to largely ignore broken refs when deciding which objects are still being used, which could spread an existing small damage and make it a larger one. * jk/run-command-capture (2015-03-22) 7 commits (merged to 'next' on 2015-03-23 at f6db88b) + run-command: forbid using run_command with piped output + trailer: use capture_command + submodule: use capture_command + wt-status: use capture_command + run-command: introduce capture_command helper + wt_status: fix signedness mismatch in strbuf_read call + wt-status: don't flush before running submodule status The run-command interface was easy to abuse and make a pipe for us to read from the process, wait for the process to finish and then attempt to read its output, which is a pattern that lead to a deadlock. Fix such uses by introducing a helper to do this correctly (i.e. we need to read first and then wait the process to finish) and also add code to prevent such abuse in the run-command helper. * jk/simplify-csum-file-sha1fd-check (2015-03-19) 1 commit (merged to 'next' on 2015-03-20 at 6f6d1c2) + sha1fd_check: die when we cannot open the file Code simplification. * jk/test-chain-lint (2015-03-25) 36 commits (merged to 'next' on 2015-03-25 at 011a687) + t9001: drop save_confirm helper + t0020: use test_* helpers instead of hand-rolled messages + t: simplify loop exit-code status variables + t: fix some trivial cases of ignored exit codes in loops + t7701: fix ignored exit code inside loop + t3305: fix ignored exit code inside loop + t0020: fix ignored exit code inside loops + perf-lib: fix ignored exit code inside loop (merged to 'next' on 2015-03-24 at 31df637)
[ANNOUNCE] Git v2.4.0-rc0
An early preview release Git v2.4.0-rc0 is now available for testing at the usual places. This cycle is turning out to be a product excellence release---majority of the changes are bugfixes, about one-third of which are also already in the v2.3.x maintenance track. The tarballs are found at: https://www.kernel.org/pub/software/scm/git/testing/ The following public repositories all have a copy of the 'v2.4.0-rc0' 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 2.4 Release Notes (draft) = Backward compatibility warning(s) - This release has a few changes in the user-visible output from Porcelain commands, which the users may want to be aware of. * Output from git log --decorate (and %d format specifier used in the userformat --format=string parameter git log family of command takes) used to list HEAD just like other tips of branch names, separated with a comma in between. E.g. $ git log --decorate -1 master commit bdb0f6788fa5e3cacc4315e9ff318a27b2676ff4 (HEAD, master) ... This release updates the output slightly when HEAD refers to the tip of a branch whose name is also shown in the output. The above is shown as: $ git log --decorate -1 master commit bdb0f6788fa5e3cacc4315e9ff318a27b2676ff4 (HEAD - master) ... * The phrasing git branch uses to describe a detached HEAD has been updated to match that of git status: - When the HEAD is at the same commit as it was originally detached, they now both show detached at commit object name. - When the HEAD has moved since it was originally detached, they now both show detached from commit object name. Earlier git branch always used from Updates since v2.3 -- Ports * Our default I/O size (8 MiB) for large files was too large for some platforms with smaller SSIZE_MAX, leading to read(2)/write(2) failures. * We did not check the curl library version before using CURLOPT_PROXYAUTH feature that may not exist. * We now detect number of CPUs on older BSD-derived systems. * Portability fixes and workarounds for shell scripts have been added to help BSD-derived systems. UI, Workflows Features * The command usage info strings given by git cmd -h and in documentation have been tweaked for consistency. * The sync subcommand of git p4 now allows users to exclude subdirectories like its clone subcommand does. * git log --invert-grep --grep=WIP will show only commits that do not have the string WIP in their messages. * git push has been taught a --atomic option that makes push to update more than one ref an all-or-none affair. * Extending the push to deploy added in 2.3, the behaviour of git push when updating the branch that is checked out can now be tweaked by push-to-checkout hook. * Using environment variable LANGUAGE and friends on the client side, HTTP-based transports now send Accept-Language when making requests. * git send-email used to accept a mistaken y (or yes) as an answer to What encoding do you want to use [UTF-8]? without questioning. Now it asks for confirmation when the answer looks too short to be a valid encoding name. * When git apply --whitespace=fix fixed whitespace errors in the common context lines, the command reports that it did so. * git status now allows the -v to be given twice to show the differences that are left in the working tree not to be committed. * git cherry-pick used to clean-up the log message even when it is merely replaying an existing commit. It now replays the message verbatim unless you are editing the message of resulting commits. * git archive can now be told to set the 'text' attribute in the resulting zip archive. * Output from git log --decorate mentions HEAD when it points at a tip of an branch differently from a detached HEAD. This is a potentially backward-incompatible change. * git branch on a detached HEAD always said (detached from xyz), even when git status would report detached at xyz. The HEAD is actually at xyz and haven't been moved since it was detached in such a case, but the user cannot read what the current value of HEAD is when detached from is used. * git -C '' subcmd refused to work in the current directory, unlike cd '' which silently behaves as a no-op. (merge 6a536e2 kn/git-cd-to-empty later to maint). * The versionsort.prerelease configuration variable can be used to specify that v1.0-pre1 comes before v1.0. * A new push.followTags
Re: [PATCH] docs: Clarify what git-rebase's --preserve-merges does
Sebastian Schuberth sschube...@gmail.com writes: Instead of flattening the history by replaying each non-merge commit to be rebased, preserve the shape of the rebased history by recreating merge commits as well. or something along that line, perhaps? Hm, I'm not sure about the as well here. Non-merge commits basically are just picked, not recreated in the same sense as merge commits. I'll come up with another proposal. OK. I do not see qualitative difference between picking a non-merge and picking a merge; they are both being replayed and it is not like the machiery is trying to preserve an evil merge. Having said that, I do not have a strong feeling either way between keeping and dropping that as well. I threw it in there only to contrast the preserve mode (where merges are also picked) with the normal mode (where merges are not picked). -- 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
Dr Harry Thomas
Dr Harry Thomas Brondesbury, North West Londyn Anglia Drogi Przyjacielu. Jestem dr Harry Thomas z Brondesbury, North West London, tutaj w Anglii. Pracuję dla UBS Investment Bank Londyn. Piszę wam o propozycji biznesowych, które będą z ogromną korzyścią dla nas obu. W moim departamencie, jako członek Komitetu Wykonawczego UBS Investment Bank i również Officer Chief Risk tutaj (Greater London Regional Office). Odkryłem opuszczonej sumę 15 milionów Great British funtach (piętnaście milionów Great British Pounds Sterling) na koncie należącym do jednego z naszych zagranicznych klientów zmarłego, miliarder Business Man (Late Pan Mojżesz Saba Masri) z Meksyku, który był ofiarą katastrofy lotniczej, w wyniku jego śmierci i członków jego rodziny. Saba był 51-letni. Również w katastrofie lotniczej był z żoną i synem Abrahama (Saba) i jego córka-in-law. Wybór kontaktowania się budzi z charakter geograficzny, gdzie mieszkasz, w szczególności ze względu na wrażliwość transakcji i poufność w niniejszym wynalazku. Teraz nasz bank został czeka na którykolwiek z krewnymi, aby przyjść się do roszczenia, ale nikt tego nie zrobił. Ja osobiście przegrali sprawę w odnalezieniu krewnych do 10 miesięcy teraz, szukam Twojej zgody, aby zaprezentować Państwu jak najbliższych krewnych / Will Beneficjenta do zmarłego tak, że wpływy z tego konta wyceniono na 15 milionów funtów funtów może być wypłacona do Ciebie , To będzie wypłacane lub udostępniane w tych procentów, 60% do 40% mnie i dla Ciebie. Mam zabezpieczone wszystkie niezbędne dokumenty prawne, które mogą być wykorzystane do wykonania kopii zapasowej tego twierdzenia jest uczynienie. Wszystko, co musisz zrobić, to wypełnić swoje nazwiska do dokumentów i zalegalizować go w sądzie, aby udowodnić Ci za prawowitego beneficjenta. All I wymagają teraz jest uczciwy współpracy, poufności i zaufania w celu umożliwienia nam patrz poprzez tę transakcję. Gwarantuję, że będzie to wykonane zgodnie z prawem rozwiązanie, które będzie chronić komputer z wszelkich przypadków naruszenia prawa. Proszę dostarczyć mi następujące: jak mamy 7 dni, aby go uruchomić poprzez. To jest bardzo pilne PLEASE. 1. Imię i nazwisko: 2. Twój numer telefonu komórkowego: 3. Twój Adres kontaktowy: 4. Twój Wiek: 5. Płeć: Po przejściu przez metodyczne wyszukiwania, postanowiłem skontaktować się z Tobą nadzieję, że znajdziesz to propozycja interesująca. Na potwierdzenie tej wiadomości i wskazując zainteresowanie dostarczą Państwu więcej informacji. Starania, aby dać mi znać swojej decyzji zamiast trzymać mnie czeka. Pozdrawiam, Dr Harry Thomas -- 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] docs: Clarify what git-rebase's --preserve-merges does
Junio C Hamano gits...@pobox.com writes: [...] I think the current preserve-merges considers everything between upstream and branch as commits to be rebased, and recreate merges across these rebased tips of branches that are merged. There however were repeated wishes (or wishful misunderstandings ;-) that there were a mode to rebuild the trunk, considering only the commits on the first-parent chain as commits to be rebased, recreating the history by replaying the merge commits (whose first parent might be rewritten during the rebase, but the tips of side branches these merges bring into the history are kept intact). Surely there is no such mode right now, Isn't it what Johannes Sixt j...@kdbg.org mentions here?: [QUOTE] If you want a version of --preserve-merges that does what *you* need, consider this commit: git://repo.or.cz/git/mingw/j6t.git rebase-p-first-parent Use it like this: git rebase -i -p --first-parent ... Beware, its implementation is incomplete: if the rebase is interrupted, then 'git rebase --continue' behaves as if --first-parent were not given. [/QUOTE]. ref: http://permalink.gmane.org/gmane.comp.version-control.git/263584 If so, then I'd say such mode almost exists. but I am fairly sure that I wouldn't have any objection against a patch to implement such a feature (perhaps --first-parent --preserve-merges?), It'd be very welcome feature here, preferably along with a way to pass it to 'git pull --rebase', including a way to configure it to be the default. and with or without such a feature in the system, I would be happier if we made sure that the description we are discussing to update makes it clear that the current behaviour is everything between upstream and branch, and cannot be misread as do not touch side branches instead of dropping merged commits. I'd also suggest to somehow warn in the manual that current modes of operation silently drop changes to merge commits that were made to non-conflicting paths (either during conflict resolution or otherwise.) -- Sergey. -- 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] docs: Clarify what git-rebase's --preserve-merges does
Am 26.03.2015 um 22:17 schrieb Sergey Organov: Junio C Hamano gits...@pobox.com writes: There however were repeated wishes (or wishful misunderstandings ;-) that there were a mode to rebuild the trunk, considering only the commits on the first-parent chain as commits to be rebased, recreating the history by replaying the merge commits (whose first parent might be rewritten during the rebase, but the tips of side branches these merges bring into the history are kept intact). Surely there is no such mode right now, Isn't it what Johannes Sixt j...@kdbg.org mentions here?: [QUOTE] If you want a version of --preserve-merges that does what *you* need, consider this commit: git://repo.or.cz/git/mingw/j6t.git rebase-p-first-parent Use it like this: git rebase -i -p --first-parent ... Beware, its implementation is incomplete: if the rebase is interrupted, then 'git rebase --continue' behaves as if --first-parent were not given. [/QUOTE]. ref: http://permalink.gmane.org/gmane.comp.version-control.git/263584 If so, then I'd say such mode almost exists. The patch was discussed here: http://thread.gmane.org/gmane.comp.version-control.git/198125 The reason that this has not progressed any further is this response in the thread: http://thread.gmane.org/gmane.comp.version-control.git/198125/focus=198483 where you basically say that a --first-parent mode is good, but it should be separate from --preserve-merges. I haven't made up my mind, yet, how to proceed from there. If somebody wants to pick up the baton, I'll happily pass it on. -- Hannes -- 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 v2] config.c: split some variables to $GIT_DIR/config.worktree
On Thu, Mar 26, 2015 at 07:04:24PM +0700, Nguyễn Thái Ngọc Duy wrote:
When you define $GIT_DIR/info/config.worktree, which contains of
gitignore-style patterns (*), config variables that match these
patterns will be saved in $GIT_DIR/config.worktree instead of
$GIT_DIR/config.
Should it rather be in GIT_COMMON_DIR? As far as I
understand, its meaning is variables which we allow to use
per-worktree because we intend to have them different in
different worktrees, and sure no bad issues
can happen because this. It is not hardcored in git because
the list is going to extend, and we'd like to allow older
versions of git (and other git implementations) to be still
able to understand newer repositories. So there should be
no sense to make the list worktree-specific.
Also, probably the per-worktree variables should be searched
for in both common config and per-worktree config, and the
main repository should not have config.worktree, to be able
to work with implementations which are not aware of the
whole multiple worktrees feature. And in worktrees, if the
variable is not defined in config.wortree, the default
vaalue should come from common config. This though has
downside that worktree cannot use the more global vlue for
variable implicitly.
--
Max
On the surface, they are just like any other variables. You can read
or modify them with `git config` command, or config_* API. Underneath,
they are always stored in $GIT_DIR/config.worktree instead of
$GIT_DIR/config (and never in $HOME/.gitconfig or /etc/gitconfig)
The reason for this split is, as the name implies, for
worktree-specific configuration. When the same repo is attached to
more than one worktree, we can't use $GIT_DIR/config to store worktree
specific stuff because it's shared across worktrees.
(*) Config variable names are separated by dots. However as this is a
quick and dirty patch to experiment with submodules and multiple
worktrees, you must substitute dots with slashes when writing these
patterns, for now. E.g. write remote/*/foo instead of remote.*.foo
Signed-off-by: Nguyễn Thái Ngọc Duy pclo...@gmail.com
---
Something for Max to play with if he's still experimenting with
multiple worktree support for submodules :-) It's far from perfect,
but good enough for this purpose.
Documentation/config.txt | 6 -
builtin/config.c | 8 ++
config.c | 67
t/t1300-repo-config.sh | 34
4 files changed, 114 insertions(+), 1 deletion(-)
diff --git a/Documentation/config.txt b/Documentation/config.txt
index 2700a1b..6d00f49 100644
--- a/Documentation/config.txt
+++ b/Documentation/config.txt
@@ -2,11 +2,15 @@ CONFIGURATION FILE
--
The Git configuration file contains a number of variables that affect
-the Git commands' behavior. The `.git/config` file in each repository
+the Git commands' behavior. The `.git/config` and `.git/config.worktree`
+files in each repository
is used to store the configuration for that repository, and
`$HOME/.gitconfig` is used to store a per-user configuration as
fallback values for the `.git/config` file. The file `/etc/gitconfig`
can be used to store a system-wide default configuration.
+If `.git/info/core.worktree` exists, it contains gitignore-style
+patterns. Variables that match these patterns can only be contained in
+`.git/config.worktree`.
The configuration variables are used by both the Git plumbing
and the porcelains. The variables are divided into sections, wherein
diff --git a/builtin/config.c b/builtin/config.c
index 8cc2604..4ca8fc2 100644
--- a/builtin/config.c
+++ b/builtin/config.c
@@ -555,6 +555,14 @@ int cmd_config(int argc, const char **argv, const char
*prefix)
usage_with_options(builtin_config_usage,
builtin_config_options);
}
+ /*
+ * For set operations, --local could be either config or
+ * config.worktree. Let config.c determine the path based on
+ * config keys.
+ */
+ if (use_local_config actions != ACTION_LIST)
+ given_config_source.file = NULL;
+
if (actions == ACTION_LIST) {
check_argc(argc, 0, 0);
if (git_config_with_options(show_all_config, NULL,
diff --git a/config.c b/config.c
index 15a2983..f68eb6a 100644
--- a/config.c
+++ b/config.c
@@ -12,6 +12,7 @@
#include quote.h
#include hashmap.h
#include string-list.h
+#include dir.h
struct config_source {
struct config_source *prev;
@@ -37,6 +38,7 @@ struct config_source {
};
static struct config_source *cf;
+static struct exclude_list config_local;
static int zlib_compression_seen;
@@ -84,6 +86,34 @@ static long config_buf_ftell(struct config_source *conf)
return conf-u.buf.pos;
}
+static int is_config_local(const char *key_)
+{
+ static struct strbuf key =
Re: [PATCH V2/RFC][GSoC] diff-no-index: transform $directory $file args to $directory/$file $file
Yurii Shevtsov unge...@gmail.com writes: git diff --no-index refuses to compare if args are directory and file, instead of usual diff. Now git diff --no-index modifies args, if they're directory and file, and diffs files, as usual diff does. Changes are done in diff_no_index(). Helped-by: Junio C Hamano gits...@pobox.com Signed-off-by: Yurii Shevtsov unge...@gmail.com --- diff-no-index.c | 31 +-- 1 files changed, 29 insertions(+), 2 deletions(-) This round looks sensible. Good catch to notice that POSIX wants you to append not just the path to the file, but the basename of the file, to the directory name. I didn't try your patch, but I wouldn't be surprised if it passed the tests in the patches I wrote last night in the $gmane/266315 thread ;-). Good luck with your GSoC application. -- 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] git-p4: Fix copy detection test
File file11 is copied from file2 and diff-tree correctly reports this file as its the source, but the test expression was checking for file10 instead (which was a file that also originated from file2). It is possible that the diff-tree algorithm was updated in recent versions, which resulted in this mismatch in behavior. Signed-off-by: Vitor Antunes vitor@gmail.com --- t/t9814-git-p4-rename.sh |4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/t/t9814-git-p4-rename.sh b/t/t9814-git-p4-rename.sh index 24008ff..018f01d 100755 --- a/t/t9814-git-p4-rename.sh +++ b/t/t9814-git-p4-rename.sh @@ -156,14 +156,14 @@ test_expect_success 'detect copies' ' git diff-tree -r -C HEAD git p4 submit p4 filelog //depot/file10 - p4 filelog //depot/file10 | grep -q branch from //depot/file + p4 filelog //depot/file10 | grep -q branch from //depot/file2 cp file2 file11 git add file11 git commit -a -m Copy file2 to file11 git diff-tree -r -C --find-copies-harder HEAD src=$(git diff-tree -r -C --find-copies-harder HEAD | sed 1d | cut -f2) - test $src = file10 + test $src = file2 git config git-p4.detectCopiesHarder true git p4 submit p4 filelog //depot/file11 -- 1.7.10.4 -- 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] git-p4: Make rename test case runnable under dash
Signed-off-by: Vitor Antunes vitor@gmail.com --- t/t9814-git-p4-rename.sh |8 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/t/t9814-git-p4-rename.sh b/t/t9814-git-p4-rename.sh index 95f4421..24008ff 100755 --- a/t/t9814-git-p4-rename.sh +++ b/t/t9814-git-p4-rename.sh @@ -178,9 +178,9 @@ test_expect_success 'detect copies' ' test -n $level test $level -gt 0 test $level -lt 98 src=$(git diff-tree -r -C --find-copies-harder HEAD | sed 1d | cut -f2) case $src in - file10 | file11) : ;; # happy + file10 | file11) true ;; # happy *) false ;; # not - + esac git config git-p4.detectCopies $(($level + 2)) git p4 submit p4 filelog //depot/file12 @@ -195,9 +195,9 @@ test_expect_success 'detect copies' ' test -n $level test $level -gt 2 test $level -lt 100 src=$(git diff-tree -r -C --find-copies-harder HEAD | sed 1d | cut -f2) case $src in - file10 | file11 | file12) : ;; # happy + file10 | file11 | file12) true ;; # happy *) false ;; # not - + esac git config git-p4.detectCopies $(($level - 2)) git p4 submit p4 filelog //depot/file13 -- 1.7.10.4 -- 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 0/2] git-p4: Small updates to test cases
This patch set includes two small fixes to the rename test case. The fix to support dash should be trivial, but in the fix to the copy detection test case it isn't obvious to me what changed in diff-tree to result in a different file being detected as the origin of a copy. Vitor Antunes (2): git-p4: Make rename test case runnable under dash git-p4: Fix copy detection test t/t9814-git-p4-rename.sh | 12 ++-- 1 file changed, 6 insertions(+), 6 deletions(-) -- 1.7.10.4 -- 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 0/2] git-p4: Small updates to test cases
Vitor Antunes vitor@gmail.com writes: This patch set includes two small fixes to the rename test case. The fix to support dash should be trivial, but in the fix to the copy detection test case it isn't obvious to me what changed in diff-tree to result in a different file being detected as the origin of a copy. Thanks. As to 1/2 the lack of esac is clearly a bug---any self respecting POSIX shell should have executed it without complaining. But changing from ':' to true should not be necessary---after all, the colon is a more traditional way to spell true to Bourne shells, and we use it in many places already. Can you try reverting all the colon to true bits, keeping only the add missing esac part, and run your tests again? -- 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 0/2] git-p4: Small updates to test cases
Junio C Hamano gits...@pobox.com writes: As to 1/2 the lack of esac is clearly a bug---any self respecting POSIX shell should have executed it without complaining. But s/should/shouldn't/; sorry for a noise. -- 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 0/2] git-p4: Small updates to test cases
On Fri, 27 Mar 2015 at 01:26 Junio C Hamano gits...@pobox.com wrote: As to 1/2 the lack of esac is clearly a bug---any self respecting POSIX shell should have executed it without complaining. But changing from ':' to true should not be necessary---after all, the colon is a more traditional way to spell true to Bourne shells, and we use it in many places already. Can you try reverting all the colon to true bits, keeping only the add missing esac part, and run your tests again? I confirm that it still works with ':' instead of true; could swear I tested that at the time... Anyway, I'll re-submit this patch with this fixed tomorrow. Thanks for taking the time to review the patch. One more thing: was there any change in way diff-tree detects copies? -- 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 v2 0/2] diff --no-index updates
Here are a few patches to scratch my itches in diff --no-index I have had for quite some time, but didn't feel strong enough to fix them myself so far. The first one is to make diff File Directory (and diff Directory File) more useful by aligning its behaviour with more mainstream diff implementations. We used to complain that one is a file and the other is a directory and died without doing anything useful. Instead, we pretend as if the user asked to compare diff File Directory/File (or vice versa), which is what GNU diff does. The second one on the other hand is to make it behave more like the normal git diff when comparing two directories, when one directory has a path as a file while the other directory has the same path as a directory. GNU diff punts and says File D1/path is a regular file while file D2/path is a directory in such a case, and that is what diff --no-index does, too, but when the normal git diff compares two such trees, we show a removal of the file and creations of all the files in the directory (or vice versa). With this patch, we teach diff --no-index codepath to do the same, which would be more in line with the spirit of diff --no-index, which is to make git diff goodies available to people who compare paths outside control of any git repository. Junio C Hamano (2): diff-no-index: DWIM diff D F into diff D/F F diff: align D/F handling of diff --no-index with that of normal Git diff-no-index.c | 66 ++-- t/t4053-diff-no-index.sh | 34 + 2 files changed, 98 insertions(+), 2 deletions(-) -- 2.3.4-475-g3180e2e -- 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 v2 1/2] diff-no-index: DWIM diff D F into diff D/F F
git diff --no-index was supposed to be a poor-man's approach to
allow using Git diff goodies outside of a Git repository, without
having to patch mainstream diff implementations.
Unlike a POSIX diff that treats diff D F (or diff F D) as a
request to compare D/F and F (or F and D/F) when D is a directory
and F is a file, however, we did not accept such a command line and
instead barfed with file/directory conflict.
Imitate what POSIX diff does and append the basename of the file
after the name of the directory before comparing.
Signed-off-by: Junio C Hamano gits...@pobox.com
---
diff-no-index.c | 43 +++
t/t4053-diff-no-index.sh | 22 ++
2 files changed, 65 insertions(+)
diff --git a/diff-no-index.c b/diff-no-index.c
index 265709b..49c4536 100644
--- a/diff-no-index.c
+++ b/diff-no-index.c
@@ -182,12 +182,50 @@ static int queue_diff(struct diff_options *o,
}
}
+/* append basename of F to D */
+static void append_basename(struct strbuf *path, const char *dir, const char
*file)
+{
+ const char *tail = strrchr(file, '/');
+
+ strbuf_addstr(path, dir);
+ while (path-len path-buf[path-len - 1] == '/')
+ path-len--;
+ strbuf_addch(path, '/');
+ strbuf_addstr(path, tail ? tail + 1 : file);
+}
+
+/*
+ * DWIM diff D F into diff D/F F and diff F D into diff F D/F
+ * Note that we append the basename of F to D/, so diff a/b/file D
+ * becomes diff a/b/file D/file, not diff a/b/file D/a/b/file.
+ */
+static void fixup_paths(const char **path, struct strbuf *replacement)
+{
+ unsigned int isdir0, isdir1;
+
+ if (path[0] == file_from_standard_input ||
+ path[1] == file_from_standard_input)
+ return;
+ isdir0 = is_directory(path[0]);
+ isdir1 = is_directory(path[1]);
+ if (isdir0 == isdir1)
+ return;
+ if (isdir0) {
+ append_basename(replacement, path[0], path[1]);
+ path[0] = replacement-buf;
+ } else {
+ append_basename(replacement, path[1], path[0]);
+ path[1] = replacement-buf;
+ }
+}
+
void diff_no_index(struct rev_info *revs,
int argc, const char **argv,
const char *prefix)
{
int i, prefixlen;
const char *paths[2];
+ struct strbuf replacement = STRBUF_INIT;
diff_setup(revs-diffopt);
for (i = 1; i argc - 2; ) {
@@ -217,6 +255,9 @@ void diff_no_index(struct rev_info *revs,
p = xstrdup(prefix_filename(prefix, prefixlen, p));
paths[i] = p;
}
+
+ fixup_paths(paths, replacement);
+
revs-diffopt.skip_stat_unmatch = 1;
if (!revs-diffopt.output_format)
revs-diffopt.output_format = DIFF_FORMAT_PATCH;
@@ -235,6 +276,8 @@ void diff_no_index(struct rev_info *revs,
diffcore_std(revs-diffopt);
diff_flush(revs-diffopt);
+ strbuf_release(replacement);
+
/*
* The return code for --no-index imitates diff(1):
* 0 = no changes, 1 = changes, else error
diff --git a/t/t4053-diff-no-index.sh b/t/t4053-diff-no-index.sh
index 2ab3c48..01eca4c 100755
--- a/t/t4053-diff-no-index.sh
+++ b/t/t4053-diff-no-index.sh
@@ -55,4 +55,26 @@ test_expect_success 'git diff --no-index executed outside
repo gives correct err
)
'
+test_expect_success 'diff D F and diff F D' '
+ (
+ cd repo
+ echo in-repo a
+ echo non-repo ../non/git/a
+ mkdir sub
+ echo sub-repo sub/a
+
+ test_must_fail git diff --no-index sub/a ../non/git/a expect
+ test_must_fail git diff --no-index sub/a ../non/git/ actual
+ test_cmp expect actual
+
+ test_must_fail git diff --no-index a ../non/git/a expect
+ test_must_fail git diff --no-index a ../non/git/ actual
+ test_cmp expect actual
+
+ test_must_fail git diff --no-index ../non/git/a a expect
+ test_must_fail git diff --no-index ../non/git a actual
+ test_cmp expect actual
+ )
+'
+
test_done
--
2.3.4-475-g3180e2e
--
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 v2 2/2] diff: align D/F handling of diff --no-index with that of normal Git
When a commit changes a path P that used to be a file to a directory
and creates a new path P/X in it, git show would say that file P
was removed and file P/X was created for such a commit.
However, if we compare two directories, D1 and D2, where D1 has a
file D1/P in it and D2 has a directory D2/P under which there is a
file D2/P/X, and ask git diff --no-index D1 D2 to show their
differences, we simply get a refusal file/directory conflict.
Surely, that may be what GNU diff does, but we can do better and it
is easy to do so.
Signed-off-by: Junio C Hamano gits...@pobox.com
---
diff-no-index.c | 23 +--
t/t4053-diff-no-index.sh | 12
2 files changed, 33 insertions(+), 2 deletions(-)
diff --git a/diff-no-index.c b/diff-no-index.c
index 49c4536..0320605 100644
--- a/diff-no-index.c
+++ b/diff-no-index.c
@@ -97,8 +97,27 @@ static int queue_diff(struct diff_options *o,
if (get_mode(name1, mode1) || get_mode(name2, mode2))
return -1;
- if (mode1 mode2 S_ISDIR(mode1) != S_ISDIR(mode2))
- return error(file/directory conflict: %s, %s, name1, name2);
+ if (mode1 mode2 S_ISDIR(mode1) != S_ISDIR(mode2)) {
+ struct diff_filespec *d1, *d2;
+
+ if (S_ISDIR(mode1)) {
+ /* 2 is file that is created */
+ d1 = noindex_filespec(NULL, 0);
+ d2 = noindex_filespec(name2, mode2);
+ name2 = NULL;
+ mode2 = 0;
+ } else {
+ /* 1 is file that is deleted */
+ d1 = noindex_filespec(name1, mode1);
+ d2 = noindex_filespec(NULL, 0);
+ name1 = NULL;
+ mode1 = 0;
+ }
+ /* emit that file */
+ diff_queue(diff_queued_diff, d1, d2);
+
+ /* and then let the entire directory be created or deleted */
+ }
if (S_ISDIR(mode1) || S_ISDIR(mode2)) {
struct strbuf buffer1 = STRBUF_INIT;
diff --git a/t/t4053-diff-no-index.sh b/t/t4053-diff-no-index.sh
index 01eca4c..596dfe7 100755
--- a/t/t4053-diff-no-index.sh
+++ b/t/t4053-diff-no-index.sh
@@ -77,4 +77,16 @@ test_expect_success 'diff D F and diff F D' '
)
'
+test_expect_success 'turning a file into a directory' '
+ (
+ cd non/git
+ mkdir d e e/sub
+ echo 1 d/sub
+ echo 2 e/sub/file
+ printf D\td/sub\nA\te/sub/file\n expect
+ test_must_fail git diff --no-index --name-status d e actual
+ test_cmp expect actual
+ )
+'
+
test_done
--
2.3.4-475-g3180e2e
--
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: Identifying user who ran “git reset” command
First of all, my sincere apologies for the inordinate delay in reply. The user who created the mess went on leave. By the time he was back, I got stuck in some other issue. Later, I took the log of 'history' command from his machine because i wanted to first simulate the scenario before i could apply Alfred's check to see whether it works. I tried simulating the scenario but couldn't reproduce it. :( Here's the PASTEBIN link which details what the developer did and how i tried simulating the same: http://pastebin.com/0GkSc59y As you will notice from the above link, in the original case, the developer got Your branch is ahead of 'origin/some_branch' by 2 commit. message while in my simulation, i got Your branch and 'origin/some_branch' have diverged, and have 1 and 1 different commit each, respectively. Not only is the message different, in the simulation, i can actually see the user's (in this case, harry) detail in 'git log' command. In the original case, the log did not contain any info on the user who messed up history. Although i did suspect that Alfred's suggestion might not actually address this issue but i still wanted to confirm it. However, thanks Alfred because it did solve another issue (disabling force push) for which i was planning to put a check. :) @Randall/Kevin: The type of setup you suggested will definitely be ideal but in the type of environment we operate, i'm highly skeptical whether it will be implemented. :) I surely will highlight the issue and its impact though. As Gergely earlier mentioned, i guess i will have to capture ref updates. I never really looked into 'refs' before but now i will have to. I'm sure it will help me customize many other things as well especially access-related stuff. Thanks again to Junio, Gergely, Alfred, Randall and Kevin for their inputs. :) -- 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: [RFH/PATCH] git-svn: adjust info to svn 1.7 and 1.8
Michael J Gruber venit, vidit, dixit 24.03.2015 16:10: t9119 refuses to run with svn versions greater than 1.6 since git svn info does not even try to match the output of svn info for later versions. Adjust git svn info to match these versions and make t9119 run with them. This requires the following changes: * compute checksums with SHA1 instead of MD5 with svn = 1.7.0 * omit the line Revision: 0 for added content with svn = 1.8.0 (TBC) * print the Repository UUID line even for added content with svn = 1.8.0 (TBC) * add a Relative URL line for svn = 1.8.0 * add a Working Copy Root Path line for svn = 1.8.0 (TBC, RFH) Signed-off-by: Michael J Gruber g...@drmicha.warpmail.net --- Notes: While trying to increase my test run coverage I noticed that most of us won't run t9119 at all. Bad bad. My svn is 1.8.11 (r1643975) on Fedora 21. I would appreciate help with the following items: TBC = to be confirmed: confirm the svn version where this change kicked it, or run this patch and t9119 with an svn version other than mine. Please run with -v to make sure only the RFH item fails, see below. RFH = request for help: I couldn't figure out how to get the working copy root path in cmd_info. 18 subtests will fail because of the RFH item. I've figured out the exact revisions meanwhile - there's a git repo for svn :) I would appreciate help with the RFH item, though: How to teach git svn info to output the Working Copy Root Path? Michael -- 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] git-push.txt: clean up force-with-lease wording
The help text for the --force-with-lease option to git-push does not parse cleanly. Clean up the wording and syntax to be more sensible. Also remove redundant information in the --force-with-lease alone description. Signed-off-by: Phil Hord ho...@cisco.com --- Documentation/git-push.txt | 14 ++ 1 file changed, 6 insertions(+), 8 deletions(-) diff --git a/Documentation/git-push.txt b/Documentation/git-push.txt index 5171086..863c30c 100644 --- a/Documentation/git-push.txt +++ b/Documentation/git-push.txt @@ -157,9 +157,8 @@ already exists on the remote side. Usually, git push refuses to update a remote ref that is not an ancestor of the local ref used to overwrite it. + -This option bypasses the check, but instead requires that the -current value of the ref to be the expected value. git push -fails otherwise. +This option overrides this restriction if the current value of the +remote ref is the expected value. git push fails otherwise. + Imagine that you have to rebase what you have already published. You will have to bypass the must fast-forward rule in order to @@ -171,15 +170,14 @@ commit, and blindly pushing with `--force` will lose her work. This option allows you to say that you expect the history you are updating is what you rebased and want to replace. If the remote ref still points at the commit you specified, you can be sure that no -other people did anything to the ref (it is like taking a lease on -the ref without explicitly locking it, and you update the ref while -making sure that your earlier lease is still valid). +other people did anything to the ref. It is like taking a lease on +the ref without explicitly locking it, and the remote ref is updated +only if the lease is still valid. + `--force-with-lease` alone, without specifying the details, will protect all remote refs that are going to be updated by requiring their current value to be the same as the remote-tracking branch we have -for them, unless specified with a `--force-with-lease=refname:expect` -option that explicitly states what the expected value is. +for them. + `--force-with-lease=refname`, without specifying the expected value, will protect the named ref (alone), if it is going to be updated, by -- 2.3.3.377.gdac1145 -- 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
