Limiting disk usage
Hi, What can be done to limit amount of space occupied on clone and checkout? I know about shallow clone and sparse checkout, anything else? Preferably I would split repository into multiple repositories but I worry that working with multiple directories would be much more troublesome. But maybe I am wrong? I don't have much experience with submodules, repo tool (what else?) Thanks -- Piotr Krukowiecki -- 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] commit: Add -f, --fixes commit option to add Fixes: line
On Mon, Oct 28, 2013 at 3:46 AM, Johan Herland jo...@herland.net wrote: On Sun, Oct 27, 2013 at 8:04 PM, Christian Couder christian.cou...@gmail.com wrote: If git commit processes these arguments and puts the result in the commit message file that is passed to the prepare-commit-msg hook, then this hook can still get them from the file and process them however it wants. And in most cases the processing could be the same as what is done by the commit-msg hook when the user changes the Fixes: xxx and Stuffed-by: yyy lines in the editor. So it would probably be easier for people customizing the prepare-commit-msg and commit-msg if git commit processes the arguments instead of just passing them to the prepare-commit-msg hook. And it will be better for people who don't set up any *commit-msg hook. Even if there is no commit template, -f Acked-by:Peff and -f Fixes:security-bug could still work. I suspect most users don't setup any hook or commit template. Hmm. I'm not sure what you argue about which part of the system should perform which function. Let's examine the above options in more detail. Roughly, the flow of events look like this git commit -f ack:Peff -f fix:security-bug | v builtin/commit.c (i.e. inside git commit) | v prepare-commit-msg hook | v commit message template: Fixes: security-bug Acked-by: Peff Here it could already be: Fixes: 1234beef56 (Commit message summmary) Acked-by: Jeff King p...@peff.net Because builtin/commit.c hook could already have expanded everything. | v user edits commit message (may or may not change Fixes/Acked-by lines) | v commit-msg hook | v commit message: Fixes: 1234beef56 (Commit message summmary) Acked-by: Jeff King p...@peff.net (The above is even a bit simplified, but I believe it's sufficient for the current discussion.) So, there are several expansions happening between the initial git commit and the final commit message. They are: 1. fix - Fixes: 2. security-bug - 1234beef56 (Commit message summmary) 3. ack - Acked-by: 4. Peff - Jeff King p...@peff.net First, I think we both agree that expansions #2 and #4 MUST be done by the commit-msg hook. The reason for this is two-fold: (a) the expansion must be done (at least) after the user has edited the commit message (since the values entered by the user might require the same expansion), and (b) how (and whether) to perform the expansion is a project-specific policy question, and not something that Git can dictate. I don't agree. Git doesn't need to dictate anything to be able to do these expansions. Git only needs some hints to do these expansions properly and it could just look at the commit template, or the config, to get those hints. For example, if there is a Acked-by: line in the commit template, then Git might decide that ack means Acked-by, and then that -by means that Peff should be related to an author, and then that it is probably Jeff King p...@peff.net. Obviously, common functionality can be made available in the default hook shipped by Git, but it's up to each project to enable and/or customize this. Second, there is #1 and #3, the expansion of ack - Acked-by: and fix - Fixes:. Is this expansion performed by the prepare-commit-msg hook, or directly inside builtin/commit.c? If you are arguing for the latter (and I'm not sure that you are), we would need to add a dictionary to git commit that maps shorthand field names (ack) to the RFC822 -style equivalent (Acked-by: ). Yes, I am arguing that builtin/commit.c, or better a plumbing command launched by builtin/commit.c, should do it. And I don't think there is an absolute need for a dictionary. There could be such a dictionary in the config (as Junio proposed). But if there isn't, the plumbing command launched by builtin/commit.c could look at the commit template to decide that ack means Acked-by:. I would instead argue for the former, i.e. simply forwarding ack and fix as-is to the prepare-commit-msg hook, and let it deal with the appropriate expansion. The main reason for this is that if a project wants to add another shorthand expansion (e.g. bug - Related-Bugzilla-Id: ), they can do so without hacking builtin/commit.c. I agree that there should be no need to hack builtin/commit.c. For example if Bugzilla-Id: is in the commit template, the plumbing command launched by builtin/commit.c would decide that bug means Bugzilla-Id: without any hack. Of course this suppose that there is no other Bugtracker: or Bug: in the commit template. But even in this case it would mean that users have to use -f bugz:XXX (or --trailer bugz=XXX) instead of just -f bug:XXX. Supporting project specific conventions/rules would still be possible by processing lines in the commit message file without changing git commit. If git commit is already able to do some processing, it only adds
git svn already set … wanted to set to:
I am trying to clone/fetch svn branch with git-svn: git config --add svn-remote.stable-2012-03-29.url https://some_host/branch git config --add svn-remote.stable-2012-03-29.fetch :refs/remotes/stable-2012-03-29 git svn fetch stable-2012-03-29 which gives me this error message: svn-remote.stable-2012-03-29.url already set: https://some_host/branch/ wanted to set to: https://some_host/ I know that I probably can fix this by re-fetching all svn-repo from scratch, but it will take months or even years (due to size of repo). So, is there any solutions? -- 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 7/7] Documentation/gitk: document -L option
The -L option is the same as for git-log, so the entire block is just copied from git-log.txt. Signed-off-by: Thomas Rast t...@thomasrast.ch --- Documentation/gitk.txt | 12 1 file changed, 12 insertions(+) diff --git a/Documentation/gitk.txt b/Documentation/gitk.txt index d44e14c..0f1c7f8 100644 --- a/Documentation/gitk.txt +++ b/Documentation/gitk.txt @@ -98,6 +98,18 @@ linkgit:git-rev-list[1] for a complete list. (See History simplification in linkgit:git-log[1] for a more detailed explanation.) +-Lstart,end:file:: +-L:regex:file:: + + Trace the evolution of the line range given by start,end + (or the funcname regex regex) within the file. You may + not give any pathspec limiters. This is currently limited to + a walk starting from a single revision, i.e., you may only + give zero or one positive revision arguments. + You can specify this option more than once. ++ +include::line-range-format.txt[] + revision range:: Limit the revisions to show. This can be either a single revision -- 1.8.4.2.838.ga9a3e20 -- 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/7] gitk: split out diff part in $commitinfo
From: Thomas Rast tr...@inf.ethz.ch
So far we just parsed everything after the headers into the comment
bit of $commitinfo, including notes and -- if you gave weird options
-- the diff.
Split out the diff, if any, into a separate field. It's easy to
recognize, since it always starts with /^diff/ and is preceded by an
empty line.
We take care to snip away said empty line. The display code already
properly spaces the end of the message from the first diff, and
leaving another empty line at the end looks ugly.
Signed-off-by: Thomas Rast tr...@inf.ethz.ch
---
gitk-git/gitk | 11 ++-
1 file changed, 10 insertions(+), 1 deletion(-)
diff --git a/gitk-git/gitk b/gitk-git/gitk
index 11e988e..78b4354 100755
--- a/gitk-git/gitk
+++ b/gitk-git/gitk
@@ -1704,8 +1704,17 @@ proc parsecommit {id contents listed} {
set comment $newcomment
}
set hasnote [string first \nNotes:\n $contents]
+set diff
+# If there is diff output shown in the git-log stream, split it
+# out. But get rid of the empty line that always precedes the
+# diff.
+set i [string first \n\ndiff $comment]
+if {$i = 0} {
+ set diff [string range $comment $i+1 end]
+ set comment [string range $comment 0 $i-1]
+}
set commitinfo($id) [list $headline $auname $audate \
-$comname $comdate $comment $hasnote]
+$comname $comdate $comment $hasnote $diff]
}
proc getcommit {id} {
--
1.8.4.2.838.ga9a3e20
--
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/7] gitk: refactor per-line part of getblobdiffline and its support
From: Thomas Rast tr...@inf.ethz.ch
For later use with data sources other than a pipe, refactor the big
worker part of getblobdiffline to a separate function
parseblobdiffline. Also refactor its initialization and wrap-up to
separate routines.
Signed-off-by: Thomas Rast tr...@inf.ethz.ch
---
gitk-git/gitk | 408 ++
1 file changed, 213 insertions(+), 195 deletions(-)
diff --git a/gitk-git/gitk b/gitk-git/gitk
index 0e95814..11e988e 100755
--- a/gitk-git/gitk
+++ b/gitk-git/gitk
@@ -7710,15 +7710,25 @@ proc changeworddiff {name ix op} {
reselectline
}
+proc initblobdiffvars {} {
+global diffencoding targetline diffnparents
+global diffinhdr currdiffsubmod diffseehere
+set targetline {}
+set diffnparents 0
+set diffinhdr 0
+set diffencoding [get_path_encoding {}]
+set currdiffsubmod
+set diffseehere -1
+}
+
proc getblobdiffs {ids} {
global blobdifffd diffids env
-global diffinhdr treediffs
+global treediffs
global diffcontext
global ignorespace
global worddiff
global limitdiffs vfilelimit curview
-global diffencoding targetline diffnparents
-global git_version currdiffsubmod
+global git_version
set textconv {}
if {[package vcompare $git_version 1.6.1] = 0} {
@@ -7742,13 +7752,9 @@ proc getblobdiffs {ids} {
error_popup [mc Error getting diffs: %s $err]
return
}
-set targetline {}
-set diffnparents 0
-set diffinhdr 0
-set diffencoding [get_path_encoding {}]
fconfigure $bdf -blocking 0 -encoding binary -eofchar {}
set blobdifffd($ids) $bdf
-set currdiffsubmod
+initblobdiffvars
filerun $bdf [list getblobdiffline $bdf $diffids]
}
@@ -7814,13 +7820,17 @@ proc makediffhdr {fname ids} {
set diffline 0
}
+proc blobdiffmaybeseehere {ateof} {
+global diffseehere
+if {$diffseehere = 0} {
+ mark_ctext_line [lindex [split $diffseehere .] 0]
+}
+maybe_scroll_ctext ateof
+}
+
proc getblobdiffline {bdf ids} {
-global diffids blobdifffd ctext curdiffstart
-global diffnexthead diffnextnote difffilestart
-global ctext_file_names ctext_file_lines
-global diffinhdr treediffs mergemax diffnparents
-global diffencoding jump_to_here targetline diffline currdiffsubmod
-global worddiff
+global diffids blobdifffd
+global ctext
set nr 0
$ctext conf -state normal
@@ -7829,212 +7839,220 @@ proc getblobdiffline {bdf ids} {
catch {close $bdf}
return 0
}
- if {![string compare -length 5 diff $line]} {
- if {![regexp {^diff (--cc|--git) } $line m type]} {
- set line [encoding convertfrom $line]
- $ctext insert end $line\n hunksep
- continue
+ parseblobdiffline $ids $line
+}
+$ctext conf -state disabled
+blobdiffmaybeseehere [eof $bdf]
+if {[eof $bdf]} {
+ catch {close $bdf}
+ return 0
+}
+return [expr {$nr = 1000? 2: 1}]
+}
+
+proc parseblobdiffline {ids line} {
+global ctext curdiffstart
+global diffnexthead diffnextnote difffilestart
+global ctext_file_names ctext_file_lines
+global diffinhdr treediffs mergemax diffnparents
+global diffencoding jump_to_here targetline diffline currdiffsubmod
+global worddiff diffseehere
+
+if {![string compare -length 5 diff $line]} {
+ if {![regexp {^diff (--cc|--git) } $line m type]} {
+ set line [encoding convertfrom $line]
+ $ctext insert end $line\n hunksep
+ continue
+ }
+ # start of a new file
+ set diffinhdr 1
+ $ctext insert end \n
+ set curdiffstart [$ctext index end - 1c]
+ lappend ctext_file_names
+ lappend ctext_file_lines [lindex [split $curdiffstart .] 0]
+ $ctext insert end \n filesep
+
+ if {$type eq --cc} {
+ # start of a new file in a merge diff
+ set fname [string range $line 10 end]
+ if {[lsearch -exact $treediffs($ids) $fname] 0} {
+ lappend treediffs($ids) $fname
+ add_flist [list $fname]
}
- # start of a new file
- set diffinhdr 1
- $ctext insert end \n
- set curdiffstart [$ctext index end - 1c]
- lappend ctext_file_names
- lappend ctext_file_lines [lindex [split $curdiffstart .] 0]
- $ctext insert end \n filesep
-
- if {$type eq --cc} {
- # start of a new file in a merge diff
- set fname [string range $line 10 end]
- if {[lsearch -exact $treediffs($ids) $fname] 0} {
- lappend treediffs($ids) $fname
- add_flist [list $fname]
- }
+ } else {
+ set line [string range $line 11 end]
+ # If the name hasn't changed the length will be odd,
+ # the middle char will be a
[PATCH v2 6/7] Documentation: put blame/log -L in sticked form
The next patch will document gitk -L, but gitk does not understand the
separated form ('gitk -L :foo:bar' results in an error). Spell
git-blame and git-log -L, which are supposed to be the same option,
without the spaces to prevent confusion.
Signed-off-by: Thomas Rast t...@thomasrast.ch
---
Documentation/blame-options.txt | 8
Documentation/git-blame.txt | 8
Documentation/git-log.txt | 6 +++---
3 files changed, 11 insertions(+), 11 deletions(-)
diff --git a/Documentation/blame-options.txt b/Documentation/blame-options.txt
index 0cebc4f..28ca95e 100644
--- a/Documentation/blame-options.txt
+++ b/Documentation/blame-options.txt
@@ -9,13 +9,13 @@
--show-stats::
Include additional statistics at the end of blame output.
--L start,end::
--L :regex::
+-Lstart,end::
+-L:regex::
Annotate only the given line range. May be specified multiple times.
Overlapping ranges are allowed.
+
-start and end are optional. ``-L start'' or ``-L start,'' spans from
-start to end of file. ``-L ,end'' spans from start of file to end.
+start and end are optional. ``-Lstart'' or ``-Lstart,'' spans from
+start to end of file. ``-L,end'' spans from start of file to end.
+
include::line-range-format.txt[]
diff --git a/Documentation/git-blame.txt b/Documentation/git-blame.txt
index f2c85cc..085dba1 100644
--- a/Documentation/git-blame.txt
+++ b/Documentation/git-blame.txt
@@ -9,7 +9,7 @@ SYNOPSIS
[verse]
'git blame' [-c] [-b] [-l] [--root] [-t] [-f] [-n] [-s] [-e] [-p] [-w]
[--incremental]
- [-L range] [-S revs-file] [-M] [-C] [-C] [-C] [--since=date]
+ [-Lrange] [-S revs-file] [-M] [-C] [-C] [-C] [--since=date]
[--abbrev=n] [rev | --contents file | --reverse rev] [--]
file
DESCRIPTION
@@ -139,12 +139,12 @@ lines 40-60 for file `foo`, you can use the `-L` option
like so
(they mean the same thing -- both ask for 21 lines starting at
line 40):
- git blame -L 40,60 foo
- git blame -L 40,+21 foo
+ git blame -L40,60 foo
+ git blame -L40,+21 foo
Also you can use a regular expression to specify the line range:
- git blame -L '/^sub hello {/,/^}$/' foo
+ git blame -L'/^sub hello {/,/^}$/' foo
which limits the annotation to the body of the `hello` subroutine.
diff --git a/Documentation/git-log.txt b/Documentation/git-log.txt
index 34097ef..87c10fa 100644
--- a/Documentation/git-log.txt
+++ b/Documentation/git-log.txt
@@ -62,8 +62,8 @@ produced by --stat etc.
Note that only message is considered, if also a diff is shown
its size is not included.
--L start,end:file::
--L :regex:file::
+-Lstart,end:file::
+-L:regex:file::
Trace the evolution of the line range given by start,end
(or the funcname regex regex) within the file. You may
@@ -152,7 +152,7 @@ EXAMPLES
This makes sense only when following a strict policy of merging all
topic branches when staying on a single integration branch.
-`git log -L '/int main/',/^}/:main.c`::
+`git log -L'/int main/',/^}/:main.c`::
Shows how the function `main()` in the file 'main.c' evolved
over time.
--
1.8.4.2.838.ga9a3e20
--
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/7] gitk: support -G option from the command line
From: Thomas Rast tr...@inf.ethz.ch
The -G option's usage is exactly analogous to that of -S, so
supporting it is easy.
Signed-off-by: Thomas Rast tr...@inf.ethz.ch
---
gitk-git/gitk | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/gitk-git/gitk b/gitk-git/gitk
index 5cd00d8..0e95814 100755
--- a/gitk-git/gitk
+++ b/gitk-git/gitk
@@ -227,7 +227,7 @@ proc parseviewargs {n arglist} {
--until=* - --before=* - --max-age=* - --min-age=* -
--author=* - --committer=* - --grep=* - -[iE] -
--remove-empty - --first-parent - --cherry-pick -
- -S* - --pickaxe-all - --pickaxe-regex -
+ -S* - -G* - --pickaxe-all - --pickaxe-regex -
--simplify-by-decoration {
# These mean that we get a subset of the commits
set filtered 1
--
1.8.4.2.838.ga9a3e20
--
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/7] gitk: support showing the gathered inline diffs
From: Thomas Rast tr...@inf.ethz.ch
The previous commit split the diffs into a separate field. Now we
actually want to show them.
To that end we use the stored diff, and
- process it once to build a fake tree diff, i.e., a list of all
changed files;
- feed it through parseblobdiffline to actually format it into the
$ctext field, like the existing diff machinery would.
Signed-off-by: Thomas Rast tr...@inf.ethz.ch
---
gitk-git/gitk | 38 ++
1 file changed, 38 insertions(+)
diff --git a/gitk-git/gitk b/gitk-git/gitk
index 78b4354..5ece2a1 100755
--- a/gitk-git/gitk
+++ b/gitk-git/gitk
@@ -156,10 +156,12 @@ proc unmerged_files {files} {
proc parseviewargs {n arglist} {
global vdatemode vmergeonly vflags vdflags vrevs vfiltered vorigargs env
+global vinlinediff
global worddiff git_version
set vdatemode($n) 0
set vmergeonly($n) 0
+set vinlinediff($n) 0
set glflags {}
set diffargs {}
set nextisval 0
@@ -7089,6 +7091,7 @@ proc selectline {l isnew {desired_loc {}}} {
global cmitmode showneartags allcommits
global targetrow targetid lastscrollrows
global autoselect autosellen jump_to_here
+global vinlinediff
catch {unset pending_select}
$canv delete hover
@@ -7230,6 +7233,8 @@ proc selectline {l isnew {desired_loc {}}} {
init_flist [mc Comments]
if {$cmitmode eq tree} {
gettree $id
+} elseif {$vinlinediff($curview) == 1} {
+ showinlinediff $id
} elseif {[llength $olds] = 1} {
startdiff $id
} else {
@@ -7566,6 +7571,39 @@ proc startdiff {ids} {
}
}
+proc showinlinediff {ids} {
+global commitinfo commitdata ctext
+global treediffs
+
+set info $commitinfo($ids)
+set diff [lindex $info 7]
+set difflines [split $diff \n]
+
+initblobdiffvars
+set treediff {}
+
+set inhdr 0
+foreach line $difflines {
+ if {![string compare -length 5 diff $line]} {
+ set inhdr 1
+ } elseif {$inhdr ![string compare -length 4 +++ $line]} {
+ # offset also accounts for the b/ prefix
+ lappend treediff [string range $line 6 end]
+ set inhdr 0
+ }
+}
+
+set treediffs($ids) $treediff
+add_flist $treediff
+
+$ctext conf -state normal
+foreach line $difflines {
+ parseblobdiffline $ids $line
+}
+maybe_scroll_ctext 1
+$ctext conf -state disabled
+}
+
# If the filename (name) is under any of the passed filter paths
# then return true to include the file in the listing.
proc path_filter {filter name} {
--
1.8.4.2.838.ga9a3e20
--
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 5/7] gitk: recognize -L option
From: Thomas Rast tr...@inf.ethz.ch
This gives line-log support to gitk, by exploiting the new support for
processing and showing inline diffs straight from the git-log
output.
Note that we 'set allknown 0', which is a bit counterintuitive since
this is a known option. But that flag prevents gitk from thinking
it can optimize the view by running rev-list to see the topology; in
the -L case that doesn't work.
Signed-off-by: Thomas Rast tr...@inf.ethz.ch
---
gitk-git/gitk | 8
1 file changed, 8 insertions(+)
diff --git a/gitk-git/gitk b/gitk-git/gitk
index 5ece2a1..3679467 100755
--- a/gitk-git/gitk
+++ b/gitk-git/gitk
@@ -235,6 +235,14 @@ proc parseviewargs {n arglist} {
set filtered 1
lappend glflags $arg
}
+ -L* {
+ # Line-log with 'sticked' argument (unsticked form is
+ # not supported)
+ set filtered 1
+ set vinlinediff($n) 1
+ set allknown 0
+ lappend glflags $arg
+ }
-n {
# This appears to be the only one that has a value as a
# separate word following it
--
1.8.4.2.838.ga9a3e20
--
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/7] gitk -L
Thomas Rast wrote: Jonathan Nieder wrote: Support for just the sticked form is better than nothing, especially if the gitk(1) manpage gains a note about it. In the long run I guess the ideal would be to add a parse-options-like library to the tcl support. Ok. I'm generally not happy with the state of that manpage, so I took the chance to improve it. [...] I'll hold the gitk patches until we get this one sorted out, but then just do the sticked form as before. Ok, there weren't any comments and this patch is in 'next', so here's gitk -L built on top of it. I'm sending this as a single topic, but once agreement is reached, it has to be applied in two parts: the gitk patches (1-5) need to be subtree-rebased to match gitk.git, and then merged separately, while the documentation patches (67) need to be applied directly. The latter depend on the patch I'm replying to. Changes since v1: * 1/7 is new; while investigating the sticked/unsticked issue, I noticed that -G is not even supported by gitk. * 3/7 has improved snipping logic, to get rid of an extra empty line before the diff * 5/7 has a slightly different comment pointing out that this is only the sticked form of -L * 67 are new, to resolve the sticky issue Thomas Rast (7): gitk: support -G option from the command line gitk: refactor per-line part of getblobdiffline and its support gitk: split out diff part in $commitinfo gitk: support showing the gathered inline diffs gitk: recognize -L option Documentation: put blame/log -L in sticked form Documentation/gitk: document -L option Documentation/blame-options.txt | 8 +- Documentation/git-blame.txt | 8 +- Documentation/git-log.txt | 6 +- Documentation/gitk.txt | 12 ++ gitk-git/gitk | 467 +++- 5 files changed, 293 insertions(+), 208 deletions(-) -- 1.8.4.2.838.ga9a3e20 -- 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 already set … wanted to set to:
DimanNe dima...@ya.ru writes: I am trying to clone/fetch svn branch with git-svn: git config --add svn-remote.stable-2012-03-29.url https://some_host/branch git config --add svn-remote.stable-2012-03-29.fetch :refs/remotes/stable-2012-03-29 git svn fetch stable-2012-03-29 which gives me this error message: svn-remote.stable-2012-03-29.url already set: https://some_host/branch/ wanted to set to: https://some_host/ I know that I probably can fix this by re-fetching all svn-repo from scratch, but it will take months or even years (due to size of repo). What does your config look like now? You should have only one svn-remote with one url, but it can have multiple .fetch entries. To fetch all branches, you can also just configure its .branches. -- Thomas Rast t...@thomasrast.ch -- 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
links of london sweetie bracelet sale Available for sale
The unique flexible links of london necklaces sale http://www.linksoflondonvipsale.co.uk/is usually just one area of anklet bracelets and the majority probably really the only ring within a female's anklet bracelets variety at least 18 could possibly for no reason receive cleared of. Giving additional to your usefulness is usually that the reptile ring can be found in a lot of colorations consisting of silvery, black onyx, jewelry, real estate agent in addition to brown. -- View this message in context: http://git.661346.n2.nabble.com/links-of-london-sweetie-bracelet-sale-Available-for-sale-tp7598434.html Sent from the git mailing list archive at Nabble.com. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
links of london friendship bracelet sale during this internet is rather low-priced on sale
Maybe you can never come to feel just what exactly I actually express, hence just simply aim to practical experience the best way superb links of london friendship bracelet sale http://www.genuinelinksoflondonsale.co.uk/ is definitely yourself. Don't know where to shop for One-way links with London, uk rings? Just simply reach toplinkslondon.com, the online store for Links London jewelry. You should know that brand jewelry is very expensive, but the Links of London jewelry at this online is very cheap for sale now, that is why I introduce the store to you. the suitable one. What is more, the store has the collections of 2010 new arrivals, if you want to get the latest fashionable jewelry, hurry up. -- View this message in context: http://git.661346.n2.nabble.com/links-of-london-friendship-bracelet-sale-during-this-internet-is-rather-low-priced-on-sale-tp7598435.html Sent from the git mailing list archive at Nabble.com. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
I enjoy Back links regarding Greater london Selling
The particular strong cheap links of london bracelets uk http://www.linksoflondondiscountshop.co.uk/ strong provides eternally experimented with the best to good deal the purchasers any equilibrium regarding current and also only exclusive function several charms regarding fans on earth. Almost all plant has been filled with those who just like the flavour regarding living persistently. These kinds of offer you choices to suit your needs. -- View this message in context: http://git.661346.n2.nabble.com/I-enjoy-Back-links-regarding-Greater-london-Selling-tp7598436.html Sent from the git mailing list archive at Nabble.com. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
pandora pendants uk Good quality Selected
This specific variety usually means one of several most significant Low-priced pandora that will Pandora features readily available, along with involves a number of surely gorgeous pieces strong pandora pendants uk http://www.cheappandoracharms2013.co.uk/ strong discounted pertaining to people. Pandora drops are generally accomplished using meaning via expect along with eagerness. Pandora drops along with earrings are generally worldwide regarded using large crucial testimonials along with situation. They've been employed to create loved diamond jewelry to acquire many, many years, which enable it to ecological pertaining to without notice because of their exclusive people. Pandora necklaces pieces are incredibly clear-cut internet marketing created, even so these are amazingly wonderful along with eye-catching. -- View this message in context: http://git.661346.n2.nabble.com/pandora-pendants-uk-Good-quality-Selected-tp7598437.html Sent from the git mailing list archive at Nabble.com. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
This pandora beads, superb treat
Most of these completely new strong pandora watches http://www.pandoraussale.biz/ strong connected with spg 2011 usually are electrifying seeing that very well seeing that contemporary| which might be eternal representations connected with really enjoy in addition to aims. Because of their a long time connected with expertise with bracelets company| just about every 12 many weeks many people add a substantial different excellent jewelleries which might be modern-day in addition to hip any way you like. Absolutely many Pandora bracelets is usually excellent that's liked by means of every woman's. While using the strengthen successful these bracelets| right now they've also been easily obtainable in quite a few on-line outlets. The most issue around the on-line shops is usually them to deliver most of these wristbands on low-priced prices. That denotes you certainly to help skimp on with all your money. -- View this message in context: http://git.661346.n2.nabble.com/This-pandora-beads-superb-treat-tp7598438.html Sent from the git mailing list archive at Nabble.com. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Limiting disk usage
Piotr Krukowiecki piotr.krukowie...@gmail.com writes: Hi, What can be done to limit amount of space occupied on clone and checkout? I know about shallow clone and sparse checkout, anything else? Sorry if I'm stating the obvious, but git gc is a good start. If you did something wrong with your repo before, maybe git gc --aggressive can help. -- Matthieu Moy http://www-verimag.imag.fr/~moy/ -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] commit: Add -f, --fixes commit option to add Fixes: line
Jeff King p...@peff.net writes: We could probably make this friendlier by reading from ~/.githooks and defining some semantics for multiple hooks. I'd be all for it, except I'd call this ~/.config/git/hooks/* (or $XDG_CONFIG_HOME if set). E.g., fall back to ~/.githooks if the repo hook is not executable, or possibly run them both I think running them both would be the best option. Otherwise, adding a (possibly trivial) hook to a repo would disable the user-wide one, that'd feel weird. -- Matthieu Moy http://www-verimag.imag.fr/~moy/ -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
swarovski crystal rings Apparent Solitaire Stud Pierced Bracelets
You'll will need a couple of smooth nosed diamond jewelry pliers that will put the particular clasp and also back links on the particular comes to an end with the necklace around your neck and lastly, a selection of strong swarovski crystal http://www.swarovskicrystalonlineshop.co.uk/ strong. You can even help make basic necklace around your neck simply by threading these kinds of beads in a variety of strings. Affix the hop band to one loop as well as the equivalent get for the some other and also quickly there is a gorgeous necklace around your neck. The thing in which restrictions an individual can be your very own creativeness, thus allow it to go work outrageous. Determine the style you'd like to generate making use of a variety of Swarovski and also emphasize beads. -- View this message in context: http://git.661346.n2.nabble.com/swarovski-crystal-rings-Apparent-Solitaire-Stud-Pierced-Bracelets-tp7598440.html Sent from the git mailing list archive at Nabble.com. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
git-contacts questions
Hi, I'm currently trying to get git-contacts to work under Windows / MSYS. I have a few issues that may be due to me using the script in a wrong way, or the script having some bugs, so I'd like to ask you for help. 1) Passing just HEAD as a committish like in git contacts HEAD does not output anything for me, but using the SHA1 for HEAD does neither. My HEAD commit does not add any files, but only modifies previously existing files, so I would have expected some output. In case it turns out to be correct to have no output in my case, could we probably say that in some message to the user? 2) For some commits I get error messages from git blame in function get_blame because multiple -L options are specified: $ git contacts b0783baacd20be7007df40cf274985c4863d63fb fatal: More than one '-L n,m' option given fatal: More than one '-L n,m' option given fatal: More than one '-L n,m' option given fatal: More than one '-L n,m' option given From reading git-blame's man page it indeed seems to me as if only one -L option is allowed, so is this something that needs to be fixed in git-contacts? Thanks. -- Sebastian Schuberth -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 2/2] merge-base: teach --fork-point mode
On Mon, Oct 28, 2013 at 12:13:22PM -0700, Junio C Hamano wrote: John Keeping j...@keeping.me.uk writes: The --reflog name has the advantage that it makes clear that this is looking at something more than the commit graph and I don't think --fork-point does imply that. I think I understand what you are saying, but that more than the commit graph part in your reasoning is exactly one of the two reasons why I do not think that it is a good idea to call it with reflog in its name. The next round of update to the feature may find a better way to find the fork point than looking at the reflog. What the feature is meant to do, i.e. find the fork point can stay the same (i.e. people can use it in their script), while the way how the implementation achieves it (i.e. by looking at reflog) can evolve over time, and by not hardcoding how in the name, the users will benefit from the updated behaviour, without having to ask for a better heuristics by using a different option by updating all of their scripts. OK - given this reasoning I agree that --fork-point makes sense. I think this would have been clearer if the short description said something like: Find the point at which a branch forked from another branch; this does not just look for the common ancestor of the two commits but also takes into account the reflog of ref to see if the branch forked from an earlier incarnation. -- 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 v4 12/10] git-remote-testgit: support the new 'force' option
Richard Hansen wrote:
Signed-off-by: Richard Hansen rhan...@bbn.com
---
git-remote-testgit.sh | 18 ++
1 file changed, 18 insertions(+)
diff --git a/git-remote-testgit.sh b/git-remote-testgit.sh
index 6d2f282..80546c1 100755
--- a/git-remote-testgit.sh
+++ b/git-remote-testgit.sh
@@ -6,6 +6,7 @@ url=$2
dir=$GIT_DIR/testgit/$alias
prefix=refs/testgit/$alias
+forcearg=
default_refspec=refs/heads/*:${prefix}/heads/*
@@ -39,6 +40,7 @@ do
fi
test -n $GIT_REMOTE_TESTGIT_SIGNED_TAGS echo signed-tags
test -n $GIT_REMOTE_TESTGIT_NO_PRIVATE_UPDATE echo
no-private-update
+ echo 'option'
echo
;;
list)
@@ -93,6 +95,7 @@ do
before=$(git for-each-ref --format=' %(refname) %(objectname) ')
git fast-import \
+ ${forcearg} \
${testgitmarks:+--import-marks=$testgitmarks} \
${testgitmarks:+--export-marks=$testgitmarks} \
--quiet
@@ -115,6 +118,21 @@ do
echo
;;
+ option\ *)
+ read cmd opt val EOF
+${line}
+EOF
We can do -EOF to align this properly.
Also, I don't see why all the variables are ${foo} instead of $foo.
+ case ${opt} in
+ force)
I think the convention is to align these:
case $opt in
force)
+ case ${val} in
+ true) forcearg=--force; echo 'ok';;
+ false) forcearg=; echo 'ok';;
+ *) printf %s\\n error '${val}'\
+ is not a valid value for option ${opt};;
I think this is packing a lot of stuff and it's not that readable.
Moreover, this is not for production purposes, it's for testing purposes and a
guideline, I think this suffices.
option\ *)
read cmd opt val -EOF
$line
EOF
case $opt in
force)
test $val = true force=true || force=
echo ok
;;
*)
echo unsupported
;;
esac
;;
But this is definetly good to have, will merge.
--
Felipe Contreras
--
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-contacts questions
On Tue, Oct 29, 2013 at 2:34 AM, Sebastian Schuberth sschube...@gmail.com wrote: 1) Passing just HEAD as a committish like in git contacts HEAD does not output anything for me, but using the SHA1 for HEAD does neither. My HEAD commit does not add any files, but only modifies previously existing files, so I would have expected some output. In case it turns out to be correct to have no output in my case, could we probably say that in some message to the user? It should be HEAD^, or -1, like with 'git format-patch'. 2) For some commits I get error messages from git blame in function get_blame because multiple -L options are specified: $ git contacts b0783baacd20be7007df40cf274985c4863d63fb fatal: More than one '-L n,m' option given fatal: More than one '-L n,m' option given fatal: More than one '-L n,m' option given fatal: More than one '-L n,m' option given From reading git-blame's man page it indeed seems to me as if only one -L option is allowed, so is this something that needs to be fixed in git-contacts? You are probably using a newer version of the script on an older version of Git. You can also try git-related instead[1]. [1] https://github.com/felipec/git-related -- Felipe Contreras -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: What's cooking in git.git (Oct 2013, #06; Fri, 25)
On Mon, Oct 28, 2013 at 10:04 PM, Vicent Martí tan...@gmail.com wrote: On Mon, Oct 28, 2013 at 8:45 PM, Karsten Blees karsten.bl...@gmail.com wrote: Regarding performance, khash uses open addressing, which requires more key comparisons (O(1/(1-load_factor))) than chaining (O(1+load_factor)). However, any measurable differences will most likely be dwarfed by IO costs in this particular use case. I don't think this is true. If you actually run a couple insertion and lookup benchmarks comparing the two implementations, you'll find khash to be around ~30% faster for most workloads (venturing a guess from past experience). I am obviously not the author of khash, but I've found that the theoretical increase in key comparisons is completely dwarfed by the benefit of increased cache locality during the probing fase. I still haven't found a faster C hash table implementation than khash for the general case, that's why I normally use it despite the worrisome preprocessor crash-party going on in that header file. Yes, cache locality is where open addressing shines, however, you loose that benefit when the keys are pointers (e.g. sha1's). Btw., pack-objects.c::rehash_objects() in patch 03 unnecessarily checks for duplicates. That's probably the reason for the high hashcmp times you found in the first round of the patch series. Patch 03 is a refactoring -- the duplicate checking code has been in pack-objects.c for years. I am not sure duplicate checking is superfluous at all, there are many cases where you could be double-inserting objects in a pack-objects run, and you really don't want to generate packfiles with dupe objects. The point is that its in _rehash_. Duplicate checking should be in add/put. Rehash only rearranges entries that are alread _in_ the map, and it usually only needs the hash code for that. So pack-objects implements rehash in terms of a full clear + add-all instead, which is of course slower than what khash, hashmap etc. would do. Ciao, Karsten -- 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-contacts questions
On Tue, Oct 29, 2013 at 9:57 AM, Felipe Contreras felipe.contre...@gmail.com wrote: 1) Passing just HEAD as a committish like in git contacts HEAD does not output anything for me, but using the SHA1 for HEAD does neither. My HEAD commit does not add any files, but only modifies previously existing files, so I would have expected some output. In case it turns out to be correct to have no output in my case, could we probably say that in some message to the user? It should be HEAD^, or -1, like with 'git format-patch'. Oh, that's pretty much unexpected. Wouldn't it be much more natural if I had to specify the commit(s) that introduce(s) the changes that I want others to look at? 2) For some commits I get error messages from git blame in function get_blame because multiple -L options are specified: $ git contacts b0783baacd20be7007df40cf274985c4863d63fb fatal: More than one '-L n,m' option given fatal: More than one '-L n,m' option given fatal: More than one '-L n,m' option given fatal: More than one '-L n,m' option given From reading git-blame's man page it indeed seems to me as if only one -L option is allowed, so is this something that needs to be fixed in git-contacts? You are probably using a newer version of the script on an older version of Git. Well, I'm running Git for Windows 1.8.4, and according to [1] git-blame was not changed after 1.8.4. You can also try git-related instead[1]. [1] https://github.com/felipec/git-related I just did very quickly (with Ruby 1.8.7) and I get: $ git related b0783baacd20be7007df40cf274985c4863d63fb C:/Program Files (x86)/Git/libexec/git-core/git-related:309:in `popen': can't convert Array into String (TypeError) from C:/Program Files (x86)/Git/libexec/git-core/git-related:309:in `from_rev_args' from C:/Program Files (x86)/Git/libexec/git-core/git-related:345 [1] http://git-scm.com/docs/git-blame.html -- Sebastian Schuberth -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: git-contacts questions
On Tue, Oct 29, 2013 at 3:12 AM, Sebastian Schuberth sschube...@gmail.com wrote: On Tue, Oct 29, 2013 at 9:57 AM, Felipe Contreras felipe.contre...@gmail.com wrote: 1) Passing just HEAD as a committish like in git contacts HEAD does not output anything for me, but using the SHA1 for HEAD does neither. My HEAD commit does not add any files, but only modifies previously existing files, so I would have expected some output. In case it turns out to be correct to have no output in my case, could we probably say that in some message to the user? It should be HEAD^, or -1, like with 'git format-patch'. Oh, that's pretty much unexpected. Wouldn't it be much more natural if I had to specify the commit(s) that introduce(s) the changes that I want others to look at? Yeah, that's exactly what you are doing. How do you tell 'git log' to show you certain changes? You can also try git-related instead[1]. [1] https://github.com/felipec/git-related I just did very quickly (with Ruby 1.8.7) and I get: $ git related b0783baacd20be7007df40cf274985c4863d63fb C:/Program Files (x86)/Git/libexec/git-core/git-related:309:in `popen': can't convert Array into String (TypeError) from C:/Program Files (x86)/Git/libexec/git-core/git-related:309:in `from_rev_args' from C:/Program Files (x86)/Git/libexec/git-core/git-related:345 Fixed. -- Felipe Contreras -- 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] Add option --no-tags
From 1cbc2c49454581a67cce09ada1386dac4ffa2828 Mon Sep 17 00:00:00 2001
From: Nicolas Cornu nco...@aldebaran-robotics.com
Date: Tue, 29 Oct 2013 11:31:10 +0100
Subject: [PATCH] Add option --no-tags
---
gitk-git/gitk | 13 ++---
1 file changed, 10 insertions(+), 3 deletions(-)
diff --git a/gitk-git/gitk b/gitk-git/gitk
index 5cd00d8..d6f5e07 100755
--- a/gitk-git/gitk
+++ b/gitk-git/gitk
@@ -156,7 +156,7 @@ proc unmerged_files {files} {
proc parseviewargs {n arglist} {
global vdatemode vmergeonly vflags vdflags vrevs vfiltered vorigargs env
-global worddiff git_version
+global worddiff git_version no_tags
set vdatemode($n) 0
set vmergeonly($n) 0
@@ -167,6 +167,7 @@ proc parseviewargs {n arglist} {
set origargs $arglist
set allknown 1
set filtered 0
+set no_tags 0
set i -1
foreach arg $arglist {
incr i
@@ -183,6 +184,9 @@ proc parseviewargs {n arglist} {
set origargs [lreplace $origargs $i $i]
incr i -1
}
+ --no-tags {
+set no_tags 1
+ }
-[puabwcrRBMC] -
--no-renames - --full-index - --binary - --abbrev=* -
--find-copies-harder - -l* - --ext-diff - --no-ext-diff -
@@ -6394,13 +6398,16 @@ proc drawtags {id x xt y1} {
global headbgcolor headfgcolor headoutlinecolor remotebgcolor
global tagbgcolor tagfgcolor tagoutlinecolor
global reflinecolor
+global no_tags
set marks {}
set ntags 0
set nheads 0
if {[info exists idtags($id)]} {
-set marks $idtags($id)
-set ntags [llength $marks]
+ if {$no_tags 1} {
+set marks $idtags($id)
+set ntags [llength $marks]
+ }
}
if {[info exists idheads($id)]} {
set marks [concat $marks $idheads($id)]
--
1.8.4.2
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
How to retrieve the rewritten list like the one made by git-rebase
Hello, I'd like to get a similar rewritten list than the one that git-rebase pass to the post-rewrite hook. Is there any ways to do that without using the post-rewrite hook ? Thanks -- Francis -- 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: Limiting disk usage
[resending as sent previous version as HTML, sorry about that] On Tue, Oct 29, 2013 at 9:21 AM, Matthieu Moy matthieu@grenoble-inp.fr wrote: Piotr Krukowiecki piotr.krukowie...@gmail.com writes: Hi, What can be done to limit amount of space occupied on clone and checkout? I know about shallow clone and sparse checkout, anything else? Sorry if I'm stating the obvious, but git gc is a good start. If you did something wrong with your repo before, maybe git gc --aggressive can help. Yes, I put a lot of code into the repository. I know it is wrong from git POV ;) That's why I wrote about splitting repository into multiple smaller repositories, but AFAIK git is not very good at managing that too... (Background: we're thinking about migrating svn repository into git. Currently there is one svn repository containing many related directories. They are branched/merged/tagged together. Often work is done on all/many of them, but there are some use cases where we need only some of them) -- Piotr Krukowiecki -- 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] Add a scrollbar for commit history in gitk
From b3570290bd761a1bf952ea491fa62b123231fe61 Mon Sep 17 00:00:00 2001
From: Nicolas Cornu nco...@aldebaran-robotics.com
Date: Tue, 29 Oct 2013 14:51:29 +0100
Subject: [PATCH] Add a scrollbar for commit history in gitk
---
gitk-git/gitk | 8 +++-
1 file changed, 7 insertions(+), 1 deletion(-)
diff --git a/gitk-git/gitk b/gitk-git/gitk
index d6f5e07..e517253 100755
--- a/gitk-git/gitk
+++ b/gitk-git/gitk
@@ -2124,11 +2124,17 @@ proc makewindow {} {
# create three canvases
set cscroll .tf.histframe.csb
set canv .tf.histframe.pwclist.canv
+set cscrollhl .tf.histframe.pwclist.canv.csb
canvas $canv \
-selectbackground $selectbgcolor \
-background $bgcolor -bd 0 \
--yscrollincr $linespc -yscrollcommand scrollcanv $cscroll
+-yscrollincr $linespc -yscrollcommand scrollcanv $cscroll \
+-xscrollcommand scrollcanv $cscrollhl
.tf.histframe.pwclist add $canv
+${NS}::scrollbar $cscrollhl -command {$canv xview} -orient horizontal
+if {!$use_ttk} {$cscrollhl configure -highlightthickness 0}
+pack $cscrollhl -fill x -side bottom
+
set canv2 .tf.histframe.pwclist.canv2
canvas $canv2 \
-selectbackground $selectbgcolor \
--
1.8.4.2
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Why is git-subtree docs XML and not HTML?
Hi, I'm currently looking at subtree's Makefile and wondering why the generated markup docs is git-subtree.xml, and not git-subtree.html like for the rest of the git commands. I have not looked at git-subtree.xml because I'm lacking asciidoc right now, but is it just a matter of changing the file extension from .xml to .html, or does generating a HTML file involve more work? -- Sebastian Schuberth -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: git-contacts questions
On Tue, Oct 29, 2013 at 11:35 AM, Felipe Contreras felipe.contre...@gmail.com wrote: On Tue, Oct 29, 2013 at 3:12 AM, Sebastian Schuberth sschube...@gmail.com wrote: On Tue, Oct 29, 2013 at 9:57 AM, Felipe Contreras felipe.contre...@gmail.com wrote: 1) Passing just HEAD as a committish like in git contacts HEAD does not output anything for me, but using the SHA1 for HEAD does neither. My HEAD commit does not add any files, but only modifies previously existing files, so I would have expected some output. In case it turns out to be correct to have no output in my case, could we probably say that in some message to the user? It should be HEAD^, or -1, like with 'git format-patch'. Oh, that's pretty much unexpected. Wouldn't it be much more natural if I had to specify the commit(s) that introduce(s) the changes that I want others to look at? Yeah, that's exactly what you are doing. How do you tell 'git log' to show you certain changes? I'm not sure what you're trying to point me at. It's clear that from an implementation view you need to blame HEAD^ if you need to know which poeple should review your changes in HEAD. But IMHO that is an implementation detail that should be hidden from the user. Like I said, I think it would be much more natural if it worked by specifying the commits that *I* introduced, and then lists all people to contact for a review. $ git related b0783baacd20be7007df40cf274985c4863d63fb C:/Program Files (x86)/Git/libexec/git-core/git-related:309:in `popen': can't convert Array into String (TypeError) from C:/Program Files (x86)/Git/libexec/git-core/git-related:309:in `from_rev_args' from C:/Program Files (x86)/Git/libexec/git-core/git-related:345 Fixed. Thanks, but now I'm getting $ git related b0783baacd20be7007df40cf274985c4863d63fb fatal: ambiguous argument '\^b0783baacd20be7007df40cf274985c4863d63fb': unknown revision or path not in the working tree. Use '--' to separate paths from revisions, like this: 'git command [revision...] -- [file...]' I've checked of course that the commit exists. -- Sebastian Schuberth -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: git svn already set … wanted to set to:
What does your config look like now? [core] repositoryformatversion = 0 filemode = true bare = false logallrefupdates = true [svn-remote svn] url = https://some_host/trunk/ fetch = :refs/remotes/git-svn [merge] renameLimit = 5 [svn-remote stable-2012-09-13] url = https://some_host/branches/stable-2012-09-13/ fetch = :refs/remotes/stable-2012-09-13 29.10.2013, 11:25, Thomas Rast t...@thomasrast.ch: DimanNe dima...@ya.ru writes: I am trying to clone/fetch svn branch with git-svn: git config --add svn-remote.stable-2012-03-29.url https://some_host/branch git config --add svn-remote.stable-2012-03-29.fetch :refs/remotes/stable-2012-03-29 git svn fetch stable-2012-03-29 which gives me this error message: svn-remote.stable-2012-03-29.url already set: https://some_host/branch/ wanted to set to: https://some_host/ I know that I probably can fix this by re-fetching all svn-repo from scratch, but it will take months or even years (due to size of repo). What does your config look like now? You should have only one svn-remote with one url, but it can have multiple .fetch entries. To fetch all branches, you can also just configure its .branches. -- Thomas Rast t...@thomasrast.ch -- 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-contacts questions
Sebastian Schuberth sschube...@gmail.com writes: On Tue, Oct 29, 2013 at 11:35 AM, Felipe Contreras felipe.contre...@gmail.com wrote: On Tue, Oct 29, 2013 at 3:12 AM, Sebastian Schuberth sschube...@gmail.com wrote: On Tue, Oct 29, 2013 at 9:57 AM, Felipe Contreras felipe.contre...@gmail.com wrote: 1) Passing just HEAD as a committish like in git contacts HEAD does not output anything for me, but using the SHA1 for HEAD does neither. My HEAD commit does not add any files, but only modifies previously existing files, so I would have expected some output. In case it turns out to be correct to have no output in my case, could we probably say that in some message to the user? It should be HEAD^, or -1, like with 'git format-patch'. Oh, that's pretty much unexpected. Wouldn't it be much more natural if I had to specify the commit(s) that introduce(s) the changes that I want others to look at? Yeah, that's exactly what you are doing. How do you tell 'git log' to show you certain changes? I'm not sure what you're trying to point me at. It's clear that from an implementation view you need to blame HEAD^ if you need to know which poeple should review your changes in HEAD. I agree that the situation when providing only HEAD is really disappointing... But IMHO that is an implementation detail that should be hidden from the user. ... but it's not just an implementation detail: git-contacts takes a range of commits, so you can ask for people to Cc for a whole patch series for example. If I understand correctly, git contact $ONE_COMMIT does git contact $ONE_COMMIT..HEAD implicitly, and this is weird when $ONE_COMMIT is HEAD. -- Matthieu Moy http://www-verimag.imag.fr/~moy/ -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Limiting disk usage
On 2013-10-29 14:50, Piotr Krukowiecki wrote: Yes, I put a lot of code into the repository. I know it is wrong from git POV ;) That's why I wrote about splitting repository into multiple smaller repositories, but AFAIK git is not very good at managing that too... Lot of code isn't problem, see Linux kernel or GCC, or LibreOffice.org (Background: we're thinking about migrating svn repository into git. Currently there is one svn repository containing many related directories. They are branched/merged/tagged together. Often work is done on all/many of them, but there are some use cases where we need only some of them) If they are independent projects, they should get independent repositories; you can stitch them back together using git-submodule (or git-subtree). reposurgeon can hel you with that. -- Jakub Narębski -- 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
eccellenza del lusso russia emirati arabi
http://www.fashionvipmagazine.com http://www.fashionvipmagazine.com -- If you do not want to receive any more newsletters, http://dem.fashionvipmagazine.com/lists/?p=unsubscribeuid=28f5b000728b6a9507611f37112d001e To update your preferences and to unsubscribe visit http://dem.fashionvipmagazine.com/lists/?p=preferencesuid=28f5b000728b6a9507611f37112d001e Forward a Message to Someone http://dem.fashionvipmagazine.com/lists/?p=forwarduid=28f5b000728b6a9507611f37112d001emid=83 -- powered by phpList, www.phplist.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: git-contacts questions
On Tue, Oct 29, 2013 at 3:39 PM, Matthieu Moy matthieu@grenoble-inp.fr wrote: I'm not sure what you're trying to point me at. It's clear that from an implementation view you need to blame HEAD^ if you need to know which poeple should review your changes in HEAD. I agree that the situation when providing only HEAD is really disappointing... But IMHO that is an implementation detail that should be hidden from the user. ... but it's not just an implementation detail: git-contacts takes a range of commits, so you can ask for people to Cc for a whole patch series for example. If I understand correctly, git contact $ONE_COMMIT does git contact $ONE_COMMIT..HEAD implicitly, and this is weird when $ONE_COMMIT is HEAD. It's not only weird if $ONE_COMMIT is HEAD, but for any single commit. At least I would expect git contacts $ONE_COMMIT to list the poeple interested in the single commit $ONE_COMMIT. Instead, what it seems to do is list the people who are interested in the commits *after* $ONE_COMMIT. -- Sebastian Schuberth -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Why is git-subtree docs XML and not HTML?
On Tue, Oct 29, 2013 at 03:03:40PM +0100, Sebastian Schuberth wrote: I'm currently looking at subtree's Makefile and wondering why the generated markup docs is git-subtree.xml, and not git-subtree.html like for the rest of the git commands. I have not looked at git-subtree.xml because I'm lacking asciidoc right now, but is it just a matter of changing the file extension from .xml to .html, or does generating a HTML file involve more work? The XML is an intermediate format for the manpage; the original source is .txt, from which asciidoc generate docbook .xml, from which xmlto generate the roff git-subtree.1. If you want HTML, you need to have asciidoc generate .html from the .txt directly (you probably _can_ generate it from docbook, but that is more complicated, and not how regular git commands work). I think this would do what you want: diff --git a/contrib/subtree/Makefile b/contrib/subtree/Makefile index 435b2de..e9026da 100644 --- a/contrib/subtree/Makefile +++ b/contrib/subtree/Makefile @@ -21,6 +21,7 @@ GIT_SUBTREE:= git-subtree GIT_SUBTREE_DOC := git-subtree.1 GIT_SUBTREE_XML := git-subtree.xml GIT_SUBTREE_TXT := git-subtree.txt +GIT_SUBTREE_HTML := git-subtree.html all: $(GIT_SUBTREE) @@ -46,6 +47,10 @@ $(GIT_SUBTREE_XML): $(GIT_SUBTREE_TXT) asciidoc -b docbook -d manpage -f $(ASCIIDOC_CONF) \ -agit_version=$(gitver) $^ +$(GIT_SUBTREE_HTML): $(GIT_SUBTREE_TXT) + asciidoc -b xhtml11 -d manpage -f $(ASCIIDOC_CONF) \ + -agit_version=$(gitver) $^ + test: $(MAKE) -C t/ test -- 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: Why is git-subtree docs XML and not HTML?
On Tue, Oct 29, 2013 at 4:50 PM, Jeff King p...@peff.net wrote: I think this would do what you want: diff --git a/contrib/subtree/Makefile b/contrib/subtree/Makefile index 435b2de..e9026da 100644 --- a/contrib/subtree/Makefile +++ b/contrib/subtree/Makefile @@ -21,6 +21,7 @@ GIT_SUBTREE:= git-subtree GIT_SUBTREE_DOC := git-subtree.1 GIT_SUBTREE_XML := git-subtree.xml GIT_SUBTREE_TXT := git-subtree.txt +GIT_SUBTREE_HTML := git-subtree.html all: $(GIT_SUBTREE) @@ -46,6 +47,10 @@ $(GIT_SUBTREE_XML): $(GIT_SUBTREE_TXT) asciidoc -b docbook -d manpage -f $(ASCIIDOC_CONF) \ -agit_version=$(gitver) $^ +$(GIT_SUBTREE_HTML): $(GIT_SUBTREE_TXT) + asciidoc -b xhtml11 -d manpage -f $(ASCIIDOC_CONF) \ + -agit_version=$(gitver) $^ + test: $(MAKE) -C t/ test I just gave it a try and it works nicely: Tested-by: Sebastian Schuberth sschube...@gmail.com Also, the clean target already contains *.html, so nothing else to do there. Any chance to get this queued in pu? Thanks a lot! -- Sebastian Schuberth -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] subtree: add makefile target for html docs
On Tue, Oct 29, 2013 at 05:03:53PM +0100, Sebastian Schuberth wrote: I just gave it a try and it works nicely: Tested-by: Sebastian Schuberth sschube...@gmail.com Also, the clean target already contains *.html, so nothing else to do there. Any chance to get this queued in pu? Here it is with a commit message, and the additional wiring into make doc. -- 8 -- Subject: subtree: add makefile target for html docs The Makefile currently builds the roff manpage, but not the html form. As some people may prefer the latter, let's make it an option to build that, too. We also wire it into make doc so that it is built by default. This patch does not build or install it as part of install-doc; that would require extra infrastructure to handle installing the html as we do in git's regular Documentation/ tree. That can come later if somebody is interested. Tested-by: Sebastian Schuberth sschube...@gmail.com Signed-off-by: Jeff King p...@peff.net --- contrib/subtree/Makefile | 7 ++- 1 file changed, 6 insertions(+), 1 deletion(-) diff --git a/contrib/subtree/Makefile b/contrib/subtree/Makefile index 435b2de..4030a16 100644 --- a/contrib/subtree/Makefile +++ b/contrib/subtree/Makefile @@ -21,13 +21,14 @@ GIT_SUBTREE:= git-subtree GIT_SUBTREE_DOC := git-subtree.1 GIT_SUBTREE_XML := git-subtree.xml GIT_SUBTREE_TXT := git-subtree.txt +GIT_SUBTREE_HTML := git-subtree.html all: $(GIT_SUBTREE) $(GIT_SUBTREE): $(GIT_SUBTREE_SH) cp $ $@ chmod +x $@ -doc: $(GIT_SUBTREE_DOC) +doc: $(GIT_SUBTREE_DOC) $(GIT_SUBTREE_HTML) install: $(GIT_SUBTREE) $(INSTALL) -d -m 755 $(DESTDIR)$(libexecdir) @@ -46,6 +47,10 @@ $(GIT_SUBTREE_XML): $(GIT_SUBTREE_TXT) asciidoc -b docbook -d manpage -f $(ASCIIDOC_CONF) \ -agit_version=$(gitver) $^ +$(GIT_SUBTREE_HTML): $(GIT_SUBTREE_TXT) + asciidoc -b xhtml11 -d manpage -f $(ASCIIDOC_CONF) \ + -agit_version=$(gitver) $^ + test: $(MAKE) -C t/ test -- 1.8.4.1.898.g8bf8a41.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
rcs
Hi. I'm going to attempt to import a git database into Razor which is linux rcs based. Does the linux version of git use rcs ? Thanks Jim Jim Finnerty ECS, Inc. Comm: (270) 798-1386, Fax: (270)798-7724 Cell: (570) 498-8499 CAUTION: This message may contain competitive, sensitive or other non-public information not intended for disclosure outside official government channels. Do not disseminate this message outside of official channels. If you received this message in error, please notify the sender by reply e-mail and delete all copies of this message. STATEMENT OF LIMITATION OF AUTHORITY: You are hereby notified that I do not have the authority to direct you in any way to alter your contractual obligations. Further, if your U.S. Army customer, as the result of the information obtained from discussions or emails, does desire to alter your contract requirements, changes will be issued in writing and signed by the contracting officer. You should take no action on any change unless and until you receive such a contract modification or written direction by the Contracting Officer. -- 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-contacts questions
On Tue, Oct 29, 2013 at 8:17 AM, Sebastian Schuberth sschube...@gmail.com wrote: On Tue, Oct 29, 2013 at 11:35 AM, Felipe Contreras felipe.contre...@gmail.com wrote: On Tue, Oct 29, 2013 at 3:12 AM, Sebastian Schuberth sschube...@gmail.com wrote: $ git related b0783baacd20be7007df40cf274985c4863d63fb C:/Program Files (x86)/Git/libexec/git-core/git-related:309:in `popen': can't convert Array into String (TypeError) from C:/Program Files (x86)/Git/libexec/git-core/git-related:309:in `from_rev_args' from C:/Program Files (x86)/Git/libexec/git-core/git-related:345 Fixed. Thanks, but now I'm getting $ git related b0783baacd20be7007df40cf274985c4863d63fb fatal: ambiguous argument '\^b0783baacd20be7007df40cf274985c4863d63fb': unknown revision or path not in the working tree. Use '--' to separate paths from revisions, like this: 'git command [revision...] -- [file...]' I've checked of course that the commit exists. I've pushed a fix, it's not complete, but should work for most cases. -- Felipe Contreras -- 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: rcs
Finnerty, James M Mr CTR USA USASOC-SOAR jim.finnerty@soar.army.mil writes: Hi. I'm going to attempt to import a git database into Razor which is linux rcs based. Does the linux version of git use rcs ? If you're talking about the GNU rcs program, no, it does not. -Keshav -- 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: rcs
On Tue, Oct 29, 2013 at 11:35:21AM -0500, Finnerty, James M Mr CTR USA
USASOC-SOAR wrote:
Hi. I'm going to attempt to import a git database into Razor which is
linux rcs based. Does the linux version of git use rcs ?
No, the formats are completely different, and you will have to
translate. We don't usually get requests to go from git to rcs; it
usually goes the other way. :)
I don't know offhand of a tool that does it out of the box. It should
be possible to generate the RCS files directly from the git log data
(though RCS does not use unified diff for storage, but rather ed
commands, so you'd have to translate there). A slower simpler way would
be to just replay the git history, committing to rcs at each step.
That might look something like the hacky, largely untested script below:
-- 8 --
#!/bin/sh
# note that this does not handle filenames which need quoting.
changed_files() {
git diff-tree -r --name-only $1 | tail -n +2
}
# Look at each commit in chronological order; note
# that this will linearize your history, as this
# script does not know about branches at all.
git rev-list --reverse HEAD |
while read rev; do
# take a lock on each file we are about to update
rcs -l $(changed_files $rev)
# update the working tree to this revision
git checkout -fq $rev
# get commit date in iso8601
date=$(git log -1 --format=%ai)
# get author login. This just pulls the username from
# the email address; you may also want to map email
# addresses to logins via a file.
login=$(git log -1 --format=%ae | cut -d@ -f1)
# original commit message
msg=$(git log -1 --format=%B)
# now we're ready to checkin
ci -w$login -d$date -m$msg $(changed_files $rev) /dev/null
done
-- 8 --
There are lots of ways it can go wrong (and I tried to note them above),
but it may be enough for a simple history.
-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-contacts questions
On Tue, Oct 29, 2013 at 4:57 AM, Felipe Contreras felipe.contre...@gmail.com wrote: On Tue, Oct 29, 2013 at 2:34 AM, Sebastian Schuberth sschube...@gmail.com wrote: 2) For some commits I get error messages from git blame in function get_blame because multiple -L options are specified: $ git contacts b0783baacd20be7007df40cf274985c4863d63fb fatal: More than one '-L n,m' option given fatal: More than one '-L n,m' option given fatal: More than one '-L n,m' option given fatal: More than one '-L n,m' option given From reading git-blame's man page it indeed seems to me as if only one -L option is allowed, so is this something that needs to be fixed in git-contacts? You are probably using a newer version of the script on an older version of Git. Right. git-blame learned to accept multiple -L's in 58dbfa2e59a1, and git-contacts started taking advantage of that feature in 4c70cfbfbc2d. A git-contacts prior to 4c70cfbfbc2d might work for you. -- 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
Documentation for fetch, url, branches, tags keywords in git config?
A typical config [svn-remote svn] noMetadata = 1 url = http://repository.url/svn fetch = trunk/etl_app:refs/remotes/etl_app/trunk branches = branches/etl_app/*:refs/remotes/branches/* tags = tags/etl_app/*:refs/remotes/tags/* However, the manpage for git-config(1) does not include anything exlicit on url, fetch, branches, 'tags, and the meaning of the syntax following the colon. Where can I find this info? -- 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: Documentation for fetch, url, branches, tags keywords in git config?
On Tue, Oct 29, 2013 at 07:23:20PM +, Jim Garrison wrote: A typical config [svn-remote svn] noMetadata = 1 url = http://repository.url/svn fetch = trunk/etl_app:refs/remotes/etl_app/trunk branches = branches/etl_app/*:refs/remotes/branches/* tags = tags/etl_app/*:refs/remotes/tags/* However, the manpage for git-config(1) does not include anything exlicit on url, fetch, branches, 'tags, and the meaning of the syntax following the colon. Where can I find this info? Is the info in here what you're looking for? http://jk.gs/git-svn.html -- Med vänliga hälsningar Fredrik Gustafsson tel: 0733-608274 e-post: iv...@iveqy.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: Documentation for fetch, url, branches, tags keywords in git config?
I've already read that manpage. It does not describe the meaning of fetch, branches and tags, and the significance of the :refs/remotes/branches/* syntax. -Original Message- From: Fredrik Gustafsson [mailto:iveqy.mail...@gmail.com] On Behalf Of Fredrik Gustafsson Sent: Tuesday, October 29, 2013 12:37 PM To: Jim Garrison Cc: git@vger.kernel.org Subject: Re: Documentation for fetch, url, branches, tags keywords in git config? On Tue, Oct 29, 2013 at 07:23:20PM +, Jim Garrison wrote: A typical config [svn-remote svn] noMetadata = 1 url = http://repository.url/svn fetch = trunk/etl_app:refs/remotes/etl_app/trunk branches = branches/etl_app/*:refs/remotes/branches/* tags = tags/etl_app/*:refs/remotes/tags/* However, the manpage for git-config(1) does not include anything exlicit on url, fetch, branches, 'tags, and the meaning of the syntax following the colon. Where can I find this info? Is the info in here what you're looking for? http://jk.gs/git-svn.html -- Med vänliga hälsningar Fredrik Gustafsson tel: 0733-608274 e-post: iv...@iveqy.com -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] commit: Add -f, --fixes commit option to add Fixes: line
Christian Couder christian.cou...@gmail.com writes: On Mon, Oct 28, 2013 at 10:08 AM, Junio C Hamano gits...@pobox.com wrote: Thinking aloud further, what I had in mind was along the lines of the following. * The most generic external interface would be spelled as --trailer token[=param] where token can be things like signoff, closes, acked-by, change-id, fixes, etc.; they can be taken from an unbounded set. The historical --signoff can become a short-hand for --trailer signoff. More than one --trailer option can be given on a single command line. Ok, and maybe the token could also be the full trailer like Signed-off-by. Yeah, between these two: [commitTrailer Signed-off-by] style = append-norepeat shorthand = signoff command = echo $GIT_COMMITTER_NAME $GIT_COMMITTER_EMAIL' [commitTrailer signoff] style = append-norepeat trailer = Signed-off-by command = echo $GIT_COMMITTER_NAME $GIT_COMMITTER_EMAIL' I do not have strong preference either way. One of these two sets of configuration will have to become a built-in default (i.e. still allowing people from other development community conventions to redefine how S-o-b: works), so there will be no user-visible difference either way at the highest-level Porcelain anyway. Oh, also, it seems people prefer to call them footers, judging by the messages in this thread. I do not have a problem with that word, either; I suspect we may have to update existing documentation that calls them trailers, if we go that way, though. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 2/2] merge-base: teach --fork-point mode
John Keeping j...@keeping.me.uk writes: OK - given this reasoning I agree that --fork-point makes sense. I think this would have been clearer if the short description said something like: Find the point at which a branch forked from another branch; this does not just look for the common ancestor of the two commits but also takes into account the reflog of ref to see if the branch forked from an earlier incarnation. That's much easier to read. Will squash the following in (I do want to make sure that it is clear that commit does not have to be at the tip, and also ref does not have to be a branch---it could be any ref). Thanks. --fork-point:: - Given a commit that is derived from possibly an earlier - incarnation of a ref, find an appropriate fork-point of the - derived history to rebase it on top of an updated base - history (see discussion on this mode below). + Find the point at which a branch (or any history that leads + to commit) forked from another branch (or any reference) + ref. This does not just look for the common ancestor of + the two commits, but also takes into account the reflog of + ref to see if the history leading to commit forked from + an earlier incarnation of the branch ref (see discussion + on this mode below). 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: git-contacts questions
On Tue, Oct 29, 2013 at 8:02 PM, Eric Sunshine sunsh...@sunshineco.com wrote: $ git contacts b0783baacd20be7007df40cf274985c4863d63fb fatal: More than one '-L n,m' option given fatal: More than one '-L n,m' option given fatal: More than one '-L n,m' option given fatal: More than one '-L n,m' option given From reading git-blame's man page it indeed seems to me as if only one -L option is allowed, so is this something that needs to be fixed in git-contacts? You are probably using a newer version of the script on an older version of Git. Right. git-blame learned to accept multiple -L's in 58dbfa2e59a1, and git-contacts started taking advantage of that feature in 4c70cfbfbc2d. A git-contacts prior to 4c70cfbfbc2d might work for you. Ah, and 58dbfa2e59a1 is not in any release yet. Thanks. -- Sebastian Schuberth -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH V3] git clone: is an URL local or ssh
Commit 8d3d28f5 added test cases for URLs which should be ssh.
Add more tests testing all the combinations:
-IPv4 or IPv6
-path starting with / or with /~
-with and without the ssh:// scheme
Add tests for ssh:// with port number.
When a git repository foo:bar exist, git clone will call
absolute_path() and git_connect() will be called with
something like /home/user/projects/foo:bar
Tighten the test and use foo:bar instead of ./foo:bar,
refactor clear_ssh() and expect_ssh() into test_clone_url().
git clone foo/bar:baz should not be ssh:
Make the rule
if there is a slash before the first colon, it is not ssh
more strict by using the same is_local() in both connect.c
and transport.c. Add a test case.
Bug fixes for corner cases:
- Handle clone of [::1]:/~repo correctly (2e7766655):
Git should call ssh ::1 ~repo, not ssh ::1 /~repo
This was caused by looking at (host != url), which never
worked for host names with literal IPv6 adresses, embedded by []
Support for the [] URLs was introduced in 356bece0a.
- Do not tamper local URLs starting with '[' which have a ']'
Signed-off-by: Torsten Bögershausen tbo...@web.de
---
(Thanks for the reviews)
Changes since V2:
clear_ssh and expect_ssh did come back
And I couldn't get it working without the
$TRASH_DIRECTORY/ssh-output
test_when_finished:
I could not get that to work. Probably because of the
battle between the quotings: '' ' ''
Other note about test_might_fail:
The first version did not need it, git clone did
always succeed.
After a while it always failed.
According to my understanding, git clone ssh://xxx.yy
should fail (as we can not clone) ??
But it seems to be a timing problem, anybody wants to comment
on this ?
connect.c| 47
connect.h| 1 +
t/t5601-clone.sh | 81 +---
transport.c | 8 --
4 files changed, 102 insertions(+), 35 deletions(-)
diff --git a/connect.c b/connect.c
index 06e88b0..d61adc9 100644
--- a/connect.c
+++ b/connect.c
@@ -231,6 +231,7 @@ int server_supports(const char *feature)
}
enum protocol {
+ PROTO_LOCAL_OR_SSH = 0,
PROTO_LOCAL = 1,
PROTO_SSH,
PROTO_GIT
@@ -547,6 +548,15 @@ static char *get_port(char *host)
static struct child_process no_fork;
+int is_local(const char *url)
+{
+ const char *colon = strchr(url, ':');
+ const char *slash = strchr(url, '/');
+ return !colon || (slash slash colon) ||
+ has_dos_drive_prefix(url);
+}
+
+
/*
* This returns a dummy child_process if the transport protocol does not
* need fork(2), or a struct child_process object if it does. Once done,
@@ -564,9 +574,9 @@ struct child_process *git_connect(int fd[2], const char
*url_orig,
char *url;
char *host, *path;
char *end;
- int c;
+ int separator;
struct child_process *conn = no_fork;
- enum protocol protocol = PROTO_LOCAL;
+ enum protocol protocol = PROTO_LOCAL_OR_SSH;
int free_path = 0;
char *port = NULL;
const char **arg;
@@ -587,20 +597,23 @@ struct child_process *git_connect(int fd[2], const char
*url_orig,
*host = '\0';
protocol = get_protocol(url);
host += 3;
- c = '/';
+ separator = '/';
} else {
host = url;
- c = ':';
+ separator = ':';
+ if (is_local(url))
+ protocol = PROTO_LOCAL;
}
/*
* Don't do destructive transforms with git:// as that
* protocol code does '[]' unwrapping of its own.
+* Don't change local URLs
*/
if (host[0] == '[') {
end = strchr(host + 1, ']');
if (end) {
- if (protocol != PROTO_GIT) {
+ if (protocol != PROTO_GIT protocol != PROTO_LOCAL) {
*end = 0;
host++;
}
@@ -610,17 +623,17 @@ struct child_process *git_connect(int fd[2], const char
*url_orig,
} else
end = host;
- path = strchr(end, c);
- if (path !has_dos_drive_prefix(end)) {
- if (c == ':') {
- if (host != url || path strchrnul(host, '/')) {
- protocol = PROTO_SSH;
- *path++ = '\0';
- } else /* '/' in the host part, assume local path */
- path = end;
+ path = strchr(end, separator);
+ if (separator == ':') {
+ if (path protocol == PROTO_LOCAL_OR_SSH) {
+ /* We have a ':' */
+ protocol = PROTO_SSH;
+ *path++ = '\0';
+ } else {/* assume local path */
+ protocol
Re: collapsing old git history to reduce repo size, while preserving commit #s and tags
Hi, I have an old git repo with e.g. 1000 commits, that grew up to considerable size. Now, I am starting a new project and want to use this repo, but slimmed down. I'd like to clone the repo to the new project and slim it down I'd like to collapse 900 first commits into one, but keep last 100, with their commit numbers and tags. I also want to be able to push and merge changes from the old repo to the new one. I've read about git rebase, but it seems to tamper with commit numbers and looses tags.. Is there any other way to have it done ? thanks!! -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: collapsing old git history to reduce repo size, while preserving commit #s and tags
On 29 October 2013 15:42, Stas Cherkassky scher...@gmail.com wrote: I'd like to clone the repo to the new project and slim it down I'd like to collapse 900 first commits into one, but keep last 100, with their commit numbers and tags. I also want to be able to push and merge changes from the old repo to the new one. If you want to change the actual history of your repository, it will be largely incompatible with the original, and this is by design. You don't want somebody being able to change your history without you knowing about it. I've read about git rebase, but it seems to tamper with commit numbers and looses tags.. Is there any other way to have it done ? It sounds like a shallow checkout might be appropriate for you, try looking that up. Regards, Andrew Ardill -- 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 1/7] gitk: support -G option from the command line
Thomas Rast t...@thomasrast.ch writes:
From: Thomas Rast tr...@inf.ethz.ch
The -G option's usage is exactly analogous to that of -S, so
supporting it is easy.
Signed-off-by: Thomas Rast tr...@inf.ethz.ch
---
gitk-git/gitk | 2 +-
You CC'ed Paul, which is absolutely the right thing to do, but
please make patches against his tree, which does not have gitk-git/
directory at the top-level.
I think the patch itself makes sense.
Thanks.
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/gitk-git/gitk b/gitk-git/gitk
index 5cd00d8..0e95814 100755
--- a/gitk-git/gitk
+++ b/gitk-git/gitk
@@ -227,7 +227,7 @@ proc parseviewargs {n arglist} {
--until=* - --before=* - --max-age=* - --min-age=* -
--author=* - --committer=* - --grep=* - -[iE] -
--remove-empty - --first-parent - --cherry-pick -
- -S* - --pickaxe-all - --pickaxe-regex -
+ -S* - -G* - --pickaxe-all - --pickaxe-regex -
--simplify-by-decoration {
# These mean that we get a subset of the commits
set filtered 1
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 6/7] Documentation: put blame/log -L in sticked form
Thomas Rast t...@thomasrast.ch writes:
The next patch will document gitk -L, but gitk does not understand the
separated form ('gitk -L :foo:bar' results in an error). Spell
git-blame and git-log -L, which are supposed to be the same option,
without the spaces to prevent confusion.
I agree that this patch may reduce confusion locally, but if we were
to go in this direction, we should be consistent and enforce stuck
form everywhere, not just the options you happened to have passed
thru to gitk, but other options such as -S revs-file, and also
other commands that do not have anything to do with gitk (e.g. git
commit -Ccommit, not git commit -C commit. Otherwise you
will give a wrong impression to readers as if they have to remember
which ones need to use the stuck form and which ones do not.
Signed-off-by: Thomas Rast t...@thomasrast.ch
---
Documentation/blame-options.txt | 8
Documentation/git-blame.txt | 8
Documentation/git-log.txt | 6 +++---
3 files changed, 11 insertions(+), 11 deletions(-)
diff --git a/Documentation/blame-options.txt b/Documentation/blame-options.txt
index 0cebc4f..28ca95e 100644
--- a/Documentation/blame-options.txt
+++ b/Documentation/blame-options.txt
@@ -9,13 +9,13 @@
--show-stats::
Include additional statistics at the end of blame output.
--L start,end::
--L :regex::
+-Lstart,end::
+-L:regex::
Annotate only the given line range. May be specified multiple times.
Overlapping ranges are allowed.
+
-start and end are optional. ``-L start'' or ``-L start,'' spans from
-start to end of file. ``-L ,end'' spans from start of file to end.
+start and end are optional. ``-Lstart'' or ``-Lstart,'' spans from
+start to end of file. ``-L,end'' spans from start of file to end.
+
include::line-range-format.txt[]
diff --git a/Documentation/git-blame.txt b/Documentation/git-blame.txt
index f2c85cc..085dba1 100644
--- a/Documentation/git-blame.txt
+++ b/Documentation/git-blame.txt
@@ -9,7 +9,7 @@ SYNOPSIS
[verse]
'git blame' [-c] [-b] [-l] [--root] [-t] [-f] [-n] [-s] [-e] [-p] [-w]
[--incremental]
- [-L range] [-S revs-file] [-M] [-C] [-C] [-C] [--since=date]
+ [-Lrange] [-S revs-file] [-M] [-C] [-C] [-C] [--since=date]
[--abbrev=n] [rev | --contents file | --reverse rev] [--]
file
DESCRIPTION
@@ -139,12 +139,12 @@ lines 40-60 for file `foo`, you can use the `-L` option
like so
(they mean the same thing -- both ask for 21 lines starting at
line 40):
- git blame -L 40,60 foo
- git blame -L 40,+21 foo
+ git blame -L40,60 foo
+ git blame -L40,+21 foo
Also you can use a regular expression to specify the line range:
- git blame -L '/^sub hello {/,/^}$/' foo
+ git blame -L'/^sub hello {/,/^}$/' foo
which limits the annotation to the body of the `hello` subroutine.
diff --git a/Documentation/git-log.txt b/Documentation/git-log.txt
index 34097ef..87c10fa 100644
--- a/Documentation/git-log.txt
+++ b/Documentation/git-log.txt
@@ -62,8 +62,8 @@ produced by --stat etc.
Note that only message is considered, if also a diff is shown
its size is not included.
--L start,end:file::
--L :regex:file::
+-Lstart,end:file::
+-L:regex:file::
Trace the evolution of the line range given by start,end
(or the funcname regex regex) within the file. You may
@@ -152,7 +152,7 @@ EXAMPLES
This makes sense only when following a strict policy of merging all
topic branches when staying on a single integration branch.
-`git log -L '/int main/',/^}/:main.c`::
+`git log -L'/int main/',/^}/:main.c`::
Shows how the function `main()` in the file 'main.c' evolved
over time.
--
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 v1.8.4.2 test failure in ./t5570-git-daemon.sh
Jeff King p...@peff.net writes: On Tue, Oct 29, 2013 at 01:54:31AM +0100, Simon Ruderich wrote: I just compiled Git v1.8.4.2 on Debian Wheezy amd64 and test t5570 fails (with GIT_TEST_GIT_DAEMON=1): [...] Bisecting leads to this commit: commit 68b939b2f097b6675c4aaa17869aa81b25cb Author: Jeff King p...@peff.net Date: Wed Sep 18 16:05:13 2013 -0400 clone: send diagnostic messages to stderr This is already fixed by Brian Gernhardt's 360a326 (t5570: Update for clone-progress-to-stderr branch, 2013-10-21). Junio, that patch seems to have gone onto jc/upload-pack-send-symref, but should have gone onto jk/clone-progress-to-stderr. The latter made it into maint for v1.8.4.2, but the former did not. I think it was just a simple mixup caused by Brian sending two fixups to t5570 as series, when they are really fixups for two different topics. Not worth an immediate v1.8.4.3, I think, but you may want to cherry-pick 360a326 onto maint if there is another release before v1.8.5. I am torn on this, actually. I've been hoping that the other topic that fixes a long-standing bug will also be a part of maintenance track. -- 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 10/15] fetch --tags: fetch tags *in addition to* other stuff
On 10/28/2013 08:10 PM, Junio C Hamano wrote: Michael Haggerty mhag...@alum.mit.edu writes: True but when fetching other references, tags relevant to the history being fetched by default should automatically follow, so the above explains why fetch --tags is not a useful thing to do daily. Maybe not necessary in many scenarios, but is it harmful for the common case of cloning from and then periodically fetching from an upstream? There is no mention of harmful; I only said not useful. And it comes primarily from knowing why --tags was introduced in the first place; I should have said less useful than before, ever since we started to reliably auto-follow. The only harmful part is its interaction with --prune, which your series nicely addresses. OK, then we are in agreement. ISTM that the result of the declarative --tags option we have all upstream tags is easier to reason about than the history-dependent tag-following behavior I'd say we have all the relevant tags and we have all the tags the other side has are equally valid things to wish for, depending who you are and how your project is organized, and one is not necessarily easy/useful than the other. In case it was unclear, I was not seriously advocating to deprecate/remove --tags. Yes, I agree that both are valid things to wish for. I guess I was mostly thinking about which would be a better default. clone and remote add, by default, configure the repo to fetch all branches on the remote. For this default setup, what are the pros and cons of the two tag-fetching options (assuming that this patch series has fixed the problem with tag pruning)? Pros of auto-following: * Doesn't require a change to the status quo * The the user can change the refspec to be more restrictive without having to change the tag-following option and it continues to do the right thing. * If the project has branches outside of refs/heads (which would not, by default, be fetched--think continuous integration artifacts) and also has tags pointing at those branches, the user might get unwanted contents with --tags, but not with auto-following. Pros of --tags: * Easier to understand (?) because result is not history-dependent. * Avoids missing tags that are not directly on a branch: o---o---o---o- branch \ o - tag So it's not obvious that one is better than the other. I think if I were choosing the behavior for the first time, I would favor --tags. But I don't think the advantage is strong enough to make it worth changing the existing default. Regarding your first point: if it matters which of the duplicates is chosen, then it can only matter because they differ in some other way than their reference names, for example in their flags. So a robust way of de-duping them (if it is possible) would be to compare the two records and decide which one should take precedence based on this other information rather than based on which one happened to come earlier in the list. Then the list order would be immaterial and (for example) it wouldn't be a problem to reorder the items. But that changes the behaviour to those who has cared to rely on the ordering. With the change to first collect and then sort unstably before deduping, the series already tells them not to rely on the order, and two of us tentatively agreed in this discussion that it is not likely to matter. If later this agreement turns out to be a mistake and there are people who *do* rely on the ordering, the only acceptable fix for them is by making sure we restore the first one trumps semantics, not by defining an alternative, arguably better, behaviour---that is not a regression fix. Please note that the current patch series does *not* change the algorithm to use an unstable sort; that was only a suggestion for the future should somebody discover that the O(N^2) algorithm in this function is a performance bottleneck. What the old patch series *did* do was change the ordering that get_ref_map() adds references to the list in the case of (refspec_count tags == TAGS_SET) by moving the (tags == TAGS_SET) handling outside of the true branch of the (refspec_count) conditional. This had the result that the references added by get_fetch_map(remote_refs, tag_refspec, tail, 0); came after, rather than before, the references opportunistically being fetched with FETCH_HEAD_IGNORE status. But I dug even deeper and found that there was a (rather obscure) situation where the ordering change could lead to incorrect behavior, namely if all of the following are true: * there is a configured refspec for tags, like refs/tags/*:refs/tags/* * the user runs fetch with the --tags option and also with an explicit refspec on the command line to fetch a remote tag (e.g., refs/tags/foo:refs/heads/foo). In that case (after this version of this patch), an entry for refs/tags/foo:refs/heads/foo would be added to the list, then the
[PATCH v2 00/23] Change semantics of fetch --tags
This is v2 of my proposed fix for the local tag killer problem that I reported recently [1]. Thanks a lot to Junio for his feedback on v1. Changes since v1: * Rebase to current upstream master (0d6cf2471f); no conflicts were encountered. * Incorporate feedback from Junio: * Improve the documentation as suggested * Fix a few typos * Document get_expanded_map() and fix a minor memory leak that I found there. * get_ref_map(): Do not look for references that can be updated opportunistically among the entries added by --tags. Preserve the order of output list when changing the function to handle the new --tags semantics. (I know more about how the output is used and am less worried now that the changes will have bad interactions with the rest of the system.) * Improve the description of tag-following in the git fetch manpage. * Moved the changes to ref_remove_duplicates() later in the series, as they were not really integral to the rest of the patch series. Make the following changes to that function: * Add tests of how it handles duplicates. * Simplify the loop in a different way than v1, to make it more modular. * Extract a function to handle duplicates. * Improve the error messages emitted if ref_remove_duplicates() finds conflicting duplicates, and mark the messages for translation. * Do not die() if a user-specified refspec conflicts with an opportunistic update. [1] http://article.gmane.org/gmane.comp.version-control.git/234723 Michael Haggerty (23): t5510: use the correct tag name in test t5510: prepare test refs more straightforwardly t5510: check that git fetch --prune --tags does not prune branches api-remote.txt: correct section struct refspec get_ref_map(): rename local variables builtin/fetch.c: reorder function definitions get_expanded_map(): add docstring get_expanded_map(): avoid memory leak fetch: only opportunistically update references based on command line fetch --tags: fetch tags *in addition to* other stuff fetch --prune: prune only based on explicit refspecs query_refspecs(): move some constants out of the loop builtin/remote.c: reorder function definitions builtin/remote.c:update(): use struct argv_array fetch, remote: properly convey --no-prune options to subprocesses fetch-options.txt: simplify ifdef/ifndef/endif usage git-fetch.txt: improve description of tag auto-following ref_remove_duplicates(): avoid redundant bisection t5536: new test of refspec conflicts when fetching ref_remove_duplicates(): simplify loop logic ref_remote_duplicates(): extract a function handle_duplicate() handle_duplicate(): mark error message for translation fetch: improve the error messages emitted for conflicting refspecs Documentation/config.txt | 4 +- Documentation/fetch-options.txt | 26 +-- Documentation/git-fetch.txt | 14 +- Documentation/technical/api-remote.txt | 20 +-- builtin/fetch.c | 298 --- builtin/remote.c | 196 ++-- git-pull.sh | 2 +- remote.c | 94 +++--- remote.h | 8 +- t/t5510-fetch.sh | 36 +++- t/t5515/fetch.br-unconfig_--tags_.._.git | 1 + t/t5515/fetch.master_--tags_.._.git | 1 + t/t5525-fetch-tagopt.sh | 23 ++- t/t5536-fetch-conflicts.sh | 100 +++ 14 files changed, 503 insertions(+), 320 deletions(-) create mode 100755 t/t5536-fetch-conflicts.sh -- 1.8.4.1 -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 04/23] api-remote.txt: correct section struct refspec
* Replace reference to function parse_ref_spec() with references to functions parse_fetch_refspec() and parse_push_refspec(). * Correct description of src and dst: they *do* include the '*' characters. Signed-off-by: Michael Haggerty mhag...@alum.mit.edu --- Documentation/technical/api-remote.txt | 20 ++-- 1 file changed, 10 insertions(+), 10 deletions(-) diff --git a/Documentation/technical/api-remote.txt b/Documentation/technical/api-remote.txt index 4be8776..5d245aa 100644 --- a/Documentation/technical/api-remote.txt +++ b/Documentation/technical/api-remote.txt @@ -58,16 +58,16 @@ default remote, given the current branch and configuration. struct refspec -- -A struct refspec holds the parsed interpretation of a refspec. If it -will force updates (starts with a '+'), force is true. If it is a -pattern (sides end with '*') pattern is true. src and dest are the two -sides (if a pattern, only the part outside of the wildcards); if there -is only one side, it is src, and dst is NULL; if sides exist but are -empty (i.e., the refspec either starts or ends with ':'), the -corresponding side is . - -This parsing can be done to an array of strings to give an array of -struct refpsecs with parse_ref_spec(). +A struct refspec holds the parsed interpretation of a refspec. If it +will force updates (starts with a '+'), force is true. If it is a +pattern (sides end with '*') pattern is true. src and dest are the +two sides (including '*' characters if present); if there is only one +side, it is src, and dst is NULL; if sides exist but are empty (i.e., +the refspec either starts or ends with ':'), the corresponding side is +. + +An array of strings can be parsed into an array of struct refspecs +using parse_fetch_refspec() or parse_push_refspec(). remote_find_tracking(), given a remote and a struct refspec with either src or dst filled out, will fill out the other such that the -- 1.8.4.1 -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 15/23] fetch, remote: properly convey --no-prune options to subprocesses
If --no-prune is passed to one of the following commands:
git fetch --all
git fetch --multiple
git fetch --recurse-submodules
git remote update
then it must also be passed to the fetch subprocesses that those
commands use to do their work. Otherwise there might be a fetch.prune
or remote.name.prune configuration setting that causes pruning to
occur, contrary to the user's express wish.
Signed-off-by: Michael Haggerty mhag...@alum.mit.edu
---
builtin/fetch.c | 4 ++--
builtin/remote.c | 6 +++---
2 files changed, 5 insertions(+), 5 deletions(-)
diff --git a/builtin/fetch.c b/builtin/fetch.c
index 1514b90..5ddb9af 100644
--- a/builtin/fetch.c
+++ b/builtin/fetch.c
@@ -936,8 +936,8 @@ static void add_options_to_argv(struct argv_array *argv)
{
if (dry_run)
argv_array_push(argv, --dry-run);
- if (prune 0)
- argv_array_push(argv, --prune);
+ if (prune != -1)
+ argv_array_push(argv, prune ? --prune : --no-prune);
if (update_head_ok)
argv_array_push(argv, --update-head-ok);
if (force)
diff --git a/builtin/remote.c b/builtin/remote.c
index bffe2f9..f532f35 100644
--- a/builtin/remote.c
+++ b/builtin/remote.c
@@ -1371,7 +1371,7 @@ static int get_remote_default(const char *key, const char
*value, void *priv)
static int update(int argc, const char **argv)
{
- int i, prune = 0;
+ int i, prune = -1;
struct option options[] = {
OPT_BOOL('p', prune, prune,
N_(prune remotes after fetching)),
@@ -1386,8 +1386,8 @@ static int update(int argc, const char **argv)
argv_array_push(fetch_argv, fetch);
- if (prune)
- argv_array_push(fetch_argv, --prune);
+ if (prune != -1)
+ argv_array_push(fetch_argv, prune ? --prune : --no-prune);
if (verbose)
argv_array_push(fetch_argv, -v);
argv_array_push(fetch_argv, --multiple);
--
1.8.4.1
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 07/23] get_expanded_map(): add docstring
Signed-off-by: Michael Haggerty mhag...@alum.mit.edu
---
remote.c | 7 +++
1 file changed, 7 insertions(+)
diff --git a/remote.c b/remote.c
index 9f1a8aa..0d082cd 100644
--- a/remote.c
+++ b/remote.c
@@ -1553,6 +1553,13 @@ static int ignore_symref_update(const char *refname)
return (flag REF_ISSYMREF);
}
+/*
+ * Create and return a list of (struct ref) consisting of copies of
+ * each remote_ref that matches refspec. refspec must be a pattern.
+ * Fill in the copies' peer_ref to describe the local tracking refs to
+ * which they map. Omit any references that would map to an existing
+ * local symbolic ref.
+ */
static struct ref *get_expanded_map(const struct ref *remote_refs,
const struct refspec *refspec)
{
--
1.8.4.1
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 08/23] get_expanded_map(): avoid memory leak
The old code could leak *expn_name if match_name_with_pattern()
succeeded but ignore_symref_update() returned true. So make sure that
*expn_name is freed in any case.
Signed-off-by: Michael Haggerty mhag...@alum.mit.edu
---
remote.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/remote.c b/remote.c
index 0d082cd..e42daa8 100644
--- a/remote.c
+++ b/remote.c
@@ -1567,9 +1567,9 @@ static struct ref *get_expanded_map(const struct ref
*remote_refs,
struct ref *ret = NULL;
struct ref **tail = ret;
- char *expn_name;
-
for (ref = remote_refs; ref; ref = ref-next) {
+ char *expn_name = NULL;
+
if (strchr(ref-name, '^'))
continue; /* a dereference item */
if (match_name_with_pattern(refspec-src, ref-name,
@@ -1578,12 +1578,12 @@ static struct ref *get_expanded_map(const struct ref
*remote_refs,
struct ref *cpy = copy_ref(ref);
cpy-peer_ref = alloc_ref(expn_name);
- free(expn_name);
if (refspec-force)
cpy-peer_ref-force = 1;
*tail = cpy;
tail = cpy-next;
}
+ free(expn_name);
}
return ret;
--
1.8.4.1
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 01/23] t5510: use the correct tag name in test
Fix an apparent copy-paste error: A few lines earlier, a tag refs/tags/sometag is created. Check for the (non-)existence of that tag, not somebranch, which is otherwise never mentioned in the script. Signed-off-by: Michael Haggerty mhag...@alum.mit.edu --- t/t5510-fetch.sh | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/t/t5510-fetch.sh b/t/t5510-fetch.sh index 1f0f8e6..c5e5dfc 100755 --- a/t/t5510-fetch.sh +++ b/t/t5510-fetch.sh @@ -121,7 +121,7 @@ test_expect_success 'fetch --prune --tags does not delete the remote-tracking br git fetch --prune --tags origin git rev-parse origin/master - test_must_fail git rev-parse somebranch + test_must_fail git rev-parse sometag ' test_expect_success 'fetch --prune --tags with branch does not delete other remote-tracking branches' ' -- 1.8.4.1 -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 05/23] get_ref_map(): rename local variables
Rename refs - refspecs and ref_count - refspec_count to
reduce confusion, because they describe an array of struct refspec,
as opposed to the struct ref objects that are also used in this
function.
Signed-off-by: Michael Haggerty mhag...@alum.mit.edu
---
builtin/fetch.c | 12 ++--
1 file changed, 6 insertions(+), 6 deletions(-)
diff --git a/builtin/fetch.c b/builtin/fetch.c
index bd7a101..2248abf 100644
--- a/builtin/fetch.c
+++ b/builtin/fetch.c
@@ -165,8 +165,8 @@ static void find_non_local_tags(struct transport *transport,
struct ref ***tail);
static struct ref *get_ref_map(struct transport *transport,
- struct refspec *refs, int ref_count, int tags,
- int *autotags)
+ struct refspec *refspecs, int refspec_count,
+ int tags, int *autotags)
{
int i;
struct ref *rm;
@@ -175,12 +175,12 @@ static struct ref *get_ref_map(struct transport
*transport,
const struct ref *remote_refs = transport_get_remote_refs(transport);
- if (ref_count || tags == TAGS_SET) {
+ if (refspec_count || tags == TAGS_SET) {
struct ref **old_tail;
- for (i = 0; i ref_count; i++) {
- get_fetch_map(remote_refs, refs[i], tail, 0);
- if (refs[i].dst refs[i].dst[0])
+ for (i = 0; i refspec_count; i++) {
+ get_fetch_map(remote_refs, refspecs[i], tail, 0);
+ if (refspecs[i].dst refspecs[i].dst[0])
*autotags = 1;
}
/* Merge everything on the command line, but not --tags */
--
1.8.4.1
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 10/23] fetch --tags: fetch tags *in addition to* other stuff
Previously, fetch's --tags option was considered equivalent to
specifying the refspec refs/tags/*:refs/tags/* on the command line;
in particular, it caused the remote.name.refspec configuration to be
ignored.
But it is not very useful to fetch tags without also fetching other
references, whereas it *is* quite useful to be able to fetch tags *in
addition to* other references. So change the semantics of this option
to do the latter.
If a user wants to fetch *only* tags, then it is still possible to
specifying an explicit refspec:
git fetch remote 'refs/tags/*:refs/tags/*'
Please note that the documentation prior to 1.8.0.3 was ambiguous
about this aspect of fetch --tags behavior. Commit
f0cb2f137c 2012-12-14 fetch --tags: clarify documentation
made the documentation match the old behavior. This commit changes
the documentation to match the new behavior.
Signed-off-by: Michael Haggerty mhag...@alum.mit.edu
---
Documentation/fetch-options.txt | 8 ++---
builtin/fetch.c | 59 +++-
git-pull.sh | 2 +-
t/t5510-fetch.sh | 22 ++--
t/t5515/fetch.br-unconfig_--tags_.._.git | 1 +
t/t5515/fetch.master_--tags_.._.git | 1 +
t/t5525-fetch-tagopt.sh | 23 ++---
7 files changed, 78 insertions(+), 38 deletions(-)
diff --git a/Documentation/fetch-options.txt b/Documentation/fetch-options.txt
index ba1fe49..921f6be 100644
--- a/Documentation/fetch-options.txt
+++ b/Documentation/fetch-options.txt
@@ -61,11 +61,9 @@ endif::git-pull[]
ifndef::git-pull[]
-t::
--tags::
- This is a short-hand for giving `refs/tags/*:refs/tags/*`
- refspec from the command line, to ask all tags to be fetched
- and stored locally. Because this acts as an explicit
- refspec, the default refspecs (configured with the
- remote.$name.fetch variable) are overridden and not used.
+ Request that all tags be fetched from the remote in addition
+ to whatever else is being fetched. Its effect is similar to
+ that of the refspec `refs/tags/*:refs/tags/*`.
--recurse-submodules[=yes|on-demand|no]::
This option controls if and under what conditions new commits of
diff --git a/builtin/fetch.c b/builtin/fetch.c
index 0849f09..887fa3e 100644
--- a/builtin/fetch.c
+++ b/builtin/fetch.c
@@ -269,12 +269,12 @@ static struct ref *get_ref_map(struct transport
*transport,
struct ref *ref_map = NULL;
struct ref **tail = ref_map;
- const struct ref *remote_refs = transport_get_remote_refs(transport);
+ /* opportunistically-updated references: */
+ struct ref *orefs = NULL, **oref_tail = orefs;
- if (refspec_count || tags == TAGS_SET) {
- /* opportunistically-updated references: */
- struct ref *orefs = NULL, **oref_tail = orefs;
+ const struct ref *remote_refs = transport_get_remote_refs(transport);
+ if (refspec_count) {
for (i = 0; i refspec_count; i++) {
get_fetch_map(remote_refs, refspecs[i], tail, 0);
if (refspecs[i].dst refspecs[i].dst[0])
@@ -310,12 +310,6 @@ static struct ref *get_ref_map(struct transport *transport,
if (tags == TAGS_SET)
get_fetch_map(remote_refs, tag_refspec, tail, 0);
-
- *tail = orefs;
- for (rm = orefs; rm; rm = rm-next) {
- rm-fetch_head_status = FETCH_HEAD_IGNORE;
- tail = rm-next;
- }
} else {
/* Use the defaults */
struct remote *remote = transport-remote;
@@ -353,9 +347,19 @@ static struct ref *get_ref_map(struct transport *transport,
}
}
- if (tags == TAGS_DEFAULT *autotags)
+ if (tags == TAGS_SET)
+ /* also fetch all tags */
+ get_fetch_map(remote_refs, tag_refspec, tail, 0);
+ else if (tags == TAGS_DEFAULT *autotags)
find_non_local_tags(transport, ref_map, tail);
+ /* Now append any refs to be updated opportunistically: */
+ *tail = orefs;
+ for (rm = orefs; rm; rm = rm-next) {
+ rm-fetch_head_status = FETCH_HEAD_IGNORE;
+ tail = rm-next;
+ }
+
ref_remove_duplicates(ref_map);
return ref_map;
@@ -846,31 +850,38 @@ static int do_fetch(struct transport *transport,
goto cleanup;
}
if (prune) {
- /*
-* If --tags was specified, pretend that the user gave us
-* the canonical tags refspec
-*/
+ struct refspec *prune_refspecs;
+ int prune_refspec_count;
+
+ if (ref_count) {
+ prune_refspecs = refs;
+ prune_refspec_count = ref_count;
+ } else {
[PATCH v2 02/23] t5510: prepare test refs more straightforwardly
git fetch was being used with contrived refspecs to create tags and remote-tracking branches in test repositories in preparation for the actual tests. This is obscure and also makes one wonder whether this is indeed just preparation or whether some side-effect of git fetch is being tested. So use the more straightforward commands git tag / git update-ref when preparing branches in test repositories. Signed-off-by: Michael Haggerty mhag...@alum.mit.edu --- t/t5510-fetch.sh | 8 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/t/t5510-fetch.sh b/t/t5510-fetch.sh index c5e5dfc..08d8dbb 100755 --- a/t/t5510-fetch.sh +++ b/t/t5510-fetch.sh @@ -88,7 +88,7 @@ test_expect_success 'fetch --prune on its own works as expected' ' cd $D git clone . prune cd prune - git fetch origin refs/heads/master:refs/remotes/origin/extrabranch + git update-ref refs/remotes/origin/extrabranch master git fetch --prune origin test_must_fail git rev-parse origin/extrabranch @@ -98,7 +98,7 @@ test_expect_success 'fetch --prune with a branch name keeps branches' ' cd $D git clone . prune-branch cd prune-branch - git fetch origin refs/heads/master:refs/remotes/origin/extrabranch + git update-ref refs/remotes/origin/extrabranch master git fetch --prune origin master git rev-parse origin/extrabranch @@ -117,7 +117,7 @@ test_expect_success 'fetch --prune --tags does not delete the remote-tracking br cd $D git clone . prune-tags cd prune-tags - git fetch origin refs/heads/master:refs/tags/sometag + git tag sometag master git fetch --prune --tags origin git rev-parse origin/master @@ -128,7 +128,7 @@ test_expect_success 'fetch --prune --tags with branch does not delete other remo cd $D git clone . prune-tags-branch cd prune-tags-branch - git fetch origin refs/heads/master:refs/remotes/origin/extrabranch + git update-ref refs/remotes/origin/extrabranch master git fetch --prune --tags origin master git rev-parse origin/extrabranch -- 1.8.4.1 -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 03/23] t5510: check that git fetch --prune --tags does not prune branches
git fetch --prune --tags is currently interpreted as follows: * --tags is equivalent to specifying a refspec refs/tags/*:refs/tags/*, and supersedes any default refspecs configured via remote.$REMOTE.fetch. * --prune only operates on the refspecs being fetched. Therefore, git fetch --prune --tags prunes tags in refs/tags/* but does not fetch or prune other references. The fact that this command does not prune references outside of refs/tags/* was previously untested. So add a test that verifies the status quo. However, the status quo is surprising, so it will be changed later in this patch series. Signed-off-by: Michael Haggerty mhag...@alum.mit.edu --- t/t5510-fetch.sh | 4 1 file changed, 4 insertions(+) diff --git a/t/t5510-fetch.sh b/t/t5510-fetch.sh index 08d8dbb..8328be1 100755 --- a/t/t5510-fetch.sh +++ b/t/t5510-fetch.sh @@ -118,9 +118,13 @@ test_expect_success 'fetch --prune --tags does not delete the remote-tracking br git clone . prune-tags cd prune-tags git tag sometag master + # Create what looks like a remote-tracking branch from an earlier + # fetch that has since been deleted from the remote: + git update-ref refs/remotes/origin/fake-remote master git fetch --prune --tags origin git rev-parse origin/master + git rev-parse origin/fake-remote test_must_fail git rev-parse sometag ' -- 1.8.4.1 -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 06/23] builtin/fetch.c: reorder function definitions
Reorder function definitions to avoid the need for a forward
declaration of function find_non_local_tags().
Signed-off-by: Michael Haggerty mhag...@alum.mit.edu
---
builtin/fetch.c | 198 +++-
1 file changed, 97 insertions(+), 101 deletions(-)
diff --git a/builtin/fetch.c b/builtin/fetch.c
index 2248abf..61e8117 100644
--- a/builtin/fetch.c
+++ b/builtin/fetch.c
@@ -160,9 +160,105 @@ static void add_merge_config(struct ref **head,
}
}
+static int add_existing(const char *refname, const unsigned char *sha1,
+ int flag, void *cbdata)
+{
+ struct string_list *list = (struct string_list *)cbdata;
+ struct string_list_item *item = string_list_insert(list, refname);
+ item-util = xmalloc(20);
+ hashcpy(item-util, sha1);
+ return 0;
+}
+
+static int will_fetch(struct ref **head, const unsigned char *sha1)
+{
+ struct ref *rm = *head;
+ while (rm) {
+ if (!hashcmp(rm-old_sha1, sha1))
+ return 1;
+ rm = rm-next;
+ }
+ return 0;
+}
+
static void find_non_local_tags(struct transport *transport,
struct ref **head,
- struct ref ***tail);
+ struct ref ***tail)
+{
+ struct string_list existing_refs = STRING_LIST_INIT_DUP;
+ struct string_list remote_refs = STRING_LIST_INIT_NODUP;
+ const struct ref *ref;
+ struct string_list_item *item = NULL;
+
+ for_each_ref(add_existing, existing_refs);
+ for (ref = transport_get_remote_refs(transport); ref; ref = ref-next) {
+ if (prefixcmp(ref-name, refs/tags/))
+ continue;
+
+ /*
+* The peeled ref always follows the matching base
+* ref, so if we see a peeled ref that we don't want
+* to fetch then we can mark the ref entry in the list
+* as one to ignore by setting util to NULL.
+*/
+ if (!suffixcmp(ref-name, ^{})) {
+ if (item !has_sha1_file(ref-old_sha1)
+ !will_fetch(head, ref-old_sha1)
+ !has_sha1_file(item-util)
+ !will_fetch(head, item-util))
+ item-util = NULL;
+ item = NULL;
+ continue;
+ }
+
+ /*
+* If item is non-NULL here, then we previously saw a
+* ref not followed by a peeled reference, so we need
+* to check if it is a lightweight tag that we want to
+* fetch.
+*/
+ if (item !has_sha1_file(item-util)
+ !will_fetch(head, item-util))
+ item-util = NULL;
+
+ item = NULL;
+
+ /* skip duplicates and refs that we already have */
+ if (string_list_has_string(remote_refs, ref-name) ||
+ string_list_has_string(existing_refs, ref-name))
+ continue;
+
+ item = string_list_insert(remote_refs, ref-name);
+ item-util = (void *)ref-old_sha1;
+ }
+ string_list_clear(existing_refs, 1);
+
+ /*
+* We may have a final lightweight tag that needs to be
+* checked to see if it needs fetching.
+*/
+ if (item !has_sha1_file(item-util)
+ !will_fetch(head, item-util))
+ item-util = NULL;
+
+ /*
+* For all the tags in the remote_refs string list,
+* add them to the list of refs to be fetched
+*/
+ for_each_string_list_item(item, remote_refs) {
+ /* Unless we have already decided to ignore this item... */
+ if (item-util)
+ {
+ struct ref *rm = alloc_ref(item-string);
+ rm-peer_ref = alloc_ref(item-string);
+ hashcpy(rm-old_sha1, item-util);
+ **tail = rm;
+ *tail = rm-next;
+ }
+ }
+
+ string_list_clear(remote_refs, 0);
+}
static struct ref *get_ref_map(struct transport *transport,
struct refspec *refspecs, int refspec_count,
@@ -612,106 +708,6 @@ static int prune_refs(struct refspec *refs, int
ref_count, struct ref *ref_map)
return result;
}
-static int add_existing(const char *refname, const unsigned char *sha1,
- int flag, void *cbdata)
-{
- struct string_list *list = (struct string_list *)cbdata;
- struct string_list_item *item = string_list_insert(list, refname);
- item-util = xmalloc(20);
- hashcpy(item-util, sha1);
- return 0;
-}
-
-static int will_fetch(struct ref **head, const unsigned char *sha1)
-{
- struct ref *rm =
[PATCH v2 18/23] ref_remove_duplicates(): avoid redundant bisection
The old code called string_list_lookup(), and if that failed called
string_list_insert(), thus doing the bisection search through the
string list twice in the latter code path.
Instead, just call string_list_insert() right away. If an entry for
that peer reference name already existed, then its util pointer is
always non-NULL.
Of course this doesn't change the fact that the repeated
string_list_insert() calls make the function scale like O(N^2) if the
input reference list is not already approximately sorted.
Signed-off-by: Michael Haggerty mhag...@alum.mit.edu
---
remote.c | 12 ++--
1 file changed, 6 insertions(+), 6 deletions(-)
diff --git a/remote.c b/remote.c
index a5e6c7f..15f3dc5 100644
--- a/remote.c
+++ b/remote.c
@@ -750,13 +750,15 @@ void ref_remove_duplicates(struct ref *ref_map)
struct string_list refs = STRING_LIST_INIT_NODUP;
struct string_list_item *item = NULL;
struct ref *prev = NULL, *next = NULL;
+
for (; ref_map; prev = ref_map, ref_map = next) {
next = ref_map-next;
if (!ref_map-peer_ref)
continue;
- item = string_list_lookup(refs, ref_map-peer_ref-name);
- if (item) {
+ item = string_list_insert(refs, ref_map-peer_ref-name);
+ if (item-util) {
+ /* Entry already existed */
if (strcmp(((struct ref *)item-util)-name,
ref_map-name))
die(%s tracks both %s and %s,
@@ -767,11 +769,9 @@ void ref_remove_duplicates(struct ref *ref_map)
free(ref_map-peer_ref);
free(ref_map);
ref_map = prev; /* skip this; we freed it */
- continue;
+ } else {
+ item-util = ref_map;
}
-
- item = string_list_insert(refs, ref_map-peer_ref-name);
- item-util = ref_map;
}
string_list_clear(refs, 0);
}
--
1.8.4.1
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 17/23] git-fetch.txt: improve description of tag auto-following
Make it clearer that tags are fetched independent of which branches were fetched from the remote in any particular fetch. (Tags are even fetched if they point at objects that are in the current repository but not reachable, which is probably a bug.) Put less emphasis on the mechanism and more on the effect of tag auto-following. Also mention the options and configuration settings that can change the tag-fetching behavior. Signed-off-by: Michael Haggerty mhag...@alum.mit.edu --- The probable bug mentioned above has been reported to the mailing list [1] but is not addressed in the current patch series. [1] http://article.gmane.org/gmane.comp.version-control.git/236829 Documentation/git-fetch.txt | 14 +++--- 1 file changed, 7 insertions(+), 7 deletions(-) diff --git a/Documentation/git-fetch.txt b/Documentation/git-fetch.txt index e08a028..1065713 100644 --- a/Documentation/git-fetch.txt +++ b/Documentation/git-fetch.txt @@ -24,13 +24,13 @@ The ref names and their object names of fetched refs are stored in `.git/FETCH_HEAD`. This information is left for a later merge operation done by 'git merge'. -When refspec stores the fetched result in remote-tracking branches, -the tags that point at these branches are automatically -followed. This is done by first fetching from the remote using -the given refspecs, and if the repository has objects that are -pointed by remote tags that it does not yet have, then fetch -those missing tags. If the other end has tags that point at -branches you are not interested in, you will not get them. +By default, tags are auto-followed. This means that when fetching +from a remote, any tags on the remote that point to objects that exist +in the local repository are fetched. The effect is to fetch tags that +point at branches that you are interested in. This default behavior +can be changed by using the --tags or --no-tags options, by +configuring remote.name.tagopt, or by using a refspec that fetches +tags explicitly. 'git fetch' can fetch from either a single named repository, or from several repositories at once if group is given and -- 1.8.4.1 -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 12/23] query_refspecs(): move some constants out of the loop
Signed-off-by: Michael Haggerty mhag...@alum.mit.edu
---
remote.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/remote.c b/remote.c
index e42daa8..a5e6c7f 100644
--- a/remote.c
+++ b/remote.c
@@ -825,6 +825,8 @@ static int query_refspecs(struct refspec *refs, int
ref_count, struct refspec *q
{
int i;
int find_src = !query-src;
+ const char *needle = find_src ? query-dst : query-src;
+ char **result = find_src ? query-src : query-dst;
if (find_src !query-dst)
return error(query_refspecs: need either src or dst);
@@ -833,8 +835,6 @@ static int query_refspecs(struct refspec *refs, int
ref_count, struct refspec *q
struct refspec *refspec = refs[i];
const char *key = find_src ? refspec-dst : refspec-src;
const char *value = find_src ? refspec-src : refspec-dst;
- const char *needle = find_src ? query-dst : query-src;
- char **result = find_src ? query-src : query-dst;
if (!refspec-dst)
continue;
--
1.8.4.1
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 16/23] fetch-options.txt: simplify ifdef/ifndef/endif usage
Signed-off-by: Michael Haggerty mhag...@alum.mit.edu --- Documentation/fetch-options.txt | 5 + 1 file changed, 1 insertion(+), 4 deletions(-) diff --git a/Documentation/fetch-options.txt b/Documentation/fetch-options.txt index 12b1d92..f0ef7d0 100644 --- a/Documentation/fetch-options.txt +++ b/Documentation/fetch-options.txt @@ -51,13 +51,10 @@ ifndef::git-pull[] subject to pruning. endif::git-pull[] -ifdef::git-pull[] ---no-tags:: -endif::git-pull[] ifndef::git-pull[] -n:: ---no-tags:: endif::git-pull[] +--no-tags:: By default, tags that point at objects that are downloaded from the remote repository are fetched and stored locally. This option disables this automatic tag following. The default -- 1.8.4.1 -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 14/23] builtin/remote.c:update(): use struct argv_array
Use struct argv_array for calling the git fetch subprocesses.
Signed-off-by: Michael Haggerty mhag...@alum.mit.edu
---
builtin/remote.c | 33 +
1 file changed, 17 insertions(+), 16 deletions(-)
diff --git a/builtin/remote.c b/builtin/remote.c
index ecedd96..bffe2f9 100644
--- a/builtin/remote.c
+++ b/builtin/remote.c
@@ -6,6 +6,7 @@
#include strbuf.h
#include run-command.h
#include refs.h
+#include argv-array.h
static const char * const builtin_remote_usage[] = {
N_(git remote [-v | --verbose]),
@@ -1376,36 +1377,36 @@ static int update(int argc, const char **argv)
N_(prune remotes after fetching)),
OPT_END()
};
- const char **fetch_argv;
- int fetch_argc = 0;
+ struct argv_array fetch_argv = ARGV_ARRAY_INIT;
int default_defined = 0;
-
- fetch_argv = xmalloc(sizeof(char *) * (argc+5));
+ int retval;
argc = parse_options(argc, argv, NULL, options,
builtin_remote_update_usage,
PARSE_OPT_KEEP_ARGV0);
- fetch_argv[fetch_argc++] = fetch;
+ argv_array_push(fetch_argv, fetch);
if (prune)
- fetch_argv[fetch_argc++] = --prune;
+ argv_array_push(fetch_argv, --prune);
if (verbose)
- fetch_argv[fetch_argc++] = -v;
- fetch_argv[fetch_argc++] = --multiple;
+ argv_array_push(fetch_argv, -v);
+ argv_array_push(fetch_argv, --multiple);
if (argc 2)
- fetch_argv[fetch_argc++] = default;
+ argv_array_push(fetch_argv, default);
for (i = 1; i argc; i++)
- fetch_argv[fetch_argc++] = argv[i];
+ argv_array_push(fetch_argv, argv[i]);
- if (strcmp(fetch_argv[fetch_argc-1], default) == 0) {
+ if (strcmp(fetch_argv.argv[fetch_argv.argc-1], default) == 0) {
git_config(get_remote_default, default_defined);
- if (!default_defined)
- fetch_argv[fetch_argc-1] = --all;
+ if (!default_defined) {
+ argv_array_pop(fetch_argv);
+ argv_array_push(fetch_argv, --all);
+ }
}
- fetch_argv[fetch_argc] = NULL;
-
- return run_command_v_opt(fetch_argv, RUN_GIT_CMD);
+ retval = run_command_v_opt(fetch_argv.argv, RUN_GIT_CMD);
+ argv_array_clear(fetch_argv);
+ return retval;
}
static int remove_all_fetch_refspecs(const char *remote, const char *key)
--
1.8.4.1
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 23/23] fetch: improve the error messages emitted for conflicting refspecs
If we find two refspecs that want to update the same local reference,
emit an error message that is more informative based on whether one of
the conflicting refspecs is an opportunistic update during a fetch
with explicit command-line refspecs. And especially, do not die if an
opportunistic reference update conflicts with an express wish of the
user; rather, just emit a warning and skip the opportunistic reference
update.
Signed-off-by: Michael Haggerty mhag...@alum.mit.edu
---
remote.c | 25 ++---
t/t5536-fetch-conflicts.sh | 14 +-
2 files changed, 31 insertions(+), 8 deletions(-)
diff --git a/remote.c b/remote.c
index 06a0eda..15e6e5e 100644
--- a/remote.c
+++ b/remote.c
@@ -747,9 +747,28 @@ int for_each_remote(each_remote_fn fn, void *priv)
static void handle_duplicate(struct ref *ref1, struct ref *ref2)
{
- if (strcmp(ref1-name, ref2-name))
- die(_(%s tracks both %s and %s),
- ref2-peer_ref-name, ref1-name, ref2-name);
+ if (strcmp(ref1-name, ref2-name)) {
+ if (ref1-fetch_head_status != FETCH_HEAD_IGNORE
+ ref2-fetch_head_status != FETCH_HEAD_IGNORE) {
+ die(_(Cannot fetch both %s and %s to %s),
+ ref1-name, ref2-name, ref2-peer_ref-name);
+ } else if (ref1-fetch_head_status != FETCH_HEAD_IGNORE
+ ref2-fetch_head_status == FETCH_HEAD_IGNORE) {
+ warning(_(%s usually tracks %s, not %s),
+ ref2-peer_ref-name, ref2-name, ref1-name);
+ } else if (ref1-fetch_head_status == FETCH_HEAD_IGNORE
+ ref2-fetch_head_status == FETCH_HEAD_IGNORE) {
+ die(_(%s tracks both %s and %s),
+ ref2-peer_ref-name, ref1-name, ref2-name);
+ } else {
+ /*
+* This last possibility doesn't occur because
+* FETCH_HEAD_IGNORE entries always appear at
+* the end of the list.
+*/
+ die(_(Internal error));
+ }
+ }
free(ref2-peer_ref);
free(ref2);
}
diff --git a/t/t5536-fetch-conflicts.sh b/t/t5536-fetch-conflicts.sh
index 679c53e..6c5d3a4 100755
--- a/t/t5536-fetch-conflicts.sh
+++ b/t/t5536-fetch-conflicts.sh
@@ -22,7 +22,7 @@ verify_stderr () {
cat expected
# We're not interested in the error
# fatal: The remote end hung up unexpectedly:
- grep -v hung up error actual
+ grep -E '^(fatal|warning):' error | grep -v 'hung up' actual | sort
test_cmp expected actual
}
@@ -49,7 +49,7 @@ test_expect_success 'fetch conflict: config vs. config' '
cd ccc
test_must_fail git fetch origin 2error
verify_stderr -\EOF
- fatal: refs/remotes/origin/branch1 tracks both
refs/heads/branch1 and refs/heads/branch2
+ fatal: Cannot fetch both refs/heads/branch1 and
refs/heads/branch2 to refs/remotes/origin/branch1
EOF
)
'
@@ -78,18 +78,22 @@ test_expect_success 'fetch conflict: arg vs. arg' '
refs/heads/*:refs/remotes/origin/* \
refs/heads/branch2:refs/remotes/origin/branch1 2error
verify_stderr -\EOF
- fatal: refs/remotes/origin/branch1 tracks both
refs/heads/branch1 and refs/heads/branch2
+ fatal: Cannot fetch both refs/heads/branch1 and
refs/heads/branch2 to refs/remotes/origin/branch1
EOF
)
'
-test_expect_failure 'fetch conflict: criss-cross args' '
+test_expect_success 'fetch conflict: criss-cross args' '
setup_repository xaa \
+refs/heads/*:refs/remotes/origin/* (
cd xaa
git fetch origin \
refs/heads/branch1:refs/remotes/origin/branch2 \
- refs/heads/branch2:refs/remotes/origin/branch1
+ refs/heads/branch2:refs/remotes/origin/branch1 2error
+ verify_stderr -\EOF
+ warning: refs/remotes/origin/branch1 usually tracks
refs/heads/branch1, not refs/heads/branch2
+ warning: refs/remotes/origin/branch2 usually tracks
refs/heads/branch2, not refs/heads/branch1
+ EOF
)
'
--
1.8.4.1
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 22/23] handle_duplicate(): mark error message for translation
Signed-off-by: Michael Haggerty mhag...@alum.mit.edu
---
remote.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/remote.c b/remote.c
index 2deb2db..06a0eda 100644
--- a/remote.c
+++ b/remote.c
@@ -748,7 +748,7 @@ int for_each_remote(each_remote_fn fn, void *priv)
static void handle_duplicate(struct ref *ref1, struct ref *ref2)
{
if (strcmp(ref1-name, ref2-name))
- die(%s tracks both %s and %s,
+ die(_(%s tracks both %s and %s),
ref2-peer_ref-name, ref1-name, ref2-name);
free(ref2-peer_ref);
free(ref2);
--
1.8.4.1
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 09/23] fetch: only opportunistically update references based on command line
The old code processed (tags == TAGS_SET) before adding the entries
used to opportunistically update references mentioned on the command
line. The result was that all tags were also considered candidates
for opportunistic updating.
This is harmless for two reasons: (a) because it would only add
entries if there is a configured refspec that covers tags *and* both
--tags and another refspec appear on the command-line; (b) because any
extra entries would be deleted later by the call to
ref_remove_duplicates() anyway.
But, to avoid extra work and extra memory usage, and to make the
implementation better match the intention, change the algorithm
slightly: compute the opportunistic refspecs based only on the
command-line arguments, storing the results into a separate temporary
list. Then add the tags (which have to come earlier in the list so
that they are not de-duped in favor of an opportunistic entry). Then
concatenate the temporary list onto the main list.
This change will also make later changes easier.
Signed-off-by: Michael Haggerty mhag...@alum.mit.edu
---
builtin/fetch.c | 44
1 file changed, 32 insertions(+), 12 deletions(-)
diff --git a/builtin/fetch.c b/builtin/fetch.c
index 61e8117..0849f09 100644
--- a/builtin/fetch.c
+++ b/builtin/fetch.c
@@ -272,32 +272,50 @@ static struct ref *get_ref_map(struct transport
*transport,
const struct ref *remote_refs = transport_get_remote_refs(transport);
if (refspec_count || tags == TAGS_SET) {
- struct ref **old_tail;
+ /* opportunistically-updated references: */
+ struct ref *orefs = NULL, **oref_tail = orefs;
for (i = 0; i refspec_count; i++) {
get_fetch_map(remote_refs, refspecs[i], tail, 0);
if (refspecs[i].dst refspecs[i].dst[0])
*autotags = 1;
}
- /* Merge everything on the command line, but not --tags */
+ /* Merge everything on the command line (but not --tags) */
for (rm = ref_map; rm; rm = rm-next)
rm-fetch_head_status = FETCH_HEAD_MERGE;
- if (tags == TAGS_SET)
- get_fetch_map(remote_refs, tag_refspec, tail, 0);
/*
-* For any refs that we happen to be fetching via command-line
-* arguments, take the opportunity to update their configured
-* counterparts. However, we do not want to mention these
-* entries in FETCH_HEAD at all, as they would simply be
-* duplicates of existing entries.
+* For any refs that we happen to be fetching via
+* command-line arguments, the destination ref might
+* have been missing or have been different than the
+* remote-tracking ref that would be derived from the
+* configured refspec. In these cases, we want to
+* take the opportunity to update their configured
+* remote-tracking reference. However, we do not want
+* to mention these entries in FETCH_HEAD at all, as
+* they would simply be duplicates of existing
+* entries, so we set them FETCH_HEAD_IGNORE below.
+*
+* We compute these entries now, based only on the
+* refspecs specified on the command line. But we add
+* them to the list following the refspecs resulting
+* from the tags option so that one of the latter,
+* which has FETCH_HEAD_NOT_FOR_MERGE, is not removed
+* by ref_remove_duplicates() in favor of one of these
+* opportunistic entries with FETCH_HEAD_IGNORE.
*/
- old_tail = tail;
for (i = 0; i transport-remote-fetch_refspec_nr; i++)
get_fetch_map(ref_map, transport-remote-fetch[i],
- tail, 1);
- for (rm = *old_tail; rm; rm = rm-next)
+ oref_tail, 1);
+
+ if (tags == TAGS_SET)
+ get_fetch_map(remote_refs, tag_refspec, tail, 0);
+
+ *tail = orefs;
+ for (rm = orefs; rm; rm = rm-next) {
rm-fetch_head_status = FETCH_HEAD_IGNORE;
+ tail = rm-next;
+ }
} else {
/* Use the defaults */
struct remote *remote = transport-remote;
@@ -334,8 +352,10 @@ static struct ref *get_ref_map(struct transport *transport,
tail = ref_map-next;
}
}
+
if (tags == TAGS_DEFAULT *autotags)
find_non_local_tags(transport, ref_map, tail);
+
ref_remove_duplicates(ref_map);
[PATCH v2 20/23] ref_remove_duplicates(): simplify loop logic
Change the loop body into the more straightforward
* remove item from the front of the old list
* if necessary, add it to the tail of the new list
and return a pointer to the new list (even though it is currently
always the same as the input argument, because the first element in
the list is currently never deleted).
Signed-off-by: Michael Haggerty mhag...@alum.mit.edu
---
builtin/fetch.c | 4 +---
remote.c| 52 +++-
remote.h| 8 ++--
3 files changed, 38 insertions(+), 26 deletions(-)
diff --git a/builtin/fetch.c b/builtin/fetch.c
index 5ddb9af..3d978eb 100644
--- a/builtin/fetch.c
+++ b/builtin/fetch.c
@@ -360,9 +360,7 @@ static struct ref *get_ref_map(struct transport *transport,
tail = rm-next;
}
- ref_remove_duplicates(ref_map);
-
- return ref_map;
+ return ref_remove_duplicates(ref_map);
}
#define STORE_REF_ERROR_OTHER 1
diff --git a/remote.c b/remote.c
index 15f3dc5..c90a2bf 100644
--- a/remote.c
+++ b/remote.c
@@ -745,35 +745,45 @@ int for_each_remote(each_remote_fn fn, void *priv)
return result;
}
-void ref_remove_duplicates(struct ref *ref_map)
+struct ref *ref_remove_duplicates(struct ref *ref_map)
{
struct string_list refs = STRING_LIST_INIT_NODUP;
- struct string_list_item *item = NULL;
- struct ref *prev = NULL, *next = NULL;
+ struct ref *retval = NULL;
+ struct ref **p = retval;
- for (; ref_map; prev = ref_map, ref_map = next) {
- next = ref_map-next;
- if (!ref_map-peer_ref)
- continue;
+ while (ref_map) {
+ struct ref *ref = ref_map;
+
+ ref_map = ref_map-next;
+ ref-next = NULL;
- item = string_list_insert(refs, ref_map-peer_ref-name);
- if (item-util) {
- /* Entry already existed */
- if (strcmp(((struct ref *)item-util)-name,
- ref_map-name))
- die(%s tracks both %s and %s,
- ref_map-peer_ref-name,
- ((struct ref *)item-util)-name,
- ref_map-name);
- prev-next = ref_map-next;
- free(ref_map-peer_ref);
- free(ref_map);
- ref_map = prev; /* skip this; we freed it */
+ if (!ref-peer_ref) {
+ *p = ref;
+ p = ref-next;
} else {
- item-util = ref_map;
+ struct string_list_item *item =
+ string_list_insert(refs, ref-peer_ref-name);
+
+ if (item-util) {
+ /* Entry already existed */
+ if (strcmp(((struct ref *)item-util)-name,
+ ref-name))
+ die(%s tracks both %s and %s,
+ ref-peer_ref-name,
+ ((struct ref *)item-util)-name,
+ ref-name);
+ free(ref-peer_ref);
+ free(ref);
+ } else {
+ *p = ref;
+ p = ref-next;
+ item-util = ref;
+ }
}
}
+
string_list_clear(refs, 0);
+ return retval;
}
int remote_has_url(struct remote *remote, const char *url)
diff --git a/remote.h b/remote.h
index 131130a..c07eb99 100644
--- a/remote.h
+++ b/remote.h
@@ -149,9 +149,13 @@ int resolve_remote_symref(struct ref *ref, struct ref
*list);
int ref_newer(const unsigned char *new_sha1, const unsigned char *old_sha1);
/*
- * Removes and frees any duplicate refs in the map.
+ * Remove and free all but the first of any entries in the input list
+ * that map the same remote reference to the same local reference. If
+ * there are two entries that map different remote references to the
+ * same local reference, emit an error message and die. Return a
+ * pointer to the head of the resulting list.
*/
-void ref_remove_duplicates(struct ref *ref_map);
+struct ref *ref_remove_duplicates(struct ref *ref_map);
int valid_fetch_refspec(const char *refspec);
struct refspec *parse_fetch_refspec(int nr_refspec, const char **refspec);
--
1.8.4.1
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 11/23] fetch --prune: prune only based on explicit refspecs
The old behavior of fetch --prune was to prune whatever was being
fetched. In particular, fetch --prune --tags caused tags not only
to be fetched, but also to be pruned. This is inappropriate because
there is only one tags namespace that is shared among the local
repository and all remotes. Therefore, if the user defines a local
tag and then runs git fetch --prune --tags, then the local tag is
deleted. Moreover, --prune and --tags can also be configured via
fetch.prune / remote.name.prune and remote.name.tagopt, making it
even less obvious that an invocation of git fetch could result in
tag lossage.
Since the command git remote update invokes git fetch, it had the
same problem.
The command git remote prune, on the other hand, disregarded the
setting of remote.name.tagopt, and so its behavior was inconsistent
with that of the other commands.
So the old behavior made it too easy to lose tags. To fix this
problem, change fetch --prune to prune references based only on
refspecs specified explicitly by the user, either on the command line
or via remote.name.fetch. Thus, tags are no longer made subject to
pruning by the --tags option or the remote.name.tagopt setting.
However, tags *are* still subject to pruning if they are fetched as
part of a refspec, and that is good. For example:
* On the command line,
git fetch --prune 'refs/tags/*:refs/tags/*'
causes tags, and only tags, to be fetched and pruned, and is
therefore a simple way for the user to get the equivalent of the old
behavior of --prune --tag.
* For a remote that was configured with the --mirror option, the
configuration is set to include
[remote name]
fetch = +refs/*:refs/*
, which causes tags to be subject to pruning along with all other
references. This is the behavior that will typically be desired for
a mirror.
Signed-off-by: Michael Haggerty mhag...@alum.mit.edu
---
Documentation/config.txt| 4 ++--
Documentation/fetch-options.txt | 19 ++-
builtin/fetch.c | 39 +--
t/t5510-fetch.sh| 10 +-
4 files changed, 30 insertions(+), 42 deletions(-)
diff --git a/Documentation/config.txt b/Documentation/config.txt
index ab26963..a405806 100644
--- a/Documentation/config.txt
+++ b/Documentation/config.txt
@@ -2087,8 +2087,8 @@ remote.name.vcs::
remote.name.prune::
When set to true, fetching from this remote by default will also
- remove any remote-tracking branches which no longer exist on the
- remote (as if the `--prune` option was give on the command line).
+ remove any remote-tracking references that no longer exist on the
+ remote (as if the `--prune` option was given on the command line).
Overrides `fetch.prune` settings, if any.
remotes.group::
diff --git a/Documentation/fetch-options.txt b/Documentation/fetch-options.txt
index 921f6be..12b1d92 100644
--- a/Documentation/fetch-options.txt
+++ b/Documentation/fetch-options.txt
@@ -41,8 +41,14 @@ ifndef::git-pull[]
-p::
--prune::
- After fetching, remove any remote-tracking branches which
- no longer exist on the remote.
+ After fetching, remove any remote-tracking references that no
+ longer exist on the remote. Tags are not subject to pruning
+ if they are fetched only because of the default tag
+ auto-following or due to a --tags option. However, if tags
+ are fetched due to an explicit refspec (either on the command
+ line or in the remote configuration, for example if the remote
+ was cloned with the --mirror option), then they are also
+ subject to pruning.
endif::git-pull[]
ifdef::git-pull[]
@@ -61,9 +67,12 @@ endif::git-pull[]
ifndef::git-pull[]
-t::
--tags::
- Request that all tags be fetched from the remote in addition
- to whatever else is being fetched. Its effect is similar to
- that of the refspec `refs/tags/*:refs/tags/*`.
+ Fetch all tags from the remote (i.e., fetch remote tags
+ `refs/tags/*` into local tags with the same name), in addition
+ to whatever else would otherwise be fetched. Using this
+ option alone does not subject tags to pruning, even if --prune
+ is used (though tags may be pruned anyway if they are also the
+ destination of an explicit refspec; see '--prune').
--recurse-submodules[=yes|on-demand|no]::
This option controls if and under what conditions new commits of
diff --git a/builtin/fetch.c b/builtin/fetch.c
index 887fa3e..1514b90 100644
--- a/builtin/fetch.c
+++ b/builtin/fetch.c
@@ -850,38 +850,17 @@ static int do_fetch(struct transport *transport,
goto cleanup;
}
if (prune) {
- struct refspec *prune_refspecs;
- int prune_refspec_count;
-
+ /*
+* We only prune based on refspecs specified
+* explicitly (via command
[PATCH v2 21/23] ref_remote_duplicates(): extract a function handle_duplicate()
It will become more complex in a moment.
Signed-off-by: Michael Haggerty mhag...@alum.mit.edu
---
remote.c | 18 ++
1 file changed, 10 insertions(+), 8 deletions(-)
diff --git a/remote.c b/remote.c
index c90a2bf..2deb2db 100644
--- a/remote.c
+++ b/remote.c
@@ -745,6 +745,15 @@ int for_each_remote(each_remote_fn fn, void *priv)
return result;
}
+static void handle_duplicate(struct ref *ref1, struct ref *ref2)
+{
+ if (strcmp(ref1-name, ref2-name))
+ die(%s tracks both %s and %s,
+ ref2-peer_ref-name, ref1-name, ref2-name);
+ free(ref2-peer_ref);
+ free(ref2);
+}
+
struct ref *ref_remove_duplicates(struct ref *ref_map)
{
struct string_list refs = STRING_LIST_INIT_NODUP;
@@ -766,14 +775,7 @@ struct ref *ref_remove_duplicates(struct ref *ref_map)
if (item-util) {
/* Entry already existed */
- if (strcmp(((struct ref *)item-util)-name,
- ref-name))
- die(%s tracks both %s and %s,
- ref-peer_ref-name,
- ((struct ref *)item-util)-name,
- ref-name);
- free(ref-peer_ref);
- free(ref);
+ handle_duplicate((struct ref *)item-util, ref);
} else {
*p = ref;
p = ref-next;
--
1.8.4.1
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 13/23] builtin/remote.c: reorder function definitions
Reorder function definitions to remove the need for forward
declarations.
Signed-off-by: Michael Haggerty mhag...@alum.mit.edu
---
builtin/remote.c | 159 +++
1 file changed, 78 insertions(+), 81 deletions(-)
diff --git a/builtin/remote.c b/builtin/remote.c
index 4e14891..ecedd96 100644
--- a/builtin/remote.c
+++ b/builtin/remote.c
@@ -77,9 +77,6 @@ static const char * const builtin_remote_seturl_usage[] = {
static int verbose;
-static int show_all(void);
-static int prune_remote(const char *remote, int dry_run);
-
static inline int postfixcmp(const char *string, const char *postfix)
{
int len1 = strlen(string), len2 = strlen(postfix);
@@ -1084,6 +1081,64 @@ static int show_push_info_item(struct string_list_item
*item, void *cb_data)
return 0;
}
+static int get_one_entry(struct remote *remote, void *priv)
+{
+ struct string_list *list = priv;
+ struct strbuf url_buf = STRBUF_INIT;
+ const char **url;
+ int i, url_nr;
+
+ if (remote-url_nr 0) {
+ strbuf_addf(url_buf, %s (fetch), remote-url[0]);
+ string_list_append(list, remote-name)-util =
+ strbuf_detach(url_buf, NULL);
+ } else
+ string_list_append(list, remote-name)-util = NULL;
+ if (remote-pushurl_nr) {
+ url = remote-pushurl;
+ url_nr = remote-pushurl_nr;
+ } else {
+ url = remote-url;
+ url_nr = remote-url_nr;
+ }
+ for (i = 0; i url_nr; i++)
+ {
+ strbuf_addf(url_buf, %s (push), url[i]);
+ string_list_append(list, remote-name)-util =
+ strbuf_detach(url_buf, NULL);
+ }
+
+ return 0;
+}
+
+static int show_all(void)
+{
+ struct string_list list = STRING_LIST_INIT_NODUP;
+ int result;
+
+ list.strdup_strings = 1;
+ result = for_each_remote(get_one_entry, list);
+
+ if (!result) {
+ int i;
+
+ sort_string_list(list);
+ for (i = 0; i list.nr; i++) {
+ struct string_list_item *item = list.items + i;
+ if (verbose)
+ printf(%s\t%s\n, item-string,
+ item-util ? (const char *)item-util :
);
+ else {
+ if (i !strcmp((item - 1)-string,
item-string))
+ continue;
+ printf(%s\n, item-string);
+ }
+ }
+ }
+ string_list_clear(list, 1);
+ return result;
+}
+
static int show(int argc, const char **argv)
{
int no_query = 0, result = 0, query_flag = 0;
@@ -1246,26 +1301,6 @@ static int set_head(int argc, const char **argv)
return result;
}
-static int prune(int argc, const char **argv)
-{
- int dry_run = 0, result = 0;
- struct option options[] = {
- OPT__DRY_RUN(dry_run, N_(dry run)),
- OPT_END()
- };
-
- argc = parse_options(argc, argv, NULL, options,
builtin_remote_prune_usage,
-0);
-
- if (argc 1)
- usage_with_options(builtin_remote_prune_usage, options);
-
- for (; argc; argc--, argv++)
- result |= prune_remote(*argv, dry_run);
-
- return result;
-}
-
static int prune_remote(const char *remote, int dry_run)
{
int result = 0, i;
@@ -1304,6 +1339,26 @@ static int prune_remote(const char *remote, int dry_run)
return result;
}
+static int prune(int argc, const char **argv)
+{
+ int dry_run = 0, result = 0;
+ struct option options[] = {
+ OPT__DRY_RUN(dry_run, N_(dry run)),
+ OPT_END()
+ };
+
+ argc = parse_options(argc, argv, NULL, options,
builtin_remote_prune_usage,
+0);
+
+ if (argc 1)
+ usage_with_options(builtin_remote_prune_usage, options);
+
+ for (; argc; argc--, argv++)
+ result |= prune_remote(*argv, dry_run);
+
+ return result;
+}
+
static int get_remote_default(const char *key, const char *value, void *priv)
{
if (strcmp(key, remotes.default) == 0) {
@@ -1505,64 +1560,6 @@ static int set_url(int argc, const char **argv)
return 0;
}
-static int get_one_entry(struct remote *remote, void *priv)
-{
- struct string_list *list = priv;
- struct strbuf url_buf = STRBUF_INIT;
- const char **url;
- int i, url_nr;
-
- if (remote-url_nr 0) {
- strbuf_addf(url_buf, %s (fetch), remote-url[0]);
- string_list_append(list, remote-name)-util =
- strbuf_detach(url_buf, NULL);
- } else
- string_list_append(list, remote-name)-util = NULL;
- if
[PATCH v2 19/23] t5536: new test of refspec conflicts when fetching
Add some tests that git fetch handles refspec conflicts (i.e., when
the same local reference should be updated from two different remote
references) correctly.
There is a small bug when updating references opportunistically,
namely that an explicit user wish like
git fetch origin \
refs/heads/branch1:refs/remotes/origin/branch2 \
refs/heads/branch2:refs/remotes/origin/branch1
should override a configured refspec like
+refs/heads/*:refs/remotes/origin/*
The current code incorrectly treats this as a fatal error.
In a few commits we will improve the error messages for refspec
conflicts in general and also turn this buggy fatal error into a
warning.
Signed-off-by: Michael Haggerty mhag...@alum.mit.edu
---
t/t5536-fetch-conflicts.sh | 96 ++
1 file changed, 96 insertions(+)
create mode 100755 t/t5536-fetch-conflicts.sh
diff --git a/t/t5536-fetch-conflicts.sh b/t/t5536-fetch-conflicts.sh
new file mode 100755
index 000..679c53e
--- /dev/null
+++ b/t/t5536-fetch-conflicts.sh
@@ -0,0 +1,96 @@
+#!/bin/sh
+
+test_description='fetch handles conflicting refspecs correctly'
+
+. ./test-lib.sh
+
+D=$(pwd)
+
+setup_repository () {
+ git init $1 (
+ cd $1
+ git config remote.origin.url $D
+ shift
+ for refspec in $@
+ do
+ git config --add remote.origin.fetch $refspec
+ done
+ )
+}
+
+verify_stderr () {
+ cat expected
+ # We're not interested in the error
+ # fatal: The remote end hung up unexpectedly:
+ grep -v hung up error actual
+ test_cmp expected actual
+}
+
+test_expect_success 'setup' '
+ git commit --allow-empty -m Initial
+ git branch branch1
+ git tag tag1
+ git commit --allow-empty -m First
+ git branch branch2
+ git tag tag2
+'
+
+test_expect_success 'fetch with no conflict' '
+ setup_repository ok +refs/heads/*:refs/remotes/origin/* (
+ cd ok
+ git fetch origin
+ )
+'
+
+test_expect_success 'fetch conflict: config vs. config' '
+ setup_repository ccc \
+ +refs/heads/branch1:refs/remotes/origin/branch1 \
+ +refs/heads/branch2:refs/remotes/origin/branch1 (
+ cd ccc
+ test_must_fail git fetch origin 2error
+ verify_stderr -\EOF
+ fatal: refs/remotes/origin/branch1 tracks both
refs/heads/branch1 and refs/heads/branch2
+ EOF
+ )
+'
+
+test_expect_success 'fetch duplicate: config vs. config' '
+ setup_repository dcc \
+ +refs/heads/*:refs/remotes/origin/* \
+ +refs/heads/branch1:refs/remotes/origin/branch1 (
+ cd dcc
+ git fetch origin
+ )
+'
+
+test_expect_success 'fetch conflict: arg overrides config' '
+ setup_repository aoc \
+ +refs/heads/*:refs/remotes/origin/* (
+ cd aoc
+ git fetch origin refs/heads/branch2:refs/remotes/origin/branch1
+ )
+'
+
+test_expect_success 'fetch conflict: arg vs. arg' '
+ setup_repository caa (
+ cd caa
+ test_must_fail git fetch origin \
+ refs/heads/*:refs/remotes/origin/* \
+ refs/heads/branch2:refs/remotes/origin/branch1 2error
+ verify_stderr -\EOF
+ fatal: refs/remotes/origin/branch1 tracks both
refs/heads/branch1 and refs/heads/branch2
+ EOF
+ )
+'
+
+test_expect_failure 'fetch conflict: criss-cross args' '
+ setup_repository xaa \
+ +refs/heads/*:refs/remotes/origin/* (
+ cd xaa
+ git fetch origin \
+ refs/heads/branch1:refs/remotes/origin/branch2 \
+ refs/heads/branch2:refs/remotes/origin/branch1
+ )
+'
+
+test_done
--
1.8.4.1
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
git rm bug?
Hello, My understanding was that running git rm on a file will delete all ancestors of the file that are empty directories from the file system. I've ran into a case that seems a little strange. To reproduce (using version 1.8.4.1 on Mac OS X 10.7.5): git init mkdir a mkdir b touch a/b/c.txt git add . git commit Then, running the commands $ rm a/b/c.txt $ git rm a/b/c.txt deletes c.txt as well as both directories a and b, as expected. But if I instead do $ rm -r a/b $ git rm a/b/c.txt then git deletes c.txt and b, but leaves a intact in the file system. Is this a bug? Thank you, Eunsuk -- 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
