Re: [BUG] [PATCH] infinite loop due to broken symlink

2015-03-26 Thread Petr Stodulka


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

2015-03-26 Thread Nguyễn Thái Ngọc Duy
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

2015-03-26 Thread Nguyễn Thái Ngọc Duy
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

2015-03-26 Thread Sebastian Schuberth
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

2015-03-26 Thread Kirill Marchuk
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

2015-03-26 Thread Jeff King
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

2015-03-26 Thread Matthieu Moy
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

2015-03-26 Thread 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:
  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

2015-03-26 Thread Sebastian Schuberth
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)

2015-03-26 Thread Jeff King
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

2015-03-26 Thread Junio C Hamano
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

2015-03-26 Thread Junio C Hamano
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

2015-03-26 Thread Jeff King
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

2015-03-26 Thread Kevin D
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

2015-03-26 Thread Junio C Hamano
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

2015-03-26 Thread Junio C Hamano
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

2015-03-26 Thread Sebastian Schuberth

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

2015-03-26 Thread Sebastian Schuberth
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.

2015-03-26 Thread Jeff King
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

2015-03-26 Thread Junio C Hamano
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

2015-03-26 Thread Junio C Hamano
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

2015-03-26 Thread Tony Finch

 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)

2015-03-26 Thread Tommy38
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

2015-03-26 Thread Eric Sunshine
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?

2015-03-26 Thread Marc Branchaud
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

2015-03-26 Thread Thomas Ackermann

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

2015-03-26 Thread Jens Lehmann

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

2015-03-26 Thread Yurii Shevtsov
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)

2015-03-26 Thread Junio C Hamano
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

2015-03-26 Thread Junio C Hamano
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

2015-03-26 Thread Junio C Hamano
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

2015-03-26 Thread 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

2015-03-26 Thread Sergey Organov
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

2015-03-26 Thread Johannes Sixt

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

2015-03-26 Thread Max Kirillov
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

2015-03-26 Thread Junio C Hamano
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

2015-03-26 Thread Vitor Antunes
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

2015-03-26 Thread Vitor Antunes

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

2015-03-26 Thread Vitor Antunes
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

2015-03-26 Thread Junio C Hamano
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

2015-03-26 Thread Junio C Hamano
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

2015-03-26 Thread Vitor Antunes
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

2015-03-26 Thread Junio C Hamano
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

2015-03-26 Thread Junio C Hamano
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

2015-03-26 Thread Junio C Hamano
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

2015-03-26 Thread Gaurav Chhabra
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

2015-03-26 Thread Michael J Gruber
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

2015-03-26 Thread Phil Hord
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