Re: [PATCH v2 1/4] t4014: more tests about appending s-o-b lines
On 22.11.12 17:38, Nguyễn Thái Ngọc Duy wrote: > > Signed-off-by: Nguyễn Thái Ngọc Duy > --- > t/t4014-format-patch.sh | 145 > > 1 file changed, 145 insertions(+) > + echo -n subject | append_signoff >actual && "echo -n" is not portable, and we use printf everywhere. I found one "echo -n" in line 996. Can we squeeze that in, before going to next? diff --git a/t/t4014-format-patch.sh b/t/t4014-format-patch.sh index 6cfad13..f460930 100755 --- a/t/t4014-format-patch.sh +++ b/t/t4014-format-patch.sh @@ -993,7 +993,7 @@ EOF ' test_expect_success 'signoff: commit with only subject that does not end with NL' ' - echo -n subject | append_signoff >actual && + printf subject | append_signoff >actual && cat >expected <<\EOF && 4:Subject: [PATCH] subject 8: -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 6/8] imap-send: change msg_data from storing (char *, len) to storing strbuf
On 12/02/2012 02:48 AM, Junio C Hamano wrote: > Michael Haggerty writes: > >> On 11/29/2012 10:30 PM, Junio C Hamano wrote: >> A side effect of this change is that the memory for each message is freed after it is used rather than leaked, though that detail is unimportant given that imap-send is a top-level command. -- >>> >>> ? >> >> If by "?" you are wondering where the memory leak was, it was: > > No, I was wondering if you meant to say "---" to mark te remainder > of what you wrote does not exactly belong to the log message. Oh. Yes, that was my intention. 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: does a successful 'git gc' imply 'git fsck'
On Sat, Dec 1, 2012 at 6:31 PM, Sitaram Chamarty wrote: > Background: I have a situation where I have to fix up a few hundred > repos in terms of 'git gc' (the auto gc seems to have failed in many > cases; they have far more than 6700 loose objects). I also found some > corrupted objects in some cases that prevent the gc from completing. > > I am running "git gc" followed by "git fsck". The majority of the > repos I have worked through so far appear to be fine, but in the > larger repos (upwards of 2-3 GB) the git fsck is taking almost 5 times > longer than the 'gc'. > > If I could assume that a successful 'git gc' means an fsck is not > needed, I'd save a lot of time. Hence my question. Not really. For example fsck verifies that every blob when decompressed and fully inflated matches its SHA-1. gc only checks connectivity of the commit and tree graph by making sure every object was accounted for. But when creating the output pack it only verifies a CRC-32 was correct when copying the bits from the source to the destination, it does not verify that the data decompresses and matches the SHA-1 it should match. So it depends on what level of check you need to feel safe. -- 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 v6 4/4] submodule update: add submodule..remote config option
From: "W. Trevor King"
Don't force the user to clone from the tracked repository
(branch..remote) or `origin`. By setting
submodule..remote in .gitmodules or the usual git config files,
you can easily point a submodule at a different remote when using
`submodule update --remote`.
The configured remote name is also used in `submodule sync` to
determine which remote..url is updated with the submodule's
origin URL.
Signed-off-by: W. Trevor King
---
Documentation/config.txt| 7 ---
Documentation/git-submodule.txt | 10 +-
git-submodule.sh| 27 +--
t/t7406-submodule-update.sh | 18 ++
4 files changed, 48 insertions(+), 14 deletions(-)
diff --git a/Documentation/config.txt b/Documentation/config.txt
index 6f4663c..c54b9b4 100644
--- a/Documentation/config.txt
+++ b/Documentation/config.txt
@@ -1999,10 +1999,11 @@ submodule..update::
by 'git submodule init'; edit them to override the
URL and other values found in the `.gitmodules` file. See
+submodule..remote::
submodule..branch::
- The remote branch name for a submodule, used by `git submodule
- update --remote`. Set this option to override the value found in
- the `.gitmodules` file. See linkgit:git-submodule[1] and
+ The remote repository and branch names for a submodule, used by `git
+ submodule update --remote`. Set these options to override the value
+ found in the `.gitmodules` file. See linkgit:git-submodule[1] and
linkgit:gitmodules[5] for details.
submodule..fetchRecurseSubmodules::
diff --git a/Documentation/git-submodule.txt b/Documentation/git-submodule.txt
index 988bba9..1d8d5f1 100644
--- a/Documentation/git-submodule.txt
+++ b/Documentation/git-submodule.txt
@@ -242,11 +242,11 @@ OPTIONS
This option is only valid for the update command. Instead of using
the superproject's recorded SHA-1 to update the submodule, use the
status of the submodule's remote tracking branch. The remote used
- is branch's remote (`branch..remote`), defaulting to `origin`.
- The remote branch used defaults to `master`, but the branch name may
- be overridden by setting the `submodule..branch` option in
- either `.gitmodules` or `.git/config` (with `.git/config` taking
- precedence).
+ is branch's remote (`branch..remote`, defaulting to `origin`),
+ and the remote branch used defaults to `master`, but either may be
+ overridden by setting the `submodule..remote` or
+ `submodule..branch` option in `.gitmodules` or `.git/config`
+ (with `.git/config` taking precedence).
+
This works for any of the supported update procedures (`--checkout`,
`--rebase`, etc.). The only change is the source of the target SHA-1.
diff --git a/git-submodule.sh b/git-submodule.sh
index 27b02fe..3e39e29 100755
--- a/git-submodule.sh
+++ b/git-submodule.sh
@@ -179,6 +179,21 @@ get_submodule_config()
printf '%s' "${value:-$default}"
}
+#
+# Print the name of a submodule's configured remote
+#
+# $1 = submodule name
+#
+get_submodule_remote()
+{
+ name="$1"
+ remote=$(get_submodule_config "$name" remote)
+ if test -z "$remote"
+ then
+ remote=$(get_default_remote)
+ fi
+ printf '%s' "${remote}"
+}
#
# Map submodule path to submodule name
@@ -605,6 +620,7 @@ cmd_update()
fi
name=$(module_name "$sm_path") || exit
url=$(git config submodule."$name".url)
+ remote_name=$(get_submodule_remote "$name")
branch=$(get_submodule_config "$name" branch master)
if ! test -z "$update"
then
@@ -645,10 +661,9 @@ Maybe you want to use 'update --init'?")"
if test -z "$nofetch"
then
# Fetch remote before determining tracking $sha1
- (clear_local_git_env; cd "$sm_path" &&
git-fetch) ||
- die "$(eval_gettext "Unable to fetch in
submodule path '\$sm_path'")"
+ (clear_local_git_env; cd "$sm_path" &&
git-fetch "$remote_name") ||
+ die "$(eval_gettext "Unable to fetch
'\$remote_name' in submodule path '\$sm_path'")"
fi
- remote_name=$(get_default_remote)
sha1=$(clear_local_git_env; cd "$sm_path" &&
git rev-parse --verify
"${remote_name}/${branch}") ||
die "$(eval_gettext "Unable to find current
${remote_name}/${branch} revision in submodule path '\$sm_path'")"
@@ -669,8 +684,8 @@ Maybe you want to use 'update --init'?")"
# is not reachable from a ref.
(clear_local_git_env; cd "$sm_path" &&
[PATCH v6 1/4] submodule: add get_submodule_config helper funtion
From: "W. Trevor King"
Several submodule configuration variables
(e.g. fetchRecurseSubmodules) are read from .gitmodules with local
overrides from the usual git config files. This shell function mimics
that logic to help initialize configuration variables in
git-submodule.sh.
Signed-off-by: W. Trevor King
---
git-submodule.sh | 27 +++
1 file changed, 27 insertions(+)
diff --git a/git-submodule.sh b/git-submodule.sh
index ab6b110..97ce5e4 100755
--- a/git-submodule.sh
+++ b/git-submodule.sh
@@ -152,6 +152,33 @@ die_if_unmatched ()
}
#
+# Print a submodule configuration setting
+#
+# $1 = submodule name
+# $2 = option name
+# $3 = default value
+#
+# Checks in the usual git-config places first (for overrides),
+# otherwise it falls back on .gitmodules. This allows you to
+# distribute project-wide defaults in .gitmodules, while still
+# customizing individual repositories if necessary. If the option is
+# not in .gitmodules either, print a default value.
+#
+get_submodule_config()
+{
+ name="$1"
+ option="$2"
+ default="$3"
+ value=$(git config submodule."$name"."$option")
+ if test -z "$value"
+ then
+ value=$(git config -f .gitmodules submodule."$name"."$option")
+ fi
+ printf '%s' "${value:-$default}"
+}
+
+
+#
# Map submodule path to submodule name
#
# $1 = path
--
1.8.0.4.gf74b0fc.dirty
--
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 v6 0/4] submodule update: add --remote for submodule's upstream changes
From: "W. Trevor King" On Thu, Nov 29, 2012 at 10:27:19PM -0500, W. Trevor King wrote: > On Thu, Nov 29, 2012 at 08:11:20PM -0500, Phil Hord wrote: > > I've always felt that the "origin" defaults are broken and are simply > > being ignored because most users do not trip over them. But ISTR that > > submodule commands use the remote indicated by the superproject's > > current remote-tracking configuration, with a fallback to 'origin' if > > there is none. Sort of a "best effort" algorithm, I think. Am I > > remembering that wrong? > > The current code uses a bare "git-fetch". I'm not sure what that > defaults to if you're on a detached head. If it bothers you, I'm fine > adding the submodule..remote option in v6. Here it is. Now the remote defaults to $(get_default_remote) with an optional override via submodule..remote. Changes since v5: * New patch 1 for easy config variable setup. * Minor tweaks and rewordings in patches 2 and 3 (v5 patches 1 and 2). * New patch 4 adding submodule..remote. I'm fine with squashing patches 1, 2, and 4 together, if people prefer a more compact series. W. Trevor King (4): submodule: add get_submodule_config helper funtion submodule update: add --remote for submodule's upstream changes submodule add: If --branch is given, record it in .gitmodules submodule update: add submodule..remote config option Documentation/config.txt| 8 - Documentation/git-submodule.txt | 27 ++- Documentation/gitmodules.txt| 5 +++ git-submodule.sh| 74 ++--- t/t7400-submodule-basic.sh | 1 + t/t7406-submodule-update.sh | 49 +++ 6 files changed, 158 insertions(+), 6 deletions(-) -- 1.8.0.4.gf74b0fc.dirty -- 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 v6 2/4] submodule update: add --remote for submodule's upstream changes
From: "W. Trevor King" The current `update` command incorporates the superproject's gitlinked SHA-1 ($sha1) into the submodule HEAD ($subsha1). Depending on the options you use, it may checkout $sha1, rebase the $subsha1 onto $sha1, or merge $sha1 into $subsha1. This helps you keep up with changes in the upstream superproject. However, it's also useful to stay up to date with changes in the upstream subproject. Previous workflows for incorporating such changes include the ungainly: $ git submodule foreach 'git checkout $(git config --file $toplevel/.gitmodules submodule.$name.branch) && git pull' With this patch, all of the useful functionality for incorporating superproject changes can be reused to incorporate upstream subproject updates. When you specify --remote, the target $sha1 is replaced with a $sha1 of the submodule's origin/master tracking branch. If you want to merge a different tracking branch, you can configure the `submodule..branch` option in `.gitmodules`. You can override the `.gitmodules` configuration setting for a particular superproject by configuring the option in that superproject's default configuration (using the usual configuration hierarchy, e.g. `.git/config`, `~/.gitconfig`, etc.). Previous use of submodule..branch === Because we're adding a new configuration option, it's a good idea to check if anyone else is already using the option. The foreach-pull example above was described by Ævar 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. Although the --remote functionality is using `submodule..branch` slightly differently, the effect is the same. The foreach-pull example uses the option to record the name of the local branch to checkout before pulls. The tracking branch to be pulled is recorded in `.git/modules//config`, which was initialized by the module clone during `submodule add` or `submodule init`. Because the branch name stored in `submodule..branch` was likely the same as the branch name used during the initial `submodule add`, the same branch will be pulled in each workflow. Implementation details == In order to ensure a current tracking branch state, `update --remote` fetches the submodule's remote repository before calculating the SHA-1. However, I didn't change the logic guarding the existing fetch: if test -z "$nofetch" then # Run fetch only if $sha1 isn't present or it # is not reachable from a ref. (clear_local_git_env; cd "$path" && ( (rev=$(git rev-list -n 1 $sha1 --not --all 2>/dev/null) && test -z "$rev") || git-fetch)) || die "$(eval_gettext "Unable to fetch in submodule path '\$path'")" fi There will not be a double-fetch, because the new $sha1 determined after the `--remote` triggered fetch should always exist in the repository. If it doesn't, it's because some racy process removed it from the submodule's repository and we *should* be re-fetching. Signed-off-by: W. Trevor King --- Documentation/config.txt| 7 ++- Documentation/git-submodule.txt | 25 - Documentation/gitmodules.txt| 5 + git-submodule.sh| 22 +- t/t7406-submodule-update.sh | 31 +++ 5 files changed, 87 insertions(+), 3 deletions(-) diff --git a/Documentation/config.txt b/Documentation/config.txt index 11f320b..6f4663c 100644 --- a/Documentation/config.txt +++ b/Documentation/config.txt @@ -1998,7 +1998,12 @@ submodule..update:: for a submodule. These variables are initially populated by 'git submodule init'; edit them to override the URL and other values found in the `.gitmodules` file. See - linkgit:git-submodule[1] and linkgit:gitmodules[5] for details. + +submodule..branch:: + The remote branch name for a submodule, used by `git submodule + update --remote`. Set this option to override the value found in + the `.gitmodules` file. See linkgit:git-submodule[1] and + linkgit:gitmodules[5] for details. submodule..fetchRecurseSubmodules:: This option can be used to control recursive fetching of this diff --git a/Documentation/git-submodule.txt b/Documentation/git-submodule.txt index b4683bb..72dd52f 100644 --- a/Documentation/git-submodule.txt +++ b/Documentation/git-submodule.txt @@ -13,7 +13,7 @@ SYNOPSIS [--reference ] [--] [] 'git submodule' [--quiet] status [--cached] [--recursive] [--] [...] 'git submodule' [--quiet] init [--] [...] -'git submodul
[PATCH v6 3/4] submodule add: If --branch is given, record it in .gitmodules
From: "W. Trevor King" This allows you to easily record a submodule..branch option in .gitmodules when you add a new submodule. With this patch, $ git submodule add -b [] $ git config -f .gitmodules submodule..branch reduces to $ git submodule add -b [] This means that future calls to $ git submodule update --remote ... will get updates from the same branch that you used to initialize the submodule, which is usually what you want. Signed-off-by: W. Trevor King --- Documentation/git-submodule.txt | 2 ++ git-submodule.sh| 4 t/t7400-submodule-basic.sh | 1 + 3 files changed, 7 insertions(+) diff --git a/Documentation/git-submodule.txt b/Documentation/git-submodule.txt index 72dd52f..988bba9 100644 --- a/Documentation/git-submodule.txt +++ b/Documentation/git-submodule.txt @@ -208,6 +208,8 @@ OPTIONS -b:: --branch:: Branch of repository to add as submodule. + The name of the branch is recorded as `submodule..branch` in + `.gitmodules` for `update --remote`. -f:: --force:: diff --git a/git-submodule.sh b/git-submodule.sh index 104b5de..27b02fe 100755 --- a/git-submodule.sh +++ b/git-submodule.sh @@ -395,6 +395,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 "$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..90e2915 100755 --- a/t/t7400-submodule-basic.sh +++ b/t/t7400-submodule-basic.sh @@ -133,6 +133,7 @@ test_expect_success 'submodule add --branch' ' ( cd addtest && git submodule add -b initial "$submodurl" submod-branch && + test "initial" = "$(git config -f .gitmodules submodule.submod-branch.branch)" && git submodule init ) && -- 1.8.0.4.gf74b0fc.dirty -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/2] git-fast-import.txt: improve documentation for quoted paths
Matthieu Moy writes: > Junio C Hamano writes: > >> That "shell-style" contradicts with what fast-import.c says, though. >> It claims to grok \octal and described as C-style. > > As Peff mentionned, my last version is better, although still a bit > incomplete. My new version documents things that _must_ be escaped, but > not what _can_. Yeah, I agree. -- 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] t4049: avoid test failures on filemode challenged file systems (Windows)
Johannes Sixt writes: > Am 11/29/2012 21:48, schrieb Junio C Hamano: >> I've tested this with the testpen set on vfat mounted on my Linux >> box, ... >> and it seems to work OK, > > Works well here on Windows, too. Thanks for checking. -- 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/5] "diff --stat" counting fixes
Antoine Pelisse writes: > I feel like (but I can obviously be wrong): > 1. The info is redundant. When performing a merge, all diffs (without > --staged flag) are unmerged Yes, it is redundant. They are primarily meant as a warning to anybody who runs "git diff --stat" while their index is not fully merged so that they do not mistakenly think they are looking at meaningful numbers. The number of added lines likely includes the conflict markers you haven't dealt with ;-) > 2. While status shows the line once, while diff shows the diff for the file > once, while diff --shortstat counts the file once, diff --stat shows two > lines for the file. Yeah, don't use shortstat while your index is unmerged. > 3. diff --numstat shows two lines for the same file. As a script > writer (I guess that's what it's meant for), I would definitely expect > uniqueness in third column/filenames. Then your script wouldn't receive any hint in the output that you are reading from a nonsense input. When you see the same filename twice, you will know there is something strange (not just "I seem to have more added lines than I thought I added -- Ah, I see added files from both sides because I still have conflicts unresolved") that gives you a chance to notice. -- 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] gitk: add a checkbox to control the visibility of tags
Łukasz Stelmach writes:
> Enable hiding of tags displayed in the tree as yellow labels.
> If a repository is used together with a system like Gerrit
> there may be quite a lot of tags used to control building
> and there may be hardly any place left for commit subjects.
>
> Signed-off-by: Łukasz Stelmach
> ---
Paul, this patch is not done against your tree (does not have gitk
at the top-level), but other than that, the change mimics the way
existing hideremoes is implemented and looks reasonable to me.
We _may_ want to unify these two "hidestuff" into a list of patterns
that hides any ref that match one of the patterns in the list, e.g.
set hidestuff {refs/heads/*/* refs/tags/* refs/remotes/*}
may hide all tags, all remote-tracking branches and local branches
that have a slash in their names.
But that is an independent change that can come later.
> gitk-git/gitk | 23 +++
> 1 files changed, 15 insertions(+), 8 deletions(-)
>
> diff --git a/gitk-git/gitk b/gitk-git/gitk
> index d93bd99..274b46b 100755
> --- a/gitk-git/gitk
> +++ b/gitk-git/gitk
> @@ -1754,7 +1754,7 @@ proc readrefs {} {
> global tagids idtags headids idheads tagobjid
> global otherrefids idotherrefs mainhead mainheadid
> global selecthead selectheadid
> -global hideremotes
> +global hideremotes hidetags
>
> foreach v {tagids idtags headids idheads otherrefids idotherrefs} {
> catch {unset $v}
> @@ -1776,6 +1776,7 @@ proc readrefs {} {
> set headids($name) $id
> lappend idheads($id) $name
> } elseif {[string match "tags/*" $name]} {
> + if {$hidetags} continue
> # this lets refs/tags/foo^{} overwrite refs/tags/foo,
> # which is what we want since the former is the commit ID
> set name [string range $name 5 end]
> @@ -2702,7 +2703,7 @@ proc savestuff {w} {
> global cmitmode wrapcomment datetimeformat limitdiffs
> global colors uicolor bgcolor fgcolor diffcolors diffcontext
> selectbgcolor
> global autoselect autosellen extdifftool perfile_attrs markbgcolor
> use_ttk
> -global hideremotes want_ttk
> +global hideremotes hidetags want_ttk
>
> if {$stuffsaved} return
> if {![winfo viewable .]} return
> @@ -2725,6 +2726,7 @@ proc savestuff {w} {
> puts $f [list set autosellen $autosellen]
> puts $f [list set showneartags $showneartags]
> puts $f [list set hideremotes $hideremotes]
> + puts $f [list set hidetags $hidetags]
> puts $f [list set showlocalchanges $showlocalchanges]
> puts $f [list set datetimeformat $datetimeformat]
> puts $f [list set limitdiffs $limitdiffs]
> @@ -10864,7 +10866,7 @@ proc create_prefs_page {w} {
> proc prefspage_general {notebook} {
> global NS maxwidth maxgraphpct showneartags showlocalchanges
> global tabstop limitdiffs autoselect autosellen extdifftool perfile_attrs
> -global hideremotes want_ttk have_ttk
> +global hideremotes hidetags want_ttk have_ttk
>
> set page [create_prefs_page $notebook.general]
>
> @@ -10887,6 +10889,9 @@ proc prefspage_general {notebook} {
> ${NS}::checkbutton $page.hideremotes -text [mc "Hide remote refs"] \
> -variable hideremotes
> grid x $page.hideremotes -sticky w
> +${NS}::checkbutton $page.hidetags -text [mc "Hide tag labels"] \
> + -variable hidetags
> +grid x $page.hidetags -sticky w
>
> ${NS}::label $page.ddisp -text [mc "Diff display options"]
> grid $page.ddisp - -sticky w -pady 10
> @@ -10988,7 +10993,7 @@ proc doprefs {} {
> global oldprefs prefstop showneartags showlocalchanges
> global uicolor bgcolor fgcolor ctext diffcolors selectbgcolor markbgcolor
> global tabstop limitdiffs autoselect autosellen extdifftool perfile_attrs
> -global hideremotes want_ttk have_ttk
> +global hideremotes hidetags want_ttk have_ttk
>
> set top .gitkprefs
> set prefstop $top
> @@ -10997,7 +11002,7 @@ proc doprefs {} {
> return
> }
> foreach v {maxwidth maxgraphpct showneartags showlocalchanges \
> -limitdiffs tabstop perfile_attrs hideremotes want_ttk} {
> +limitdiffs tabstop perfile_attrs hideremotes hidetags
> want_ttk} {
> set oldprefs($v) [set $v]
> }
> ttk_toplevel $top
> @@ -7,7 +11122,7 @@ proc prefscan {} {
> global oldprefs prefstop
>
> foreach v {maxwidth maxgraphpct showneartags showlocalchanges \
> -limitdiffs tabstop perfile_attrs hideremotes want_ttk} {
> +limitdiffs tabstop perfile_attrs hideremotes hidetags
> want_ttk} {
> global $v
> set $v $oldprefs($v)
> }
> @@ -11131,7 +11136,7 @@ proc prefsok {} {
> global oldprefs prefstop showneartags showlocalchanges
> global fontpref mainfont textfont uifont
> global limitdiffs treediffs perfile_attrs
> -global hideremotes
> +global hideremotes hidetags
>
> catch
Re: [PATCH v7 p2 1/2] fast-export: don't handle uninteresting refs
Felipe Contreras writes: > On Thu, Nov 29, 2012 at 2:16 AM, Max Horn wrote: >> >> On 28.11.2012, at 23:23, Felipe Contreras wrote: >> >>> They have been marked as UNINTERESTING for a reason, lets respect that. >>> >>> Currently the first ref is handled properly, but not the rest: >>> >>> % git fast-export master ^uninteresting ^foo ^bar >> >> All these refs are assumed to point to the same object, right? I think it >> would be better if the commit message stated that explicitly. To make up for >> the lost space, you could then get rid of one of the four refs, I think >> three are sufficient to drive the message home ;-). > > Yeah, they point to the same object. Do you want me to amend the log message of that commit to clarify this? >> >> > ... > It's actually revs.cmdline, I typed the wrong one. > ... > So I think it's good. Wait. I at least read two points above you said what you wrote in the commit was not corrrect and misleading to later readers. And then I hear "it's good". Which one? Are you merely saying that it is easily fixable to become good? If so, what do you want to do with these not-so-good part? If you want to ask me to amend, that is fine, but do so in a more explicit way, not in a message at the tail of long thread that is not even CC'ed to me. Of course, a proper re-roll like everybody else does is just fine. Thanks. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] submodule: add 'deinit' command
Jens Lehmann writes: > With "git submodule init" the user is able to tell git he cares about one > or more submodules and wants to have it populated on the next call to "git > submodule update". But currently there is no easy way he could tell git he > does not care about a submodule anymore and wants to get rid of his local > work tree (except he knows a lot about submodule internals and removes the > "submodule.$name.url" setting from .git/config himself). > > Help those users by providing a 'deinit' command. This removes the url > setting from .git/config either for the given submodule(s) or for all > those which have been initialized if none were given. Complain only when > for a submodule given on the command line the url setting can't be found > in .git/config. > > Add tests and link the man pages of "git submodule deinit" and "git rm" to > assist the user in deciding whether removing or unregistering the submodule > is the right thing to do for him. > > Signed-off-by: Jens Lehmann > --- I fully agree with your analysis on the reason why the "url" element is special and has to be copied to $GIT_DIR/config, but when you deinit (or uninit) a submodule to say you are no longer interested in it and do not want it populated in the context of the superproject, I am not sure if removing only submodule.$name.url (so that when you later decide to "init" it again, you will keep the values for submodule.$name.update and other things from the previous life) is the sane thing to do, or it is better to remove submodule.$name.* altogether as if an earlier "init" has never happened. Would it be worth analyzing the pros-and-cons here? > Am 01.12.2012 16:56, schrieb Jens Lehmann: >> Am 01.12.2012 00:52, schrieb Phil Hord: >>> If I never 'submodule init' a submodule, it does not get visited by >>> 'git submodule foreach', among others. I think some people use this >>> behavior explicitly. >>> >>> On the other hand, I've also notice that a submodule which I have >>> removed does not get de-inited later one. It causes my 'git submodule >>> foreach' to emit errors. :-( >> >> I'm currently hacking on "git submodule deinit" which removes the 'url' >> setting from git/config. This should do the trick for you, right? > > And here we go ... > > > Documentation/git-rm.txt| 4 > Documentation/git-submodule.txt | 11 + > git-submodule.sh| 50 > - > t/t7400-submodule-basic.sh | 11 + > 4 files changed, 75 insertions(+), 1 deletion(-) > > diff --git a/Documentation/git-rm.txt b/Documentation/git-rm.txt > index 262436b..ec42bf5 100644 > --- a/Documentation/git-rm.txt > +++ b/Documentation/git-rm.txt > @@ -149,6 +149,10 @@ files that aren't ignored are present in the submodules > work tree. > Ignored files are deemed expendable and won't stop a submodule's work > tree from being removed. > > +If you only want to remove the local checkout of a submodule from your > +work tree without committing that use `git submodule deinit` instead > +(see linkgit:git-submodule[1]). > + > EXAMPLES > > `git rm Documentation/\*.txt`:: > diff --git a/Documentation/git-submodule.txt b/Documentation/git-submodule.txt > index b1de3ba..fba77f6 100644 > --- a/Documentation/git-submodule.txt > +++ b/Documentation/git-submodule.txt > @@ -13,6 +13,7 @@ SYNOPSIS > [--reference ] [--] [] > 'git submodule' [--quiet] status [--cached] [--recursive] [--] [...] > 'git submodule' [--quiet] init [--] [...] > +'git submodule' [--quiet] deinit [--] [...] > 'git submodule' [--quiet] update [--init] [-N|--no-fetch] [--rebase] > [--reference ] [--merge] [--recursive] [--] > [...] > 'git submodule' [--quiet] summary [--cached|--files] [(-n|--summary-limit) > ] > @@ -134,6 +135,16 @@ init:: > the explicit 'init' step if you do not intend to customize > any submodule locations. > > +deinit:: > + Unregister the submodules, i.e. remove the `submodule.$name.url` > + setting from .git/config. Further calls to `git submodule update`, > + `git submodule foreach` and `git submodule sync` will skip any > + unregistered submodules until they are initialized again, so use > + this command if you don't want to have a local checkout of the > + submodule in your work tree anymore. If you really want to remove > + a submodule from the repository and commit that use > + linkgit:git-rm[1] instead. > + > update:: > Update the registered submodules, i.e. clone missing submodules and > checkout the commit specified in the index of the containing repository. > diff --git a/git-submodule.sh b/git-submodule.sh > index 2365149..4059a2e 100755 > --- a/git-submodule.sh > +++ b/git-submodule.sh > @@ -8,6 +8,7 @@ dashless=$(basename "$0" | sed -e 's/-/ /') > USAGE="[--quiet] add [-b ] [-f|--force] [--name ] [--reference > ] [--] [] > or: $dashless [--quiet] status [--cached] [--recursive] [--]
Re: [PATCH 6/8] imap-send: change msg_data from storing (char *, len) to storing strbuf
Michael Haggerty writes: > On 11/29/2012 10:30 PM, Junio C Hamano wrote: > >>> A side effect of this change is that the memory for each message is >>> freed after it is used rather than leaked, though that detail is >>> unimportant given that imap-send is a top-level command. >>> >>> -- >> >> ? > > If by "?" you are wondering where the memory leak was, it was: No, I was wondering if you meant to say "---" to mark te remainder of what you wrote does not exactly belong to the log message. >>> For some reason, there is a bunch of infrastructure in this file for >>> dealing with IMAP flags, although there is nothing in the code that >>> actually allows any flags to be set. If there is no plan to add >>> support for flags in the future, a bunch of code could be ripped out >>> and "struct msg_data" could be completely replaced with strbuf. >> >> Yeah, after all these years we have kept the unused flags field >> there and nobody needed anything out of it. I am OK with a removal >> if it is done at the very end of the series. > > I don't think the removal of flags needs to be part of the same series. Oh, I did not think so, either. > I suggest a separate patch series dedicated to deleting *all* the extra > imap infrastructure at once. That being said, I'm not committing to do > so. (We could add it to an "straightforward projects for aspiring git > developers" list, if we had such a thing.) A "low-hanging fruit and/or janitorial work" stack may be worth having. -- 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: Inconsistency in messages about --set-upstream from git pull and git branch
Dan Rosén writes: > > git branch --set-upstream master origin/ > This has been fixed already in 1.8.0.1 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] remove/deprecate 'submodule init' and 'sync'
On Sat, Dec 01, 2012 at 07:04:05PM +0100, Jens Lehmann wrote: > Am 01.12.2012 18:49, schrieb W. Trevor King: > > I think removing `init` will cause some compatibility issues anyway, > > so I was re-imaging how you do it. I don't think update='none' and > > "don't populate my submodule" are distinct ideas, while a locally > > configured url="somwhere" and "please populate my submodule" are (with > > the blank-url case defaulting to the superproject itself). > > Why would we want to remove "init"? It still has to copy the "url" > setting (and it would be a compatibility nightmare if we would change > that, imagine different git versions used on the same work tree). In my init-less rewrite, it doesn't have to copy the url setting. People using older versions of Git would need to run `init` using their old version. Having the url defined in .git/config won't break my init-less submodule commands, it just means that the value in .gitmodules will be masked. > >> What real world problems do we have with the current init/sync that > >> this approach would solve? > > > > I don't have any, but in my `update --remote` series I'm adding two > > new config options that are handled differently (define in > > .gitmodules, override in superproject .git/config) than existing > > submodules options. > > No, they're not. They are just handled differently than "url" and > "update", but will behave just like "fetchRecurseSubmodules" and > "ignore" do since day one. And as I explained in another mail I > think "url" is special and "update" should be change to behave like > the other two some day. I somehow missed those earlier. Thanks for correcting my tunnel vision. This makes me much happier about postponing the init-removal. Cheers, Trevor -- This email may be signed or encrypted with GnuPG (http://www.gnupg.org). For more information, see http://en.wikipedia.org/wiki/Pretty_Good_Privacy signature.asc Description: OpenPGP digital signature
Re: [RFC] remove/deprecate 'submodule init' and 'sync'
Am 01.12.2012 18:49, schrieb W. Trevor King: > I think removing `init` will cause some compatibility issues anyway, > so I was re-imaging how you do it. I don't think update='none' and > "don't populate my submodule" are distinct ideas, while a locally > configured url="somwhere" and "please populate my submodule" are (with > the blank-url case defaulting to the superproject itself). Why would we want to remove "init"? It still has to copy the "url" setting (and it would be a compatibility nightmare if we would change that, imagine different git versions used on the same work tree). >> What real world problems do we have with the current init/sync that >> this approach would solve? > > I don't have any, but in my `update --remote` series I'm adding two > new config options that are handled differently (define in > .gitmodules, override in superproject .git/config) than existing > submodules options. No, they're not. They are just handled differently than "url" and "update", but will behave just like "fetchRecurseSubmodules" and "ignore" do since day one. And as I explained in another mail I think "url" is special and "update" should be change to behave like the other two some day. -- 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] remove/deprecate 'submodule init' and 'sync'
On Sat, Dec 01, 2012 at 06:25:17PM +0100, Jens Lehmann wrote: > Am 01.12.2012 17:30, schrieb W. Trevor King: > > On Sat, Dec 01, 2012 at 04:38:02PM +0100, Jens Lehmann wrote: > > > 1) It tells the submodule commands that the user wants to have > > > that submodule populated (which is done in a subsequent "update" > > > after "init" copied the url there). > > > > Good point, but this should depend on submodule..update; > > having it as a side effect of a local submodule..url makes > > no sense. > > Sorry, but that makes tons of sense: url controls if the submodule > is to be populated and from where, update controls how (and can even > veto populating it if set to "none"). We /could/ do it differently, > but I can't see why we should (and risk severe compatibility issues). I think removing `init` will cause some compatibility issues anyway, so I was re-imaging how you do it. I don't think update='none' and "don't populate my submodule" are distinct ideas, while a locally configured url="somwhere" and "please populate my submodule" are (with the blank-url case defaulting to the superproject itself). > > > 2) It can be used to follow moving upstreams (think of checking > > > out an earlier commit before the upstream was moved, you won't > > > be able to clone it from there without having the new setting > > > persist). And which repository you follow is a matter of trust, > > > so the extra "git submodule sync" in that case is a good thing > > > to have. > > > > > > So I believe 'url' is the only setting that should be copied > > > into .git/config while all the others shouldn't. > > > > If you want to override the old repository location for an old > > commit, setting submodule..url makes sense. My rewritten > > `sync` updates the local submodule..url in the superproject > > if the configuration option is already set [1]. Perhaps a `sync > > --local` invocation should forcibly populate the local > > submodule..url to make this workflow easier. Bundling sugar > > for this special case should not happen under an extra command > > called `init`. > > What real world problems do we have with the current init/sync that > this approach would solve? I don't have any, but in my `update --remote` series I'm adding two new config options that are handled differently (define in .gitmodules, override in superproject .git/config) than existing submodules options. I'm trying to avoid confusing users by standardizing on the more flexible method, which avoids copying stuff into the superproject's .git/config, and under which the current `init` functionality doesn't make much sense. > > > > [snip get_submodule_config()] > > > > > > Something like that makes sense. You can use it for the settings > > > you add first and we can then reuse that for 'update' in a > > > separate patch later. > > > > I'm currently working out the details independently against > > v1.8.0. This will be a fairly major shift, so I think it should > > stay independent of `update --remote`. The `update --remote` > > stuff should be easy to adjust/rebase if the `init` > > removal/adjustment develops into something acceptable. > > I totally agree. Let's get the `update --remote` stuff ready first. Ok, but we'll have the possible confusion about option setting that I mention above. Still, it's good to minimize the number of irons in the fire, and an `init` removal will probably not get in until 2.0 anyway. If other people are fine with the different initialization paths, I'll put the init-removal on hold for now. Cheers, Trevor -- This email may be signed or encrypted with GnuPG (http://www.gnupg.org). For more information, see http://en.wikipedia.org/wiki/Pretty_Good_Privacy signature.asc Description: OpenPGP digital signature
Re: [msysGit] [PATCH/RFC 1/5] mingw: make fgetc raise SIGINT if apropriate
On Sat, Dec 01, 2012 at 01:31:23PM +0100, Erik Faye-Lund wrote: > >> One thing you might want to mention is that the fgetc() handling is not > >> thread-safe, and intentionally so: if two threads read from the same > >> console, we are in trouble anyway. > > > > That makes sense to me, but I'm confused why it is part of mingw_fgetc, > > which could in theory read from arbitrary streams, no? It it is not > > necessarily a console operation at all. I feel like I'm probably missing > > something subtle here... > > I did add an early out for the non-console cases. Is this what you're > missing, perhaps? Oops, yes. That is exactly what I was missing. :) Sorry for the noise. -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] remove/deprecate 'submodule init' and 'sync'
Am 01.12.2012 17:30, schrieb W. Trevor King: > On Sat, Dec 01, 2012 at 04:38:02PM +0100, Jens Lehmann wrote: >> You need to handle the 'url' setting differently. While I think the 'update' >> setting should not be copied into .git/config at all (because it makes it >> impossible for upstream to change that later without the user copying that >> himself as 'sync' doesn't do that) the 'url' setting in .git/config has two >> important implications: >> >> 1) It tells the submodule commands that the user wants to have that >> submodule populated (which is done in a subsequent "update" after "init" >> copied the url there). > > Good point, but this should depend on submodule..update; having it as a > side effect of a local submodule..url makes no sense. Sorry, but that makes tons of sense: url controls if the submodule is to be populated and from where, update controls how (and can even veto populating it if set to "none"). We /could/ do it differently, but I can't see why we should (and risk severe compatibility issues). > Perhaps `submodule init` should be reduced to just wrap: > > $ git config submodule..update checkout > > where the default update configuration would be 'none'. > >> 2) It can be used to follow moving upstreams (think of checking out an >> earlier commit before the upstream was moved, you won't be able to clone it >> from there without having the new setting persist). And which repository you >> follow is a matter of trust, so the extra "git submodule sync" in that case >> is a good thing to have. >> >> So I believe 'url' is the only setting that should be copied into >> .git/config while all the others shouldn't. > > If you want to override the old repository location for an old commit, > setting submodule..url makes sense. My rewritten `sync` updates the > local submodule..url in the superproject if the configuration option is > already set [1]. Perhaps a `sync --local` invocation should forcibly > populate the local submodule..url to make this workflow easier. > Bundling sugar for this special case should not happen under an extra command > called `init`. What real world problems do we have with the current init/sync that this approach would solve? >>> [snip get_submodule_config()] >> >> Something like that makes sense. You can use it for the settings you add >> first and we can then reuse that for 'update' in a separate patch later. > > I'm currently working out the details independently against v1.8.0. This will > be a fairly major shift, so I think it should stay independent of `update > --remote`. The `update --remote` stuff should be easy to adjust/rebase if > the `init` removal/adjustment develops into something acceptable. I totally agree. Let's get the `update --remote` stuff ready first. -- 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] remove/deprecate 'submodule init' and 'sync'
I'm currently stuck with adding a commit-less existing repository as a submodule (which happens in t7400-submodule-basic.sh, ../bar/a/b/c works with relative local path): $ mkdir -p super/sub $ cd super $ git init $ (cd sub && git init) $ git submodule add ./ sub $ git status # On branch master # # Initial commit # # Changes to be committed: # (use "git rm --cached ..." to unstage) # # new file: .gitmodules # What I'm missing is a gitlink form sub for 'Subproject commit 0...' or some such. When the subproject has an actual commit, things work as expected: $ mkdir -p super/sub $ cd super $ git init $ (cd sub && git init && echo line-1 > file && git add file && git commit -m file) $ git submodule add ./ sub $ git status # On branch master # # Initial commit # # Changes to be committed: # (use "git rm --cached ..." to unstage) # # new file: .gitmodules # new file: sub # This means that module_list isn't aware of the empty submodule, when the user has just explicitly added it. Fixing this would seem to need either 'Subproject commit 0...' as I suggested earlier, or an adjustment to module_list that also spits out submodules that are in .gitmodules but not in the index. Cheers, Trevor -- This email may be signed or encrypted with GnuPG (http://www.gnupg.org). For more information, see http://en.wikipedia.org/wiki/Pretty_Good_Privacy signature.asc Description: OpenPGP digital signature
[PATCH] submodule: add 'deinit' command
With "git submodule init" the user is able to tell git he cares about one
or more submodules and wants to have it populated on the next call to "git
submodule update". But currently there is no easy way he could tell git he
does not care about a submodule anymore and wants to get rid of his local
work tree (except he knows a lot about submodule internals and removes the
"submodule.$name.url" setting from .git/config himself).
Help those users by providing a 'deinit' command. This removes the url
setting from .git/config either for the given submodule(s) or for all
those which have been initialized if none were given. Complain only when
for a submodule given on the command line the url setting can't be found
in .git/config.
Add tests and link the man pages of "git submodule deinit" and "git rm" to
assist the user in deciding whether removing or unregistering the submodule
is the right thing to do for him.
Signed-off-by: Jens Lehmann
---
Am 01.12.2012 16:56, schrieb Jens Lehmann:
> Am 01.12.2012 00:52, schrieb Phil Hord:
>> If I never 'submodule init' a submodule, it does not get visited by
>> 'git submodule foreach', among others. I think some people use this
>> behavior explicitly.
>>
>> On the other hand, I've also notice that a submodule which I have
>> removed does not get de-inited later one. It causes my 'git submodule
>> foreach' to emit errors. :-(
>
> I'm currently hacking on "git submodule deinit" which removes the 'url'
> setting from git/config. This should do the trick for you, right?
And here we go ...
Documentation/git-rm.txt| 4
Documentation/git-submodule.txt | 11 +
git-submodule.sh| 50 -
t/t7400-submodule-basic.sh | 11 +
4 files changed, 75 insertions(+), 1 deletion(-)
diff --git a/Documentation/git-rm.txt b/Documentation/git-rm.txt
index 262436b..ec42bf5 100644
--- a/Documentation/git-rm.txt
+++ b/Documentation/git-rm.txt
@@ -149,6 +149,10 @@ files that aren't ignored are present in the submodules
work tree.
Ignored files are deemed expendable and won't stop a submodule's work
tree from being removed.
+If you only want to remove the local checkout of a submodule from your
+work tree without committing that use `git submodule deinit` instead
+(see linkgit:git-submodule[1]).
+
EXAMPLES
`git rm Documentation/\*.txt`::
diff --git a/Documentation/git-submodule.txt b/Documentation/git-submodule.txt
index b1de3ba..fba77f6 100644
--- a/Documentation/git-submodule.txt
+++ b/Documentation/git-submodule.txt
@@ -13,6 +13,7 @@ SYNOPSIS
[--reference ] [--] []
'git submodule' [--quiet] status [--cached] [--recursive] [--] [...]
'git submodule' [--quiet] init [--] [...]
+'git submodule' [--quiet] deinit [--] [...]
'git submodule' [--quiet] update [--init] [-N|--no-fetch] [--rebase]
[--reference ] [--merge] [--recursive] [--]
[...]
'git submodule' [--quiet] summary [--cached|--files] [(-n|--summary-limit) ]
@@ -134,6 +135,16 @@ init::
the explicit 'init' step if you do not intend to customize
any submodule locations.
+deinit::
+ Unregister the submodules, i.e. remove the `submodule.$name.url`
+ setting from .git/config. Further calls to `git submodule update`,
+ `git submodule foreach` and `git submodule sync` will skip any
+ unregistered submodules until they are initialized again, so use
+ this command if you don't want to have a local checkout of the
+ submodule in your work tree anymore. If you really want to remove
+ a submodule from the repository and commit that use
+ linkgit:git-rm[1] instead.
+
update::
Update the registered submodules, i.e. clone missing submodules and
checkout the commit specified in the index of the containing repository.
diff --git a/git-submodule.sh b/git-submodule.sh
index 2365149..4059a2e 100755
--- a/git-submodule.sh
+++ b/git-submodule.sh
@@ -8,6 +8,7 @@ dashless=$(basename "$0" | sed -e 's/-/ /')
USAGE="[--quiet] add [-b ] [-f|--force] [--name ] [--reference
] [--] []
or: $dashless [--quiet] status [--cached] [--recursive] [--] [...]
or: $dashless [--quiet] init [--] [...]
+ or: $dashless [--quiet] deinit [--] [...]
or: $dashless [--quiet] update [--init] [-N|--no-fetch] [-f|--force]
[--rebase] [--reference ] [--merge] [--recursive] [--] [...]
or: $dashless [--quiet] summary [--cached|--files] [--summary-limit ]
[commit] [--] [...]
or: $dashless [--quiet] foreach [--recursive]
@@ -516,6 +517,53 @@ cmd_init()
}
#
+# Unregister submodules from .git/config
+#
+# $@ = requested paths (default to all)
+#
+cmd_deinit()
+{
+ # parse $args after "submodule ... init".
+ while test $# -ne 0
+ do
+ case "$1" in
+ -q|--quiet)
+ GIT_QUIET=1
+ ;;
+ --)
+ shift
+ break
+
Re: [RFC] remove/deprecate 'submodule init' and 'sync'
On Sat, Dec 01, 2012 at 04:56:02PM +0100, Jens Lehmann wrote: > Am 01.12.2012 00:52, schrieb Phil Hord: > > If I never 'submodule init' a submodule, it does not get visited by > > 'git submodule foreach', among others. I think some people use this > > behavior explicitly. > > > > On the other hand, I've also notice that a submodule which I have > > removed does not get de-inited later one. It causes my 'git submodule > > foreach' to emit errors. :-( > > I'm currently hacking on "git submodule deinit" which removes the 'url' > setting from git/config. This should do the trick for you, right? > > Just removing that submodule automagically would not work that well, as > it would deinitialize a submodule when you switch to a branch where it > isn't present and you'd have to reinitialize it when you come back. I think this is another case where we should be looping through submodules based on the revision-specific .gitmodules content, and querying the local config only to determine if the user wants to update them (to drop into them with foreach, etc.). -- This email may be signed or encrypted with GnuPG (http://www.gnupg.org). For more information, see http://en.wikipedia.org/wiki/Pretty_Good_Privacy signature.asc Description: OpenPGP digital signature
Re: [RFC] remove/deprecate 'submodule init' and 'sync'
On Sat, Dec 01, 2012 at 04:38:02PM +0100, Jens Lehmann wrote: > Am 30.11.2012 18:53, schrieb W. Trevor King: > > In my v5 patch, I check for submodule..remote first in the usual > > `git config` files. If I don't find what I'm looking for I fall back > > on .gitmodules (basically Jens' suggestion). However, my initial > > copying-to-.git/config approach was mostly done to mimic existing > > configuration handling in git-submodule.sh. Since I agree with Jens > > on configuration precendence, and I now had two options to read > > (.branch and .remote), I thought I'd pull the logic out into its own > > function (code included at the end). While I was shifting the > > existing submodule config handling over to my new function, I noticed > > that with this logic, `submodule init` doesn't really do anything > > important anymore. Likewise for `submodule sync`, which seems to be > > quite similar to `init`. > > You need to handle the 'url' setting differently. While I think the > 'update' setting should not be copied into .git/config at all > (because it makes it impossible for upstream to change that later > without the user copying that himself as 'sync' doesn't do that) the > 'url' setting in .git/config has two important implications: > > 1) It tells the submodule commands that the user wants to have that >submodule populated (which is done in a subsequent "update" after >"init" copied the url there). Good point, but this should depend on submodule..update; having it as a side effect of a local submodule..url makes no sense. Perhaps `submodule init` should be reduced to just wrap: $ git config submodule..update checkout where the default update configuration would be 'none'. > 2) It can be used to follow moving upstreams (think of checking out >an earlier commit before the upstream was moved, you won't be able >to clone it from there without having the new setting persist). >And which repository you follow is a matter of trust, so the extra >"git submodule sync" in that case is a good thing to have. > > So I believe 'url' is the only setting that should be copied into > .git/config while all the others shouldn't. If you want to override the old repository location for an old commit, setting submodule..url makes sense. My rewritten `sync` updates the local submodule..url in the superproject if the configuration option is already set [1]. Perhaps a `sync --local` invocation should forcibly populate the local submodule..url to make this workflow easier. Bundling sugar for this special case should not happen under an extra command called `init`. > > [snip get_submodule_config()] > > Something like that makes sense. You can use it for the settings you add > first and we can then reuse that for 'update' in a separate patch later. I'm currently working out the details independently against v1.8.0. This will be a fairly major shift, so I think it should stay independent of `update --remote`. The `update --remote` stuff should be easy to adjust/rebase if the `init` removal/adjustment develops into something acceptable. Cheers, Trevor -- This email may be signed or encrypted with GnuPG (http://www.gnupg.org). For more information, see http://en.wikipedia.org/wiki/Pretty_Good_Privacy signature.asc Description: OpenPGP digital signature
Inconsistency in messages about --set-upstream from git pull and git branch
I added a new origin to a repository and did git pull and got this message: * [new branch] master -> origin/master There is no tracking information for the current branch. Please specify which branch you want to merge with. See git-pull(1) for details git pull If you wish to set tracking information for this branch you can do so with: git branch --set-upstream master origin/ I followed the instructions: $ git branch --set-upstream master origin/master The --set-upstream flag is deprecated and will be removed. Consider using --track or --set-upstream-to Branch master set up to track remote branch master from origin. I was using git version 1.8.0 precompiled for Arch Linux. I tried to find an issue tracker but perhaps it is appropriate to report this inconsistency to this mailing list. Best, Dan -- 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] remove/deprecate 'submodule init' and 'sync'
Am 01.12.2012 00:52, schrieb Phil Hord: > If I never 'submodule init' a submodule, it does not get visited by > 'git submodule foreach', among others. I think some people use this > behavior explicitly. > > On the other hand, I've also notice that a submodule which I have > removed does not get de-inited later one. It causes my 'git submodule > foreach' to emit errors. :-( I'm currently hacking on "git submodule deinit" which removes the 'url' setting from git/config. This should do the trick for you, right? Just removing that submodule automagically would not work that well, as it would deinitialize a submodule when you switch to a branch where it isn't present and you'd have to reinitialize it when you come back. -- 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/5] ignore SIG{INT,QUIT} when launching editor
jeff wrote: > This is a re-roll of the pf/editor-ignore-sigint series. > > There are two changes from the original: > > 1. We ignore both SIGINT and SIGQUIT for "least surprise" compared to > system(3). > > 2. We now use "code + 128" to look for signal death (instead of > WTERMSIG), as per run-command's documentation on how it munges the > code. this series all looks good to me. thanks for re- and re-re-rolling. paul > > People mentioned some buggy editors which go into an infinite EIO loop > when their parent dies due to SIGQUIT. That should be a non-issue now, > as we will be ignoring SIGQUIT. And even if you could replicate it > (e.g., with another signal) those programs should be (and reportedly > have been) fixed. It is not git's job to babysit its child processes. > > The patches are: > > [1/5]: run-command: drop silent_exec_failure arg from wait_or_whine > [2/5]: launch_editor: refactor to use start/finish_command > [3/5]: launch_editor: ignore terminal signals while editor has control > [4/5]: run-command: do not warn about child death from terminal > [5/5]: launch_editor: propagate signals from editor to git > > Since this can be thought of as "act more like system(3)", I wondered > whether the signal-ignore logic should be moved into run-command, or > even used by default for blocking calls to run_command (which are > basically our version of system(3)). But it is detrimental in the common > case that the child is not taking control of the terminal, and is just > an implementation detail (e.g., we call "git update-ref" behind the > scenes, but the user does not know or care). If they hit ^C during such > a run and we are ignoring SIGINT, then either: > > 1. we will notice the child died by signal and report an > error in the subprocess rather than just dying; the end result is > similar, but the error is unnecessarily confusing > > 2. we do not bother to check the child's return code (because we do > not care whether the child succeeded or not, like a "gc --auto"); > we end up totally ignoring the user's request to abort the > operation > > So I do not think we care about this behavior except for launching the > editor. And the signal-propagation behavior of 5/5 is really so weirdly > editor-specific (because it is about behaving well whether the child > blocks signals or not). > > -Peff =- paul fox, p...@foxharp.boston.ma.us (arlington, ma, where it's 24.8 degrees) -- 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] remove/deprecate 'submodule init' and 'sync'
Am 01.12.2012 13:48, schrieb W. Trevor King: > On Fri, Nov 30, 2012 at 06:52:22PM -0500, Phil Hord wrote: >> If I never 'submodule init' a submodule, it does not get visited by 'git >> submodule foreach', among others. I think some people use this behavior >> explicitly. > > This is something I'll fix while working up a trial patch. Currently > cmd_update calls module_clone if the /.git does not exist. This > should probably happen in each command (in a wrapper around module_list?). > It's possible that module_list itself would need some work, but I haven't > absorbed its implementation yet [1]. Please do not fix it, this is a feature. "update" is the only command where that should happen (and only if "url" is set in .git/config, as I explained in my other mail). So everything should be fine here. -- 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] remove/deprecate 'submodule init' and 'sync'
Am 30.11.2012 18:53, schrieb W. Trevor King:
> In my v5 patch, I check for submodule..remote first in the usual
> `git config` files. If I don't find what I'm looking for I fall back
> on .gitmodules (basically Jens' suggestion). However, my initial
> copying-to-.git/config approach was mostly done to mimic existing
> configuration handling in git-submodule.sh. Since I agree with Jens
> on configuration precendence, and I now had two options to read
> (.branch and .remote), I thought I'd pull the logic out into its own
> function (code included at the end). While I was shifting the
> existing submodule config handling over to my new function, I noticed
> that with this logic, `submodule init` doesn't really do anything
> important anymore. Likewise for `submodule sync`, which seems to be
> quite similar to `init`.
You need to handle the 'url' setting differently. While I think the
'update' setting should not be copied into .git/config at all
(because it makes it impossible for upstream to change that later
without the user copying that himself as 'sync' doesn't do that) the
'url' setting in .git/config has two important implications:
1) It tells the submodule commands that the user wants to have that
submodule populated (which is done in a subsequent "update" after
"init" copied the url there).
2) It can be used to follow moving upstreams (think of checking out
an earlier commit before the upstream was moved, you won't be able
to clone it from there without having the new setting persist).
And which repository you follow is a matter of trust, so the extra
"git submodule sync" in that case is a good thing to have.
So I believe 'url' is the only setting that should be copied into
.git/config while all the others shouldn't.
> What to do about this? `init` has been around for a while, so we
> can't just remove it (maybe in 2.0?). Leaving it in place is not
> really a problem though, it just means that the user is locking in the
> current .gitmodules configuration (as Jens pointed out with respect to
> .branch).
We still need those commands to set and update the "url" setting.
> ---
> #
> # Print a submodule configuration setting
> #
> # $1 = submodule name
> # $2 = option name
> # $3 = default value
> #
> # Checks in the usual git-config places first (for overrides),
> # otherwise it falls back on .gitmodules. This allows you to
> # distribute project-wide defaults in .gitmodules, while still
> # customizing individual repositories if necessary. If the option is
> # not in .gitmodules either, print a default value.
> #
> get_submodule_config()
> {
> name="$1"
> option="$2"
> default="$3"
> value=$(git config submodule."$name"."$option")
> if test -z "$value"
> then
> value=$(git config -f .gitmodules submodule."$name"."$option")
> fi
> printf '%s' "${value:-$default}"
> }
Something like that makes sense. You can use it for the settings you add
first and we can then reuse that for 'update' in a separate patch later.
--
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
Also close config file handle when leaving git_config_set_multivar_in_file() early
Hi, This patch fixes the captioned problem. It is needed because our program statically link git. In this case, do not assume a fail will call die() and exit program so the handle is leave not closed. Regards, ch3cooli 0001-Also-close-config-file-handle-when-leaving-git_confi.patch Description: Binary data
Re: [RFC] remove/deprecate 'submodule init' and 'sync'
On Fri, Nov 30, 2012 at 06:52:22PM -0500, Phil Hord wrote: > If I never 'submodule init' a submodule, it does not get visited by > 'git submodule foreach', among others. I think some people use this > behavior explicitly. This is something I'll fix while working up a trial patch. Currently cmd_update calls module_clone if the /.git does not exist. This should probably happen in each command (in a wrapper around module_list?). It's possible that module_list itself would need some work, but I haven't absorbed its implementation yet [1]. Trevor [1]: I read Perl by sounding out each letter ;). -- This email may be signed or encrypted with GnuPG (http://www.gnupg.org). For more information, see http://en.wikipedia.org/wiki/Pretty_Good_Privacy signature.asc Description: OpenPGP digital signature
Re: [msysGit] [PATCH/RFC 2/5] compat/terminal: factor out echo-disabling
On Fri, Nov 30, 2012 at 6:59 PM, Johannes Schindelin wrote: > Hi, > > On Tue, 13 Nov 2012, Erik Faye-Lund wrote: > >> By moving the echo-disabling code to a separate function, we can >> implement OS-specific versions of it for non-POSIX platforms. >> >> Signed-off-by: Erik Faye-Lund >> --- >> compat/terminal.c | 43 +-- >> 1 file changed, 25 insertions(+), 18 deletions(-) >> >> diff --git a/compat/terminal.c b/compat/terminal.c >> index bbb038d..3217838 100644 >> --- a/compat/terminal.c >> +++ b/compat/terminal.c >> @@ -14,6 +14,7 @@ static void restore_term(void) >> return; >> >> tcsetattr(term_fd, TCSAFLUSH, &old_term); >> + close(term_fd); >> term_fd = -1; >> } > > That looks like an independent resource leak fix... correct? It might look like it, but it's not; term_fd used to be returned by "fileno(fh)", and fh did get properly closed. With my refactoring, disable_echo/restore_term takes opens /dev/tty a second time, like Jeff points out. And that second file descriptor needs to be closed. -- 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: [msysGit] [PATCH/RFC 1/5] mingw: make fgetc raise SIGINT if apropriate
On Fri, Nov 30, 2012 at 6:58 PM, Johannes Schindelin wrote: > Hi, > > On Tue, 13 Nov 2012, Erik Faye-Lund wrote: > >> Set a control-handler to prevent the process from terminating, and >> simulate SIGINT so it can be handled by a signal-handler as usual. > > One thing you might want to mention is that the fgetc() handling is not > thread-safe, and intentionally so: if two threads read from the same > console, we are in trouble anyway. I'm not entirely sure if I know what you mean. Do you suggest that two threads can race for setting the console ctrl-handler? I don't think that's the case; "SetConsoleCtrlHandler(x, TRUE)" adds a console handler to the handler-chain, and SetConsoleCtrlHandler(x, FALSE) removes it. If two threads add handlers, it is my understanding that one of them will be run, only to report "no, no more ctrl-handling needed". Since both handlers block further ctrl-handling, I don't think there's a problem. Do you care to clarify what your thread-safety complaint is? > BTW I like the new mingw_raise() very much! Thanks! I originally implemented it for a different reason, but that patch didn't turn out to be useful, so it's nice to finally put it to use ;) -- 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/5] ignore SIG{INT,QUIT} when launching editor
On Fri, Nov 30, 2012 at 05:39:43PM -0500, Jeff King wrote: > This is a re-roll of the pf/editor-ignore-sigint series. > > People mentioned some buggy editors which go into an infinite EIO loop > when their parent dies due to SIGQUIT. That should be a non-issue now, > as we will be ignoring SIGQUIT. And even if you could replicate it > (e.g., with another signal) those programs should be (and reportedly > have been) fixed. It is not git's job to babysit its child processes. > Also some good editors printed error message after they got EIO, confusing the user. Looks good to me. I've tested this with ed (always ignores SIGINT and SIGQUIT), vim (always ignores SIGINT, but dies after three SIGQUIT) and "sleep" (dies after SIGINT and SIGQUIT) and git works now as expected. Doing what editor does is probably the best thing to do. Tested-by: Krzysztof Mazur Thanks, Krzysiek -- 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: [msysGit] [PATCH/RFC 1/5] mingw: make fgetc raise SIGINT if apropriate
On Fri, Nov 30, 2012 at 7:11 PM, Jeff King wrote: > On Fri, Nov 30, 2012 at 06:58:11PM +0100, Johannes Schindelin wrote: > >> Hi, >> >> On Tue, 13 Nov 2012, Erik Faye-Lund wrote: >> >> > Set a control-handler to prevent the process from terminating, and >> > simulate SIGINT so it can be handled by a signal-handler as usual. >> >> One thing you might want to mention is that the fgetc() handling is not >> thread-safe, and intentionally so: if two threads read from the same >> console, we are in trouble anyway. > > That makes sense to me, but I'm confused why it is part of mingw_fgetc, > which could in theory read from arbitrary streams, no? It it is not > necessarily a console operation at all. I feel like I'm probably missing > something subtle here... I did add an early out for the non-console cases. Is this what you're missing, perhaps? -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Bug report : gitattribute export-ignore behavior does not match documentation
Tested on latest maint and master. The 'export-ignore' gitattribute is documented as behaving on a pattern, just like in .gitignore. In repo where I have a tree like this: .gitattributes figures/ fr/figures/ I want to remove from archive all the figures directories. So I added figures/ export-ignore to the top level .gitattributes file. but then: $ git check-attr -a fr/figures $ git check-attr -a figures $ If I change the line in .gitattributes to : figures export-ignore I get the correct result, but I am not sure to exclude only directories. Am I wrong somewhere? Thank you. Jean-Noël AVILA -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 4/4] git-svn: Note about tags.
Document that 'git svn' will import SVN tags as branches. Signed-off-by: Sebastian Leske --- Documentation/git-svn.txt |7 +++ 1 file changed, 7 insertions(+) diff --git a/Documentation/git-svn.txt b/Documentation/git-svn.txt index 6bda014..18d5e45 100644 --- a/Documentation/git-svn.txt +++ b/Documentation/git-svn.txt @@ -959,6 +959,13 @@ the possible corner cases (git doesn't do it, either). Committing renamed and copied files is fully supported if they're similar enough for git to detect them. +SVN tags (if tracked using options '--tags' or '--stdlayout') are +imported as git branches, prefixing the tag name with 'tags/'. +This is because tags in SVN behave more like git branches: The contents +of a tag need not be identical to the tagged commit, and it is possible +(though discouraged) to commit changes to a tag (because a tag is just a +directory copy, thus technically the same as a branch). + CONFIGURATION - -- 1.7.10.4 -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 3/4] git-svn: Expand documentation for --follow-parent
Describe what the option --follow-parent does, and what happens if it is set or unset. Signed-off-by: Sebastian Leske --- Documentation/git-svn.txt | 15 --- 1 file changed, 12 insertions(+), 3 deletions(-) diff --git a/Documentation/git-svn.txt b/Documentation/git-svn.txt index bfa8788..6bda014 100644 --- a/Documentation/git-svn.txt +++ b/Documentation/git-svn.txt @@ -628,10 +628,19 @@ ADVANCED OPTIONS Default: "svn" --follow-parent:: + This option is only relevant if we are tracking branches (using + one of the repository layout options --trunk, --tags, + --branches, --stdlayout). For each tracked branch, try to find + out where its revision was copied (i.e. branched) from, and set + a suitable parent in the first git commit for the branch. This is especially helpful when we're tracking a directory - that has been moved around within the repository, or if we - started tracking a branch and never tracked the trunk it was - descended from. This feature is enabled by default, use + that has been moved around within the repository. If this + feature is disabled, the branches created by 'git svn' will all + be linear and not share any history, meaning that there will be + no information on where branches where branched off or merged. + However, following long/convoluted histories can take a long + time, so disabling this feature may speed up the cloning + process. This feature is enabled by default, use --no-follow-parent to disable it. + [verse] -- 1.7.10.4 -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 2/4] Recommend use of structure options for git svn.
Document that when using git svn, one should usually either use the directory structure options to import branches as branches, or only import one subdirectory. The default behaviour of cloning all branches and tags as subdirectories in the working copy is usually not what the user wants. Signed-off-by: Sebastian Leske --- Documentation/git-svn.txt | 24 +--- 1 file changed, 21 insertions(+), 3 deletions(-) diff --git a/Documentation/git-svn.txt b/Documentation/git-svn.txt index 824bf82..bfa8788 100644 --- a/Documentation/git-svn.txt +++ b/Documentation/git-svn.txt @@ -739,7 +739,8 @@ for rewriteRoot and rewriteUUID which can be used together. BASIC EXAMPLES -- -Tracking and contributing to the trunk of a Subversion-managed project: +Tracking and contributing to the trunk of a Subversion-managed project +(ignoring tags and branches): # Clone a repo (like git clone): @@ -764,8 +765,10 @@ Tracking and contributing to an entire Subversion-managed project (complete with a trunk, tags and branches): -# Clone a repo (like git clone): - git svn clone http://svn.example.com/project -T trunk -b branches -t tags +# Clone a repo with standard SVN directory layout (like git clone): + git svn clone http://svn.example.com/project --stdlayout +# Or, if the repo uses a non-standard directory layout: + git svn clone http://svn.example.com/project -T tr -b branch -t tag # View all branches and tags you have cloned: git branch -r # Create a new branch in SVN @@ -871,6 +874,21 @@ already dcommitted. It is considered bad practice to --amend commits you've already pushed to a remote repository for other users, and dcommit with SVN is analogous to that. +When cloning an SVN repository, if none of the options for describing +the repository layout is used (--trunk, --tags, --branches, +--stdlayout), 'git svn clone' will create a git repository with +completely linear history, where branches and tags appear as separate +folders in the working copy. While this is the easiest way to get a +copy of a complete repository, for projects with many branches it will +lead to a working copy many times larger than just the trunk. Thus for +projects using the standard directory structure (trunk/branches/tags), +it is recommended to clone with option '--stdlayout'. If the project +uses a non-standard structure, and/or if branches and tags are not +required, it is easiest to only clone one directory (typically trunk), +without giving any repository layout options. If the full history with +branches and tags is required, the options '--trunk' / '--branches' / +'--tags' must be used. + When using multiple --branches or --tags, 'git svn' does not automatically handle name collisions (for example, if two branches from different paths have the same name, or if a branch and a tag have the same name). In these cases, -- 1.7.10.4 -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 1/4] git-svn: Document branches with at-sign(@).
git svn will sometimes create branches with an at-sign in the name (branchname@revision). These branches confuse many users and it is a FAQ why they are created. Document when git svn will create them. Signed-off-by: Sebastian Leske --- Documentation/git-svn.txt | 38 ++ 1 file changed, 38 insertions(+) diff --git a/Documentation/git-svn.txt b/Documentation/git-svn.txt index 8b0d3ad..824bf82 100644 --- a/Documentation/git-svn.txt +++ b/Documentation/git-svn.txt @@ -881,6 +881,44 @@ different name spaces. For example: branches = stable/*:refs/remotes/svn/stable/* branches = debug/*:refs/remotes/svn/debug/* +If 'git svn' is configured to fetch branches (and --follow-branches +is in effect), it will sometimes create multiple branches for one SVN +branch, where the addtional branches have names of the form +'branchname@nnn' (with nnn an SVN revision number). These additional +branches are created if 'git svn' cannot find a parent commit for the +first commit in an SVN branch, to connect the branch to the history of +the other branches. Normally, the first commit in an SVN branch consists +of a copy operation. 'git svn' will read this commit to get the SVN +revision the branch was created (copied) from. It will then try to find the +git commit that corresponds to this SVN revision, and use that as the +parent of the branch. However, it is possible that there is no suitable +git commit to serve as parent. This will happen, among other reasons, +if the SVN branch is a copy of a revision that was not fetched by 'git +svn' (e.g. because it is an old revision that was skipped with +'--revision'), or if in SVN a directory was copied that is not tracked +by 'git svn' (such as a branch that is not tracked at all, or a +subdirectory of a tracked branch). In these cases, 'git svn' will still +create a git branch, but instead of using an existing git commit as the +parent of the branch, it will read the SVN history of the directory the +branch was copied from and create appropriate git commits (this is +indicated by the message "Initializing parent: "). +Additionally, it will create a special branch named +'@', where is the SVN revision +number the branch was copied from. This branch will point to the newly +created parent commit of the branch. If in SVN the branch was deleted +and later recreated from a different version, there will be multiple +such branches with an '@'. +Note that this may mean that multiple git commits are created for a +single SVN revision. An example: In an SVN repository with a standard +trunk/tags/branches layout, a directory trunk/sub is created in r.100. +In r.200, trunk/sub is branched by copying it to branches/. 'git svn +clone -s' will then create a branch 'sub'. It will also create new git +commits for r.100 through r.199 and use these as the history of branch +'sub'. Thus there will be two git commits for each revision from r.100 +to r.199 (one containing trunk/, one containing trunk/sub/). Finally, +it will create a branch 'sub@200' pointing to the new parent commit of +branch 'sub' (i.e. the commit for r.200 and trunk/sub/). + BUGS -- 1.7.10.4 -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 0/4] git-svn: More docs for branch handling in
Updated version of my documentation patch for git-svn. Thanks to Michael J Gruber and Eric Wong for helpful comments. Sebastian Leske (4): git-svn: Document branches with at-sign(@). Recommend use of structure options for git svn. git-svn: Expand documentation for --follow-parent git-svn: Note about tags. Documentation/git-svn.txt | 84 + 1 file changed, 78 insertions(+), 6 deletions(-) -- 1.7.10.4 -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/5] "diff --stat" counting fixes
Hi Junio, That does make a lot of sense and I would have indeed missed a couple of things here. I've been thinking about that "Unmerged" line quite a lot, and I can't get myself any good reason to keep it. Would you mind taking a couple of minutes to make it clear ? I feel like (but I can obviously be wrong): 1. The info is redundant. When performing a merge, all diffs (without --staged flag) are unmerged 2. While status shows the line once, while diff shows the diff for the file once, while diff --shortstat counts the file once, diff --stat shows two lines for the file. 3. diff --numstat shows two lines for the same file. As a script writer (I guess that's what it's meant for), I would definitely expect uniqueness in third column/filenames. Cheers, Antoine On Tue, Nov 27, 2012 at 10:21 PM, Junio C Hamano wrote: > > It turns out that there are at least two bugs in the diffstat > counting code. This series comes on top of the earlier 74faaa1 (Fix > "git diff --stat" for interesting - but empty - file changes, > 2012-10-17) to fix them. > > Junio C Hamano (5): > test: add failing tests for "diff --stat" to t4049 > diff --stat: status of unmodified pair in diff-q is not zero > diff --stat: use "file" temporary variable to refer to data->files[i] > diff --stat: move the "total count" logic to the last loop > diff --stat: do not count "unmerged" entries > > diff.c | 49 > +- > t/t4049-diff-stat-count.sh | 46 ++- > 2 files changed, 72 insertions(+), 23 deletions(-) > > -- > 1.8.0.1.331.g808d2af > -- 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] fast-export: Allow pruned-references in mark file
> Yeah, I think I agree that you would need to make sure that the > other side does not use the revision marked with :2, once you retire > the object you originally marked with :2 by pruning. Shouldn't the > second export show :1 and :3 but not :2? It feels like a bug in the > exporter to me that the mark number is reused in such a case. It depends what you call a bug. If the last item from the list is pruned, and no new objects are exported, you will lose both reference and count to mark :2. In this situation, incrementing last_idnum was pointless. Assuming that we can't do anything about that, marks should be considered mutable (and I don't think there is any way it shouldn't). Then incrementing last_idnum is always useless. Now, if marks can change, I don't understand why we use them at all. (or don't provide the possibility to not use them at least). In the "hg <-> git" case, it seems like an unecessary step: hg revs <-> git marks <-> git sha1 Potentially forces the remote-helper to re-read the "marks <-> sha1" everytime. Also in the remote-helper, the "list" command requires sha1 for each heads, while "import/export" can't work with sha1 but only marks, which seems inconsistent. My last point is about "git-remote-hg" and still mutable revs. It seems like Felipe is using revs() rather than node() or hex() to refer to mercurial changeset while those revs are also mutable, and there exists immutable references: hex. To sum up, the whole idea is, why would we use unsafe mutable marks when we can use safer immutable references ? Cheers, Antoine -- 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 1/2] reset: learn to reset to tree
Martin von Zweigbergk writes: > On Thu, Nov 29, 2012 at 2:00 PM, Martin von Zweigbergk > wrote: >> Slightly off topic, but another difference (or somehow another aspect >> of the same difference?) that has tripped me up a few times is that >> "git checkout $rev ." only affects added and modified files... "checkout $commit pathspec" has always been about checking out the contents stored in the paths that match the pathspec from the named commit to the index and also o the working tree. "checkout pathspec" is similar, but the stuff comes out of the index. When pathspec is "dir/", it does not match the directory whose name is "dir". The pathspec matches the paths that store blobs under that directory. In other words, "checkout dir/" (or "checkout HEAD~4 dir/) has never been about "please remove everything in dir/, and then check out everything in dir/ from the index (or from HEAD~4)". The "please remove everything in dir/" part is not the job of "checkout"; of course, you can do it as a separate step (e.g. "rm -fr dir/"). -- 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
