Re: [PATCHv3 6/6] entry.c: fix a memleak
On Mon, Mar 30, 2015 at 06:22:11PM -0700, Stefan Beller wrote:
From: John Keeping j...@keeping.me.uk
stream_blob_to_fd() always frees the filter now, so there is no memory
leak in entry.c:152 just before the `goto finish`.
Signed-off-by: John Keeping j...@keeping.me.uk
Signed-off-by: Stefan Beller sbel...@google.com
---
I added Johns signoff here tentatively, John can you confirm the sign off?
Signed-off-by: John Keeping j...@keeping.me.uk
streaming.c | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/streaming.c b/streaming.c
index 2ff036a..811fcc2 100644
--- a/streaming.c
+++ b/streaming.c
@@ -507,8 +507,11 @@ int stream_blob_to_fd(int fd, unsigned const char *sha1,
struct stream_filter *f
int result = -1;
st = open_istream(sha1, type, sz, filter);
- if (!st)
+ if (!st) {
+ if (filter)
+ free_stream_filter(filter);
return result;
+ }
if (type != OBJ_BLOB)
goto close_and_exit;
for (;;) {
--
2.3.0.81.gc37f363
--
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
Allowing weak references to blobs and strong references to commits
Hi, Currently, in git-cinnabar[1], I'm using a private namespace (refs/cinnabar) for various different things: - references to all the imported heads (which may or may not match remote refs), - the last refs used for a fetch (part of the refspec protocol for remote-helpers) - a branch containing mappings from mercurial sha1s to git objects. - a branch used to store all mercurial manifests. - a cache of some sort (used for tags only atm) So essentially there are a bit more than twice as many refs as actually necessary (and up to more than three when there is only one remote). Ideally, the mercurial manifests data would use as many refs as branches, so that their parent information wouldn't have to be guessed from the corresponding git commits, but I didn't do that initially to avoid making the number of necessary refs even bigger (that would make the number three or four times as many as necessary). I won't bother you with all the whys and hows, but that ends up being a lot of unwanted noise for users, because many commands don't limit themselves to refs/heads, refs/tags and refs/remotes. One way to reduce this noise would be for me to create fake octopus merges and reduce the number of heads to one, or at least one per category. But this is cumbersome and would create a lot of useless commits that would end up loose, except if they are kept forever which seems even worse. So I thought, since commits are already allowed in tree objects, for submodules, why not add a bit to the mode that would tell git that those commit object references are meant to always be there aka strong reference, as opposed to the current weak references for submodules. I was thinking something like 020, which is above S_IFMT, but I haven't checked if mode is expected to be a short anywhere, maybe one of the file permission flags could be abused instead (sticky bit?). I could see this used in the future to e.g. implement a fetchable reflog (which could be a ref to a tree with strong references to commits). Then that got me thinking that the opposite would be useful to me as well: I'm currently storing mercurial manifests as git trees with (weak) commit references using the mercurial sha1s for files. Unfortunately, that doesn't allow to store the corresponding file permissions, so I'm going through hoops to get that. It would be simpler for me if I could just declare files or symlinks with the right permissions and say 'the corresponding blob doesn't need to exist'. I'm sure other tools using git as storage would have a use for such weak references. What do you think about this? Does that seem reasonable to have in git core, and if yes, how would you go about implementing it (same bit with different meaning for blobs and commits (or would you rather that were only done for commits and not for blobs)? what should I be careful about, besides making sure gc and fsck don't mess up?) Cheers, Mike 1. a git-remote-hg tool, https://github.com/glandium/git-cinnabar/ -- 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
Johannes Sixt j...@kdbg.org writes: Junio C Hamano gits...@pobox.com writes: [...] 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. As far as I can see, there are 2 separate issues: 1. How to calculate the set of commits to rebase. 2. How to rebase merge commits. Can we leave (1) for a while at its current state and focus on (2)? Johannes's patch contains a fix for that: use cherry-pick to recreate merge commits instead of trying to re-merge. Could this change be accepted alone, as a known fix for current buggy behavior of loosing user changes in merge commits? -- 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
Forcing git top-level
Hello I’ve copied a .git folder located at the root (/) of a filesystem, into another directory (/home/mydir). If I issue a git rev-parse —show-toplevel I got /... I would like to change the top-level to point to /home/mydir. I’ve also tried to bare clone the original .git folder, but the new git repo stills points it top-level to /. Thank you for your answer Best regards Cedric-- 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] gitweb.conf.txt: fix typo
On 2014-04-03 at 22:49, git-pa...@agt-the-walker.net wrote: From: Jérôme Zago git-pa...@agt-the-walker.net build-time is used everywhere else. Signed-off-by: Jérôme Zago git-pa...@agt-the-walker.net You are right, it is variable set during build process, not after project is built. ACK (for what it is worth). Acked-by: Jakub Narebski jna...@gmail.com --- Documentation/gitweb.conf.txt | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/Documentation/gitweb.conf.txt b/Documentation/gitweb.conf.txt index 952f503..8b25a2f 100644 --- a/Documentation/gitweb.conf.txt +++ b/Documentation/gitweb.conf.txt @@ -482,7 +482,7 @@ project config. Per-repository configuration takes precedence over value composed from `@git_base_url_list` elements and project name. + You can setup one single value (single entry/item in this list) at build -time by setting the `GITWEB_BASE_URL` built-time configuration variable. +time by setting the `GITWEB_BASE_URL` build-time configuration variable. By default it is set to (), i.e. an empty list. This means that gitweb would not try to create project URL (to fetch) from project name. -- 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 v3] config.c: split some variables to $GIT_DIR/config.worktree
.git/info/config.worktree is a pattern list that splits .git/config in to sets, the common set that does not match the patterns and the worktree set. In normal worktree, or in the main worktree when git checkout --to is used, both sets are stored in .git/config. Nothing interesting. In linked worktrees, the common and worktree sets are read from and saved to .git/config and .git/config.worktree respectively. Config keys in .git/config that belong to the worktree set is ignored. Those are for the main worktree only. The effect is similar to the $GIT_DIR/$GIT_COMMON_DIR split, we can define that some vars can be shared and some cannot. core.worktree and core.bare, which are treated specially in 31e26eb [1], are now moved to info/core.worktree and the special treatment reverted. [1] 31e26eb (setup.c: support multi-checkout repo setup - 2014-11-30) Helped-by: Max Kirillov m...@max630.net Helped-by: Jens Lehmann jens.lehm...@web.de Signed-off-by: Nguyễn Thái Ngọc Duy pclo...@gmail.com --- Much happier with this version, especially when we can now generalize the treatment for core.worktree and core.bare. The general principle is like in the last mail: .git/config is for both shared and private keys of main worktree (i.e. nothing is changed from today). .git/worktrees/xx/config.worktree is for private keys only (and private keys in .git/config are ignored) With this we don't have to bump core.repository_format_version for main worktree because nothing is changed. There will be problems with info/config.worktree: - it's customizable, so expect the user to break it (*) - if we add new stuff to the template, we'll need to help migrate current info/core.worktree (which does not have new stuff). Auto updating this file could be risky. I'm tend to just warn the user that this and that keys should be included and let them modify the file. (*) but I don't want to keep the hard coded version of this in git binary either, simply to avoid this customization problem. The list compiled by Max shows that many keys may or may not be shared. So let the user decide what's best for them. Documentation/config.txt | 10 Documentation/gitrepository-layout.txt | 6 +++ builtin/config.c | 8 +++ cache.h| 2 +- config.c | 97 -- dir.c | 41 ++ dir.h | 1 + setup.c| 8 +-- t/t2025-checkout-to.sh | 26 + templates/info--config.worktree (new) | 2 + 10 files changed, 189 insertions(+), 12 deletions(-) create mode 100644 templates/info--config.worktree diff --git a/Documentation/config.txt b/Documentation/config.txt index 2700a1b..ca4de1f 100644 --- a/Documentation/config.txt +++ b/Documentation/config.txt @@ -8,6 +8,16 @@ is used to store the configuration for that repository, and fallback values for the `.git/config` file. The file `/etc/gitconfig` can be used to store a system-wide default configuration. +Linked worktrees (see multple working trees in +linkgit:git-checkout[1]) have two config files under its .git +directory: config is shared with other worktrees while +config.worktree is per worktree. Configuration variables that match +patterns in $GIT_DIR/info/config.worktree are stored and read from +config.worktree. Matched configuration variables in config is +ignored by linked worktrees. They are only used by the main +worktree. The patterns follow gitignore syntax, where the separator is +'.' instead of '/'. + The configuration variables are used by both the Git plumbing and the porcelains. The variables are divided into sections, wherein the fully qualified variable name of the variable itself is the last diff --git a/Documentation/gitrepository-layout.txt b/Documentation/gitrepository-layout.txt index 7173b38..6228280 100644 --- a/Documentation/gitrepository-layout.txt +++ b/Documentation/gitrepository-layout.txt @@ -212,6 +212,12 @@ info/sparse-checkout:: This file stores sparse checkout patterns. See also: linkgit:git-read-tree[1]. +info/checkout.worktree: + This file stores the configuration variable pattern list where + $GIT_DIR/config.worktree is used as storage instead of + $GIT_DIR/config. The syntax is the same as .gitignore except + that '.' is considered the separator instead of '/'. + remotes:: Stores shorthands for URL and default refnames for use when interacting with remote repositories via 'git fetch', 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); } +
Re: [PATCH v3] config.c: split some variables to $GIT_DIR/config.worktree
On Tue, Mar 31, 2015 at 7:14 PM, Nguyễn Thái Ngọc Duy pclo...@gmail.com wrote: The general principle is like in the last mail: .git/config is for both shared and private keys of main worktree (i.e. nothing is changed from today). .git/worktrees/xx/config.worktree is for private keys only (and private keys in .git/config are ignored) When I put it this way, I realize that .git/worktrees/xx/config.worktree can simply be .git/worktrees/xx/config. No .worktree. Looks nice (or it's just a source of more confusion later) -- Duy -- 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] prune --worktrees: fix expire vs worktree existence condition
On Tue, Mar 31, 2015 at 3:47 AM, Max Kirillov m...@max630.net wrote:
`git prune --worktrees` was pruning worktrees which were non-existent OR
expired, while it rather should prune those which are orphaned AND
expired, as git-checkout documentation describes. Fix it.
Add test 'not prune proper checkouts', which uses valid but expired
worktree.
Modify test 'not prune recent checkouts' to remove the worktree before
pruning - link in worktrees still must survive. In older form it is
useless because would pass always when the other test passes.
Urgh.. Ack.
Signed-off-by: Max Kirillov m...@max630.net
---
builtin/prune.c | 10 +++---
t/t2026-prune-linked-checkouts.sh | 12
2 files changed, 19 insertions(+), 3 deletions(-)
diff --git a/builtin/prune.c b/builtin/prune.c
index 34a5ce1..fd31485 100644
--- a/builtin/prune.c
+++ b/builtin/prune.c
@@ -120,11 +120,15 @@ static int prune_worktree(const char *id, struct strbuf
*reason)
if (!stat(git_path(worktrees/%s/link, id), st_link)
st_link.st_nlink 1)
return 0;
- strbuf_addf(reason, _(Removing worktrees/%s: gitdir file
points to non-existent location), id);
- return 1;
+ if (st.st_mtime = expire) {
+ strbuf_addf(reason, _(Removing worktrees/%s: gitdir file
points to non-existent location), id);
+ return 1;
+ } else {
+ return 0;
+ }
}
free(path);
- return st.st_mtime = expire;
+ return 0;
}
static void prune_worktrees(void)
diff --git a/t/t2026-prune-linked-checkouts.sh
b/t/t2026-prune-linked-checkouts.sh
index e885baf..1821a48 100755
--- a/t/t2026-prune-linked-checkouts.sh
+++ b/t/t2026-prune-linked-checkouts.sh
@@ -4,6 +4,10 @@ test_description='prune $GIT_DIR/worktrees'
. ./test-lib.sh
+test_expect_success initialize '
+ git commit --allow-empty -m init
+'
+
test_expect_success 'prune --worktrees on normal repo' '
git prune --worktrees
test_must_fail git prune --worktrees abc
@@ -77,8 +81,16 @@ test_expect_success 'not prune recent checkouts' '
mkdir zz
mkdir -p .git/worktrees/jlm
echo $(pwd)/zz .git/worktrees/jlm/gitdir
+ rmdir zz
git prune --worktrees --verbose --expire=2.days.ago
test -d .git/worktrees/jlm
'
+test_expect_success 'not prune proper checkouts' '
+ test_when_finished rm -r .git/worktrees
+ git checkout --to=$PWD/nop --detach master
+ git prune --worktrees
+ test -d .git/worktrees/nop
+'
+
test_done
--
2.3.4.2801.g3d0809b
--
Duy
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[bug (maybe)] Applying patch with '---'
Hi List, So I was just sent a patch generated with 'git format-patch' that 'git am' fails to apply correctly. It applies but part of the commit message is lost. The problem is that the commit message has lines like --- Foo happened did some things to handle Foo --- Bar happened Still processing update from Foo which led to a crash git mailinfo seems to discard everything after the first '--- Blah'. I know ^---$ is special but I thought ^---.+$ would be OK. I know git mailinfo shouldn't handle garbage input but I guess the problem I have is that the patch was generated by git format-patch so surely git mailinfo (and therefore git am) _should_ handle something generated by generated by git format-patch. Do people agree with my thinking? I'm not sure if it would be appropriate for git format-patch to produce a warning or for git mailinfo to tighten the matching of '---'. Regards, Chris -- 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: Clone from shallow bundle bug
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On 03/31/2015 06:17 PM, Junio C Hamano wrote: Phillip Susi ps...@ubuntu.com writes: I made a shallow clone of my repo, then used git bundle create to pack it all into a bundle file, then cloned from that bundle. I think the introdution of shallow clone feature broke git bundle create by not teaching it that its shallow boundaries are prerequisite commits to unbundle its contents. IOW, the bundle created from the shallow clone is broken, I would think. It seems to me that it isn't exactly broken; it just needs to put something in the bundle noting that it was built from a shallow clone, and then when cloning from the shallow bundle, the new clone needs its .git/shallow file. In other words, the bundle contains all of the objects in the shallow clone, so a new shallow clone can be correctly constructed from the bundle, it's just that the new clone doesn't *know* it too is shallow and things like git log and gitk need to stop following the history chain when they reach the shallow point rather than complain that the rest of the history is missing ( which is intentional ). For that matter, if you do create a depth limited bundle from a non shallow repository, then try to clone from it, the cloned repo should automatically become shallow rather than complain about missing history. In other words, any time you clone from a bundle, the clone process should check if the full history is in the bundle, and if not, automatically make the new repo shallow so as to avoid the error messages about the missing history. -BEGIN PGP SIGNATURE- Version: GnuPG v1 iQEcBAEBCgAGBQJVG15kAAoJENRVrw2cjl5RnvgH/iMyN/1U2zg+ju/teVEQIMRL prvC60S9/yLxSp6RmiXpN2xuGHMkn7i2y6XpM9RQdE6ETeGaIw7UaDan3r7BPTSD +Q9DrAM0g17IGNxvmGPiJZP7j0t2e43oTA9KM8alf6icMU/mWJgQsbtc9QFVfVkd jsYevK1GR6ysrAHBAV6GxKfNw5yw3N+kTf9s2rKXWIFaArD0rcKJZVxiygMlhVSa hT4j3+n5f3n0WMDVxFzhwOaW+yrPiXF3gs1pKFX8GT5g1BtvOAEnyskSgA5nZsNB G53ncyyefinaaBqCvPSbcTLXmWLV8QuLBExc13BWXiVUD2rRNQr7u1ihbxWKyvU= =D90B -END PGP SIGNATURE- -- 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: Trying to push into empty repo, get fatal: bad revision 'HEAD'
Junio C Hamano gits...@pobox.com writes:
Samuel Williams space.ship.travel...@gmail.com writes:
I would expect if you push to an empty repo, it would update it
(because denyCurrentBranch = updateInstead).
Good finding.
I think the current implementation of updateInstead is set up to
bootstrap from an empty repository but only supports incremental
updates once the receiving repository and its working tree gets set
up. But I do not think it was a conscious design decison to forbid
bootstrapping an empty repository, but was a mere gap in the
implementation. At least, I do not think of a reason why we should
forbid it (and I am Cc'ing Dscho to confirm).
Fixing it should not be too hard, but I am on a bus right now so...
A fix (or is it an enhancement) would probably look like this.
This is a tangent but I think we should unify the do we already
have history behind HEAD, or is the current branch still unborn
test done by various commands and tighten it. As a quick and dirty
hack, I just mimicked what builtin/merge.c seems to do, but this
would tell a detached HEAD that points at a nonsense object name
(i.e. abcde not a full 40-hex) as unborn, where we would be
better off stopping the operation instead of making the repository
breakage worse by doing further damage.
I originally suspected I'd need to fix the push_to_checkout()
codepath, too, but it turns out that the detection of unborn-ness
of the current branch is also outsourced to the push-to-checkout
hook, so I do not have to do anything special ;-)
builtin/receive-pack.c | 14 +-
1 file changed, 13 insertions(+), 1 deletion(-)
diff --git a/builtin/receive-pack.c b/builtin/receive-pack.c
index fc8ec9c..758b0b3 100644
--- a/builtin/receive-pack.c
+++ b/builtin/receive-pack.c
@@ -733,6 +733,13 @@ static int update_shallow_ref(struct command *cmd, struct
shallow_info *si)
return 0;
}
+static int head_has_history(void)
+{
+ unsigned char sha1[20];
+
+ return !get_sha1(HEAD, sha1);
+}
+
static const char *push_to_deploy(unsigned char *sha1,
struct argv_array *env,
const char *work_tree)
@@ -745,13 +752,15 @@ static const char *push_to_deploy(unsigned char *sha1,
};
const char *diff_index[] = {
diff-index, --quiet, --cached, --ignore-submodules,
- HEAD, --, NULL
+ NULL, --, NULL
};
const char *read_tree[] = {
read-tree, -u, -m, NULL, NULL
};
struct child_process child = CHILD_PROCESS_INIT;
+ int empty = !head_has_history();
+
child.argv = update_refresh;
child.env = env-argv;
child.dir = work_tree;
@@ -772,6 +781,9 @@ static const char *push_to_deploy(unsigned char *sha1,
if (run_command(child))
return Working directory has unstaged changes;
+ /* diff-index with either HEAD or an empty tree */
+ diff_index[4] = empty ? EMPTY_TREE_SHA1_HEX : HEAD;
+
child_process_init(child);
child.argv = diff_index;
child.env = env-argv;
--
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
RFC: git status --amend
Hi, for frontends or scripts it would be helpful to be able to use git status for getting the repository status compared to HEAD~1 instead of only HEAD (as provided by git commit --amend in the pre-filled commit message). Thus, I'm suggesting to add a --amend parameter (or a parameter with a better naming) to git status. What do you think of this idea? -- Best regards, Sven Strickroth PGP key id F5A9D4C4 @ any key-server -- 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] improve documentation for some commands that use pathspecs
After being surprised that git-ls-files expands pathspecs, here's a patch that would have saved me. --- Documentation/git-ls-files.txt | 9 + Documentation/git-ls-tree.txt | 8 2 files changed, 9 insertions(+), 8 deletions(-) diff --git a/Documentation/git-ls-files.txt b/Documentation/git-ls-files.txt index e26f01f..f7a3039 100644 --- a/Documentation/git-ls-files.txt +++ b/Documentation/git-ls-files.txt @@ -17,7 +17,7 @@ SYNOPSIS [--exclude-per-directory=file] [--exclude-standard] [--error-unmatch] [--with-tree=tree-ish] - [--full-name] [--abbrev] [--] [file...] + [--full-name] [--abbrev] [--] [pathspec...] DESCRIPTION --- @@ -101,7 +101,7 @@ OPTIONS --with-tree=tree-ish:: When using --error-unmatch to expand the user supplied - file (i.e. path pattern) arguments to paths, pretend + pathspec arguments to paths, pretend that paths which were removed in the index since the named tree-ish are still present. Using this option with `-s` or `-u` options does not make any sense. @@ -150,9 +150,10 @@ a space) at the start of each line: \--:: Do not interpret any more arguments as options. -file:: +pathspec:: Files to show. If no files are given all files which match the other - specified criteria are shown. + specified criteria are shown. (Note that this isn't really raw + pathnames, but rather a list of patterns to match.) Output -- diff --git a/Documentation/git-ls-tree.txt b/Documentation/git-ls-tree.txt index 16e87fd..58e7f64 100644 --- a/Documentation/git-ls-tree.txt +++ b/Documentation/git-ls-tree.txt @@ -11,7 +11,7 @@ SYNOPSIS [verse] 'git ls-tree' [-d] [-r] [-t] [-l] [-z] [--name-only] [--name-status] [--full-name] [--full-tree] [--abbrev[=n]] - tree-ish [path...] + tree-ish [pathspec...] DESCRIPTION --- @@ -19,11 +19,11 @@ Lists the contents of a given tree object, like what /bin/ls -a does in the current working directory. Note that: - the behaviour is slightly different from that of /bin/ls in that the - 'path' denotes just a list of patterns to match, e.g. so specifying + 'pathspec' denotes just a list of patterns to match, e.g. so specifying directory name (without '-r') will behave differently, and order of the arguments does not matter. - - the behaviour is similar to that of /bin/ls in that the 'path' is + - the behaviour is similar to that of /bin/ls in that the 'pathspec' is taken as relative to the current working directory. E.g. when you are in a directory 'sub' that has a directory 'dir', you can run 'git ls-tree -r HEAD dir' to list the contents of the tree (that is @@ -72,7 +72,7 @@ OPTIONS Do not limit the listing to the current working directory. Implies --full-name. -[path...]:: +[pathspec...]:: When paths are given, show them (note that this isn't really raw pathnames, but rather a list of patterns to match). Otherwise implicitly uses the root level of the tree as the sole path argument. -- 2.1.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] docs: Clarify what git-rebase's --preserve-merges does
Junio C Hamano gits...@pobox.com writes: I wonder if it will be the right way to get a correct result to apply the difference to go from B to Z on top of an old commit when you are side-porting. Imagine you want to backport the same X-Y history by redoing the merge Z on top of another child of O (i.e. A's sibling). That is, you start from this: X---Y / \ O---A---B---Z--- \ M---N and would want to create this: O X'--Y' \ / \ M---N---A'--B'--Z'-- As long as everything down to the merge-base of the parents of the original merge (in this example, merge-base across Y and B that are Z's parents, which is A) is being transplanted, apply the difference going from B to Z, on top of B', to obtain Z' should work, I would think. And just after I send the message because I needed to catch a bus, I notice that there is a problem. Actually, replay diff going from B to Z instead of merging must be done very carefully. Imagine when Y in the original history were a cherry-pick of M. What you would be creating would look more like this instead: O X'--. \ / \ M---N---A'--B'--Z'-- because Y' becomes a no-op, as the transplanted history already has M applied. But the original diff going from B to Z has the effect of M already in there. You would end up adding the same hunk twice without noticing. You somehow need to come up with a way to deal with this. If you did a real merge between X' and B' to recreate Z', you would not have such a problem. One way to be careful when recreating Z' out of Z might be: - Retry a merge between the original B and Y, with conflict markers intact; - Compare the result with what is recorded in Z. The differences are textual conflict resolution and evil merge changes; - Now try a merge between B' and Y', with conflict markers intact; - Apply the difference you obtained in the second step to the result of the third step. which is essentially the same as what rerere does. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] docs: Clarify what git-rebase's --preserve-merges does
Junio C Hamano gits...@pobox.com writes: Sergey Organov sorga...@gmail.com writes: 1. How to calculate the set of commits to rebase. 2. How to rebase merge commits. Can we leave (1) for a while at its current state and focus on (2)? Perhaps. You would have to be careful though, so let me think aloud a bit... Yeah, care should be taken indeed, and it's not trivial to foresee all possible troubles from changing to cherry-picking of merge commits. However, in general it looks like it's better to get some conflict to deal with from cherry-picking than to miss essential changes silently as it sometimes happens now. I also wonder if git remembers in merge commits what merge strategy was used? If not, then it's yet another argument in favor of cherry-picking. -- 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
Sergey Organov sorga...@gmail.com writes: 1. How to calculate the set of commits to rebase. 2. How to rebase merge commits. Can we leave (1) for a while at its current state and focus on (2)? Perhaps. You would have to be careful though, so let me think aloud a bit... Suppose you started from an upstream history whose tip was B, and you worked on merging some changes X an Y you made earlier on a side branch. X---Y / \ O---A---B---Z--- In the meantime, the upstream history has advance and now it looks like this: O---A---B---C---D You want to forward-port the change done by X, Y on the side branch and its merge Z on top of D, right? In other words, you want to have this: X---Y / \ O---A---B---C---D---Z' In this case, replaying the difference going from B to Z on top of D may be better than redoing a merge between Y and D, in that the former will carry evil merges and resolution of conflict forward. I wonder if it will be the right way to get a correct result to apply the difference to go from B to Z on top of an old commit when you are side-porting. Imagine you want to backport the same X-Y history by redoing the merge Z on top of another child of O (i.e. A's sibling). That is, you start from this: X---Y / \ O---A---B---Z--- \ M---N and would want to create this: O X'--Y' \ / \ M---N---A'--B'--Z'-- As long as everything down to the merge-base of the parents of the original merge (in this example, merge-base across Y and B that are Z's parents, which is A) is being transplanted, apply the difference going from B to Z, on top of B', to obtain Z' should work, I would think. -- 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] improve documentation for some commands that use pathspecs
Joey Hess jo...@joeyh.name writes: After being surprised that git-ls-files expands pathspecs, here's a patch that would have saved me. --- I have a vague recollection that we originally wanted to consistently say pathspec but some user friendliness folks wanted to avoid the term as much as possible---blaming might reveal this may be reverting the description to the original ;-). I like the general direction, but please sign-off your patch. @@ -150,9 +150,10 @@ a space) at the start of each line: \--:: Do not interpret any more arguments as options. -file:: +pathspec:: Files to show. If no files are given all files which match the other - specified criteria are shown. + specified criteria are shown. (Note that this isn't really raw + pathnames, but rather a list of patterns to match.) After updating the heading to pathspec, it would be clear that it is not listing filename but a specification to choose path with. I do not see the need for this added Note that. Perhaps what you need to update is the first sentence Files to show. It is more like Limit the paths to show with. or something, perhaps? Then the If no files are given part (which is wrong after your patch, because this is no longer talking about giving any file) can go. By default we show everything, and use of pathspecs is merely one of the ways to limit the output, and you would not want to repeat if this option is not given, all paths that match the other specified criteria are shown to all the other options that limit what is shown. -- 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 status --amend
Jeff King p...@peff.net writes:
On Tue, Mar 31, 2015 at 04:59:27PM +0200, Sven Strickroth wrote:
for frontends or scripts it would be helpful to be able to use git
status for getting the repository status compared to HEAD~1 instead of
only HEAD (as provided by git commit --amend in the pre-filled commit
message).
Thus, I'm suggesting to add a --amend parameter (or a parameter with a
better naming) to git status.
What do you think of this idea?
Once upon a time git status really was just git commit --dry-run.
These days it has diverged a bit. But I think you could get what you
want with:
git commit --dry-run --amend
It even supports alternate styles like --short.
I think everything you said is correct, but your diverged a bit
may hide one difference that could be crucial depending on the use
case: pathspec.
What git commit --dry-run [--other-options] pathspec does, and
what git status [--other-options] pathspec does, are different.
With or without --dry-run, to git commit, pathspec tells the
command to update the index at the paths specified by it from the
working tree contents before proceeding (the contents recorded for
the other paths depend on the use of -o or -i option). But ever
since git status departed from being git commit -n, a pathspec
given to the command means completely different thing.
After working on various parts of the tree, planning to conclude the
current work with commit, git status directory/ is a good way to
see what you did in that directory without seeing what you did
outside (which will be included in the commit, too).
But what you get from git commit --no-edit --dry-run directory/
would be different; it would show all the changes in the working
tree inside directory/, including the ones that you deliberately
left out of the index, as paths to be committed.
Having said all that, I am a bit torn on this topic. Just like git
status is a way to ask I've worked so far, planning to conclude
this with 'git commit'; tell me what I have achieved so far that are
in the index and in the working tree, possibly limiting to these
paths?, I think it is a reasonable thing to ask the same question
with s/git commit/git commit --amend/.
One workaround might be to
git reset --soft HEAD^
git status [pathspec]
...
git commit -c @{1}
but that is simply too error prone and ugly. I would say it would
be better if status knows how to answer that I am planning to
conclude with 'git commit --amend' question.
The reason why I am torn is because I do not think status --amend
is a sensible name for that option. status is not about amending
anything.
If the normal status is give me status for the next commit, this
new mode would be give me status for the 'commit --amend'. Naming
it git status --for-amend crossed my mind, but it does not sound
great to me, either.
So...
--
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: [PATCHv3 6/6] entry.c: fix a memleak
John Keeping j...@keeping.me.uk writes:
On Mon, Mar 30, 2015 at 06:22:11PM -0700, Stefan Beller wrote:
From: John Keeping j...@keeping.me.uk
stream_blob_to_fd() always frees the filter now, so there is no memory
leak in entry.c:152 just before the `goto finish`.
Signed-off-by: John Keeping j...@keeping.me.uk
Signed-off-by: Stefan Beller sbel...@google.com
---
I added Johns signoff here tentatively, John can you confirm the sign off?
Signed-off-by: John Keeping j...@keeping.me.uk
Thanks. I'll queue with a retitle, as this no longer is about
entry.c at all.
streaming.c | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/streaming.c b/streaming.c
index 2ff036a..811fcc2 100644
--- a/streaming.c
+++ b/streaming.c
@@ -507,8 +507,11 @@ int stream_blob_to_fd(int fd, unsigned const char
*sha1, struct stream_filter *f
int result = -1;
st = open_istream(sha1, type, sz, filter);
-if (!st)
+if (!st) {
+if (filter)
+free_stream_filter(filter);
return result;
+}
if (type != OBJ_BLOB)
goto close_and_exit;
for (;;) {
--
2.3.0.81.gc37f363
--
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: Allowing weak references to blobs and strong references to commits
From: Mike Hommey m...@glandium.org [...] So I thought, since commits are already allowed in tree objects, for submodules, why not add a bit to the mode that would tell git that those commit object references are meant to always be there aka strong reference, as opposed to the current weak references for submodules. I was thinking something like 020, which is above S_IFMT, but I haven't checked if mode is expected to be a short anywhere, maybe one of the file permission flags could be abused instead (sticky bit?). I could see this used in the future to e.g. implement a fetchable reflog (which could be a ref to a tree with strong references to commits). Then that got me thinking that the opposite would be useful to me as well: I'm currently storing mercurial manifests as git trees with (weak) commit references using the mercurial sha1s for files. Unfortunately, that doesn't allow to store the corresponding file permissions, so I'm going through hoops to get that. It would be simpler for me if I could just declare files or symlinks with the right permissions and say 'the corresponding blob doesn't need to exist'. I'm sure other tools using git as storage would have a use for such weak references. The weak references idea is something that's on my back list of Toh-Doh's for the purpose of having a Narrow clone. However it's not that easy as you need to consider three areas - what's on disk (worktree/file system), what's in the index, and what's in the object store and how a coherent view is kept of all three without breakage. The 'Sparse Checkout' / 'Skip Worktree' (see `git help read-tree`) covers the first two but not the third (which submodules does) [that's your 'the corresponding blob doesn't need to exist' aspect from my perspective] What do you think about this? Does that seem reasonable to have in git core, and if yes, how would you go about implementing it (same bit with different meaning for blobs and commits (or would you rather that were only done for commits and not for blobs)? what should I be careful about, besides making sure gc and fsck don't mess up?) Cheers, Mike 1. a git-remote-hg tool, https://github.com/glandium/git-cinnabar/ -- Philip -- 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] protocol upload-pack-v2
Junio C Hamano gits...@pobox.com writes: I have a feeling that it is a bit too premature to specify the details at such a low level as capaiblities are announced by prefixing four-byte 'c', 'a', 'p', ':' in front and a multi-record group has its element count at the beginning (or an end marker at the end, for that matter), and it may be a better idea to outline all the necessary elements at a bit higher level first---that would avoid needs for useless exchanges like what we are having right now. If you keep the discussion at the level like fetch first asks capabilities it wants upload-pack-2 to enable, optionally gives the current shallow boundaries when the capaibilty says the other side supports it, and then starts showing what it has while we are trying to achieve concensus on what kind of protocol elements we would need, and what information each element would carry, the discussion will help us reach a shared understanding on what to write down in EBNF form exactly faster, I would imagine. And I see we went silent after this, so let's try to stir the pot again to see if it simmers. This is a follow-up on $gmane/264553, which is a continuation of $gmane/264000, but instead of giving two required readings to readers, I'll start with reproduction of the two, and add a few more things the current protocol lacks that I would want to see in the updated protocol. The current protocol has the following problems that limit us: - It is not easy to make it resumable, because we recompute every time. This is especially problematic for the initial fetch aka clone as we will be talking about a large transfer. Redirection to a bundle hosted on CDN might be something we could do transparently. - The protocol extension has a fairly low length limit. - Because the protocol exchange starts by the server side advertising all its refs, even when the fetcher is interested in a single ref, the initial overhead is nontrivial, especially when you are doing a small incremental update. The worst case is an auto-builder that polls every five minutes, even when there is no new commits to be fetched. - Because we recompute every time, taking into account of what the fetcher has, in addition to what the fetcher obtained earlier from us in order to reduce the transferred bytes, the payload for incremental updates become tailor-made for each fetch and cannot be easily reused. - The semantics of the side-bands are unclear. - Is band #2 meant only for progress output (I think the current protocol handlers assume that and unconditionally squelch it under --quiet)? Do we rather want a dedicated progress and error message sidebands instead? - Is band #2 meant for human consumption, or do we expect the other end to interpret and act on it? If the former, would it make sense to send locale information from the client side and ask the server side to produce its output with _(message)? - The semantics of packet_flush() is suboptimal, and this shortcoming seeps through to the protocol mapped to the smart-HTTP transport. Originally, packet_flush() was meant as Here is an end of one logical section of what I am going to speak., hinting that it might be a good idea for the underlying implementation to hold the packets up to that point in-core and then write(2) them all out (i.e. flush) to the file descriptor only when we handle packet_flush(). It never meant Now I am finished speaking for now and it is your turn to speak. But because HTTP is inherently a ping-pong protocol where the requestor at one point stops talking and lets the responder speak, the code to map our protocol to the smart HTTP transport made the packet_flush() boundary as Now I am done talking, it is my turn to listen. We probably need two kinds of packet_flush(). When a requestor needs to say two or more logical groups of things before telling the other side Now I am done talking; it is your turn., we need some marker (i.e. the original meaning of packet_flush()) at the end of these logical groups. And in order to be able to say Now I am done saying everything I need to say at this point for you to respond to me. It is your turn., we need another kind of marker. - The fetch-pack direction does the common-parent discovery but the push-pack direction does not. This is OK for the normal fast-forward push, in which case we will see a known commit on the tip of the branch we are pushing into, but makes forced push inefficient. - The existing common-parent discovery done on the fetch-pack side enumerates commits contiguously traversing the history to the past. We might want to go exponential or Fibonacci to quickly find an ancient common commit and bisect the history from there (or it might turn out not to be worth it). - We may want to revamp the
Re: [PATCHv3 3/6] line-log.c: fix a memleak
Stefan Beller stefanbel...@gmail.com writes: On 30.03.2015 22:06, Junio C Hamano wrote: If add-line-range does not take ownership of parent_range from us, shouldn't we be freeing it whether we called it or not??? In my understanding it does take ownership of it. (According to my code review on friday) Hmmm. add_line_range() is given the parent_range as its third parameter, i.e. range. If there is nothing for the commit yet, it calls line_log_data_copy() on it to make a deep copy and stores that in new, which is then used as the decoration for the commit---the copy is what is retained. I am not quite sure what the lifetime rule is for the original of this deep copy, i.e. range, aka parent_range of the caller. Who holds pointers into it after this function is done? -- 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] init: don't set core.worktree when initializing /.git
Jeff King wrote:
No tests, as we would need to be able to write to / to do
so.
t1509-root-worktree.sh is supposed to test the repository-at-/ case.
But I wouldn't be surprised if it's bitrotted, since people don't set
up a throwaway chroot or VM for tests too often.
[...]
The current behavior isn't _wrong_, in the sense that it's OK to set
core.worktree when we don't need to. But I think it is unnecessarily
confusing to users who expect to be able to move .git directories
around, because it usually just works. So I'd call this an extremely
minor bug.
This belongs in the commit message.
[...]
--- a/builtin/init-db.c
+++ b/builtin/init-db.c
@@ -182,6 +182,21 @@ static int git_init_db_config(const char *k, const char
*v, void *cb)
return 0;
}
+/*
+ * If the git_dir is not directly inside the working tree, then git will not
+ * find it by default, and we need to set the worktree explicitly.
+ */
+static int needs_work_tree_config(const char *git_dir, const char *work_tree)
+{
+ /* special case that is missed by the general rule below */
(optional) I'd leave out this comment --- it seems obvious enough in
context and the purpose of the comment is unobvious without looking
at the history.
+ if (!strcmp(work_tree, /) !strcmp(git_dir, /.git))
+ return 0;
+ if (skip_prefix(git_dir, work_tree, git_dir)
+ !strcmp(git_dir, /.git))
+ return 0;
work_tree has been cleaned up with real_path, so in the normal case it
contains getcwd() output which will not end with a / unless it has to.
The only exception I can see is when git hits the MAXDEPTH limit for
symlink resolution (5 nested symlinks), in which case we take what we
find instead of erroring out, which looks like a bug.
We have called set_git_dir_init so git_dir has been cleaned up by
real_path in the same way. Good.
With or without the commit message, comment, and test improvements
mentioned above,
Reviewed-by: Jonathan Nieder jrnie...@gmail.com
Thanks.
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 0/6] implement @{push} shorthand
The basic idea is that in a triangular workflow, it's useful to be able
to refer to both @{upstream} and the place I would push to with a
shorthand. This idea was discussed over a year ago:
http://thread.gmane.org/gmane.comp.version-control.git/240144/focus=240198
I've found it useful since then, so I decided to clean it up and submit
it. This iteration renames it to @{push} (rather than @{publish}),
which is more descriptive. It's rebased, as there were some changes in
the area, and it also fixes some bugs in the original (of course, I may
also have _introduced_ bugs, as this is largely a rewrite that has not
had a year's worth of exercise).
I also took the opportunity to do some more aggressive refactoring of
the remote.c code, as there were some bits there that confused me every
time I looked at it. I think the result is easier to follow.
[1/6]: remote.c: drop default_remote_name variable
[2/6]: remote.c: drop remote pointer from struct branch
[3/6]: remote.c: hoist branch.*.remote lookup out of remote_get_1
[4/6]: remote.c: provide per-branch pushremote name
[5/6]: sha1_name: refactor upstream_mark
[6/6]: sha1_name: implement @{push} shorthand
The one thing I _didn't_ do here is refactor the logic in
builtin/push.c so what we could reuse it. There's still a switch
statement here on push_default. I don't like that, but I spent an hour
or so trying to pull out the push.c logic, and it got rather nasty.
There are a lot of global variables that get mutated by one-off
functions, and it all needs to happen in the right order. It looked like
any serious refactoring there is going to have a risk of regressions in
push.
So I punted on that. The simplified logic that is here in sha1_name is
not too bad, and I feel like we can unify the two at a later date if we
want to. And I'd much rather see bug reports like @{push} doesn't act
like git-push and deal with that, as opposed to your series breaks
push.
-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] enter_repo(): fix docs to match code
Jeff King p...@peff.net writes: I'm not sure that's true. The precedence changed, and the is it valid check changed. Yeah, I must have misread the review thread. I only noticed that the postimage does not have any lines that v1 changed from the original, but at the word level there indeed are these changes you listed above. Thanks. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 3/6] remote.c: hoist branch.*.remote lookup out of remote_get_1
We'll want to use this logic as a fallback when looking up
the pushremote, so let's pull it out into its own function.
We don't technically need to make this available outside of
remote.c, but doing so will provide a consistent API with
pushremote_for_branch, which we will add later.
Signed-off-by: Jeff King p...@peff.net
---
remote.c | 21 ++---
remote.h | 1 +
2 files changed, 15 insertions(+), 7 deletions(-)
diff --git a/remote.c b/remote.c
index d5fd605..9555904 100644
--- a/remote.c
+++ b/remote.c
@@ -693,6 +693,18 @@ static int valid_remote_nick(const char *name)
return !strchr(name, '/'); /* no slash */
}
+const char *remote_for_branch(struct branch *branch, int *explicit)
+{
+ if (branch branch-remote_name) {
+ if (explicit)
+ *explicit = 1;
+ return branch-remote_name;
+ }
+ if (explicit)
+ *explicit = 0;
+ return origin;
+}
+
static struct remote *remote_get_1(const char *name, const char
*pushremote_name)
{
struct remote *ret;
@@ -704,13 +716,8 @@ static struct remote *remote_get_1(const char *name, const
char *pushremote_name
if (pushremote_name) {
name = pushremote_name;
name_given = 1;
- } else {
- if (current_branch current_branch-remote_name) {
- name = current_branch-remote_name;
- name_given = 1;
- } else
- name = origin;
- }
+ } else
+ name = remote_for_branch(current_branch, name_given);
}
ret = make_remote(name, 0);
diff --git a/remote.h b/remote.h
index 4bb6672..2a7e7a6 100644
--- a/remote.h
+++ b/remote.h
@@ -211,6 +211,7 @@ struct branch {
};
struct branch *branch_get(const char *name);
+const char *remote_for_branch(struct branch *branch, int *explicit);
int branch_has_merge_config(struct branch *branch);
int branch_merge_matches(struct branch *, int n, const char *);
--
2.4.0.rc0.363.gf9f328b
--
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/6] remote.c: drop remote pointer from struct branch
When we create each branch struct, we fill in the
remote_name field from the config, and then fill in the
actual remote field based on that name. However, it turns
out that nobody really cares about this field. The only two
sites that access it are:
1. git-merge, which uses it to notice when the branch does
not have a remote defined. But we can easily replace this
with looking at remote_name instead.
2. remote.c itself, when setting up the @{upstream} merge
config. But we don't need to save the remote for
that; we can just look it up for the duration of the
operation.
Getting rid of it drops one potential source of confusion:
is the value the match for remote_name, or is it the
remote we would fetch from when on that branch (i.e., does
it fall back to origin)?
When we add pushremote_name, this question would get even
more confusing, as pushremotes have a more complicated
lookup procedure. It would be nice for the code to be
consistent between the remote and pushremote, and this takes
us one step closer.
Signed-off-by: Jeff King p...@peff.net
---
builtin/merge.c | 2 +-
remote.c| 14 --
remote.h| 1 -
3 files changed, 9 insertions(+), 8 deletions(-)
diff --git a/builtin/merge.c b/builtin/merge.c
index 3b0f8f9..1840317 100644
--- a/builtin/merge.c
+++ b/builtin/merge.c
@@ -955,7 +955,7 @@ static int setup_with_upstream(const char ***argv)
if (!branch)
die(_(No current branch.));
- if (!branch-remote)
+ if (!branch-remote_name)
die(_(No remote for the current branch.));
if (!branch-merge_nr)
die(_(No default upstream defined for the current branch.));
diff --git a/remote.c b/remote.c
index fcd868d..d5fd605 100644
--- a/remote.c
+++ b/remote.c
@@ -1633,15 +1633,20 @@ void set_ref_status_for_push(struct ref *remote_refs,
int send_mirror,
static void set_merge(struct branch *ret)
{
+ struct remote *remote;
char *ref;
unsigned char sha1[20];
int i;
+ if (!ret-remote_name || !ret-merge_nr)
+ return;
+ remote = remote_get(ret-remote_name);
+
ret-merge = xcalloc(ret-merge_nr, sizeof(*ret-merge));
for (i = 0; i ret-merge_nr; i++) {
ret-merge[i] = xcalloc(1, sizeof(**ret-merge));
ret-merge[i]-src = xstrdup(ret-merge_name[i]);
- if (!remote_find_tracking(ret-remote, ret-merge[i]) ||
+ if (!remote_find_tracking(remote, ret-merge[i]) ||
strcmp(ret-remote_name, .))
continue;
if (dwim_ref(ret-merge_name[i], strlen(ret-merge_name[i]),
@@ -1661,11 +1666,8 @@ struct branch *branch_get(const char *name)
ret = current_branch;
else
ret = make_branch(name, 0);
- if (ret ret-remote_name) {
- ret-remote = remote_get(ret-remote_name);
- if (ret-merge_nr)
- set_merge(ret);
- }
+ if (ret)
+ set_merge(ret);
return ret;
}
diff --git a/remote.h b/remote.h
index 02d66ce..4bb6672 100644
--- a/remote.h
+++ b/remote.h
@@ -203,7 +203,6 @@ struct branch {
const char *refname;
const char *remote_name;
- struct remote *remote;
const char **merge_name;
struct refspec **merge;
--
2.4.0.rc0.363.gf9f328b
--
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 v3] enter_repo(): fix docs to match code
Hi, On Wed, Apr 1, 2015 at 1:35 AM, Junio C Hamano gits...@pobox.com wrote: It appears to me that Peff's squash is nullifying everything you did, so a more truthful attribution might be From: Jeff King p...@peff.net commit log message S-o-b: Jeff S-o-b: Paul Tan Thanks, didn't know that could be done. Fixed patch (and fixed scissors line) below, -- 8 -- From: Jeff King p...@peff.net In b3256eb (standardize and improve lookup rules for external local repos), enter_repo() was modified to use a different precedence ordering of suffixes for DWIM of the repository path, and to ensure that the repository path is actually valid instead of just testing for existence. However, the documentation was not modified to reflect these changes. As such, fix the documentation to match the code. Signed-off-by: Jeff King p...@peff.net Signed-off-by: Paul Tan pyoka...@gmail.com --- path.c | 11 +++ 1 file changed, 3 insertions(+), 8 deletions(-) diff --git a/path.c b/path.c index e608993..595da81 100644 --- a/path.c +++ b/path.c @@ -303,14 +303,9 @@ return_null: * (3) relative/path to mean cwd relative directory; or * (4) /absolute/path to mean absolute directory. * - * Unless strict is given, we try access() for existence of %s.git/.git, - * %s/.git, %s.git, %s in this order. The first one that exists is - * what we try. - * - * Second, we try chdir() to that. Upon failure, we return NULL. - * - * Then, we try if the current directory is a valid git repository. - * Upon failure, we return NULL. + * Unless strict is given, we check %s/.git, %s, %s.git/.git, %s.git + * in this order. We select the first one that is a valid git repository, and + * chdir() to it. If none match, or we fail to chdir, we return NULL. * * If all goes well, we return the directory we used to chdir() (but * before ~user is expanded), avoiding getcwd() resolving symbolic -- 2.1.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: Forcing git top-level
On Tue, Mar 31, 2015 at 11:25:58AM +0200, Cedric Gava wrote:
I’ve copied a .git folder located at the root (/) of a filesystem,
into another directory (/home/mydir). If I issue a git rev-parse
—show-toplevel I got /...
I would like to change the top-level to point to /home/mydir.
Try running git config --unset core.worktree in the .git dir.
It looks like git init will write a core.worktree entry in this case,
even though it isn't technically needed. I think it is due to these
lines in builtin/init-db.c:
if (!starts_with(git_dir, work_tree) ||
strcmp(git_dir + strlen(work_tree), /.git)) {
git_config_set(core.worktree, work_tree);
}
The check returns a false positive for the root directory because we
only have one slash (i.e., appending /.git to our worktree would be
//.git in this case).
-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] enter_repo(): fix docs to match code
Paul Tan pyoka...@gmail.com writes: On Mon, Mar 30, 2015 at 07:44:08AM -0400, Jeff King wrote: Yes, this was adjusted in b3256eb (standardize and improve lookup rules for external local repos, 2012-02-02), but I failed to update the comment. Your patch is certainly an improvement, but I think there are more inaccuracies in the comment caused by that commit. Maybe squash this on top: Thanks for catching. I've squashed the patches and rewrote the commit message. --8-- In b3256eb (standardize and improve lookup rules for external local repos), enter_repo() was modified to use a different precedence ordering of suffixes for DWIM of the repository path, and to ensure that the repository path is actually valid instead of just testing for existence. However, the documentation was not modified to reflect these changes. As such, fix the documentation to match the code. Documentation contributed by Jeff King. Signed-off-by: Jeff King p...@peff.net Signed-off-by: Paul Tan pyoka...@gmail.com --- It appears to me that Peff's squash is nullifying everything you did, so a more truthful attribution might be From: Jeff King p...@peff.net commit log message S-o-b: Jeff S-o-b: Paul Tan Thanks. path.c | 11 +++ 1 file changed, 3 insertions(+), 8 deletions(-) diff --git a/path.c b/path.c index e608993..595da81 100644 --- a/path.c +++ b/path.c @@ -303,14 +303,9 @@ return_null: * (3) relative/path to mean cwd relative directory; or * (4) /absolute/path to mean absolute directory. * - * Unless strict is given, we try access() for existence of %s.git/.git, - * %s/.git, %s.git, %s in this order. The first one that exists is - * what we try. - * - * Second, we try chdir() to that. Upon failure, we return NULL. - * - * Then, we try if the current directory is a valid git repository. - * Upon failure, we return NULL. + * Unless strict is given, we check %s/.git, %s, %s.git/.git, %s.git + * in this order. We select the first one that is a valid git repository, and + * chdir() to it. If none match, or we fail to chdir, we return NULL. * * If all goes well, we return the directory we used to chdir() (but * before ~user is expanded), avoiding getcwd() resolving symbolic -- 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/6] remote.c: drop default_remote_name variable
When we read the remote config from disk, we update a
default_remote_name variable if we see branch.*.remote
config for the current branch. This isn't wrong, or even all
that complicated, but it is a bit simpler (because it
reduces our overall state) to just lazily compute the
default when we need it.
The ulterior motive here is that the push config uses a
similar structure, and _is_ much more complicated as a
result. That will be simplified in a future patch, and it's
more readable if the logic remotes and push-remotes matches.
Note that we also used default_remote_name as a signal that
the remote config has been loaded; after this patch, we now
use an explicit flag.
Signed-off-by: Jeff King p...@peff.net
---
remote.c | 24
1 file changed, 12 insertions(+), 12 deletions(-)
diff --git a/remote.c b/remote.c
index 68901b0..fcd868d 100644
--- a/remote.c
+++ b/remote.c
@@ -39,6 +39,8 @@ struct rewrites {
int rewrite_nr;
};
+static int loaded_remotes_config;
+
static struct remote **remotes;
static int remotes_alloc;
static int remotes_nr;
@@ -49,10 +51,8 @@ static int branches_alloc;
static int branches_nr;
static struct branch *current_branch;
-static const char *default_remote_name;
static const char *branch_pushremote_name;
static const char *pushremote_name;
-static int explicit_default_remote_name;
static struct rewrites rewrites;
static struct rewrites rewrites_push;
@@ -367,12 +367,7 @@ static int handle_config(const char *key, const char
*value, void *cb)
return 0;
branch = make_branch(name, subkey - name);
if (!strcmp(subkey, .remote)) {
- if (git_config_string(branch-remote_name, key, value))
- return -1;
- if (branch == current_branch) {
- default_remote_name = branch-remote_name;
- explicit_default_remote_name = 1;
- }
+ return git_config_string(branch-remote_name, key,
value);
} else if (!strcmp(subkey, .pushremote)) {
if (branch == current_branch)
if (git_config_string(branch_pushremote_name,
key, value))
@@ -504,9 +499,11 @@ static void read_config(void)
unsigned char sha1[20];
const char *head_ref;
int flag;
- if (default_remote_name) /* did this already */
+
+ if (loaded_remotes_config)
return;
- default_remote_name = origin;
+ loaded_remotes_config = 1;
+
current_branch = NULL;
head_ref = resolve_ref_unsafe(HEAD, 0, sha1, flag);
if (head_ref (flag REF_ISSYMREF)
@@ -708,8 +705,11 @@ static struct remote *remote_get_1(const char *name, const
char *pushremote_name
name = pushremote_name;
name_given = 1;
} else {
- name = default_remote_name;
- name_given = explicit_default_remote_name;
+ if (current_branch current_branch-remote_name) {
+ name = current_branch-remote_name;
+ name_given = 1;
+ } else
+ name = origin;
}
}
--
2.4.0.rc0.363.gf9f328b
--
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 status --amend
On Tue, Mar 31, 2015 at 04:59:27PM +0200, Sven Strickroth wrote: for frontends or scripts it would be helpful to be able to use git status for getting the repository status compared to HEAD~1 instead of only HEAD (as provided by git commit --amend in the pre-filled commit message). Thus, I'm suggesting to add a --amend parameter (or a parameter with a better naming) to git status. What do you think of this idea? Once upon a time git status really was just git commit --dry-run. These days it has diverged a bit. But I think you could get what you want with: git commit --dry-run --amend It even supports alternate styles like --short. -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
[PATCH 4/6] remote.c: provide per-branch pushremote name
When remote.c loads its config, it records the
branch.*.pushremote for the current branch along with the
global remote.pushDefault value, and then binds them into a
single value: the default push for the current branch. We
then pass this value (which may be NULL) to remote_get_1
when looking up a remote for push.
This has a few downsides:
1. It's confusing. The early-binding of the current
value led to bugs like the one fixed by 98b406f
(remote: handle pushremote config in any order,
2014-02-24). And the fact that pushremotes fall back to
ordinary remotes is not explicit at all; it happens
because remote_get_1 cannot tell the difference between
we are not asking for the push remote and there is
no push remote configured.
2. It throws away intermediate data. After read_config()
finishes, we have no idea what the value of
remote.pushDefault was, because the string has been
overwritten by the current branch's
branch.*.pushremote.
3. It doesn't record other data. We don't note the
branch.*.pushremote value for anything but the current
branch.
Let's make this more like the fetch-remote config. We'll
record the pushremote for each branch, and then explicitly
compute the correct remote for the current branch at the
time of reading.
Signed-off-by: Jeff King p...@peff.net
---
remote.c | 41 +++--
remote.h | 2 ++
2 files changed, 25 insertions(+), 18 deletions(-)
diff --git a/remote.c b/remote.c
index 9555904..8363bdb 100644
--- a/remote.c
+++ b/remote.c
@@ -51,7 +51,6 @@ static int branches_alloc;
static int branches_nr;
static struct branch *current_branch;
-static const char *branch_pushremote_name;
static const char *pushremote_name;
static struct rewrites rewrites;
@@ -369,9 +368,7 @@ static int handle_config(const char *key, const char
*value, void *cb)
if (!strcmp(subkey, .remote)) {
return git_config_string(branch-remote_name, key,
value);
} else if (!strcmp(subkey, .pushremote)) {
- if (branch == current_branch)
- if (git_config_string(branch_pushremote_name,
key, value))
- return -1;
+ return git_config_string(branch-pushremote_name, key,
value);
} else if (!strcmp(subkey, .merge)) {
if (!value)
return config_error_nonbool(key);
@@ -511,10 +508,6 @@ static void read_config(void)
current_branch = make_branch(head_ref, 0);
}
git_config(handle_config, NULL);
- if (branch_pushremote_name) {
- free((char *)pushremote_name);
- pushremote_name = branch_pushremote_name;
- }
alias_all_urls();
}
@@ -705,20 +698,32 @@ const char *remote_for_branch(struct branch *branch, int
*explicit)
return origin;
}
-static struct remote *remote_get_1(const char *name, const char
*pushremote_name)
+const char *pushremote_for_branch(struct branch *branch, int *explicit)
+{
+ if (branch branch-pushremote_name) {
+ if (explicit)
+ *explicit = 1;
+ return branch-pushremote_name;
+ }
+ if (pushremote_name) {
+ if (explicit)
+ *explicit = 1;
+ return pushremote_name;
+ }
+ return remote_for_branch(branch, explicit);
+}
+
+static struct remote *remote_get_1(const char *name, int for_push)
{
struct remote *ret;
int name_given = 0;
if (name)
name_given = 1;
- else {
- if (pushremote_name) {
- name = pushremote_name;
- name_given = 1;
- } else
- name = remote_for_branch(current_branch, name_given);
- }
+ else
+ name = for_push ?
+ pushremote_for_branch(current_branch, name_given) :
+ remote_for_branch(current_branch, name_given);
ret = make_remote(name, 0);
if (valid_remote_nick(name)) {
@@ -739,13 +744,13 @@ static struct remote *remote_get_1(const char *name,
const char *pushremote_name
struct remote *remote_get(const char *name)
{
read_config();
- return remote_get_1(name, NULL);
+ return remote_get_1(name, 0);
}
struct remote *pushremote_get(const char *name)
{
read_config();
- return remote_get_1(name, pushremote_name);
+ return remote_get_1(name, 1);
}
int remote_is_configured(const char *name)
diff --git a/remote.h b/remote.h
index 2a7e7a6..30a11da 100644
--- a/remote.h
+++ b/remote.h
@@ -203,6 +203,7 @@ struct branch {
const char *refname;
const char *remote_name;
+ const char *pushremote_name;
const char **merge_name;
struct
Re: [PATCH v2] enter_repo(): fix docs to match code
On Tue, Mar 31, 2015 at 10:35:56AM -0700, Junio C Hamano wrote: In b3256eb (standardize and improve lookup rules for external local repos), enter_repo() was modified to use a different precedence ordering of suffixes for DWIM of the repository path, and to ensure that the repository path is actually valid instead of just testing for existence. However, the documentation was not modified to reflect these changes. As such, fix the documentation to match the code. Documentation contributed by Jeff King. Signed-off-by: Jeff King p...@peff.net Signed-off-by: Paul Tan pyoka...@gmail.com --- It appears to me that Peff's squash is nullifying everything you did, so a more truthful attribution might be I'm not sure that's true. The precedence changed, and the is it valid check changed. The fix for the first is from Paul, but the latter is from me. My squash (hopefully) retained his half. My half just took more words to change. I'm OK with the attribution either way (I do not need the credit, but am happy to take the blame). -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
[PATCH 6/6] sha1_name: implement @{push} shorthand
In a triangular workflow, each branch may have two distinct
points of interest: the @{upstream} that you normally pull
from, and the destination that you normally push to. There
isn't a shorthand for the latter, but it's useful to have.
For instance, you may want to know which commits you haven't
pushed yet:
git log @{push}..
Or as a more complicated example, imagine that you normally
pull changes from origin/master (which you set as your
@{upstream}), and push changes to your own personal fork
(e.g., as myfork/topic). You may push to your fork from
multiple machines, requiring you to integrate the changes
from the push destination, rather than upstream. With this
patch, you can just do:
git rebase @{push}
rather than typing out the full name.
Signed-off-by: Jeff King p...@peff.net
---
As an aside, I messed up an -chain in the tests, which was caught by
GIT_TEST_CHAIN_LINT before submitting. The system works!
Documentation/revisions.txt | 25 +++
sha1_name.c | 102 +++-
t/t1514-rev-parse-push.sh | 63 +++
3 files changed, 189 insertions(+), 1 deletion(-)
create mode 100755 t/t1514-rev-parse-push.sh
diff --git a/Documentation/revisions.txt b/Documentation/revisions.txt
index 0796118..5d9df25 100644
--- a/Documentation/revisions.txt
+++ b/Documentation/revisions.txt
@@ -98,6 +98,31 @@ some output processing may assume ref names in UTF-8.
`branch.name.merge`). A missing branchname defaults to the
current one.
+'branchname@\{push\}', e.g. 'master@\{push\}', '@\{push\}'::
+ The suffix `@{push}` reports the branch where we would push to if
+ `git push` were run while `branchname` was checked out (or the current
+ `HEAD` is no branchname is specified). Since our push destination is
+ in a remote repository, of course, we report the local tracking branch
+ that corresponds to that branch (i.e., something in `refs/remotes/`).
++
+Here's an example to make it more clear:
++
+--
+$ git config push.default current
+$ git config remote.pushdefault myfork
+$ git checkout -b mybranch origin/master
+
+$ git rev-parse --symbolic-full-name @{upstream}
+refs/remotes/origin/master
+
+$ git rev-parse --symbolic-full-name @{push}
+refs/remotes/myfork/mybranch
+--
++
+Note in the example that we set up a triangular workflow, where we pull
+from one location and push to another. In a non-triangular workflow,
+`@{push}` is the same as `@{upstream}`, and there is no need for it.
+
'rev{caret}', e.g. 'HEAD{caret}, v1.5.1{caret}0'::
A suffix '{caret}' to a revision parameter means the first parent of
that commit object. '{caret}n' means the nth parent (i.e.
diff --git a/sha1_name.c b/sha1_name.c
index 3741ca3..1da3291 100644
--- a/sha1_name.c
+++ b/sha1_name.c
@@ -435,6 +435,12 @@ static inline int upstream_mark(const char *string, int
len)
return at_mark(string, len, suffix, ARRAY_SIZE(suffix));
}
+static inline int push_mark(const char *string, int len)
+{
+ const char *suffix[] = { @{push} };
+ return at_mark(string, len, suffix, ARRAY_SIZE(suffix));
+}
+
static int get_sha1_1(const char *name, int len, unsigned char *sha1, unsigned
lookup_flags);
static int interpret_nth_prior_checkout(const char *name, int namelen, struct
strbuf *buf);
@@ -482,7 +488,8 @@ static int get_sha1_basic(const char *str, int len,
unsigned char *sha1,
nth_prior = 1;
continue;
}
- if (!upstream_mark(str + at, len - at)) {
+ if (!upstream_mark(str + at, len - at)
+ !push_mark(str + at, len - at)) {
reflog_len = (len-1) - (at+2);
len = at;
}
@@ -1104,6 +,95 @@ static int interpret_upstream_mark(const char *name, int
namelen,
return len + at;
}
+static char *tracking_ref_for(struct remote *remote, const char *refname)
+{
+ char *ret;
+
+ ret = apply_refspecs(remote-fetch, remote-fetch_refspec_nr, refname);
+ if (!ret)
+ die(_(@{push} has no local tracking branch for remote '%s'),
+ refname);
+ return ret;
+}
+
+static char *get_push_branch(const char *name, int len)
+{
+ char *branch_name;
+ struct branch *branch;
+ struct remote *remote;
+
+ branch_name = xmemdupz(name, len);
+ branch = branch_get(*branch_name ? branch_name : NULL);
+ if (!branch)
+ die(_(HEAD does not point to a branch));
+ free(branch_name);
+
+ remote = remote_get(pushremote_for_branch(branch, NULL));
+ if (!remote)
+ die(_(branch '%s' has no remote for pushing), branch-name);
+
+ if
[PATCH] init: don't set core.worktree when initializing /.git
If you create a git repository in the root directory with
git init /, we erroneously write a core.worktree entry.
That can be surprising if you later move the .git directory
to another path (which usually moves the relative working
tree, but is foiled if there is an explicit worktree set).
The problem is that we check whether core.worktree is
necessary by seeing if we can make the git_dir by
concatenating /.git onto the working tree. That would lead
to //.git in this instance, but we actually have /.git
(without the doubled slash).
We can fix this by special-casing the root directory. I also
split the logic out into its own function to make the
conditional a bit more readable (and used skip_prefix, which
I think makes it a little more obvious what is going on).
No tests, as we would need to be able to write to / to do
so. I did manually confirm that:
sudo git init /
cd /
git rev-parse --show-toplevel
git config core.worktree
Still finds the top-level correctly (as /), and does not
set any core.worktree variable.
Signed-off-by: Jeff King p...@peff.net
---
The current behavior isn't _wrong_, in the sense that it's OK to set
core.worktree when we don't need to. But I think it is unnecessarily
confusing to users who expect to be able to move .git directories
around, because it usually just works. So I'd call this an extremely
minor bug.
builtin/init-db.c | 19 ---
1 file changed, 16 insertions(+), 3 deletions(-)
diff --git a/builtin/init-db.c b/builtin/init-db.c
index 6723d39..6efe2df 100644
--- a/builtin/init-db.c
+++ b/builtin/init-db.c
@@ -182,6 +182,21 @@ static int git_init_db_config(const char *k, const char
*v, void *cb)
return 0;
}
+/*
+ * If the git_dir is not directly inside the working tree, then git will not
+ * find it by default, and we need to set the worktree explicitly.
+ */
+static int needs_work_tree_config(const char *git_dir, const char *work_tree)
+{
+ /* special case that is missed by the general rule below */
+ if (!strcmp(work_tree, /) !strcmp(git_dir, /.git))
+ return 0;
+ if (skip_prefix(git_dir, work_tree, git_dir)
+ !strcmp(git_dir, /.git))
+ return 0;
+ return 1;
+}
+
static int create_default_files(const char *template_path)
{
const char *git_dir = get_git_dir();
@@ -274,10 +289,8 @@ static int create_default_files(const char *template_path)
/* allow template config file to override the default */
if (log_all_ref_updates == -1)
git_config_set(core.logallrefupdates, true);
- if (!starts_with(git_dir, work_tree) ||
- strcmp(git_dir + strlen(work_tree), /.git)) {
+ if (needs_work_tree_config(git_dir, work_tree))
git_config_set(core.worktree, work_tree);
- }
}
if (!reinit) {
--
2.4.0.rc0.363.gf9f328b
--
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: Allowing weak references to blobs and strong references to commits
Mike Hommey m...@glandium.org writes: So I thought, since commits are already allowed in tree objects, for submodules, why not add a bit to the mode that would tell git that those commit object references are meant to always be there aka strong reference, as opposed to the current weak references for submodules. Unless you are recording the paths to these commits to be potentially checked out on the filesystem, do not put them in a tree. The entries in a tree object represent This thing go to this path in the working tree. It is not clear to me (and because you said I won't bother you with all the whys and hows, I am guessing that it is OK for readers to be unclear), but I think you only want to make sure git fetch and git push transfers these objects, the graph formed by which is *not* any part of the main history of the project. It is perfectly OK to represent these objects as a special purpose history and have a ref point at its tip. The notes database is represented that way, for example. And I do not see anything wrong to use octopus merges in the history if you want to represent here are the commit objects that I care about at this point in the 'special purpose' history (not the main history). -- 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] gitweb.conf.txt: fix typo
Jakub Narębski jna...@gmail.com writes: On 2014-04-03 at 22:49, git-pa...@agt-the-walker.net wrote: From: Jérôme Zago git-pa...@agt-the-walker.net build-time is used everywhere else. Signed-off-by: Jérôme Zago git-pa...@agt-the-walker.net You are right, it is variable set during build process, not after project is built. ACK (for what it is worth). Acked-by: Jakub Narebski jna...@gmail.com Thanks; the patch is linewrapped but I can fix it up. It is funny to see an ack to a patch that is almost a year old, though ;-) --- Documentation/gitweb.conf.txt | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/Documentation/gitweb.conf.txt b/Documentation/gitweb.conf.txt index 952f503..8b25a2f 100644 --- a/Documentation/gitweb.conf.txt +++ b/Documentation/gitweb.conf.txt @@ -482,7 +482,7 @@ project config. Per-repository configuration takes precedence over value composed from `@git_base_url_list` elements and project name. + You can setup one single value (single entry/item in this list) at build -time by setting the `GITWEB_BASE_URL` built-time configuration variable. +time by setting the `GITWEB_BASE_URL` build-time configuration variable. By default it is set to (), i.e. an empty list. This means that gitweb would not try to create project URL (to fetch) from project name. -- 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:Make 2015 the best one yourself!
only now, Make 2015 the best one yourself! http://www.google.com/url?q=%68%74tp%3A%2F%2F%63%63%62%6ftcc%2ec%6369.r%75%2F%23852%39%6e%64%35%6d%31%6c6%67%74o%77sa=Dsntz=1usg=AFQjCNHmdUNh2YMyh5HH4xz0siXbLrN_CQ -- 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: Allowing weak references to blobs and strong references to commits
On March 31, 2015 3:55 PM Philip Oakley wrote: From: Mike Hommey m...@glandium.org [...] So I thought, since commits are already allowed in tree objects, for submodules, why not add a bit to the mode that would tell git that those commit object references are meant to always be there aka strong reference, as opposed to the current weak references for submodules. I was thinking something like 020, which is above S_IFMT, but I haven't checked if mode is expected to be a short anywhere, maybe one of the file permission flags could be abused instead (sticky bit?). I could see this used in the future to e.g. implement a fetchable reflog (which could be a ref to a tree with strong references to commits). Then that got me thinking that the opposite would be useful to me as well: I'm currently storing mercurial manifests as git trees with (weak) commit references using the mercurial sha1s for files. Unfortunately, that doesn't allow to store the corresponding file permissions, so I'm going through hoops to get that. It would be simpler for me if I could just declare files or symlinks with the right permissions and say 'the corresponding blob doesn't need to exist'. I'm sure other tools using git as storage would have a use for such weak references. The weak references idea is something that's on my back list of Toh-Doh's for the purpose of having a Narrow clone. However it's not that easy as you need to consider three areas - what's on disk (worktree/file system), what's in the index, and what's in the object store and how a coherent view is kept of all three without breakage. The 'Sparse Checkout' / 'Skip Worktree' (see `git help read-tree`) covers the first two but not the third (which submodules does) [that's your 'the corresponding blob doesn't need to exist' aspect from my perspective] What do you think about this? Does that seem reasonable to have in git core, and if yes, how would you go about implementing it (same bit with different meaning for blobs and commits (or would you rather that were only done for commits and not for blobs)? what should I be careful about, besides making sure gc and fsck don't mess up?) I don't know whether this is relevant or not - forgiveness requested in advance. It may be useful to store primarily the SHA1 for a weak object. In a product called RMS, this was called an External Reference. The file itself was not stored, but its signature was. It was possible to tell that the commit was validly and completely on disk, only if the signature matched (so git status would know). If the file was missing, or had an invalid signature, the working area was considered dirty (so git status would presumably report modified). All signatures were stored for these types of files, but the contents were not - hence external. Otherwise, we stored all other repository attributes - except the contents, with the obvious risks. This was typically used to track versions of the compilers and headers being used for builds, which we did not want to store in the repository, managed by a separate systems operations group, but wanted to know the signatures in case we had to go back in time. From my point of view, I would like to be able to have /usr/include (example only) as a working area where I can be 100% certain it contains what I expect it to contain, but I don't really want to store the objects in a repository - and may not have root anyway. Cheers, Randall -- Brief whoami: NonStopUNIX developer since approximately UNIX(421664400)/NonStop(2112884442) -- In my real life, I talk too much. -- 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
Clone from shallow bundle bug
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 I made a shallow clone of my repo, then used git bundle create to pack it all into a bundle file, then cloned from that bundle. The initial shallow clone has a .git/shallow file that identifies it as a shallow clone ( and I guess keeps things from complaining about the missing history ), but the the repo cloned from the bundle does not, so gitk run in that clone complains about not being able to find the objects referenced by the oldest commit in the repo. -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.17 (MingW32) iQEcBAEBAgAGBQJVGw03AAoJENRVrw2cjl5R4aQIAKxddA+eneEEchuygYwA8zFK 4O+LuEXbJ09JR196Zj535jbJ3NLre8KLX8l7gxVRFQ5FscG0+ylvawAZ2VCUrl+6 dfTXOTfzmu36GGKJ+wG7SFIIEAzjFyLk8bj5qtJgF3F3PZqkgxmBGmQskGK1Dlet VUqXL0IndMTDnb5//pFGyF2L5aPvBfXcC6pZAUBjKz4dl7MfFVXbuzCMe2TqN+l6 dPPjqANGb8MiAdhoVQ69c0uI2XH9dvmpRJTOX1Yr1IMW/AvKKM/w/A9MDKkhsab3 ccgeYDUjtUioaplnMcDwkSj4jQfQedgmIUdHeMbT0WOiKvHRArlroRVcjQS8pps= =kPAv -END PGP SIGNATURE- -- 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] t9814: Guarantee only one source exists in git-p4 copy tests
I'm on holiday this week, so I'll not get a chance to look at these properly until next week. Luke On 30 March 2015 at 04:03, Junio C Hamano gits...@pobox.com wrote: Vitor Antunes vitor@gmail.com writes: * Modify source file (file2) before copying the file. * Check that only file2 is the source in the output of p4 filelog. * Remove all case statements and replace them simple tests to check that source is file2. Signed-off-by: Vitor Antunes vitor@gmail.com --- I am not a Perfoce user, so I'd like to ask Pete's and Luke's comments on these changes. t/t9814-git-p4-rename.sh | 46 +++--- 1 file changed, 31 insertions(+), 15 deletions(-) diff --git a/t/t9814-git-p4-rename.sh b/t/t9814-git-p4-rename.sh index 8b9c295..d8fb22d 100755 --- a/t/t9814-git-p4-rename.sh +++ b/t/t9814-git-p4-rename.sh @@ -132,6 +132,9 @@ test_expect_success 'detect copies' ' cd $git git config git-p4.skipSubmitEdit true + echo file8 file2 Style: please lose SP between redirection and its target, i.e. echo file8 file2 The same comment applies to everywhere else. + git commit -a -m Differentiate file2 + git p4 submit cp file2 file8 git add file8 git commit -a -m Copy file2 to file8 @@ -140,6 +143,10 @@ test_expect_success 'detect copies' ' p4 filelog //depot/file8 p4 filelog //depot/file8 | test_must_fail grep -q branch from + echo file9 file2 + git commit -a -m Differentiate file2 + git p4 submit + cp file2 file9 git add file9 git commit -a -m Copy file2 to file9 @@ -149,28 +156,39 @@ test_expect_success 'detect copies' ' p4 filelog //depot/file9 p4 filelog //depot/file9 | test_must_fail grep -q branch from + echo file10 file2 + git commit -a -m Differentiate file2 + git p4 submit + echo file2 file2 cp file2 file10 git add file2 file10 git commit -a -m Modify and copy file2 to file10 git diff-tree -r -C HEAD + src=$(git diff-tree -r -C HEAD | sed 1d | sed 2d | cut -f2) + test $src = file2 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 + + echo file11 file2 + git commit -a -m Differentiate file2 + git p4 submit 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) - case $src in - file2 | file10) : ;; # happy - *) false ;; # not - esac + test $src = file2 git config git-p4.detectCopiesHarder true git p4 submit p4 filelog //depot/file11 - p4 filelog //depot/file11 | grep -q branch from //depot/file + p4 filelog //depot/file11 | grep -q branch from //depot/file2 + + echo file12 file2 + git commit -a -m Differentiate file2 + git p4 submit cp file2 file12 echo some text file12 @@ -180,15 +198,16 @@ test_expect_success 'detect copies' ' level=$(git diff-tree -r -C --find-copies-harder HEAD | sed 1d | cut -f1 | cut -d -f5 | sed s/C0*//) 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 - *) false ;; # not - esac + test $src = file2 git config git-p4.detectCopies $(($level + 2)) git p4 submit p4 filelog //depot/file12 p4 filelog //depot/file12 | test_must_fail grep -q branch from + echo file13 file2 + git commit -a -m Differentiate file2 + git p4 submit + cp file2 file13 echo different text file13 git add file13 @@ -197,14 +216,11 @@ test_expect_success 'detect copies' ' level=$(git diff-tree -r -C --find-copies-harder HEAD | sed 1d | cut -f1 | cut -d -f5 | sed s/C0*//) 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
[PATCH v2] enter_repo(): fix docs to match code
On Mon, Mar 30, 2015 at 07:44:08AM -0400, Jeff King wrote: Yes, this was adjusted in b3256eb (standardize and improve lookup rules for external local repos, 2012-02-02), but I failed to update the comment. Your patch is certainly an improvement, but I think there are more inaccuracies in the comment caused by that commit. Maybe squash this on top: Thanks for catching. I've squashed the patches and rewrote the commit message. --8-- In b3256eb (standardize and improve lookup rules for external local repos), enter_repo() was modified to use a different precedence ordering of suffixes for DWIM of the repository path, and to ensure that the repository path is actually valid instead of just testing for existence. However, the documentation was not modified to reflect these changes. As such, fix the documentation to match the code. Documentation contributed by Jeff King. Signed-off-by: Jeff King p...@peff.net Signed-off-by: Paul Tan pyoka...@gmail.com --- path.c | 11 +++ 1 file changed, 3 insertions(+), 8 deletions(-) diff --git a/path.c b/path.c index e608993..595da81 100644 --- a/path.c +++ b/path.c @@ -303,14 +303,9 @@ return_null: * (3) relative/path to mean cwd relative directory; or * (4) /absolute/path to mean absolute directory. * - * Unless strict is given, we try access() for existence of %s.git/.git, - * %s/.git, %s.git, %s in this order. The first one that exists is - * what we try. - * - * Second, we try chdir() to that. Upon failure, we return NULL. - * - * Then, we try if the current directory is a valid git repository. - * Upon failure, we return NULL. + * Unless strict is given, we check %s/.git, %s, %s.git/.git, %s.git + * in this order. We select the first one that is a valid git repository, and + * chdir() to it. If none match, or we fail to chdir, we return NULL. * * If all goes well, we return the directory we used to chdir() (but * before ~user is expanded), avoiding getcwd() resolving symbolic -- 2.1.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: Allowing weak references to blobs and strong references to commits
On Tue, Mar 31, 2015 at 4:14 PM, Jonathan Nieder jrnie...@gmail.com wrote: Mike Hommey wrote: Octopus merges are limited to 16 parents. The note about this in fast-import is out of date (e.g., see t/t7602-merge-octopus-many.sh and v1.6.0-rc0~194, 2008-06-27). How about this patch? Ahh, I thought we eradicated all mentions of that ancient limit back then. Thanks for catching. -- 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
Trying to push into empty repo, get fatal: bad revision 'HEAD'
I have set up a remote repository like so: remote $ cat .git/config [core] repositoryformatversion = 0 filemode = true bare = false logallrefupdates = true sharedrepository = 1 worktree = /srv/http/www.site.com [receive] denyNonFastforwards = true denyCurrentBranch = updateInstead This repo is empty by default. When I try to push into it, I get the following: local $ git push --set-upstream production master Counting objects: 29, done. Delta compression using up to 8 threads. Compressing objects: 100% (27/27), done. Writing objects: 100% (29/29), 1.13 MiB | 0 bytes/s, done. Total 29 (delta 3), reused 17 (delta 0) fatal: bad revision 'HEAD' To ssh://remote.net/srv/http/www.site.com ! [remote rejected] master - master (Working directory has staged changes) error: failed to push some refs to 'ssh://remote.net/srv/http/www.site.com' Is this expected? Am I doing something wrong? Or, is this a bug in Git? I would expect if you push to an empty repo, it would update it (because denyCurrentBranch = updateInstead). Thanks -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH V2] t9814: Guarantee only one source exists in git-p4 copy tests
* Modify source file (file2) before copying the file. * Check that only file2 is the source in the output of p4 filelog. * Remove all case statements and replace them with simple tests to check that source is file2. Signed-off-by: Vitor Antunes vitor@gmail.com --- t/t9814-git-p4-rename.sh | 46 +++--- 1 file changed, 31 insertions(+), 15 deletions(-) diff --git a/t/t9814-git-p4-rename.sh b/t/t9814-git-p4-rename.sh index 8b9c295..99bb71b 100755 --- a/t/t9814-git-p4-rename.sh +++ b/t/t9814-git-p4-rename.sh @@ -132,6 +132,9 @@ test_expect_success 'detect copies' ' cd $git git config git-p4.skipSubmitEdit true + echo file8 file2 + git commit -a -m Differentiate file2 + git p4 submit cp file2 file8 git add file8 git commit -a -m Copy file2 to file8 @@ -140,6 +143,10 @@ test_expect_success 'detect copies' ' p4 filelog //depot/file8 p4 filelog //depot/file8 | test_must_fail grep -q branch from + echo file9 file2 + git commit -a -m Differentiate file2 + git p4 submit + cp file2 file9 git add file9 git commit -a -m Copy file2 to file9 @@ -149,28 +156,39 @@ test_expect_success 'detect copies' ' p4 filelog //depot/file9 p4 filelog //depot/file9 | test_must_fail grep -q branch from + echo file10 file2 + git commit -a -m Differentiate file2 + git p4 submit + echo file2 file2 cp file2 file10 git add file2 file10 git commit -a -m Modify and copy file2 to file10 git diff-tree -r -C HEAD + src=$(git diff-tree -r -C HEAD | sed 1d | sed 2d | cut -f2) + test $src = file2 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 + + echo file11 file2 + git commit -a -m Differentiate file2 + git p4 submit 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) - case $src in - file2 | file10) : ;; # happy - *) false ;; # not - esac + test $src = file2 git config git-p4.detectCopiesHarder true git p4 submit p4 filelog //depot/file11 - p4 filelog //depot/file11 | grep -q branch from //depot/file + p4 filelog //depot/file11 | grep -q branch from //depot/file2 + + echo file12 file2 + git commit -a -m Differentiate file2 + git p4 submit cp file2 file12 echo some text file12 @@ -180,15 +198,16 @@ test_expect_success 'detect copies' ' level=$(git diff-tree -r -C --find-copies-harder HEAD | sed 1d | cut -f1 | cut -d -f5 | sed s/C0*//) 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 - *) false ;; # not - esac + test $src = file2 git config git-p4.detectCopies $(($level + 2)) git p4 submit p4 filelog //depot/file12 p4 filelog //depot/file12 | test_must_fail grep -q branch from + echo file13 file2 + git commit -a -m Differentiate file2 + git p4 submit + cp file2 file13 echo different text file13 git add file13 @@ -197,14 +216,11 @@ test_expect_success 'detect copies' ' level=$(git diff-tree -r -C --find-copies-harder HEAD | sed 1d | cut -f1 | cut -d -f5 | sed s/C0*//) 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 - *) false ;; # not - esac + test $src = file2 git config git-p4.detectCopies $(($level - 2)) git p4 submit p4 filelog //depot/file13 - p4 filelog //depot/file13 | grep -q branch from //depot/file + p4 filelog
Re: Allowing weak references to blobs and strong references to commits
On Tue, Mar 31, 2015 at 04:14:49PM -0700, Jonathan Nieder wrote: Mike Hommey wrote: Octopus merges are limited to 16 parents. The note about this in fast-import is out of date (e.g., see t/t7602-merge-octopus-many.sh and v1.6.0-rc0~194, 2008-06-27). How about this patch? Aha! I wasn't stoned! Thanks for fixing this :) Mike -- 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: Trying to push into empty repo, get fatal: bad revision 'HEAD'
Samuel Williams space.ship.travel...@gmail.com writes: I would expect if you push to an empty repo, it would update it (because denyCurrentBranch = updateInstead). Good finding. I think the current implementation of updateInstead is set up to bootstrap from an empty repository but only supports incremental updates once the receiving repository and its working tree gets set up. But I do not think it was a conscious design decison to forbid bootstrapping an empty repository, but was a mere gap in the implementation. At least, I do not think of a reason why we should forbid it (and I am Cc'ing Dscho to confirm). Fixing it should not be too hard, but I am on a bus right now so... -- 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 6/6] sha1_name: implement @{push} shorthand
On Tue, Mar 31, 2015 at 1:38 PM, Jeff King p...@peff.net wrote:
Signed-off-by: Jeff King p...@peff.net
---
diff --git a/Documentation/revisions.txt b/Documentation/revisions.txt
index 0796118..5d9df25 100644
--- a/Documentation/revisions.txt
+++ b/Documentation/revisions.txt
@@ -98,6 +98,31 @@ some output processing may assume ref names in UTF-8.
`branch.name.merge`). A missing branchname defaults to the
current one.
+'branchname@\{push\}', e.g. 'master@\{push\}', '@\{push\}'::
+ The suffix `@{push}` reports the branch where we would push to if
+ `git push` were run while `branchname` was checked out (or the current
+ `HEAD` is no branchname is specified). Since our push destination is
s/is no/if no/
+ in a remote repository, of course, we report the local tracking branch
+ that corresponds to that branch (i.e., something in `refs/remotes/`).
++
+Here's an example to make it more clear:
++
+--
+$ git config push.default current
+$ git config remote.pushdefault myfork
+$ git checkout -b mybranch origin/master
+
+$ git rev-parse --symbolic-full-name @{upstream}
+refs/remotes/origin/master
+
+$ git rev-parse --symbolic-full-name @{push}
+refs/remotes/myfork/mybranch
+--
++
+Note in the example that we set up a triangular workflow, where we pull
+from one location and push to another. In a non-triangular workflow,
+`@{push}` is the same as `@{upstream}`, and there is no need for it.
+
'rev{caret}', e.g. 'HEAD{caret}, v1.5.1{caret}0'::
A suffix '{caret}' to a revision parameter means the first parent of
that commit object. '{caret}n' means the nth parent (i.e.
--
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 4/6] remote.c: provide per-branch pushremote name
Jeff King p...@peff.net writes: Let's make this more like the fetch-remote config. We'll record the pushremote for each branch, and then explicitly compute the correct remote for the current branch at the time of reading. Signed-off-by: Jeff King p...@peff.net --- remote.c | 41 +++-- remote.h | 2 ++ 2 files changed, 25 insertions(+), 18 deletions(-) Very nicely done. Thanks. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: VCS popularity
On 1 April 2015 at 00:03, David Lang da...@lang.hm wrote: On Tue, 31 Mar 2015, Øyvind A. Holm wrote: openhub.net (formerly ohloh.net) has an interesting comparison of the number of public repositories on the net, based on searches of popular hosting services. This comparison is available at https://www.openhub.net/repositories/compare and shows an estimated market share between Bazaar, CVS, Git, Mercurial and Subversion. I've been monitoring this since 2014-08-05 to see how things were developing, and it's a good indication of the popularity of the various version control systems. number of repositories is an interesting datapoint, but activity in the repos would be far more interesting. There are a lot of repos of various types out there that haven't been touched for years. I do agree on that. Many repositories won't be deleted if they are converted to other VC systems to avoid breaking links and so on. What I found pretty interesting is the relative growth between the various systems. That's why I created the graphs that show creation of new repositories since August 2014 instead, for example https://github.com/sunny256/openhub-repositories/blob/master/graph/relative-zoom.svg - Øyvind -- 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: Clone from shallow bundle bug
Phillip Susi ps...@ubuntu.com writes: I made a shallow clone of my repo, then used git bundle create to pack it all into a bundle file, then cloned from that bundle. I think the introdution of shallow clone feature broke git bundle create by not teaching it that its shallow boundaries are prerequisite commits to unbundle its contents. IOW, the bundle created from the shallow clone is broken, I would think. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/6] remote.c: drop remote pointer from struct branch
On Tue, Mar 31, 2015 at 01:50:05PM -0700, Junio C Hamano wrote: Getting rid of it drops one potential source of confusion: is the value the match for remote_name, or is it the remote we would fetch from when on that branch (i.e., does it fall back to origin)? I had to read the above three times before I realized that you were wondering what is the value of this 'remote' field? is it what remote_get() would give us for 'remote_name' and is NULL if remote_name is not set, or is it never NULL and instead have the remote for 'origin' if remote_name is not set? But perhaps it is just me. We certainly have duplicated information between the two fields, and it first looked somewhat unnatural that you kept the name with which you need to trigger a search for the structure, instead of keeping the structure, one of whose field is its name already. Perhaps there was a valid reason behind this choice, and I am guessing that it is probably because it will not let you differenciate the case where the user explicitly said 'origin' and we used 'origin' as a fallback, if you keep a remote field that stores the instance of the remote structure for 'origin' without keeping remote_name. That is the reason I was trying to explain above. Though I suppose you could argue that remote_name suffers the same question (i.e., would we ever set it to origin?) It is much worse for pushremotes, which can come from branch.*.pushremote, remote.pushdefault, branch.*.remote, or origin. I'll try to re-word the commit message. -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 6/6] sha1_name: implement @{push} shorthand
Jeff King p...@peff.net writes:
diff --git a/Documentation/revisions.txt b/Documentation/revisions.txt
index 0796118..5d9df25 100644
--- a/Documentation/revisions.txt
+++ b/Documentation/revisions.txt
@@ -98,6 +98,31 @@ some output processing may assume ref names in UTF-8.
`branch.name.merge`). A missing branchname defaults to the
current one.
+'branchname@\{push\}', e.g. 'master@\{push\}', '@\{push\}'::
+ The suffix `@{push}` reports the branch where we would push to if
The corresponding description for upstream begins like this:
The suffix '@\{upstream\}' to a branchname (short form 'branchname@\{u\}')
and makes me wonder if the existing backslashes are unnecessary, or
if you forgot to use them in the new text.
@@ -1104,6 +,95 @@ static int interpret_upstream_mark(const char *name,
int namelen,
return len + at;
}
+static char *tracking_ref_for(struct remote *remote, const char *refname)
+{
+ char *ret;
+
+ ret = apply_refspecs(remote-fetch, remote-fetch_refspec_nr, refname);
+ if (!ret)
+ die(_(@{push} has no local tracking branch for remote '%s'),
+ refname);
I would imagine that it would be very plausible that anybody with a
specific remote and the name of the ref that appears on that remote
would want to learn the local name of the remote-tracking ref we use
to track it.
But the error message limits the callers only to those who are
involved in @{push} codepath. Shouldn't the error check be done in
the caller instead, anticipating the day this useful function ceases
to be static?
I would suspect that such a change would make it just a one-liner,
but I think this helper that takes remote and their refname is much
easier to read than four inlined calls to apply_refspecs() that have
to spell out remote-fetch, remote-fetch_refspec_nr separately.
Perhaps we would want
struct refspecs {
int nr, alloc;
const char **refspec;
} fetch_refspec;
in struct remote, instead of these two separate fields, and then
make apply_refspecs() take struct refspecs *? I haven't checked
and thought enough to decide if we want struct refspec * also in
that new struct, though.
--
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: VCS popularity
On Tue, 31 Mar 2015, Øyvind A. Holm wrote: openhub.net (formerly ohloh.net) has an interesting comparison of the number of public repositories on the net, based on searches of popular hosting services. This comparison is available at https://www.openhub.net/repositories/compare and shows an estimated market share between Bazaar, CVS, Git, Mercurial and Subversion. I've been monitoring this since 2014-08-05 to see how things were developing, and it's a good indication of the popularity of the various version control systems. I've created a repository at https://github.com/sunny256/openhub-repositories where the project scripts and data files are stored, along with graphs in SVG format. The graphs are pretty interesting: https://github.com/sunny256/openhub-repositories/blob/master/graph/relative.svg Graphs of relative growth between the various version control systems. https://github.com/sunny256/openhub-repositories/blob/master/graph/relative-zoom.svg Zoomed-in version of relative.svg. Git goes through the ceiling. https://github.com/sunny256/openhub-repositories/blob/master/graph/repos.svg Total number of repositories. number of repositories is an interesting datapoint, but activity in the repos would be far more interesting. There are a lot of repos of various types out there that haven't been touched for years. David Lang
VCS popularity
openhub.net (formerly ohloh.net) has an interesting comparison of the number of public repositories on the net, based on searches of popular hosting services. This comparison is available at https://www.openhub.net/repositories/compare and shows an estimated market share between Bazaar, CVS, Git, Mercurial and Subversion. I've been monitoring this since 2014-08-05 to see how things were developing, and it's a good indication of the popularity of the various version control systems. I've created a repository at https://github.com/sunny256/openhub-repositories where the project scripts and data files are stored, along with graphs in SVG format. The graphs are pretty interesting: https://github.com/sunny256/openhub-repositories/blob/master/graph/relative.svg Graphs of relative growth between the various version control systems. https://github.com/sunny256/openhub-repositories/blob/master/graph/relative-zoom.svg Zoomed-in version of relative.svg. Git goes through the ceiling. https://github.com/sunny256/openhub-repositories/blob/master/graph/repos.svg Total number of repositories. - Øyvind -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/6] remote.c: drop default_remote_name variable
On Tue, Mar 31, 2015 at 01:37:35PM -0700, Junio C Hamano wrote: When we read the remote config from disk, we update a default_remote_name variable if we see branch.*.remote config for the current branch. This isn't wrong, or even all that complicated, but it is a bit simpler (because it reduces our overall state) to just lazily compute the default when we need it. The ulterior motive here is that the push config uses a similar structure, and _is_ much more complicated as a result. That will be simplified in a future patch, and it's more readable if the logic remotes and push-remotes matches. I cannot quite parse the part after if...; the logic used by remotes and push-remotes matches? Sorry, it should have been ...if the logic for remotes and push-remotes matches. +static int loaded_remotes_config; + I expect that the reason why this is not a function scope static in read_config() will be revealed in the later patch in this series... No, it's not used. I was leaving it as an out in case somebody ever needed to reset it in order to re-read the config, but I agree it is probably better to let them pull it out of the function if and when that happens. -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 1/6] remote.c: drop default_remote_name variable
Jeff King p...@peff.net writes:
When we read the remote config from disk, we update a
default_remote_name variable if we see branch.*.remote
config for the current branch. This isn't wrong, or even all
that complicated, but it is a bit simpler (because it
reduces our overall state) to just lazily compute the
default when we need it.
The ulterior motive here is that the push config uses a
similar structure, and _is_ much more complicated as a
result. That will be simplified in a future patch, and it's
more readable if the logic remotes and push-remotes matches.
I cannot quite parse the part after if...; the logic used by
remotes and push-remotes matches?
Note that we also used default_remote_name as a signal that
the remote config has been loaded; after this patch, we now
use an explicit flag.
Signed-off-by: Jeff King p...@peff.net
---
remote.c | 24
1 file changed, 12 insertions(+), 12 deletions(-)
diff --git a/remote.c b/remote.c
index 68901b0..fcd868d 100644
--- a/remote.c
+++ b/remote.c
@@ -39,6 +39,8 @@ struct rewrites {
int rewrite_nr;
};
+static int loaded_remotes_config;
+
I expect that the reason why this is not a function scope static in
read_config() will be revealed in the later patch in this series...
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/6] remote.c: drop remote pointer from struct branch
Jeff King p...@peff.net writes:
When we create each branch struct, we fill in the
remote_name field from the config, and then fill in the
actual remote field based on that name. However, it turns
out that nobody really cares about this field. The only two
sites that access it are:
1. git-merge, which uses it to notice when the branch does
not have a remote defined. But we can easily replace this
with looking at remote_name instead.
2. remote.c itself, when setting up the @{upstream} merge
config. But we don't need to save the remote for
that; we can just look it up for the duration of the
operation.
Getting rid of it drops one potential source of confusion:
is the value the match for remote_name, or is it the
remote we would fetch from when on that branch (i.e., does
it fall back to origin)?
I had to read the above three times before I realized that you were
wondering what is the value of this 'remote' field? is it what
remote_get() would give us for 'remote_name' and is NULL if
remote_name is not set, or is it never NULL and instead have the
remote for 'origin' if remote_name is not set?
But perhaps it is just me.
We certainly have duplicated information between the two fields, and
it first looked somewhat unnatural that you kept the name with which
you need to trigger a search for the structure, instead of keeping
the structure, one of whose field is its name already. Perhaps
there was a valid reason behind this choice, and I am guessing that
it is probably because it will not let you differenciate the case
where the user explicitly said 'origin' and we used 'origin' as a
fallback, if you keep a remote field that stores the instance of
the remote structure for 'origin' without keeping remote_name.
But we shouldn't leave it for readers to guess.
When we add pushremote_name, this question would get even
more confusing, as pushremotes have a more complicated
lookup procedure. It would be nice for the code to be
consistent between the remote and pushremote, and this takes
us one step closer.
Signed-off-by: Jeff King p...@peff.net
---
builtin/merge.c | 2 +-
remote.c| 14 --
remote.h| 1 -
3 files changed, 9 insertions(+), 8 deletions(-)
diff --git a/builtin/merge.c b/builtin/merge.c
index 3b0f8f9..1840317 100644
--- a/builtin/merge.c
+++ b/builtin/merge.c
@@ -955,7 +955,7 @@ static int setup_with_upstream(const char ***argv)
if (!branch)
die(_(No current branch.));
- if (!branch-remote)
+ if (!branch-remote_name)
die(_(No remote for the current branch.));
if (!branch-merge_nr)
die(_(No default upstream defined for the current branch.));
diff --git a/remote.c b/remote.c
index fcd868d..d5fd605 100644
--- a/remote.c
+++ b/remote.c
@@ -1633,15 +1633,20 @@ void set_ref_status_for_push(struct ref *remote_refs,
int send_mirror,
static void set_merge(struct branch *ret)
{
+ struct remote *remote;
char *ref;
unsigned char sha1[20];
int i;
+ if (!ret-remote_name || !ret-merge_nr)
+ return;
+ remote = remote_get(ret-remote_name);
+
ret-merge = xcalloc(ret-merge_nr, sizeof(*ret-merge));
for (i = 0; i ret-merge_nr; i++) {
ret-merge[i] = xcalloc(1, sizeof(**ret-merge));
ret-merge[i]-src = xstrdup(ret-merge_name[i]);
- if (!remote_find_tracking(ret-remote, ret-merge[i]) ||
+ if (!remote_find_tracking(remote, ret-merge[i]) ||
strcmp(ret-remote_name, .))
continue;
if (dwim_ref(ret-merge_name[i], strlen(ret-merge_name[i]),
@@ -1661,11 +1666,8 @@ struct branch *branch_get(const char *name)
ret = current_branch;
else
ret = make_branch(name, 0);
- if (ret ret-remote_name) {
- ret-remote = remote_get(ret-remote_name);
- if (ret-merge_nr)
- set_merge(ret);
- }
+ if (ret)
+set_merge(ret);
return ret;
}
diff --git a/remote.h b/remote.h
index 02d66ce..4bb6672 100644
--- a/remote.h
+++ b/remote.h
@@ -203,7 +203,6 @@ struct branch {
const char *refname;
const char *remote_name;
- struct remote *remote;
const char **merge_name;
struct refspec **merge;
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/6] remote.c: drop remote pointer from struct branch
Jeff King p...@peff.net writes: On Tue, Mar 31, 2015 at 01:50:05PM -0700, Junio C Hamano wrote: it first looked somewhat unnatural that you kept the name with which you need to trigger a search for the structure, instead of keeping the structure, one of whose field is its name already. ... That is the reason I was trying to explain above. Though I suppose you could argue that remote_name suffers the same question (i.e., would we ever set it to origin?) Well, another would be that by keeping remote_name and making remote on-demand, we may still have to keep all the defined branches in core but we do not have to instanciate all the remotes, if each branch only knows the remote_name. A single look-up may be cheap but that is not a good reason to do one-per-each-branch if we do not need to. It is much worse for pushremotes, which can come from branch.*.pushremote, remote.pushdefault, branch.*.remote, or origin. I'll try to re-word the commit message. Thanks. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: VCS popularity
On 1 April 2015 at 00:20, Junio C Hamano gits...@pobox.com wrote: Øyvind A. Holm su...@sunbase.org writes: The graphs are pretty interesting: https://github.com/sunny256/openhub-repositories/blob/master/graph/relative.svg Graphs of relative growth between the various version control systems. This plots us at a bit over 8000. What does this number mean, exactly? Since 2014-08-01, the number of Git repositories Ohloh knows about has grown 8000-fold? Or is it just 80-fold (8000%) growth? Or 8000 more repositories were created? Yes, relative.svg and relative-zoom.svg show the number of new repositories found by Open Hub. To be specific, these are the numbers: Bazaar: 75 CVS: 59 Git: 8230 Mercurial: 215 Subversion: 607 These numbers can of course be discussed, but as a source, I believe Open Hub should be one of the more objective ones. - Øyvind -- 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
A kind reminder
Dear Invited Author, You could also upload your invited paper in our conferences in Zakynthos Island, Greece, July 16-20, 2015. Check them via www. inase. org and www. cscc. co Invited Paper implies journal publication in ISI (Web of Knowledge) and SCOPUS and double time of presentation during the conference. These conferences are based in Special Sessions and Minisymposia that Invited Speakers organize. We anticipate more than 100 Special Sessions and Minisymposia for July 2015 The Proceedings are published in CD and in hard-copy and are included in Web of Knowledge ISI Thomson, SCOPUS, IET, Elsevier, ACM, AMS, DBLP etc... Especially for the Invited Authors we will have publication in more than 40 Journals of Web of Knowledge ISI Thomson. We have received 39 Invited Special Sessions until now. Please, check: www. cscc. co Successful Session / Workshop Organizers will be benefited by a)* Free Participaaejlmpwtion b) * Financial Support c) * They will be included in the Committee of INASE 2016 d) They will be Editors in the Proceedings of INASE 2015 Invited Authors are marked in the Program as Invited Authors; they have also double time for presentation than the normal papers. Thanks, Zoe Michel Do you want to be removed from our future Invitations? Send an Empty (Blank) email to inase.editor...@gmail.com with Subject: - BLOCK git@vger.kernel.org - (Attention: The main part of your email, the so-called Body must be empty, otherwise the command of unsubscription will not be executed. The command - BLOCK git@vger.kernel.org - must be ONLY in the Subject Line of your 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 6/6] sha1_name: implement @{push} shorthand
On Tue, Mar 31, 2015 at 02:37:25PM -0700, Junio C Hamano wrote:
Jeff King p...@peff.net writes:
diff --git a/Documentation/revisions.txt b/Documentation/revisions.txt
index 0796118..5d9df25 100644
--- a/Documentation/revisions.txt
+++ b/Documentation/revisions.txt
@@ -98,6 +98,31 @@ some output processing may assume ref names in UTF-8.
`branch.name.merge`). A missing branchname defaults to the
current one.
+'branchname@\{push\}', e.g. 'master@\{push\}', '@\{push\}'::
+ The suffix `@{push}` reports the branch where we would push to if
The corresponding description for upstream begins like this:
The suffix '@\{upstream\}' to a branchname (short form 'branchname@\{u\}')
and makes me wonder if the existing backslashes are unnecessary, or
if you forgot to use them in the new text.
They are necessary inside single-quotes, but not inside backticks. IMHO
this entire file should be using backticks, but I didn't want to
reformat the entire file (and so I tried to at least keep the heading in
the same style as the rest of it).
+static char *tracking_ref_for(struct remote *remote, const char *refname)
+{
+ char *ret;
+
+ ret = apply_refspecs(remote-fetch, remote-fetch_refspec_nr, refname);
+ if (!ret)
+ die(_(@{push} has no local tracking branch for remote '%s'),
+ refname);
I would imagine that it would be very plausible that anybody with a
specific remote and the name of the ref that appears on that remote
would want to learn the local name of the remote-tracking ref we use
to track it.
I am not sure I understand. We do _not_ have a local name we use to
track it. That is the error. I can print remote %s does not have branch
%s, if that is what you mean.
But the error message limits the callers only to those who are
involved in @{push} codepath. Shouldn't the error check be done in
the caller instead, anticipating the day this useful function ceases
to be static?
Is it really a useful general function? If you remove the die() message,
it is literally a one-liner. My purpose in pulling it out at all was not
to repeat the die() message over and over in get_push_branch().
I would suspect that such a change would make it just a one-liner,
but I think this helper that takes remote and their refname is much
easier to read than four inlined calls to apply_refspecs() that have
to spell out remote-fetch, remote-fetch_refspec_nr separately.
Perhaps we would want
struct refspecs {
int nr, alloc;
const char **refspec;
} fetch_refspec;
in struct remote, instead of these two separate fields, and then
make apply_refspecs() take struct refspecs *? I haven't checked
and thought enough to decide if we want struct refspec * also in
that new struct, though.
I think it is more complicated, as there are actually two arrays indexed
by each {fetch,push}_refspec_nr. We have fetch_respec, which contains
the text (I assume), and then the struct refspec. So ideally those
would be stored together in a single list, but of course many helper
functions want just the struct refspec list. So you still end up with
two lists, but just pushed down into a single struct. I guess that's
better, but I was trying to find a bound to my refactoring rather than
touching all of the code. :-/
-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
[ANNOUNCE] Git v2.3.5
The latest maintenance release Git v2.3.5 is now available at
the usual places. It is comprised of 31 non-merge commits since
v2.3.4, contributed by 11 people, 2 of which are new faces.
This hopefully will be the last update for v2.3.x series before the
next feature release v2.4, as we flushed all the fixes that have
been cooking on the 'master' front.
The tarballs are found at:
https://www.kernel.org/pub/software/scm/git/
The following public repositories all have a copy of the 'v2.3.5'
tag and the 'maint' 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
New contributors whose contributions weren't in v2.3.4 are as follows.
Welcome to the Git development community!
Cody A Taylor, and Wilhelm Schuermann.
Returning contributors who helped this release are as follows.
Thanks for your continued support.
Jeff King, John Szakmeister, Junio C Hamano, Nguyễn Thái
Ngọc Duy, Phil Hord, Sebastian Schuberth, SZEDER Gábor,
Thomas Ackermann, and Thomas Gummerer.
Git v2.3.5 Release Notes
Fixes since v2.3.4
--
* The prompt script (in contrib/) did not show the untracked sign
when working in a subdirectory without any untracked files.
* Even though git grep --quiet is run merely to ask for the exit
status, we spawned the pager regardless. Stop doing that.
* Recommend format-patch and send-email for those who want to submit
patches to this project.
* 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.
* git fetch that fetches a commit using the allow-tip-sha1-in-want
extension could have failed to fetch all the requested refs.
* The split-index mode introduced at v2.3.0-rc0~41 was broken in the
codepath to protect us against a broken reimplementation of Git
that writes an invalid index with duplicated index entries, etc.
* 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.
* git tag -h used to show the --column and --sort options
that are about listing in a wrong section.
* The transfer.hiderefs support did not quite work for smart-http
transport.
* The code that reads from the ctags file in the completion script
(in contrib/) did not spell ${param/pattern/string} substitution
correctly, which happened to work with bash but not with zsh.
* The explanation on rebase --preserve-merges, pull --rebase=preserve,
and push --force-with-lease in the documentation was unclear.
Also contains typofixes, documentation updates and trivial code clean-ups.
Changes since v2.3.4 are as follows:
Cody A Taylor (1):
git prompt: use toplevel to find untracked files
Jeff King (15):
tag: fix some mis-organized options in -h listing
upload-pack: fix transfer.hiderefs over smart-http
upload-pack: do not check NULL return of lookup_unknown_object
sha1fd_check: die when we cannot open the file
clone: initialize atexit cleanup handler earlier
clone: drop period from end of die_errno message
filter_ref: avoid overwriting ref-old_sha1 with garbage
filter_ref: make a copy of extra sought entries
fetch_refs_via_pack: free extra copy of refs
fetch-pack: remove dead assignment to ref-new_sha1
t5312: test object deletion code paths in a corrupted repository
refs: introduce a ref paranoia flag
prune: turn on ref_paranoia flag
repack: turn on ref paranoia when doing a destructive repack
refs.c: drop curate_packed_refs
John Szakmeister (1):
contrib/completion: escape the forward slash in __git_match_ctag
Junio C Hamano (5):
SubmittingPatches: encourage users to use format-patch and send-email
report_path_error(): move to dir.c
Update mailmap to spell out Alexander Kuleshov
Prepare for 2.3.5
Git 2.3.5
Nguyễn Thái Ngọc Duy (1):
git.txt: list index versions in plain English
Phil Hord (1):
git-push.txt: clean up force-with-lease wording
SZEDER Gábor (1):
completion: use __gitcomp_nl() for completing refs
Sebastian Schuberth (2):
docs: clarify preserve option wording for git-pull
docs: clarify what git-rebase's -p / --preserve-merges does
Thomas Ackermann (1):
2.3.2 release notes: typofix
Thomas Gummerer (2):
t1700: make test pass with index-v4
read-cache: fix reading of split index
Wilhelm Schuermann (1):
Re: [PATCH 6/6] sha1_name: implement @{push} shorthand
Jeff King p...@peff.net writes:
+static char *tracking_ref_for(struct remote *remote, const char *refname)
+{
+ char *ret;
+
+ ret = apply_refspecs(remote-fetch, remote-fetch_refspec_nr, refname);
+ if (!ret)
+ die(_(@{push} has no local tracking branch for remote '%s'),
+ refname);
I would imagine that it would be very plausible that anybody with a
specific remote and the name of the ref that appears on that remote
would want to learn the local name of the remote-tracking ref we use
to track it.
I am not sure I understand. We do _not_ have a local name we use to
track it. That is the error. I can print remote %s does not have branch
%s, if that is what you mean.
No, I am not saying we should not detect an error.
But the error message limits the callers only to those who are
involved in @{push} codepath. Shouldn't the error check be done in
the caller instead, anticipating the day this useful function ceases
to be static?
Is it really a useful general function?
I often interact with this remote called 'ko'. Do I have remote-tracking
branch to keep track of its 'master' branch, and if so, what is it?
Isn't that the question that the apply_refspecs() is answering?
If you remove the die() message,
it is literally a one-liner.
Yes, I thought I said that here...
I would suspect that such a change would make it just a one-liner,
but I think this helper that takes remote and their refname is much
easier to read than four inlined calls to apply_refspecs() that have
to spell out remote-fetch, remote-fetch_refspec_nr separately.
Perhaps we would want
struct refspecs {
int nr, alloc;
const char **refspec;
} fetch_refspec;
in struct remote, instead of these two separate fields, and then
make apply_refspecs() take struct refspecs *? I haven't checked
and thought enough to decide if we want struct refspec * also in
that new struct, though.
I think it is more complicated, as there are actually two arrays indexed
by each {fetch,push}_refspec_nr. We have fetch_respec, which contains
the text (I assume), and then the struct refspec.
Yeah, I thought I said that, too ;-)
So ideally those
would be stored together in a single list, but of course many helper
functions want just the struct refspec list. So you still end up with
two lists, but just pushed down into a single struct. I guess that's
better, but I was trying to find a bound to my refactoring rather than
touching all of the code. :-/
OK.
--
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: Allowing weak references to blobs and strong references to commits
Mike Hommey wrote: Octopus merges are limited to 16 parents. The note about this in fast-import is out of date (e.g., see t/t7602-merge-octopus-many.sh and v1.6.0-rc0~194, 2008-06-27). How about this patch? -- 8-- Subject: fast-import doc: remove suggested 16-parent limit Merges with an absurd number of parents are still a bad idea because they do not render well in tools like gitk, but if they are present in the repository being imported into git then there's no need to avoid reproducing them faithfully. In olden times, before v1.6.0-rc0~194 (2008-06-27), git commit-tree and higher-level tools built on top of it were limited to writing 16 parents for a commit. Nowadays normal git operations are happy to write more parents when asked, so the motivation for this note in the fast-import documentation is gone and we can remove it. Signed-off-by: Jonathan Nieder jrnie...@gmail.com --- Thanks, Jonathan Documentation/git-fast-import.txt | 7 ++- 1 file changed, 2 insertions(+), 5 deletions(-) diff --git a/Documentation/git-fast-import.txt b/Documentation/git-fast-import.txt index f71fb01..773584e 100644 --- a/Documentation/git-fast-import.txt +++ b/Documentation/git-fast-import.txt @@ -506,11 +506,8 @@ If the `from` command is omitted when creating a new branch, the first `merge` commit will be the first ancestor of the current commit, and the branch will start out with no files. An unlimited number of `merge` commands per -commit are permitted by fast-import, thereby establishing an n-way merge. -However Git's other tools never create commits with more than 15 -additional ancestors (forming a 16-way merge). For this reason -it is suggested that frontends do not use more than 15 `merge` -commands per commit; 16, if starting a new, empty branch. +commit are permitted by fast-import and other git commands, thereby +establishing an n-way merge. Here `commit-ish` is any of the commit specification expressions also accepted by `from` (see above). -- 2.2.0.rc0.207.ga3a616c -- 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: VCS popularity
On Wed, 1 Apr 2015, Øyvind A. Holm wrote: On 1 April 2015 at 00:20, Junio C Hamano gits...@pobox.com wrote: Øyvind A. Holm su...@sunbase.org writes: The graphs are pretty interesting: https://github.com/sunny256/openhub-repositories/blob/master/graph/relative.svg Graphs of relative growth between the various version control systems. This plots us at a bit over 8000. What does this number mean, exactly? Since 2014-08-01, the number of Git repositories Ohloh knows about has grown 8000-fold? Or is it just 80-fold (8000%) growth? Or 8000 more repositories were created? Yes, relative.svg and relative-zoom.svg show the number of new repositories found by Open Hub. To be specific, these are the numbers: Bazaar: 75 CVS: 59 Git: 8230 Mercurial: 215 Subversion: 607 These numbers can of course be discussed, but as a source, I believe Open Hub should be one of the more objective ones. How many of these 8230 git repositories are duplicates of each other on github (to pick a specific example). the distributed nature of DVCS systems is going to inflate their count vs non-distributed VCS systems where there is only one copy. I believe that Git encourages making personal copies public more than Mercurial does (with github being the extreme case) David Lang
Re: Allowing weak references to blobs and strong references to commits
Jonathan Nieder wrote: How about this patch? I think I botched the wording. Here's a second try. -- 8 -- Subject: fast-import doc: remove suggested 16-parent limit Merges with an absurd number of parents are still a bad idea because they do not render well in tools like gitk, but if they are present in the repository being imported into git then there's no need to avoid reproducing them faithfully. In olden times, before v1.6.0-rc0~194 (2008-06-27), git commit-tree and higher-level tools built on top of it were limited to writing 16 parents for a commit. Nowadays normal git operations are happy to write more parents when asked, so the motivation for this note in the fast-import documentation is gone and we can remove it. Signed-off-by: Jonathan Nieder jrnie...@gmail.com --- Documentation/git-fast-import.txt | 4 1 file changed, 4 deletions(-) diff --git a/Documentation/git-fast-import.txt b/Documentation/git-fast-import.txt index f71fb01..690fed3 100644 --- a/Documentation/git-fast-import.txt +++ b/Documentation/git-fast-import.txt @@ -507,10 +507,6 @@ omitted when creating a new branch, the first `merge` commit will be the first ancestor of the current commit, and the branch will start out with no files. An unlimited number of `merge` commands per commit are permitted by fast-import, thereby establishing an n-way merge. -However Git's other tools never create commits with more than 15 -additional ancestors (forming a 16-way merge). For this reason -it is suggested that frontends do not use more than 15 `merge` -commands per commit; 16, if starting a new, empty branch. Here `commit-ish` is any of the commit specification expressions also accepted by `from` (see above). -- -- 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-p4: fix filetype detection on files opened exclusively
If a Perforce server is configured to automatically set +l (exclusive lock) on add of certain file types, git p4 submit will fail during getP4OpenedType, as the regex doesn't expect the trailing '*exclusive*' from p4 opened: //depot/file.png#1 - add default change (binary+l) *exclusive* Signed-off-by: Blair Holloway blair_hollo...@playstation.sony.com --- git-p4.py | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/git-p4.py b/git-p4.py index ff132b2..d43482a 100755 --- a/git-p4.py +++ b/git-p4.py @@ -368,7 +368,7 @@ def getP4OpenedType(file): # Returns the perforce file type for the given file. result = p4_read_pipe([opened, wildcard_encode(file)]) -match = re.match(.*\((.+)\)\r?$, result) +match = re.match(.*\((.+)\)( \*exclusive\*)?\r?$, result) if match: return match.group(1) else: -- 1.8.3.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: [PATCH 6/6] sha1_name: implement @{push} shorthand
On Tue, Mar 31, 2015 at 05:41:02PM -0400, Eric Sunshine wrote:
On Tue, Mar 31, 2015 at 1:38 PM, Jeff King p...@peff.net wrote:
Signed-off-by: Jeff King p...@peff.net
---
diff --git a/Documentation/revisions.txt b/Documentation/revisions.txt
index 0796118..5d9df25 100644
--- a/Documentation/revisions.txt
+++ b/Documentation/revisions.txt
@@ -98,6 +98,31 @@ some output processing may assume ref names in UTF-8.
`branch.name.merge`). A missing branchname defaults to the
current one.
+'branchname@\{push\}', e.g. 'master@\{push\}', '@\{push\}'::
+ The suffix `@{push}` reports the branch where we would push to if
+ `git push` were run while `branchname` was checked out (or the current
+ `HEAD` is no branchname is specified). Since our push destination is
s/is no/if no/
Thanks, fixed for my re-roll.
-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: Allowing weak references to blobs and strong references to commits
On Tue, Mar 31, 2015 at 01:23:23PM -0700, Junio C Hamano wrote: Mike Hommey m...@glandium.org writes: So I thought, since commits are already allowed in tree objects, for submodules, why not add a bit to the mode that would tell git that those commit object references are meant to always be there aka strong reference, as opposed to the current weak references for submodules. Unless you are recording the paths to these commits to be potentially checked out on the filesystem, do not put them in a tree. The entries in a tree object represent This thing go to this path in the working tree. It is not clear to me (and because you said I won't bother you with all the whys and hows, I am guessing that it is OK for readers to be unclear), but I think you only want to make sure git fetch and git push transfers these objects, the graph formed by which is *not* any part of the main history of the project. Transfer is not the main reason I have those refs, although it's a nice plus. I'm using the git database as a storage for metadata I need to keep track of the remote mercurial content that isn't part of the content history represented in the corresponding git history. Obviously, this isn't meant to be checked out, like a notes tree. The refs are only there so that a) git-cinnabar can find its data and b) git gc doesn't remove it. It is perfectly OK to represent these objects as a special purpose history and have a ref point at its tip. The notes database is represented that way, for example. Indeed, the notes database is in a similar situation. But the fact that in my use-case (cloning Mozilla mercurial repositories) _thousands_ of refs are involved is not really making it user-friendly. I'd rather hide those away from users. And I do not see anything wrong to use octopus merges in the history if you want to represent here are the commit objects that I care about at this point in the 'special purpose' history (not the main history). Octopus merges are limited to 16 parents. That means to merge thousands of refs, I need to do that on at least 3 levels, involving hundreds of commit objects, many of which would become loose quickly, or become extra noise in the metadata branches... and while researching this further, I realize it doesn't seem there is such a limit to the number of parents for octopus merges. Where did I get that from? Was there such a limit in the past or was I high? That being said, having names associated with those tips _is_ useful to me (it allows to know the corresponding mercurial sha1 and branch without having to do a note lookup for each), and a tree of commits would help, here, although I could put a tree of weak refs to commits as the content of an octopus merge... So I guess I could live without the strong commit refs. Weak blob refs would still be useful, though. Mike -- 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: Allowing weak references to blobs and strong references to commits
Mike Hommey m...@glandium.org writes: Octopus merges are limited to 16 parents. Huh? -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: bug patch: exit codes from internal commands are handled incorrectly
Ping? The original version of this got some discussion, but this version -
nothing.
Thanks,
Keni
On Feb 1, 2015, at 5:32 PM, Kenneth Lorber k...@his.com wrote:
On Dec 18, 2014, at 2:18 PM, Junio C Hamano gits...@pobox.com wrote:
Kenneth Lorber k...@his.com writes:
Bug: exit codes from (at least) internal commands are handled incorrectly.
E.g. git-merge-file, docs say:
The exit value of this program is negative on error, and the number of
conflicts otherwise. If the merge was clean, the exit value is 0.
But only 8 bits get carried through exit, so 256 conflicts gives
exit(0), which means the merge was clean.
Wouldn't any cmd_foo() that returns negative to main() be buggy?
Yes.
Your change sweeps such problems under the rug, which is not a
healthy thing to do.
Agreed. (See below.)
Expecting that the exit code can signal small positive integers and
other generic kinds of failures is a losing proposition. I think it
is a better fix to update cmd_merge_file() to return 1 (when ret is
positive), 0 (when ret is zero) or 128 (when ret is negative), or
something simple like that, and update the documentation to match
that, without touching git.c::main().
The new patch uses 0, 1, and 2 to match diff(1).
Among the in-tree users, I notice git-cvsserver.perl is already
using the command incorrectly. It does this:
my $return = system(git, merge-file, $file_local, $file_old,
$file_new);
$return = 8;
cleanupTmpDir();
if ( $return == 0 )
{
$log-info(Merged successfully);
...
}
elsif ( $return == 1 )
{
$log-info(Merged with conflicts);
...
}
else
{
$log-warn(Merge failed);
next;
}
which assumes $return == 1 is special half-good, which is not
consistent with the documented interface. It will incorrectly
say Merge failed when there are two or more conflicts.
And with such a 1 or 0 or -1 change, you will fix that caller as
well ;-)
I'll call that a win.
The attached patch covers the following:
- fixes all places where make test attempts to call exit() with a value 0
or 255
- changes git-merge-file.txt to reflect the change in exit codes
- fixes the exit codes for merge-file
- adds a warning (which should probably be changed to something clearer) if
git.c:run_builtin() is going to cause an out-of-bounds exit
- fixes a typo in t7007-show.sh
- replaces return(0) with exit(0) in test-parse-options.c
The diff is cut against 15598cf41beed0d86cd2ac443e0f69c5a3b40321 (2.3.0-rc2)
Thanks,
Keni
d2.ship
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: bug patch: exit codes from internal commands are handled incorrectly
On Tue, Mar 31, 2015 at 5:10 PM, Kenneth Lorber k...@his.com wrote: Ping? The original version of this got some discussion, but this version - nothing. Pong? I do not know what you meant by this version. Have you followed Documentaiton/SubmittingPatches? Otherwise the mailing list may have dropped the 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
