Re: [PATCH v3 1/3] git-submodule add: Add -r/--record option
"W. Trevor King" writes: > By remaining agnostic on the variable usage, this patch makes > submodule setup more convenient for all parties. I personally do not think "remaining agnostic on the usage" is a good thing, at least for any option to commands at the higher level on the stack, such as "git submodule". I am afraid that giving an easier way to set up a variable with undefined semantics may make setup more confusing for all parties. One party gives one specific meaning to the field, while another party uses it for something slightly different. I would not object to "git config submodule.$name.branch $value", on the other hand. "git config" can be used to set a piece of data that has specific meaning, but as a low-level tool, it is not _limited_ to variables that have defined meaning. -- 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: orphan blob or what?
Please excuse one inaccuracy: I did a 'git pull' not a clone. So it could be an old .idx file at my end possibly. Thanks, bruce -Original Message- From: Robertson, Bruce E Sent: Thursday, November 08, 2012 4:25 PM To: git@vger.kernel.org Subject: orphan blob or what? In today's and older clones of https://github.com/mirrors/linux.git I find this object, 6fa98ea0ae40f9a38256f11e5dc270363f785aee, that I can't figure out how to eliminate^h^h^h^h^h^h^h^h^hget rid of. I don't see it in 'git fsck', 'git gc --aggressive --prune' doesn't seem to prune it, can't see it via 'git log'. And yet linux/.git/objects/pack$ git verify-pack -v *.idx | grep 6fa98ea0ae40f9a38256f11e5dc270363f785aee 6fa98ea0ae40f9a38256f11e5dc270363f785aee blob 1519697 124840 515299673 8231eaa31ce1107c1463deb6ec33f61618aedbb9 blob 67 63 515424513 1 6fa98ea0ae40f9a38256f11e5dc270363f785aee f21a8c1b9d47736fa4e27def66f04b9fe2b4bc53 blob 90 83 515424576 1 6fa98ea0ae40f9a38256f11e5dc270363f785aee Thanks, bruce -- 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 2/3] git-submodule foreach: export .gitmodules settings as variables
From: "W. Trevor King"
This makes it easy to access per-submodule variables. For example,
git submodule foreach 'git checkout $(git config --file $toplevel/.gitmodules
submodule.$name.branch) && git pull'
can now be reduced to
git submodule foreach 'git checkout $submodule_branch && git pull'
Every submodule.. setting from .gitmodules is available as
a $submodule_ variable. These variables are not
propagated recursively into nested submodules.
Signed-off-by: W. Trevor King
Based-on-patch-by: Phil Hord
---
Documentation/git-submodule.txt | 3 +++
git-sh-setup.sh | 20
git-submodule.sh| 16
t/t7407-submodule-foreach.sh| 29 +
4 files changed, 68 insertions(+)
mode change 100644 => 100755 git-sh-setup.sh
diff --git a/Documentation/git-submodule.txt b/Documentation/git-submodule.txt
index cbec363..9a99826 100644
--- a/Documentation/git-submodule.txt
+++ b/Documentation/git-submodule.txt
@@ -175,6 +175,9 @@ foreach::
$path is the name of the submodule directory relative to the
superproject, $sha1 is the commit as recorded in the superproject,
and $toplevel is the absolute path to the top-level of the superproject.
+ In addition, every submodule.. setting from .gitmodules
+ is available as the variable $submodule_. These
+ variables are not propagated recursively into nested submodules.
Any submodules defined in the superproject but not checked out are
ignored by this command. Unless given `--quiet`, foreach prints the name
of each submodule before evaluating the command.
diff --git a/git-sh-setup.sh b/git-sh-setup.sh
old mode 100644
new mode 100755
index ee0e0bc..179a920
--- a/git-sh-setup.sh
+++ b/git-sh-setup.sh
@@ -222,6 +222,26 @@ clear_local_git_env() {
unset $(git rev-parse --local-env-vars)
}
+# Remove any suspect characters from a user-generated variable name.
+sanitize_variable_name() {
+ VAR_NAME="$1"
+ printf '%s' "$VAR_NAME" |
+ sed -e 's/^[^a-zA-Z]/_/' -e 's/[^a-zA-Z0-9]/_/g'
+}
+
+# Return a command for setting a new variable.
+# Neither the variable name nor the variable value passed to this
+# function need to be sanitized. You need to eval the returned
+# string, because new variables set by the function itself don't
+# effect the calling process.
+set_user_variable() {
+ VAR_NAME="$1"
+ VAR_VALUE="$2"
+ VAR_NAME=$(sanitize_variable_name "$VAR_NAME")
+ VAR_VALUE=$(printf '%s' "$VAR_VALUE" |
+ sed -e 's/\\//g' -e 's/"/\\"/g')
+ printf '%s=%s;\n' "$VAR_NAME" "\"$VAR_VALUE\""
+}
# Platform specific tweaks to work around some commands
case $(uname -s) in
diff --git a/git-submodule.sh b/git-submodule.sh
index bc33112..e4d26f9 100755
--- a/git-submodule.sh
+++ b/git-submodule.sh
@@ -434,8 +434,24 @@ cmd_foreach()
clear_local_git_env
# we make $path available to scripts ...
path=$sm_path
+
+ # make all submodule variables available to
scripts
+ eval $(
+ git config -f .gitmodules --get-regexp
"^submodule\.${name}\..*" |
+ sed -e "s|^submodule\.${name}\.||" |
+ while read VAR_NAME VAR_VALUE ; do
+ VAR_NAME=$(printf '%s'
"$VAR_NAME" | tr A-Z a-z)
+ set_user_variable
"submodule_${VAR_NAME}" "$VAR_VALUE"
+ done)
+ UNSET_CMD=$(set |
+ sed -n -e
's|^\(submodule_[a-z_]*\)=.*$|\1|p' |
+ while read VAR_NAME ; do
+ printf 'unset %s;\n' "$VAR_NAME"
+ done)
+
cd "$sm_path" &&
eval "$@" &&
+ eval "$UNSET_CMD" &&
if test -n "$recursive"
then
cmd_foreach "--recursive" "$@"
diff --git a/t/t7407-submodule-foreach.sh b/t/t7407-submodule-foreach.sh
index 9b69fe2..46ac746 100755
--- a/t/t7407-submodule-foreach.sh
+++ b/t/t7407-submodule-foreach.sh
@@ -313,4 +313,33 @@ test_expect_success 'command passed to foreach --recursive
retains notion of std
test_cmp expected actual
'
+cat > expect < ../actual
+ ) &&
+ test_i18ncmp expect actual
+'
+#
+#"echo \$toplevel-\$name-\$submodule_path-\$submodule_url"
+
test_done
--
1.8.0.3.gc2eb43a
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
Mo
Re: [PATCH] gitweb: make remote_heads config setting work.
Phil Pennock writes:
> @@ -2702,6 +2702,7 @@ sub git_get_project_config {
> $key = lc($key);
> }
> $key =~ s/^gitweb\.//;
> + $key =~ s/_//g;
> return if ($key =~ m/\W/);
>
> # type sanity check
The idea to strip "_" from "remote_heads" to create "remoteheads" is
fine, but I am not sure if the implementation is good.
Looking at the code before this part:
if (my ($hi, $mi, $lo) = ($key =~ /^([^.]*)\.(.*)\.([^.]*)$/)) {
$key = join(".", lc($hi), $mi, lc($lo));
} else {
$key = lc($key);
}
$key =~ s/^gitweb\.//;
return if ($key =~ m/\W/);
the new code is munding the $hi and $mi parts, while the mistaken
configuration this patch is trying to correct is about the $lo part,
and possibly the $hi part, but never the $mi part.
It is expected that $hi will always be gitweb, and I suspect that
there may not be any "per something" configuration variable (e.g.
"gitweb.master.blame" may be used to override the default value
given by "gitweb.blame" only for the master branch), that uses $mi
part, so it might not matter to munge the entire $key like this
patch does with the current code.
But that makes it even more important to get this part right _now_;
otherwise, it is likely that this new code will introduce a bug to
a future patch that adds "per something" configuration support.
--
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 0/3] git-submodule add: Add -r/--record option
From: "W. Trevor King" Here's my revised patch. Changes from v2: * Revised Ævar-vs-Gerrit usage to show agreement, following Shawn's comments. * Added a cleaned up version of Phil's $submodule_* export patch, with docs and tests. * Added a caveat to the -r/--record documentation to make it explicit that submodule..branch is not used internally by Git. Give an example of how the user may use it explicitly for Ævar-style updates. W. Trevor King (3): git-submodule add: Add -r/--record option git-submodule foreach: export .gitmodules settings as variables git-submodule: Motivate --record with an example use case Documentation/git-submodule.txt | 22 +- git-sh-setup.sh | 20 git-submodule.sh| 35 ++- t/t7400-submodule-basic.sh | 25 + t/t7407-submodule-foreach.sh| 29 + 5 files changed, 129 insertions(+), 2 deletions(-) mode change 100644 => 100755 git-sh-setup.sh -- 1.8.0.3.gc2eb43a -- 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 3/3] git-submodule: Motivate --record with an example use case
From: "W. Trevor King" Signed-off-by: W. Trevor King --- Documentation/git-submodule.txt | 8 1 file changed, 8 insertions(+) diff --git a/Documentation/git-submodule.txt b/Documentation/git-submodule.txt index 9a99826..d4e993f 100644 --- a/Documentation/git-submodule.txt +++ b/Documentation/git-submodule.txt @@ -220,6 +220,14 @@ OPTIONS is not set either, `HEAD` will be recorded. Because the branch name is optional, you must use the equal-sign form (`-r=`), not `-r `. ++ +The recorded setting is not actually used by git; however, some +external tools and workflows may make use of it. For example, if the +upstream branches still exist and you have a recorded branch setting +for each of your submodules, you can update all of the submodules to +the current branch tips with: ++ + git submodule foreach 'git checkout $submodule_branch && git pull' -f:: --force:: -- 1.8.0.3.gc2eb43a -- 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 1/3] git-submodule add: Add -r/--record option
From: "W. Trevor King"
This option allows you to record a submodule..branch option in
.gitmodules. Git does not currently use this configuration option for
anything, but users have used it for several things, so it makes sense
to add some syntactic sugar for initializing the value.
Current consumers:
Ævar uses this setting to designate the upstream branch for pulling
submodule updates:
$ git submodule foreach 'git checkout $(git config --file
$toplevel/.gitmodules submodule.$name.branch) && git pull'
as he describes in
commit f030c96d8643fa0a1a9b2bd9c2f36a77721fb61f
Author: Ævar Arnfjörð Bjarmason
Date: Fri May 21 16:10:10 2010 +
git-submodule foreach: Add $toplevel variable
Gerrit uses the same interpretation for the setting, but because
Gerrit has direct access to the subproject repositories, it updates
the superproject repositories automatically when a subproject changes.
Gerrit also accepts the special value '.', which it expands into the
superproject's branch name.
By remaining agnostic on the variable usage, this patch makes
submodule setup more convenient for all parties.
[1]
https://gerrit.googlesource.com/gerrit/+/master/Documentation/user-submodules.txt
Signed-off-by: W. Trevor King
---
Documentation/git-submodule.txt | 11 ++-
git-submodule.sh| 19 ++-
t/t7400-submodule-basic.sh | 25 +
3 files changed, 53 insertions(+), 2 deletions(-)
diff --git a/Documentation/git-submodule.txt b/Documentation/git-submodule.txt
index b4683bb..cbec363 100644
--- a/Documentation/git-submodule.txt
+++ b/Documentation/git-submodule.txt
@@ -9,7 +9,7 @@ git-submodule - Initialize, update or inspect submodules
SYNOPSIS
[verse]
-'git submodule' [--quiet] add [-b branch] [-f|--force]
+'git submodule' [--quiet] add [-b branch] [--record[=]] [-f|--force]
[--reference ] [--] []
'git submodule' [--quiet] status [--cached] [--recursive] [--] [...]
'git submodule' [--quiet] init [--] [...]
@@ -209,6 +209,15 @@ OPTIONS
--branch::
Branch of repository to add as submodule.
+-r::
+--record::
+ Record a branch name used as `submodule..branch` in
+ `.gitmodules` for future reference. If you do not list an explicit
+ name here, the name given with `--branch` will be recorded. If that
+ is not set either, `HEAD` will be recorded. Because the branch name
+ is optional, you must use the equal-sign form (`-r=`), not
+ `-r `.
+
-f::
--force::
This option is only valid for add and update commands.
diff --git a/git-submodule.sh b/git-submodule.sh
index ab6b110..bc33112 100755
--- a/git-submodule.sh
+++ b/git-submodule.sh
@@ -5,7 +5,7 @@
# Copyright (c) 2007 Lars Hjemli
dashless=$(basename "$0" | sed -e 's/-/ /')
-USAGE="[--quiet] add [-b branch] [-f|--force] [--reference ] [--]
[]
+USAGE="[--quiet] add [-b branch] [--record[=]] [-f|--force]
[--reference ] [--] []
or: $dashless [--quiet] status [--cached] [--recursive] [--] [...]
or: $dashless [--quiet] init [--] [...]
or: $dashless [--quiet] update [--init] [-N|--no-fetch] [-f|--force]
[--rebase] [--reference ] [--merge] [--recursive] [--] [...]
@@ -20,6 +20,8 @@ require_work_tree
command=
branch=
+record_branch=
+record_branch_empty=
force=
reference=
cached=
@@ -257,6 +259,12 @@ cmd_add()
branch=$2
shift
;;
+ -r | --record)
+ record_branch_empty=true
+ ;;
+ -r=* | --record=*)
+ record_branch="${1#*=}"
+ ;;
-f | --force)
force=$1
;;
@@ -328,6 +336,11 @@ cmd_add()
git ls-files --error-unmatch "$sm_path" > /dev/null 2>&1 &&
die "$(eval_gettext "'\$sm_path' already exists in the index")"
+ if test -z "$record_branch" && test "$record_branch_empty" = "true"
+ then
+ record_branch="${branch:=HEAD}"
+ fi
+
if test -z "$force" && ! git add --dry-run --ignore-missing "$sm_path"
> /dev/null 2>&1
then
eval_gettextln "The following path is ignored by one of your
.gitignore files:
@@ -366,6 +379,10 @@ Use -f if you really want to add it." >&2
git config -f .gitmodules submodule."$sm_path".path "$sm_path" &&
git config -f .gitmodules submodule."$sm_path".url "$repo" &&
+ if test -n "$branch"
+ then
+ git config -f .gitmodules submodule."$sm_path".branch
"$record_branch"
+ fi &&
git add --force .gitmodules ||
die "$(eval_gettext "Failed to register submodule '\$sm_path'")"
}
diff --git a/t/t7400-submodule-basic.sh b/t/t7400-submodule-basic.sh
index 5397037..88ae74c 100755
--- a/t/t7400-submodule-basic.sh
+++ b/t/t7400-submodule-basic.sh
@@ -133,6 +133,7 @@ test_expect_success 'submodule
Re: Support for a series of patches, i.e. patchset or changeset?
On Fri, Nov 9, 2012 at 3:09 AM, Jeff King wrote: > On Tue, Nov 06, 2012 at 08:58:35AM +0800, Eric Miao wrote: > >> > So, then the question is: What do you know/have? Is your patch the >> > output of "git format-patch", "git diff", or just some sort of diff >> > without any git information? >> >> That doesn't matter, all the info can be obtained from the SHA1 id, the >> question is: do we have a mechanism in git (or hopefully we could add) >> to record the patchset or series the patch belongs to, without people to >> guess heuristically. >> >> E.g. when we merged a series of patches: >> >> [PATCH 00/08] >> [PATCH 01/08] >> ... >> [PATCH 08/08] >> >> How do we know this whole series after merged when only one of these >> commits are known? > > Others have described how you can infer this structure from the history > graph, but as you noted, the graph does not always match the series that > was sent, nor does it contain some of the meta information about the > cover letter, associated discussions, etc. > > If you want to track the mapping between mailed patches (or any other > form of changeset id) to commits, you can put it in git in one of two > places: > > 1. In a pseudo-header at the end of the commit message. E.g., you > could use the message-id of the cover letter as a unique identifier > for the changeset, and put "Changeset: $MID" at the end of each > commit message. Then you can use "--grep" to find other entries > from the same changeset. > > 2. You can use git-notes to store the same information outside of the > commit message. This doesn't get pushed around automatically with > the history, but it means your commit messages are not polluted, > and you can make annotations after the commits are set in stone. > > I do not use Gerrit, but I recall that they do something like (1) to > mark changesets. For git development, one of the contributors does (2) > to point notes at mailing list threads (I think he uses a script to > match up mails and commits after the fact). Thanks Jeff, this is the answer I'm looking for, really appreciated to get it explained so clearly. > > But fundamentally the idea of "this is a set of logical changes" is not > represented in git's DAG. It's up to you to store changeset tokens > if you care about them. Sure, I completely understand and agree we should keep git simple enough. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: orphan blob or what?
On Thu, 08 Nov 2012 16:24:36 -0800, bruce wrote: > In today's and older clones of https://github.com/mirrors/linux.git I > find this object, 6fa98ea0ae40f9a38256f11e5dc270363f785aee, that I can't > figure out how to eliminate^h^h^h^h^h^h^h^h^hget rid of. I don't see it > in 'git fsck', 'git gc --aggressive --prune' doesn't seem to prune it, > can't see it via 'git log'. And yet > > linux/.git/objects/pack$ git verify-pack -v *.idx | grep > 6fa98ea0ae40f9a38256f11e5dc270363f785aee > 6fa98ea0ae40f9a38256f11e5dc270363f785aee blob 1519697 124840 515299673 > 8231eaa31ce1107c1463deb6ec33f61618aedbb9 blob 67 63 515424513 1 > 6fa98ea0ae40f9a38256f11e5dc270363f785aee > f21a8c1b9d47736fa4e27def66f04b9fe2b4bc53 blob 90 83 515424576 1 > 6fa98ea0ae40f9a38256f11e5dc270363f785aee Commit dee0bb9 (ASoC: Mark WM8962 Additional Control 4 register as volatile, 2010-09-29) references this blob. -- 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
orphan blob or what?
In today's and older clones of https://github.com/mirrors/linux.git I find this object, 6fa98ea0ae40f9a38256f11e5dc270363f785aee, that I can't figure out how to eliminate^h^h^h^h^h^h^h^h^hget rid of. I don't see it in 'git fsck', 'git gc --aggressive --prune' doesn't seem to prune it, can't see it via 'git log'. And yet linux/.git/objects/pack$ git verify-pack -v *.idx | grep 6fa98ea0ae40f9a38256f11e5dc270363f785aee 6fa98ea0ae40f9a38256f11e5dc270363f785aee blob 1519697 124840 515299673 8231eaa31ce1107c1463deb6ec33f61618aedbb9 blob 67 63 515424513 1 6fa98ea0ae40f9a38256f11e5dc270363f785aee f21a8c1b9d47736fa4e27def66f04b9fe2b4bc53 blob 90 83 515424576 1 6fa98ea0ae40f9a38256f11e5dc270363f785aee Thanks, bruce -- 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: Long clone time after "done."
I tried on the local disk as well and it didn't help. I managed to find a SUSE11 machine and tried it there but no luck so I think we can eliminate NFS and OS as significant factors now. I ran with perf and here's the report: ESC[31m69.07%ESC[m git /lib64/libc-2.11.1.so [.] memcpy ESC[31m12.33%ESC[m git /git-1.8.0.rc2.suse11/bin/git [.] blk_SHA1_Block ESC[31m 5.11%ESC[m git /zlib/local/lib/libz.so.1.2.5 [.] inflate_fast ESC[32m 2.61%ESC[m git /zlib/local/lib/libz.so.1.2.5 [.] adler32 ESC[32m 1.98%ESC[m git /lib64/libc-2.11.1.so [.] _int_malloc ESC[32m 0.86%ESC[m git [kernel] [k] clear_page_c Does this help? Machine has 396GB of RAM if it matters. On Thu, Nov 8, 2012 at 4:33 PM, Jeff King wrote: > On Thu, Nov 08, 2012 at 04:16:59PM -0600, Uri Moszkowicz wrote: > >> I ran "git cat-file commit some-tag" for every tag. They seem to be >> roughly uniformly distributed between 0s and 2s and about 2/3 of the >> time seems to be system. My disk is mounted over NFS so I tried on the >> local disk and it didn't make a difference. >> >> I have only one 1.97GB pack. I ran "git gc --aggressive" before. > > Ah. NFS. That is almost certainly the source of the problem. Git will > aggressively mmap. I would not be surprised to find that RHEL4's NFS > implementation is not particularly fast at mmap-ing 2G files, and is > spending a bunch of time in the kernel servicing the requests. > > Aside from upgrading your OS or getting off of NFS, I don't have a lot > of advice. The performance characteristics you are seeing are so > grossly off of what is normal that using git is probably going to be > painful. Your 2s cat-files should be more like .002s. I don't think > there's anything for git to fix here. > > You could try building with NO_MMAP, which will emulate it with pread. > That might fare better under your NFS implementation. Or it might be > just as bad. > > -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: Long clone time after "done."
On Thu, Nov 08, 2012 at 04:16:59PM -0600, Uri Moszkowicz wrote: > I ran "git cat-file commit some-tag" for every tag. They seem to be > roughly uniformly distributed between 0s and 2s and about 2/3 of the > time seems to be system. My disk is mounted over NFS so I tried on the > local disk and it didn't make a difference. > > I have only one 1.97GB pack. I ran "git gc --aggressive" before. Ah. NFS. That is almost certainly the source of the problem. Git will aggressively mmap. I would not be surprised to find that RHEL4's NFS implementation is not particularly fast at mmap-ing 2G files, and is spending a bunch of time in the kernel servicing the requests. Aside from upgrading your OS or getting off of NFS, I don't have a lot of advice. The performance characteristics you are seeing are so grossly off of what is normal that using git is probably going to be painful. Your 2s cat-files should be more like .002s. I don't think there's anything for git to fix here. You could try building with NO_MMAP, which will emulate it with pread. That might fare better under your NFS implementation. Or it might be just as bad. -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: Long clone time after "done."
I ran "git cat-file commit some-tag" for every tag. They seem to be roughly uniformly distributed between 0s and 2s and about 2/3 of the time seems to be system. My disk is mounted over NFS so I tried on the local disk and it didn't make a difference. I have only one 1.97GB pack. I ran "git gc --aggressive" before. On Thu, Nov 8, 2012 at 4:11 PM, Jeff King wrote: > On Thu, Nov 08, 2012 at 03:49:32PM -0600, Uri Moszkowicz wrote: > >> I'm using RHEL4. Looks like perf is only available with RHEL6. > > Yeah, RHEL4 is pretty ancient; I think it predates the invention of > "perf". > >> heads: 308 >> tags: 9614 >> >> Looking up the tags that way took a very long time by the way. "git >> tag | wc -l" was much quicker. I've already pruned a lot of tags to >> get to this number as well. The original repository had ~37k tags >> since we used to tag every commit with CVS. > > Hmm. I think for-each-ref will actually open the tag objects, but "git > tag" will not. That would imply that reading the refs is fast, but > opening objects is slow. I wonder why. > > How many packs do you have in .git/objects/pack of the repository? > >> All my tags are packed so cat-file doesn't work: >> fatal: git cat-file refs/tags/some-tag: bad file > > The packing shouldn't matter. The point of the command is to look up the > refs/tags/some-tag ref (in packed-refs or in the filesystem), and then > open and write the pointed-to object to stdout. If that is not working, > then there is something seriously wrong going on. > > -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: Long clone time after "done."
On Thu, Nov 08, 2012 at 03:49:32PM -0600, Uri Moszkowicz wrote: > I'm using RHEL4. Looks like perf is only available with RHEL6. Yeah, RHEL4 is pretty ancient; I think it predates the invention of "perf". > heads: 308 > tags: 9614 > > Looking up the tags that way took a very long time by the way. "git > tag | wc -l" was much quicker. I've already pruned a lot of tags to > get to this number as well. The original repository had ~37k tags > since we used to tag every commit with CVS. Hmm. I think for-each-ref will actually open the tag objects, but "git tag" will not. That would imply that reading the refs is fast, but opening objects is slow. I wonder why. How many packs do you have in .git/objects/pack of the repository? > All my tags are packed so cat-file doesn't work: > fatal: git cat-file refs/tags/some-tag: bad file The packing shouldn't matter. The point of the command is to look up the refs/tags/some-tag ref (in packed-refs or in the filesystem), and then open and write the pointed-to object to stdout. If that is not working, then there is something seriously wrong going on. -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: Long clone time after "done."
I'm using RHEL4. Looks like perf is only available with RHEL6. heads: 308 tags: 9614 Looking up the tags that way took a very long time by the way. "git tag | wc -l" was much quicker. I've already pruned a lot of tags to get to this number as well. The original repository had ~37k tags since we used to tag every commit with CVS. All my tags are packed so cat-file doesn't work: fatal: git cat-file refs/tags/some-tag: bad file On Thu, Nov 8, 2012 at 2:33 PM, Jeff King wrote: > On Thu, Nov 08, 2012 at 11:20:29AM -0600, Uri Moszkowicz wrote: > >> I tried the patch but it doesn't appear to have helped :( Clone time >> with it was ~32m. > > That sounds ridiculously long. > >> Do you all by any chance have a tool to obfuscate a repository? >> Probably I still wouldn't be permitted to distribute it but might make >> the option slightly more palatable. Anything else that I can do to >> help debug this problem? > > I don't have anything already written. What platform are you on? If it's > Linux, can you try using "perf" to record where the time is going? > > How many refs do you have? What does: > > echo "heads: $(git for-each-ref refs/heads | wc -l)" > echo " tags: $(git for-each-ref refs/tags | wc -l)" > > report? How long does it take to look up a tag, like: > > time git cat-file tag refs/tags/some-tag > > ? > > -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 2/3] diff: introduce diff.submodule configuration variable
On Thu, Nov 01, 2012 at 04:13:49PM +0530, Ramkumar Ramachandra wrote:
> diff --git a/builtin/diff.c b/builtin/diff.c
> index 9650be2..6d00311 100644
> --- a/builtin/diff.c
> +++ b/builtin/diff.c
> @@ -297,6 +297,10 @@ int cmd_diff(int argc, const char **argv, const char
> *prefix)
> DIFF_OPT_SET(&rev.diffopt, ALLOW_EXTERNAL);
> DIFF_OPT_SET(&rev.diffopt, ALLOW_TEXTCONV);
>
> + /* Set SUBMODULE_LOG if diff.submodule config var was set */
> + if (submodule_format_cfg && !strcmp(submodule_format_cfg, "log"))
> + DIFF_OPT_SET(&rev.diffopt, SUBMODULE_LOG);
> +
Yuck. Why is this parsing happening in cmd_diff?
Wouldn't you want it to kick in for "git log --submodule", too? It seems
like it should go into diff_setup(), and the porcelain/plumbing aspect
should be controlled by parsing it in git_diff_ui_config or
git_diff_basic_config. See how diff_no_prefix and diff_mnemonic prefix
are handled for an example.
Then you can keep the parsing logic for "log" in diff.c. And you should
factor it out into a function so that the command-line option and the
config parser can share the same code. I know it's only one line now,
but anybody who wants to add an option will have to update both places.
See the parsing of diff.dirstat for an example.
> else if (!prefixcmp(arg, "--submodule=")) {
> if (!strcmp(arg + 12, "log"))
> DIFF_OPT_SET(options, SUBMODULE_LOG);
> + if (!strcmp(arg + 12, "short"))
> + DIFF_OPT_CLR(options, SUBMODULE_LOG);
> }
Much better (although arguably should go in a separate patch). Should we
also produce an error if somebody says "--submodule=foobar"?
-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 0/3] Introduce diff.submodule
On Sun, Nov 04, 2012 at 11:28:17PM +0530, Ramkumar Ramachandra wrote: > Jens Lehmann wrote: > > Am 01.11.2012 11:43, schrieb Ramkumar Ramachandra: > >> Hi, > >> > >> v1 is here: > >> http://mid.gmane.org/1349196670-2844-1-git-send-email-artag...@gmail.com > >> > >> I've fixed the issues pointed out in the review by Jens. > > > > Thanks, looking good to me. > > Peff, can we pick this up? Thanks for prodding, I missed the original. I have a few comments, but I'll respond directly. Also, I was coincidentally looking at the same code today. You might find this interesting: http://article.gmane.org/gmane.comp.version-control.git/209188 -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: Long clone time after "done."
On Thu, Nov 08, 2012 at 11:20:29AM -0600, Uri Moszkowicz wrote: > I tried the patch but it doesn't appear to have helped :( Clone time > with it was ~32m. That sounds ridiculously long. > Do you all by any chance have a tool to obfuscate a repository? > Probably I still wouldn't be permitted to distribute it but might make > the option slightly more palatable. Anything else that I can do to > help debug this problem? I don't have anything already written. What platform are you on? If it's Linux, can you try using "perf" to record where the time is going? How many refs do you have? What does: echo "heads: $(git for-each-ref refs/heads | wc -l)" echo " tags: $(git for-each-ref refs/tags | wc -l)" report? How long does it take to look up a tag, like: time git cat-file tag refs/tags/some-tag ? -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] custom log formats for "diff --submodule=log"
An off-list discussion made me wonder if something like this would be
useful:
git log -p --submodule=log:' %m %an <%ae>: %s'
where the format could be whatever you find useful.
I do not use submodules myself, so writing the patch below was just a
fun exercise. I'm not planning on polishing it for inclusion. But I
thought I would publish it here in case anybody who is more interested
feels like picking it up. It would need documentation and tests at the
very least.
---
diff --git a/diff.c b/diff.c
index 86e5f2a..f2adaca 100644
--- a/diff.c
+++ b/diff.c
@@ -2241,7 +2241,7 @@ static void builtin_diff(const char *name_a,
const char *add = diff_get_color_opt(o, DIFF_FILE_NEW);
show_submodule_summary(o->file, one ? one->path : two->path,
one->sha1, two->sha1, two->dirty_submodule,
- del, add, reset);
+ del, add, reset, o->submodule_log_format);
return;
}
@@ -3654,8 +3654,13 @@ int diff_opt_parse(struct diff_options *options, const
char **av, int ac)
} else if (!strcmp(arg, "--submodule"))
DIFF_OPT_SET(options, SUBMODULE_LOG);
else if (!prefixcmp(arg, "--submodule=")) {
- if (!strcmp(arg + 12, "log"))
+ const char *v = arg + 12;
+ if (!strcmp(v, "log"))
DIFF_OPT_SET(options, SUBMODULE_LOG);
+ else if (!prefixcmp(v, "log:")) {
+ DIFF_OPT_SET(options, SUBMODULE_LOG);
+ options->submodule_log_format = xstrdup(v + 4);
+ }
}
/* misc options */
diff --git a/diff.h b/diff.h
index a658f85..9726375 100644
--- a/diff.h
+++ b/diff.h
@@ -132,6 +132,8 @@ struct diff_options {
const char *stat_sep;
long xdl_opts;
+ char *submodule_log_format;
+
int stat_width;
int stat_name_width;
int stat_graph_width;
diff --git a/submodule.c b/submodule.c
index e3e0b45..149bd87 100644
--- a/submodule.c
+++ b/submodule.c
@@ -217,12 +217,16 @@ static int prepare_submodule_summary(struct rev_info
*rev, const char *path,
}
static void print_submodule_summary(struct rev_info *rev, FILE *f,
- const char *del, const char *add, const char *reset)
+ const char *del, const char *add, const char *reset,
+ const char *format)
{
- static const char format[] = " %m %s";
+ static const char default_format[] = " %m %s";
struct strbuf sb = STRBUF_INIT;
struct commit *commit;
+ if (!format)
+ format = default_format;
+
while ((commit = get_revision(rev))) {
struct pretty_print_context ctx = {0};
ctx.date_mode = rev->date_mode;
@@ -259,7 +263,8 @@ int parse_fetch_recurse_submodules_arg(const char *opt,
const char *arg)
void show_submodule_summary(FILE *f, const char *path,
unsigned char one[20], unsigned char two[20],
unsigned dirty_submodule,
- const char *del, const char *add, const char *reset)
+ const char *del, const char *add, const char *reset,
+ const char *format)
{
struct rev_info rev;
struct commit *left = left, *right = right;
@@ -304,7 +309,7 @@ void show_submodule_summary(FILE *f, const char *path,
fwrite(sb.buf, sb.len, 1, f);
if (!message) {
- print_submodule_summary(&rev, f, del, add, reset);
+ print_submodule_summary(&rev, f, del, add, reset, format);
clear_commit_marks(left, ~0);
clear_commit_marks(right, ~0);
}
diff --git a/submodule.h b/submodule.h
index f2e8271..49a7b75 100644
--- a/submodule.h
+++ b/submodule.h
@@ -21,7 +21,8 @@ int parse_fetch_recurse_submodules_arg(const char *opt, const
char *arg);
void show_submodule_summary(FILE *f, const char *path,
unsigned char one[20], unsigned char two[20],
unsigned dirty_submodule,
- const char *del, const char *add, const char *reset);
+ const char *del, const char *add, const char *reset,
+ const char *format);
void set_config_fetch_recurse_submodules(int value);
void check_for_new_submodule_commits(unsigned char new_sha1[20]);
int fetch_populated_submodules(const struct argv_array *options,
--
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: RFD: fast-import is picky with author names (and maybe it should - but how much so?)
On Fri, Nov 02, 2012 at 03:43:24PM +0100, Michael J Gruber wrote: > It seems that our fast-import is super picky with regards to author > names. I've encountered author names like > > Foo Bar > Foo Bar foo@dev.null > > in the self-hosting repo of some other dvcs, and the question is how to > translate them faithfully into a git author name. It is not just fast-import. Git's author field looks like an rfc822 address, but it's much simpler. It fundamentally does not allow angle brackets in the "name" field, regardless of any quoting. As you noted in your followup, we strip them out if you provide them via GIT_AUTHOR_NAME. I doubt this will change anytime soon due to the compatibility fallout. So it is up to generators of fast-import streams to decide how to encode what they get from another system (you could come up with an encoding scheme that represents angle brackets). > In general, we try to do > > fullotherdvcsname > > if the other system's entry does not parse as a git author name, but > fast-import does not accept either of > > Foo Bar > "Foo Bar" > > because of the way it parses for <>. While the above could be easily > turned into > > Foo Bar > > it would not be a faithful representation of the original commit in the > other dvcs. I'd think that if a remote system has names with angle brackets and email-looking things inside them, we would do better to stick them in the email field rather than putting in a useless . The latter should only be used for systems that lack the information. But that is a quality-of-implementation issue for the import scripts (and they may even want to have options, just like git-cvsimport allows mapping cvs usernames into full identities). -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: Revert option for git add --patch
On Fri, Nov 09, 2012 at 08:42:33AM +1300, Nathan Broadbent wrote: > It sounds like we want a tool that combines the functionality of 'git add > --patch', 'git checkout --patch', and other features, so that we can > perform various actions on 'hunks' without switching context. What do you > think about naming this command 'git patch'? I think it would be a slightly confusing name, given that it is not related to the usual Unix "patch" command (git's analog to that is "git apply"). I was thinking something like "git organize" because it is about organizing muddled changes. Duy mentioned my earlier "git put", which is based around the same ideas. This could be thought of as "git put --patch", I suppose. > I'm not sure how dropping hunks into 'buckets' would work, but the main > idea is to be able to stage, discard or edit hunks in a single pass. Buckets are really just patches you are building up from hunks. So I think you are dealing with two buckets either way: a to-stage bucket and a to-discard bucket. Adding more buckets isn't hard; you just turn the to-stage bucket into an array of buckets. The tricky part is figuring out how to keep the state persistent across multiple invocations. The simplest program flow for the 2-bucket case would be something like: for h in hunks do show hunk to user ask user what they want to do if they want to stage append to to-stage patch else if they want to discard append to to-discard patch else ignore the hunk done feed to-stage patch to "git apply --cached" feed to-discard patch to "git apply -R" Modifying the loop to have more buckets is easy. But the end is probably something like: feed to-discard patch to "git apply -R" feed bucket[0] to "git apply --cached" save bucket[1..n] somewhere exit Then the user gets control back, builds, tests, commits, whatever, and then runs "git organize --continue" to apply bucket[1], and so on. And since we don't know what the user did in between, we have to be ready for conflicts in applying the buckets. Hmm, this is sounding a lot like how "rebase --interactive" works. One way to implement this would be to store each bucket as a commit against HEAD (i.e., stage it into a temporary index, then run "git write-tree" and "git commit-tree"), and then make a "rebase -i" instruction sheet like: pick $sha1_of_bucket_1_commit edit pick $sha1_of_bucket_2_commit edit and so forth, except that we would not want our picks to actually commit (just pull the changes into the working tree and/or index). That's just me thinking off the top of my head. Obviously what you are proposing is way simpler, and it is probably sane to start with the simple thing, and then build the more complex thing on top. But it might be worth keeping in mind the complex case when building out the infrastructure for the simple 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: Support for a series of patches, i.e. patchset or changeset?
On Tue, Nov 06, 2012 at 08:58:35AM +0800, Eric Miao wrote: > > So, then the question is: What do you know/have? Is your patch the > > output of "git format-patch", "git diff", or just some sort of diff > > without any git information? > > That doesn't matter, all the info can be obtained from the SHA1 id, the > question is: do we have a mechanism in git (or hopefully we could add) > to record the patchset or series the patch belongs to, without people to > guess heuristically. > > E.g. when we merged a series of patches: > > [PATCH 00/08] > [PATCH 01/08] > ... > [PATCH 08/08] > > How do we know this whole series after merged when only one of these > commits are known? Others have described how you can infer this structure from the history graph, but as you noted, the graph does not always match the series that was sent, nor does it contain some of the meta information about the cover letter, associated discussions, etc. If you want to track the mapping between mailed patches (or any other form of changeset id) to commits, you can put it in git in one of two places: 1. In a pseudo-header at the end of the commit message. E.g., you could use the message-id of the cover letter as a unique identifier for the changeset, and put "Changeset: $MID" at the end of each commit message. Then you can use "--grep" to find other entries from the same changeset. 2. You can use git-notes to store the same information outside of the commit message. This doesn't get pushed around automatically with the history, but it means your commit messages are not polluted, and you can make annotations after the commits are set in stone. I do not use Gerrit, but I recall that they do something like (1) to mark changesets. For git development, one of the contributors does (2) to point notes at mailing list threads (I think he uses a script to match up mails and commits after the fact). But fundamentally the idea of "this is a set of logical changes" is not represented in git's DAG. It's up to you to store changeset tokens if you care about them. -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: git commit/push can fail silently when clone omits ".git"
On Sun, Nov 04, 2012 at 12:50:58PM -0700, Jeffrey S. Haemer wrote:
> I got bitten by what follows. Yes, it's an edge case. Yes I now understand
> why it does what it does. Yes the right answer is "Don't do that, Jeff." :-)
>
> Still, it took me a little time to figure out what I'd done wrong because
> the failure is silent, so I thought I'd document it. Perhaps there's even
> some way to issue an error message for cases like this.
>
> The attached test script shows the issue in detail, but here's the basic
> failure:
>
> $ ls
> hello.git
> $ git clone hello # *Mistake!* Succeeds, but should have cloned "hello.git"
> or into something else.
It does clone hello.git into "hello", but it sets remote.origin.url in
the cloned repository to "/path/to/hello". I.e., to itself, rather than
the correct hello.git.
The reason is that "clone" sets the config from the repo name you gave
it, not the path it finds on disk. The name you gave was not ambiguous
at the time of clone, but it became so during the clone. I am tempted to
say that we should set the config to the path we found on disk, not what
the user gave us. That includes the ugly "/.git" for non-bare repos, but
we should be able to safely strip that off without adding any ambiguity
(i.e, it is only "foo" versus "foo.git" that is ambiguous).
Unfortunately, the patch below which does that seems to make t7407 very
unhappy. It looks like the submodule test uses "git clone ." and
"git-submodule add" expects the "/." to still be at the end of the
configured URL when processing relative submodule paths. I'm not sure if
that is important, or an unnecessary brittleness in the submodule code.
Jens, Heiko?
---
diff --git a/builtin/clone.c b/builtin/clone.c
index 0d663e3..687d5c0 100644
--- a/builtin/clone.c
+++ b/builtin/clone.c
@@ -713,8 +713,12 @@ int cmd_clone(int argc, const char **argv, const char
*prefix)
repo_name = argv[0];
path = get_repo_path(repo_name, &is_bundle);
- if (path)
- repo = xstrdup(absolute_path(repo_name));
+ if (path) {
+ if (!suffixcmp(path, "/.git"))
+ repo = xstrndup(path, strlen(path) - 5);
+ else
+ repo = xstrdup(path);
+ }
else if (!strchr(repo_name, ':'))
die(_("repository '%s' does not exist"), repo_name);
else
diff --git a/t/t5601-clone.sh b/t/t5601-clone.sh
index 67869b4..0eeeb2d 100755
--- a/t/t5601-clone.sh
+++ b/t/t5601-clone.sh
@@ -280,4 +280,20 @@ test_expect_success 'clone checking out a tag' '
test_cmp fetch.expected fetch.actual
'
+test_expect_success 'clone does not create ambiguous config' '
+ git init --bare ambiguous.git &&
+ git clone ambiguous &&
+ (
+ cd ambiguous &&
+ test_commit one &&
+ git push --all
+ ) &&
+ echo one >expect &&
+ (
+ cd ambiguous.git &&
+ git log -1 --format=%s
+ ) >actual &&
+ test_cmp expect actual
+'
+
test_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] Clarify how content states are to be built as the fast-import stream is interpreted.
On Thu, Nov 08, 2012 at 01:30:38PM -0500, Eric wrote: > > Looks reasonable. Sign-off? > > > > Ah, right. Shall resend with signoff. Probably Tuesday - I'm on the > road, and the git instance on my laptop is prone to library-load issues. > > Or you can just add > > Signed-off-by: Eric S. Raymond That's fine. I can fix it up locally. Thanks. -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: git svn problem, probably a regression
On Sun, Nov 04, 2012 at 09:31:17PM +0100, Joern Huxhorn wrote: > git svn failed on me with the following error while cloning an SVN repository: > r1216 = fcf69d5102378ee41217d60384b96549bf2173cb (refs/remotes/svn/trunk) > Found possible branch point: svn+ssh://@/trunk => > svn+ssh://@/tags/_2008-10-22, 1216 > Use of uninitialized value $u in substitution (s///) at > /usr/local/Cellar/git/1.8.0/lib/Git/SVN.pm line 106. > Use of uninitialized value $u in concatenation (.) or string at > /usr/local/Cellar/git/1.8.0/lib/Git/SVN.pm line 106. > refs/remotes/svn/asset-manager-redesign: 'svn+ssh://' not found > in '' > > I'm running git 1.8.0 via Homebrew on OS X. It was called via svn2git but I > doubt that this is the culprit. > A colleague of mine was able to perform the same operation with git 1.7.x > (not sure which) on Debian so I assume that this is a regression. > > I just wanted to let you know. If you have time and can reproduce the bug at will, it would be very helpful to use "git-bisect" to pinpoint the exact commit that causes the breakage. -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 as/check-ignore] t0007: fix tests on Windows
On Sun, Nov 04, 2012 at 10:07:54PM +0100, Johannes Sixt wrote: > The value of $global_excludes is sometimes part of the output > that is tested for. Since git on Windows only sees DOS style paths, > we have to ensure that the "expected" values are constructed in > the same manner. To account for this, use $(pwd) to set the value > of global_excludes. > > Additionally, add a SYMLINKS prerequisite to the tests involving > symbolic links. > > Signed-off-by: Johannes Sixt Thanks. I put this on top of as/check-ignore in 'pu' for reference, but I am still expecting a re-roll from Adam or Duy at some point. -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] gitweb.perl: fix %highlight_ext mappings
On Sun, Nov 04, 2012 at 09:45:55AM -0800, rh wrote: > The previous change created a dictionary of one-to-one elements when > the intent was to map mutliple related types to one main type. > e.g. bash, ksh, zsh, sh all map to sh since they share similar syntax > This makes the mapping as the original change intended. > > Signed-off-by: Richard Hubbell Thanks. > diff --git a/gitweb.cgi.orig b/gitweb.cgi > index 060db27..155b238 100755 > --- a/gitweb.cgi.orig > +++ b/gitweb.cgi This is not the name of the source file in git.git, so "git am" choked. I was able to fix it up locally, though. No need to resend. -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] git p4: RCS expansion should not span newlines
On Sun, Nov 04, 2012 at 05:04:02PM -0500, Pete Wyckoff wrote: > This bug was introduced in cb585a9 (git-p4: keyword > flattening fixes, 2011-10-16). The newline character > is indeed special, and $File$ expansions should not try > to match across multiple lines. > > Based-on-patch-by: Chris Goard > Signed-off-by: Pete Wyckoff Thanks, I'll queue this for 'maint'. Seems obviously correct to me. -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] Clarify how content states are to be built as the fast-import stream is interpreted.
On Sun, Nov 04, 2012 at 11:31:01PM -0500, Eric S. Raymond wrote: > > --- > Documentation/git-fast-import.txt |8 ++-- > 1 file changed, 6 insertions(+), 2 deletions(-) Looks reasonable. Sign-off? -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 0/2] Another minor cleanup involving string_lists
On Mon, Nov 05, 2012 at 09:41:21AM +0100, Michael Haggerty wrote: > Nothing really earthshattering here. But it's funny how every time I > look closely at a site where I think string_lists could be used, I > find problems with the old code. In this case is_absolute_path() is > called with an argument that is not a null-terminated string, which is > incorrect (though harmless because the function only looks at the > first two bytes of the string). Thanks, the new version is much easier on the eyes. > Another peculiarity of the (old and new) code is that it rejects > "comments" even in paths taken from the colon-separated environment > variable GIT_ALTERNATE_OBJECT_DIRECTORIES. The fix would be to change > link_alt_odb_entries() to take a string_list and let the callers strip > out comments when appropriate. But it didn't seem worth the extra > code. I don't think it's worth worrying about. Given that the entries must be absolute paths anyway, we do not even have to worry about an insane path starting with "#". -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: Long clone time after "done."
I tried the patch but it doesn't appear to have helped :( Clone time
with it was ~32m.
Do you all by any chance have a tool to obfuscate a repository?
Probably I still wouldn't be permitted to distribute it but might make
the option slightly more palatable. Anything else that I can do to
help debug this problem?
On Thu, Nov 8, 2012 at 9:56 AM, Jeff King wrote:
> On Wed, Nov 07, 2012 at 11:32:37AM -0600, Uri Moszkowicz wrote:
>
>> #4 parse_object (sha1=0xb0ee98
>> "\017C\205Wj\001`\254\356\307Z\332\367\353\233.\375P}D") at
>> object.c:212
>> #5 0x004ae9ec in handle_one_ref (path=0xb0eec0
>> "refs/tags/", sha1=0xb0ee98
>> "\017C\205Wj\001`\254\356\307Z\332\367\353\233.\375P}D", flags=2,
>> cb_data=) at pack-refs.
>>
>> [...]
>>
>> It looks like handle_one_ref() is called for each ref and most result
>> in a call to read_sha1_file().
>
> Right. When generating the packed-refs file, we include the "peeled"
> reference for a tag (i.e., the commit that a tag object points to). So
> we have to actually read any tag objects to get the value.
>
> The upload-pack program generates a similar list, and I recently added
> some optimizations. This code path could benefit from some of them by
> using "peel_ref" instead of hand-rolling the tag dereferencing. The main
> optimization, though, is reusing peeled values that are already in
> packed-refs; we would probably need some additional magic to reuse the
> values from the source repository.
>
> However:
>
>> It only takes a second or so for each call but when you have thousands
>> of them (one for each ref) it adds up.
>
> I am more concerned that it takes a second to read each tag. Even in my
> pathological tests for optimizing upload-pack, peeling 50,000 refs took
> only half a second.
>
>> Adding --single-branch --branch doesn't appear to help as
>> it is implemented afterwards. I would like to debug this problem
>> further but am not familiar enough with the implementation to know
>> what the next step is. Can anyone offer some suggestions? I don't see
>> why a clone should be dependent on an O(#refs) operations.
>
> Does this patch help? In a sample repo with 5000 annotated tags, it
> drops my local clone time from 0.20s to 0.11s. Which is a big percentage
> speedup, but this code isn't taking a long time in the first place for
> me.
>
> ---
> diff --git a/pack-refs.c b/pack-refs.c
> index f09a054..3344749 100644
> --- a/pack-refs.c
> +++ b/pack-refs.c
> @@ -40,13 +40,9 @@ static int handle_one_ref(const char *path, const unsigned
> char *sha1,
>
> fprintf(cb->refs_file, "%s %s\n", sha1_to_hex(sha1), path);
> if (is_tag_ref) {
> - struct object *o = parse_object(sha1);
> - if (o->type == OBJ_TAG) {
> - o = deref_tag(o, path, 0);
> - if (o)
> - fprintf(cb->refs_file, "^%s\n",
> - sha1_to_hex(o->sha1));
> - }
> + unsigned char peeled[20];
> + if (!peel_ref(path, peeled))
> + fprintf(cb->refs_file, "^%s\n", sha1_to_hex(peeled));
> }
>
> if ((cb->flags & PACK_REFS_PRUNE) && !do_not_prune(flags)) {
--
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: make remote_heads config setting work.
On Mon, Nov 05, 2012 at 06:50:47PM -0500, Phil Pennock wrote: > Git configuration items can not contain underscores in their name; the > 'remote_heads' feature can not be enabled on a per-repository basis with > that name. > > This changes the git-config option to be `gitweb.remoteheads` but does > not change the gitweb.conf option, to avoid backwards compatibility > issues. We strip underscores from keys before looking through > git-config output for them. Makes sense. Thanks for considering the backwards compatibility angle. Hopefully we can avoid adding names with underscores in the future, but I think the mapping of "remote_head -> remotehead" is obvious enough that we do not need to worry about deprecating and replacing the old name. -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: [RFC] Add a new email notification script to "contrib"
On 12-11-08 11:37 AM, Ævar Arnfjörð Bjarmason wrote: > On Thu, Nov 8, 2012 at 5:24 PM, Marc Branchaud wrote: >> I'd like there to be one list that always gets everything, and the other >> lists should get subsets of the everything list. > > Since it supports multiple mailing lists per category you can always > do (I can't remember the specific config keys, but it's not > important): > > commits = all-git-activ...@example.com,git-comm...@example.com > tags= all-git-activ...@example.com,git-t...@example.com > > etc. True enough. Still a bit awkward though, especially for folks who can't set up emails lists easily. But I'm happy with this approach. M. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Fwd: [PATCH] Remove terminal symbols from non-terminal console
On Tue, Nov 06, 2012 at 10:17:21AM +1100, Michael Naumov wrote:
> As per discussion on msysgit user group:
> https://groups.google.com/forum/?fromgroups=#!topic/msysgit/U_a982_a3rc/discussion
> we found the following patch is required to get rid of weird terminal
> characters for other tools such as GitExtensions for Windows
>
> ---8<---
Please follow SubmittingPatches (missing signoff, weird use of scissors
marker that cuts out your commit message, and your commit message should
summarize the discussion).
> @@ -29,7 +29,7 @@ int recv_sideband(const char *me, int in_stream, int out)
>
> memcpy(buf, PREFIX, pf);
> term = getenv("TERM");
> - if (term && strcmp(term, "dumb"))
> + if (isatty(out) && term && strcmp(term, "dumb"))
> suffix = ANSI_SUFFIX;
> else
> suffix = DUMB_SUFFIX;
Is that right? The "out" fd is where we send sideband 1, and it is
almost always not going to be a tty. The suffix should be sent with
sideband 2, which goes to stderr. So I'd think you would want to check
isatty(2).
Also, most isatty checks also need to cover the case that a pager has
already been started. That is probably not worth worrying about here,
though, as we shouldn't be using a pager for commands that do network
communications (and if we do, omitting the magic line-clearing signal is
probably a sane thing to do).
I think the overall goal is a step in the right direction, though.
-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/4] strbuf_split_buf(): use ALLOC_GROW()
On Tue, Nov 06, 2012 at 08:54:07AM +0100, Michael Haggerty wrote: > > I suspect this was not used originally because ALLOC_GROW relies on > > alloc_nr, which does fast growth early on. At (x+16)*3/2, we end up with > > 24 slots for the first allocation. We are typically splitting 1 or 2 > > values. > > > > It probably doesn't make a big difference in practice, though, as we're > > talking about wasting less than 200 bytes on a 64-bit platform, and we > > do not tend to keep large numbers of split lists around. > > I did a little bit of archeology, and found out that > > * ALLOC_GROW() did indeed exist when this code was developed, so it > *could have* been used. > > * OTOH, I didn't find any indication on the mailing list that the > choice not to use ALLOC_GROW() was a conscious decision. > > So history doesn't give us much guidance. Thanks for digging. > If the size of the initial allocation is a concern, then I would suggest > adding a macro like ALLOC_SET_SIZE(ary,nr,alloc) that could be called to > initialize the size to some number less than 24. Such a macro might be > useful elsewhere, too. It wouldn't, of course, slow the growth rate > *after* the first allocation. I think we are getting into premature optimization territory. Let's take your series as a cleanup, and we can worry about micro-optimizing the allocation if and when it ever becomes an issue. -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: [RFC] Add a new email notification script to "contrib"
On Thu, Nov 8, 2012 at 5:24 PM, Marc Branchaud wrote: > I'd like there to be one list that always gets everything, and the other > lists should get subsets of the everything list. Since it supports multiple mailing lists per category you can always do (I can't remember the specific config keys, but it's not important): commits = all-git-activ...@example.com,git-comm...@example.com tags= all-git-activ...@example.com,git-t...@example.com etc. -- 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] Add a new email notification script to "contrib"
On 12-11-08 07:17 AM, Michael Haggerty wrote: > On 11/08/2012 12:39 PM, Ævar Arnfjörð Bjarmason wrote: >> [...] > > I'm glad it's getting some use. Thanks for the feedback. > >> I'll test it out some more, the issues I've had with it so far in >> migrating from the existing script + some custom hacks we have to it >> have been: >> >> * Overly verbose default templates, easy to overwrite now. Might send >>patches for some of them. > > The templating is currently not super flexible nor very well documented, > but simple changes should be easy enough. I mostly carried over the > text explanations from the old post-receive-email script; it is true > that they are quite verbose. > >> * No ability to link to a custom gitweb, probably easy now. > > What do you mean by "a custom gitweb"? What are the commitmail issues > involved? We would also like to have a gitweb link in the summary email, like Ævar describes. >> * If someone only pushes one commit I'd like to only have one e-mail >>with the diff, but if they push multiple commits I'd like to have a >>summary e-mail and replies to that which have the patches. >> >>It only seemed to support the latter mode, so you send out two >>e-mails for pushing one commit. > > That's correct, and I've also thought about the feature that you > described. I think it would be pretty easy to implement; it is only not > quite obvious to which mailing list(s?) such emails should be sent. Overall, what should be the approach to the separate mailing lists? Maybe I don't understand how the script is meant to work. We configured things here with 'mailinglist' and 'commitlist' set to different lists. Now if someone wants to get both the summary and per-commit emails, they need to be on both lists. If I understand correctly, if all 4 mailing lists are distinct, someone who wants all the emails needs to be on all of them. This seems a little awkward. I'd like there to be one list that always gets everything, and the other lists should get subsets of the everything list. M. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] Add a new email notification script to "contrib"
On 12-11-08 04:42 AM, Michael Haggerty wrote: > On 11/07/2012 10:47 PM, Ævar Arnfjörð Bjarmason wrote: >> On Fri, Jul 20, 2012 at 12:01 PM, Michael Haggerty >> wrote: >>> On 07/14/2012 08:59 AM, mhag...@alum.mit.edu wrote: Add a new Python script, contrib/hooks/post-receive-multimail.py, that can be used to send notification emails describing pushes into a git repository. [...] >>> >>> >>> Thanks to everybody for your feedback. I will try to incorporate it in a >>> new version of the script, which I will put forward as a replacement for >>> contrib/hooks/post-receive-email rather than as an alternative. But I have >>> very little open-sourcing time these days, and will be on vacation next >>> week, so please be patient (or feel free to lend a hand if you are so >>> inclined). >> >> I'm curious as to whether you got around to this? I'd be interested in >> updates on this script. I installed the script in our main repository here. Some folks complained about the "flood" of emails for large pushes, but having separate mailing lists solved that. Others really appreciate the individual messages with full patches. It's a challenge to create one script that can satisfy all users, but IMHO this comes pretty close. > Thanks for asking. I have made many of the changes that were requested > and/or I had planned: > > * Tentatively renamed the system to git-multimail > > * Store the configuration in namespace "multimailhook.*" instead of > "hooks.*". > > * Reinstated (optional) support for including shortlogs since the last > tag in announce emails. > > * Script to migrate post-receive-email configuration to the equivalent > git-multimail config. > > * Better documentation (including of the migration process). > > * Made it easier to use Python code to customize the script's behavior > (by allowing it to be imported as a Python module), plus a demo script > showing this usage. I look forward to trying out your updates. One thing I had to do to the original script was override get_envelopesender() in GenericEnvironment to use $USER if hooks.envelopesender is not set. (This is what the old post-receive-email script does.) This script is one of a couple of things on my git back-burner. Hopefully things will settle down here soon and I'll be able to get back to some git hacking in the next few weeks. M. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Long clone time after "done."
On Wed, Nov 07, 2012 at 11:32:37AM -0600, Uri Moszkowicz wrote:
> #4 parse_object (sha1=0xb0ee98
> "\017C\205Wj\001`\254\356\307Z\332\367\353\233.\375P}D") at
> object.c:212
> #5 0x004ae9ec in handle_one_ref (path=0xb0eec0
> "refs/tags/", sha1=0xb0ee98
> "\017C\205Wj\001`\254\356\307Z\332\367\353\233.\375P}D", flags=2,
> cb_data=) at pack-refs.
>
> [...]
>
> It looks like handle_one_ref() is called for each ref and most result
> in a call to read_sha1_file().
Right. When generating the packed-refs file, we include the "peeled"
reference for a tag (i.e., the commit that a tag object points to). So
we have to actually read any tag objects to get the value.
The upload-pack program generates a similar list, and I recently added
some optimizations. This code path could benefit from some of them by
using "peel_ref" instead of hand-rolling the tag dereferencing. The main
optimization, though, is reusing peeled values that are already in
packed-refs; we would probably need some additional magic to reuse the
values from the source repository.
However:
> It only takes a second or so for each call but when you have thousands
> of them (one for each ref) it adds up.
I am more concerned that it takes a second to read each tag. Even in my
pathological tests for optimizing upload-pack, peeling 50,000 refs took
only half a second.
> Adding --single-branch --branch doesn't appear to help as
> it is implemented afterwards. I would like to debug this problem
> further but am not familiar enough with the implementation to know
> what the next step is. Can anyone offer some suggestions? I don't see
> why a clone should be dependent on an O(#refs) operations.
Does this patch help? In a sample repo with 5000 annotated tags, it
drops my local clone time from 0.20s to 0.11s. Which is a big percentage
speedup, but this code isn't taking a long time in the first place for
me.
---
diff --git a/pack-refs.c b/pack-refs.c
index f09a054..3344749 100644
--- a/pack-refs.c
+++ b/pack-refs.c
@@ -40,13 +40,9 @@ static int handle_one_ref(const char *path, const unsigned
char *sha1,
fprintf(cb->refs_file, "%s %s\n", sha1_to_hex(sha1), path);
if (is_tag_ref) {
- struct object *o = parse_object(sha1);
- if (o->type == OBJ_TAG) {
- o = deref_tag(o, path, 0);
- if (o)
- fprintf(cb->refs_file, "^%s\n",
- sha1_to_hex(o->sha1));
- }
+ unsigned char peeled[20];
+ if (!peel_ref(path, peeled))
+ fprintf(cb->refs_file, "^%s\n", sha1_to_hex(peeled));
}
if ((cb->flags & PACK_REFS_PRUNE) && !do_not_prune(flags)) {
--
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] Add a new email notification script to "contrib"
On Thu, Nov 8, 2012 at 1:17 PM, Michael Haggerty wrote: > On 11/08/2012 12:39 PM, Ævar Arnfjörð Bjarmason wrote: >> [...] > > I'm glad it's getting some use. Thanks for the feedback. > >> I'll test it out some more, the issues I've had with it so far in >> migrating from the existing script + some custom hacks we have to it >> have been: >> >> * Overly verbose default templates, easy to overwrite now. Might send >>patches for some of them. > > The templating is currently not super flexible nor very well documented, > but simple changes should be easy enough. I mostly carried over the > text explanations from the old post-receive-email script; it is true > that they are quite verbose. > >> * No ability to link to a custom gitweb, probably easy now. > > What do you mean by "a custom gitweb"? What are the commitmail issues > involved? Just for the E-Mail to include a link to http://gitweb.example.com/git/?h=$our_hash etc. >> * If someone only pushes one commit I'd like to only have one e-mail >>with the diff, but if they push multiple commits I'd like to have a >>summary e-mail and replies to that which have the patches. >> >>It only seemed to support the latter mode, so you send out two >>e-mails for pushing one commit. > > That's correct, and I've also thought about the feature that you > described. I think it would be pretty easy to implement; it is only not > quite obvious to which mailing list(s?) such emails should be sent. > >> * Ability to limit the number of lines, but not line length, that's >>handy for some template repositories. Should be easy to add > > Should too-long lines be folded or truncated? Either way, it should be > pretty straightforward (Python even has a textwrap module that could be > used). > >> But in addition to that we have our own custom E-Mail notification >> scripts for: >> >> * People can subscribe to changes to certain files. I.e. if you >>modify very_important.c we'll send an E-Mail to a more widely seen >>review list. >> >> * Invididuals can also edit a config file to watch individual files / >>glob patterns of files, e.g. src/main.c or src/crypto* > > I implemented something like this back when we were using Subversion, > but it didn't get much use and seemed like more configuration hassle > than it was worth. > > If this were implemented and I asked for notifications about a > particular file, and a particular reference change affects the file, > what should I see? > > * The summary email for the reference change (yes/no)? > > * Detail emails for all commits within the reference change, or only for > the individual commits that modify the file? > > * Should the detail emails include the full patch for the corresponding > commit, or only the diffs affecting the file(s) of interest? (The > latter would start to get expensive, because the script would have to > generate individual emails per subscriber instead of letting sendmail > fan the emails out across all subscribers.) I think just sending the individual patch e-mails to all people who subscribe to paths that got changed in that patch that match their watchlist makes sense. That's how an internal E-mailing script that I'm hopign to replace with this works. That script *also* supports sending the whole batch of patches pushed in that push to someone watching any file that got modified in one of the patches, in case you also want to get other stuff pushed in pushes for files you're interested in. But it doesn't generate individual E-Mails per recipient. I think that way lies madness because as you rightly point out you have to start worrying about the combinatorial nightmare of generating the E-mails per subscriber. >> I think a good way to support that would be to have either a path to a >> config file with those watch specs, or a command so you could run "git >> show ..." on some repo users can push to. > > *How* this feature would be configured depends strongly on how the repo > is hosted. For example, gitolite has a well-developed scheme for how > the server should be configured, and it would make sense to work > together with that. Other people might configure user access via LDAP > or Apache. > >> But overall it's very nice. I'll make some time to test it in my >> organization (with lots of commits and people reading commit e-mails). -- 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/RFC] launch_editor: ignore SIGINT while the editor has control
On Wed, Nov 07, 2012 at 06:35:15PM -0500, Paul Fox wrote: > the user's editor likely catches SIGINT (ctrl-C). but if the user > spawns a command from the editor and uses ctrl-C to kill that command, > the SIGINT will likely also kill git itself. (depending on the > editor, this can leave the terminal in an unusable state.) > > Signed-off-by: Paul Fox Thanks, I think this makes sense. > krzysztof wrote: > ... > > editor.c: In function 'launch_editor': > > editor.c:42:3: warning: implicit declaration of function 'sigchain_push' > [-Wimplicit-function-declaration] > > editor.c:44:3: warning: implicit declaration of function 'sigchain_pop' > [-Wimplicit-function-declaration] > > sigh. i had that initially, lost the patch, and then recreated > without it. but i'm surprised my build (i did rebuild! :-) doesn't > emit those errors. in any case, here's the fixed patch. gcc will not warn about implicit declarations by default; try compiling with "-Wall". -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: Revert option for git add --patch
On Thu, Nov 08, 2012 at 12:57:19AM -0800, Jonathon Mah wrote: > I find myself performing similar actions to you: using git add -p to > stage hunks, sometimes editing the staged patch; and keeping mental > notes of things I wanted to revert, sometimes changing them in the > editor in another window, and sometimes reverting them after the add > session with git checkout -p). Yeah, I often use a similar workflow. A related one is: (1) Make lots of unrelated changes in the working tree. $ hack hack hack (2) Pick out hunks for the first commit. $ git add -p (3) Put the rest of the changes aside. $ git stash -k (4) Test (and possibly tweak) the result, then commit. $ make test $ git commit -m "topic 1" (5) Bring back the stashed changes. $ git stash pop (6) If there are still interesting changes, goto step 2. (7) Otherwise, discard with "git reset --hard" or "git checkout -p". I.e., iterating on the changes to put them into several different commits (and achieving a clean, testable state before making each commit). The downside of these workflows is that you have to say "no" to hunks multiple times (one per iteration) instead of just sorting them in a single pass. This works OK in practice, but it might be nice to have a tool that makes a single pass and lets you drop hunks into buckets (topic 1 vs topic 2 vs discard), and then apply the buckets in order, stopping to test, tweak, and commit after each one. > The interactive staging-and-editing tool could be improved, but I'm > not sure that tool should be called 'git add -p'. git add doesn't > touch the working tree — at least I hope not, because I wouldn't > expect it. Right. I think the idea of one-pass tool is a good one, but it should not be called "git add -p". -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: bare vs non-bare <1.7 then >=1.7 ?
On Thu, Nov 08, 2012 at 02:26:40PM +0100, Carlos Martín Nieto wrote: > > When experimenting in order to train some colleagues, I saw that If I > > clone a repository, I couldn't push to it because it was a non-bare > > one. > > Searchin for some explanations, I found this ressource: > > http://www.bitflop.com/document/111 > > > > It's told to be reliable information for Git < v1.7. > > > > What would be different for Git > 1.7 so that I could be up to date > > with the facts? > > Bare vs. non-bare hasn't changed. The reasoning behind the two types > hasn't changed and is pretty fundamental. There is no reason for it to > change. Right. The key thing that changed in git v1.7 is that we started warning about and denying an operation that had always been dangerous, and that is why the referenced document mentions that version. -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: three questions: proper forum? & reverting changes to the working directory
Hi, In article , McKown, John wrote: > 1) is this the proper forum for asking general git usage questions, such > as "how to"? If not, what is? I'd say that here is fine. #git on freenode is also a good source of advice. > 2) I am unsure that I did things the "proper" way. I have a git maintained > subdirectory. I made some changes and saved them in the working > directory, but did not "git add" or "git commit" them. I then decided > that I really messed up what I was doing (basically reformatting some > source code). So to revert the changes back to what was last committed, I > did a "git reset --hard HEAD". I think this is the proper way. But I > picked up that command in the section of the documentation which was > talking about abandoning a "git merge" attempt. What I did worked, but is > it the proper way? If not, what is? The easiest answer to this is run 'git status'. It'll list the files in various states, and tell you how to undo the changes. Andy -- 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: three questions: proper forum? & reverting changes to the working directory
On Thu, 8 Nov 2012 08:26:22 -0600 "McKown, John" wrote: > 1) is this the proper forum for asking general git usage questions, > such as "how to"? If not, what is? This list is okay for the general usage questions. But since it's the place where the development questions are discussed as well, and patches get posted, you might find its signal-to-noise ratio to be not very convenient for a casual user. For "mere mortals", we have another list, git-users, hosted on Google Groups [1]. It deals only with problems Git newbies have with Git. > 2) I am unsure that I did things the "proper" way. I have a git > maintained subdirectory. I made some changes and saved them in the > working directory, but did not "git add" or "git commit" them. I then > decided that I really messed up what I was doing (basically > reformatting some source code). So to revert the changes back to what > was last committed, I did a "git reset --hard HEAD". I think this is > the proper way. But I picked up that command in the section of the > documentation which was talking about abandoning a "git merge" > attempt. What I did worked, but is it the proper way? If not, what > is? Yes, that was the proper way. A failed Git merge attempt could be considered as just another case of a messed-up state of the work tree and the index. You might want to read the "Reset Demystified" [2] document for a friendly descriptions of how different ways to invoke `git reset` affect the repository, the index and the work tree. > > 3) More generically, suppose I have a file in my working directory > that I want to put back the way it was "n" commits ago. The best that > I can see, so far, is "git show HEAD~n:file >|file", replacing the > "n" and "file" with appropriate values. `git checkout` is able to fetch specific versions of the specified files if called like this: $ git checkout HEAD~n -- filename 1. http://groups.google.com/group/git-users/ 2. http://git-scm.com/2011/07/11/reset.html -- 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: three questions: proper forum? & reverting changes to the working directory
Well, a message I read after posting seems to have answered question #3. I'll look at "git checkout", which ignorant me thought was only used to change branches. -- John McKown Systems Engineer IV IT Administrative Services Group HealthMarkets(r) 9151 Boulevard 26 * N. Richland Hills * TX 76010 (817) 255-3225 phone * john.mck...@healthmarkets.com * www.HealthMarkets.com Confidentiality Notice: This e-mail message may contain confidential or proprietary information. If you are not the intended recipient, please contact the sender by reply e-mail and destroy all copies of the original message. HealthMarkets(r) is the brand name for products underwritten and issued by the insurance subsidiaries of HealthMarkets, Inc. -The Chesapeake Life Insurance Company(r), Mid-West National Life Insurance Company of TennesseeSM and The MEGA Life and Health Insurance Company.SM > -Original Message- > From: git-ow...@vger.kernel.org [mailto:git-ow...@vger.kernel.org] On > Behalf Of McKown, John > Sent: Thursday, November 08, 2012 8:26 AM > To: 'git@vger.kernel.org' > Subject: three questions: proper forum? & reverting changes to the > working directory > > 1) is this the proper forum for asking general git usage questions, > such as "how to"? If not, what is? > > 2) I am unsure that I did things the "proper" way. I have a git > maintained subdirectory. I made some changes and saved them in the > working directory, but did not "git add" or "git commit" them. I then > decided that I really messed up what I was doing (basically > reformatting some source code). So to revert the changes back to what > was last committed, I did a "git reset --hard HEAD". I think this is > the proper way. But I picked up that command in the section of the > documentation which was talking about abandoning a "git merge" attempt. > What I did worked, but is it the proper way? If not, what is? > > 3) More generically, suppose I have a file in my working directory that > I want to put back the way it was "n" commits ago. The best that I can > see, so far, is "git show HEAD~n:file >|file", replacing the "n" and > "file" with appropriate values. > > -- > John McKown > Systems Engineer IV > IT > > Administrative Services Group > > HealthMarkets(r) > > 9151 Boulevard 26 * N. Richland Hills * TX 76010 > (817) 255-3225 phone * > john.mck...@healthmarkets.com * www.HealthMarkets.com > > Confidentiality Notice: This e-mail message may contain confidential or > proprietary information. If you are not the intended recipient, please > contact the sender by reply e-mail and destroy all copies of the > original message. HealthMarkets(r) is the brand name for products > underwritten and issued by the insurance subsidiaries of HealthMarkets, > Inc. -The Chesapeake Life Insurance Company(r), Mid-West National Life > Insurance Company of TennesseeSM and The MEGA Life and Health Insurance > Company.SM > > > -- > 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 -- 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
three questions: proper forum? & reverting changes to the working directory
1) is this the proper forum for asking general git usage questions, such as "how to"? If not, what is? 2) I am unsure that I did things the "proper" way. I have a git maintained subdirectory. I made some changes and saved them in the working directory, but did not "git add" or "git commit" them. I then decided that I really messed up what I was doing (basically reformatting some source code). So to revert the changes back to what was last committed, I did a "git reset --hard HEAD". I think this is the proper way. But I picked up that command in the section of the documentation which was talking about abandoning a "git merge" attempt. What I did worked, but is it the proper way? If not, what is? 3) More generically, suppose I have a file in my working directory that I want to put back the way it was "n" commits ago. The best that I can see, so far, is "git show HEAD~n:file >|file", replacing the "n" and "file" with appropriate values. -- John McKown Systems Engineer IV IT Administrative Services Group HealthMarkets(r) 9151 Boulevard 26 * N. Richland Hills * TX 76010 (817) 255-3225 phone * john.mck...@healthmarkets.com * www.HealthMarkets.com Confidentiality Notice: This e-mail message may contain confidential or proprietary information. If you are not the intended recipient, please contact the sender by reply e-mail and destroy all copies of the original message. HealthMarkets(r) is the brand name for products underwritten and issued by the insurance subsidiaries of HealthMarkets, Inc. -The Chesapeake Life Insurance Company(r), Mid-West National Life Insurance Company of TennesseeSM and The MEGA Life and Health Insurance Company.SM -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
git-svn with ignore-paths misses/skips some revisions during fetch
My company has a fairly large SVN repository, and I'm running into a bug with git-svn where some revisions aren't being fetched. The repository has a standard trunk/tags/branches layout, but there are some top-level directories under trunk/ that clearly don't belong in Git, and some that do. So, I've been experimenting with two approaches: a single git-svn clone that uses 'ignore-paths' to exclude the stuff that I don't want; and a series of per-subdir clones that use "fetch = trunk/:refs/remotes/trunk" to pull in only that subdir. The problem is that the 'ignore-paths' approach sometimes misses commits during a fetch, and then at some later time will "realize" it and squash those changes onto some other, unrelated commit. (I've never seen this happen with the per-subdir 'fetch' approach.) Here are three commits in SVN: $ svn log -v -r 172602 -r 172605 -r 172626 svn://dev r172602 | matt | 2012-10-31 16:03:08 -0400 (Wed, 31 Oct 2012) | 1 line Changed paths: M /branches/localization-merge/buildprocess/antfiles/dmg.xml D /branches/localization-merge/buildprocess/resources/CDs/JavaApplicationStub M /branches/localization-merge/buildprocess/resources/launchanywhere/Cognitive Tutor.app.zip update to use newer java application stub r172605 | matt | 2012-10-31 16:29:25 -0400 (Wed, 31 Oct 2012) | 1 line Changed paths: M /branches/localization-merge/buildprocess/antfiles/dmg.xml M /branches/localization-merge/buildprocess/antfiles/lmstree.xml ensure that sdk-fe code is installed; fix to get correct app-dir value for antcalls; add problem authoring tool r172626 | leslie | 2012-11-01 08:49:36 -0400 (Thu, 01 Nov 2012) | 1 line Changed paths: M /branches/localization-merge/authoring/sdk/src/sdk-cc/src/main/java/cl/sdk/tdde/problemspace/problemtypes/geo/area/AreaPerimeterTutorInstance_PPV.java check the right shape-values for the gn The first two are not to be found in git: 'git log --all --grep 17260[25]' returns nothing. However, the third commit is there, and has had the changes from the earlier two (and some others) squashed into it somehow: $ git log --grep 172626 --numstat --summary commit 6d9a10abc17c74396e07bb4bc7692059ac0e8b99 Author: leslie Date: Thu Nov 1 12:49:36 2012 + check the right shape-values for the gn git-svn-id: svn://dev.carnegielearning.com/branches/localization-merge@172626 752fcc94-cd22-0410-baa8-ef54ac2c6973 13 8 authoring/sdk/src/sdk-cc/src/main/java/cl/sdk/tdde/problemspace/problemtypes/geo/area/AreaPerimeterTutorInstance_PPV.java 11 2 buildprocess/antfiles/dmg.xml 2 0 buildprocess/antfiles/lmstree.xml - - buildprocess/resources/CDs/JavaApplicationStub - - buildprocess/resources/launchanywhere/Cognitive Tutor.app.zip 0 25 runtime/sdk-be/src/main/resources/cl/sdk/common/localized_words_es.properties 98155143 runtime/sdk-be/src/main/resources/cl/sdk/tdde/problemspace/problemtypes/scratchpads/scratchpad-tutor.ctrules 773 5 runtime/sdk-be/src/main/resources/cl/sdk/tdde/problemspace/problemtypes/scratchpads/scratchpad-tutor.ctrules_strings 773 5 runtime/sdk-be/src/main/resources/cl/sdk/tdde/problemspace/problemtypes/scratchpads/scratchpad-tutor.ctrules_strings_es 156279 runtime/sdk-be/src/main/resources/cl/sdk/tdde/problemspace/problemtypes/scratchpads/scratchpad-tutor.cttypes 261 3 runtime/sdk-be/src/main/resources/cl/sdk/tdde/problemspace/problemtypes/scratchpads/scratchpad-tutor.cttypes_strings 261 3 runtime/sdk-be/src/main/resources/cl/sdk/tdde/problemspace/problemtypes/scratchpads/scratchpad-tutor.cttypes_strings_es 217 17 runtime/sdk-be/src/main/resources/cl/sdk/tdde/problemspace/problemtypes/scratchpads/scratchpad-tutor.ttspec 25 0 runtime/sdk-be/src/main/resources_es/cl/sdk/common/localized_words_es.properties 246 0 runtime/ui/src/main/resources/tp-tx-formula-sheet_es.html delete mode 100755 buildprocess/resources/CDs/JavaApplicationStub delete mode 100644 runtime/sdk-be/src/main/resources/cl/sdk/common/localized_words_es.properties create mode 100644 runtime/sdk-be/src/main/resources_es/cl/sdk/common/localized_words_es.properties create mode 100644 runtime/ui/src/main/resources/tp-tx-formula-sheet_es.html The directories on the server are: $ svn ls svn://dev/trunk IDEs/ QA-automation/ authoring/ bugtracking/ buildprocess/ curriculum/ doc/ images/ installer/ lib/ misc-tools/ research/ runtime/ scripts/ serversearch/ user-assistance/ web/ My config file is: $ cat .git/config [core] repositoryformatversion = 0
Re: bare vs non-bare <1.7 then >=1.7 ?
Mihamina Rakotomandimby writes: > Hi all, > > We're on the way to have our first project using Git. > We're currently mostly using Hg (90%) & SVN (10%). > > When experimenting in order to train some colleagues, I saw that If I > clone a repository, I couldn't push to it because it was a non-bare > one. > Searchin for some explanations, I found this ressource: > http://www.bitflop.com/document/111 > > It's told to be reliable information for Git < v1.7. > > What would be different for Git > 1.7 so that I could be up to date > with the facts? Bare vs. non-bare hasn't changed. The reasoning behind the two types hasn't changed and is pretty fundamental. There is no reason for it to change. cmn -- 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/PATCH] __git_ps1: migrate out of contrib/completion
Jonathan Nieder wrote: Different installers put the git-prompt.sh shell library at different places on the installed system, so there is no shared location users can count on: Fedora - /etc/profile.d/git-prompt.sh FWIW, we moved it to /usr/share/git-core/contrib/completion/ -- it was only ever in /etc/profile.d in an unreleased version of Fedora for a short time. (Side note: at some point, we'll likely install most or all of contrib under /usr/share/git-core/contrib in Fedora.) Having it in a more standard location would be excellent, it would avoid bugs like: https://bugzilla.redhat.com/show_bug.cgi?id=854061 :) -- ToddOpenPGP -> KeyID: 0xBEAF0CE3 | URL: www.pobox.com/~tmz/pgp ~~ Oh, very funny! Now tell the one that doesn't suck. -- Stewie Griffin pgpC8kkxp8d22.pgp Description: PGP signature
Re: [RFC] Add a new email notification script to "contrib"
On 11/08/2012 12:39 PM, Ævar Arnfjörð Bjarmason wrote: > [...] I'm glad it's getting some use. Thanks for the feedback. > I'll test it out some more, the issues I've had with it so far in > migrating from the existing script + some custom hacks we have to it > have been: > > * Overly verbose default templates, easy to overwrite now. Might send >patches for some of them. The templating is currently not super flexible nor very well documented, but simple changes should be easy enough. I mostly carried over the text explanations from the old post-receive-email script; it is true that they are quite verbose. > * No ability to link to a custom gitweb, probably easy now. What do you mean by "a custom gitweb"? What are the commitmail issues involved? > * If someone only pushes one commit I'd like to only have one e-mail >with the diff, but if they push multiple commits I'd like to have a >summary e-mail and replies to that which have the patches. > >It only seemed to support the latter mode, so you send out two >e-mails for pushing one commit. That's correct, and I've also thought about the feature that you described. I think it would be pretty easy to implement; it is only not quite obvious to which mailing list(s?) such emails should be sent. > * Ability to limit the number of lines, but not line length, that's >handy for some template repositories. Should be easy to add Should too-long lines be folded or truncated? Either way, it should be pretty straightforward (Python even has a textwrap module that could be used). > But in addition to that we have our own custom E-Mail notification > scripts for: > > * People can subscribe to changes to certain files. I.e. if you >modify very_important.c we'll send an E-Mail to a more widely seen >review list. > > * Invididuals can also edit a config file to watch individual files / >glob patterns of files, e.g. src/main.c or src/crypto* I implemented something like this back when we were using Subversion, but it didn't get much use and seemed like more configuration hassle than it was worth. If this were implemented and I asked for notifications about a particular file, and a particular reference change affects the file, what should I see? * The summary email for the reference change (yes/no)? * Detail emails for all commits within the reference change, or only for the individual commits that modify the file? * Should the detail emails include the full patch for the corresponding commit, or only the diffs affecting the file(s) of interest? (The latter would start to get expensive, because the script would have to generate individual emails per subscriber instead of letting sendmail fan the emails out across all subscribers.) > I think a good way to support that would be to have either a path to a > config file with those watch specs, or a command so you could run "git > show ..." on some repo users can push to. *How* this feature would be configured depends strongly on how the repo is hosted. For example, gitolite has a well-developed scheme for how the server should be configured, and it would make sense to work together with that. Other people might configure user access via LDAP or Apache. > But overall it's very nice. I'll make some time to test it in my > organization (with lots of commits and people reading commit e-mails). Cool, thanks! Michael -- Michael Haggerty mhag...@alum.mit.edu http://softwareswirl.blogspot.com/ -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Revert option for git add --patch
On Thu, Nov 8, 2012 at 3:57 PM, Jonathon Mah wrote: > Nathan, > > I find myself performing similar actions to you: using git add -p to stage > hunks, sometimes editing the staged patch; and keeping mental notes of things > I wanted to revert, sometimes changing them in the editor in another window, > and sometimes reverting them after the add session with git checkout -p). I agree. I'd be really nice to have an interactive command about hunk manipulation between HEAD (or some other ref), index and worktree in both directions (except writing to HEAD, of course). This reminds me of the "git put" discussion a while ago, which also moves code between different locations.. -- 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: [RFC] Add a new email notification script to "contrib"
On Thu, Nov 8, 2012 at 10:42 AM, Michael Haggerty wrote: > On 11/07/2012 10:47 PM, Ævar Arnfjörð Bjarmason wrote: >> I'm curious as to whether you got around to this? I'd be interested in >> updates on this script. > > Thanks for asking. I have made many of the changes that were requested > and/or I had planned: I was playing around with it for some work repos last night. > * Tentatively renamed the system to git-multimail > > * Store the configuration in namespace "multimailhook.*" instead of > "hooks.*". Great, I had made this change locally myself, makes it much easier to keep the configuration separate, and I think doing and having a migration script is better than using the original config variables. > * Reinstated (optional) support for including shortlogs since the last > tag in announce emails. > > * Script to migrate post-receive-email configuration to the equivalent > git-multimail config. > > * Better documentation (including of the migration process). > > * Made it easier to use Python code to customize the script's behavior > (by allowing it to be imported as a Python module), plus a demo script > showing this usage. That's very nice, I was monkeypatching the script to overwrite some templates. This makes that easy. > * Some primitive testing tools to generate a test git repository and > generate many kinds of notification emails (though the emails still have > to be checked manually for correctness). > > Nevertheless I think that the script is quite usable as it is and it > would be great if other people could try it out, give feedback, and even > submit patches. I'll test it out some more, the issues I've had with it so far in migrating from the existing script + some custom hacks we have to it have been: * Overly verbose default templates, easy to overwrite now. Might send patches for some of them. * No ability to link to a custom gitweb, probably easy now. * If someone only pushes one commit I'd like to only have one e-mail with the diff, but if they push multiple commits I'd like to have a summary e-mail and replies to that which have the patches. It only seemed to support the latter mode, so you send out two e-mails for pushing one commit. * Ability to limit the number of lines, but not line length, that's handy for some template repositories. Should be easy to add * I wanted a hook to override the options passed to sendmail in some cases, looks easier now with the modular design. But in addition to that we have our own custom E-Mail notification scripts for: * People can subscribe to changes to certain files. I.e. if you modify very_important.c we'll send an E-Mail to a more widely seen review list. * Invididuals can also edit a config file to watch individual files / glob patterns of files, e.g. src/main.c or src/crypto* I think a good way to support that would be to have either a path to a config file with those watch specs, or a command so you could run "git show ..." on some repo users can push to. But overall it's very nice. I'll make some time to test it in my organization (with lots of commits and people reading commit e-mails). -- 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
bare vs non-bare <1.7 then >=1.7 ?
Hi all, We're on the way to have our first project using Git. We're currently mostly using Hg (90%) & SVN (10%). When experimenting in order to train some colleagues, I saw that If I clone a repository, I couldn't push to it because it was a non-bare one. Searchin for some explanations, I found this ressource: http://www.bitflop.com/document/111 It's told to be reliable information for Git < v1.7. What would be different for Git > 1.7 so that I could be up to date with the facts? Thank you. -- RMA. -- 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] Add a new email notification script to "contrib"
On 11/07/2012 10:47 PM, Ævar Arnfjörð Bjarmason wrote: > On Fri, Jul 20, 2012 at 12:01 PM, Michael Haggerty > wrote: >> On 07/14/2012 08:59 AM, mhag...@alum.mit.edu wrote: >>> >>> Add a new Python script, contrib/hooks/post-receive-multimail.py, that >>> can be used to send notification emails describing pushes into a git >>> repository. [...] >> >> >> Thanks to everybody for your feedback. I will try to incorporate it in a >> new version of the script, which I will put forward as a replacement for >> contrib/hooks/post-receive-email rather than as an alternative. But I have >> very little open-sourcing time these days, and will be on vacation next >> week, so please be patient (or feel free to lend a hand if you are so >> inclined). > > I'm curious as to whether you got around to this? I'd be interested in > updates on this script. Thanks for asking. I have made many of the changes that were requested and/or I had planned: * Tentatively renamed the system to git-multimail * Store the configuration in namespace "multimailhook.*" instead of "hooks.*". * Reinstated (optional) support for including shortlogs since the last tag in announce emails. * Script to migrate post-receive-email configuration to the equivalent git-multimail config. * Better documentation (including of the migration process). * Made it easier to use Python code to customize the script's behavior (by allowing it to be imported as a Python module), plus a demo script showing this usage. * Some primitive testing tools to generate a test git repository and generate many kinds of notification emails (though the emails still have to be checked manually for correctness). But I haven't submitted the new version because I just haven't had a good block of time to really wrap it up and call it a "final" version. One remaining question is how to fit it into the git source tree along with its supporting materials (or even whether to maintain it as a separate project). Nevertheless I think that the script is quite usable as it is and it would be great if other people could try it out, give feedback, and even submit patches. So I just created a github repository containing my current version: https://github.com/mhagger/git-multimail Enjoy! Michael -- Michael Haggerty mhag...@alum.mit.edu http://softwareswirl.blogspot.com/ -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Revert option for git add --patch
Nathan, I find myself performing similar actions to you: using git add -p to stage hunks, sometimes editing the staged patch; and keeping mental notes of things I wanted to revert, sometimes changing them in the editor in another window, and sometimes reverting them after the add session with git checkout -p). The interactive staging-and-editing tool could be improved, but I'm not sure that tool should be called 'git add -p'. git add doesn't touch the working tree — at least I hope not, because I wouldn't expect it. But I eagerly support more discussion. If someone does want to add this feature to "git add -p" (or named differently), I'll add a request for another letter (perhaps '!') to edit the hunk in the working tree. Jonathon Mah m...@jonathonmah.com -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Revert option for git add --patch
Nathan Broadbent gmail.com> writes: > I would like to propose a revert option for 'git add --patch', that > reverts the hunk. I often use `git add -p` to skip whitespace changes > when preparing a patch, and a 'revert' option would save me from > running 'git checkout ' after I've staged the desired changes. Doesn't `git checkout -p` do what you describe? Kind regards, Michal Kiedrowicz -- 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
