Git development
 help / color / mirror / Atom feed
* Re: [question] how can i verify whether a local branch is tracking a remote branch?
From: Jeff King @ 2009-04-06 21:25 UTC (permalink / raw)
  To: Paolo Ciarrocchi; +Cc: git
In-Reply-To: <4d8e3fd30904060130l985b0a5x331d215ca6106fd4@mail.gmail.com>

On Mon, Apr 06, 2009 at 10:30:21AM +0200, Paolo Ciarrocchi wrote:

> I often act like a GIT "evangelist" trying to help friends and
> colleagues in starting using GIT and one of the "complaint" I'm
> getting is that people expect to get this information out of the
> branch command.
> 
> I mean something like:
> $ git branch
>  * foo <-> origin/foo
> 
> What do you think?

Ah. Well, if you just want it for human consumption, that is much
easier. :) That information is already shown by "git status":

  $ git status
  # On branch next
  # Your branch is ahead of 'origin/next' by 8 commits.
  ...

"git branch -v" is already looking at the information, but it
prints only the "ahead/behind" summary. E.g.,:

  $ git branch -v
    bar    1e0672d [behind 5] some commit
  * baz    dccc1cd [ahead 1, behind 3] other commit
    foo    787d5a8 [ahead 1] another commit
    master a0e632e actual upstream master

It would be pretty trivial to make it do something fancier. The
(extremely rough) patch below shows the tracking branch when
double-verbosity is given:

  $ git branch -vv
  * next 2d44318 [origin/next: ahead 9] branch -vv wip

So the questions are:

  - is this worth it? The verbose information is already available via
    git status, but only for the current branch.

  - should it be the default with "-v", or require "-vv"? It take up a
    bit of screen real estate, which is already in short supply for
    "branch -v"

  - in both the "status" and "branch" cases, we show nothing if they
    are equivalent. I guess you would want to see

      * next 2d44318 [origin/next] branch -vv wip

    or

      * next 2d44318 [origin/next: uptodate] branch -vv wip

-Peff

^ permalink raw reply

* Re: [question] how can i verify whether a local branch is tracking a remote branch?
From: Jeff King @ 2009-04-06 21:29 UTC (permalink / raw)
  To: Michael J Gruber; +Cc: Paolo Ciarrocchi, git, Junio C Hamano
In-Reply-To: <49D9EEE2.3000607@drmicha.warpmail.net>

On Mon, Apr 06, 2009 at 02:00:34PM +0200, Michael J Gruber wrote:

> > +		if (!strcmp(name, "tracking")) {
> > +			struct branch *branch;
> > +			if (prefixcmp(ref->refname, "refs/heads/"))
> > +				continue;
> > +			branch = branch_get(ref->refname + 11);
> > +			if (branch && branch->merge && branch->merge[0] &&
> > +			    branch->merge[0]->dst)
> > +				v->s = branch->merge[0]->dst;
> 
> Isn't that missing out on those cases where you --track (i.e. follow) a
> local (upstream) branch? See
> 5e6e2b4 (Make local branches behave like remote branches when --tracked,
> 2009-04-01)

I thought the logic was in branch_get to handle it. And indeed:

  $ git checkout --track -b new master
  Branch new set up to track local branch master.
  Switched to a new branch "new"
  $ git for-each-ref --format='%(refname) %(tracking)'
  refs/heads/master
  refs/heads/new refs/heads/master

So it will point either to something in refs/remotes or in refs/heads,
as applicable.

> If we hook it up into git-branch there would be to useful directions:

The difference being that git-branch is porcelain and git-for-each-ref
is plumbing. So they really serve different purposes.

> - "git branch --follows foo" could list all branches which follow foo,
> analogous to --contains. It gives you all your feature work on top of
> foo, all branches affected by rebasing foo etc.

Sure, that would probably be useful.

> - "git branch --whatever foo" could list the branch whoch foo follows.
> 
> I just notices that "git branch -v foo" does not give me the "-v" output
> for foo... Improving that would open up the possibility to go for -vv foo.

See the "-vv" patch I just posted elsewhere in the thread.

-Peff

^ permalink raw reply

* Re: Fetching SHA id's instead of named references?
From: Dmitry Potapov @ 2009-04-06 21:50 UTC (permalink / raw)
  To: Johannes Schindelin; +Cc: Klas Lindberg, Git Users List
In-Reply-To: <alpine.DEB.1.00.0904061447220.6619@intel-tinevez-2-302>

On Mon, Apr 06, 2009 at 02:48:17PM +0200, Johannes Schindelin wrote:
>_
> The issue is not if someone manages to fetch stuff before you repair it.__
> The issue is that that someone should not be able to manage _after_ you_
> repair it.

But how this someone will know the exact SHA-1 needed to fetch this
commit without having seen this commit already? Guessing SHA-1 by
brute force attack does not sound very promising...

Dmitry

^ permalink raw reply

* Re: [question] how can i verify whether a local branch is tracking a  remote branch?
From: Paolo Ciarrocchi @ 2009-04-06 22:00 UTC (permalink / raw)
  To: Jeff King; +Cc: git
In-Reply-To: <20090406212516.GA882@coredump.intra.peff.net>

On 4/6/09, Jeff King <peff@peff.net> wrote:
> On Mon, Apr 06, 2009 at 10:30:21AM +0200, Paolo Ciarrocchi wrote:

>> I mean something like:
>> $ git branch
>>  * foo <-> origin/foo
>>
>> What do you think?
>
> Ah. Well, if you just want it for human consumption, that is much
> easier. :) That information is already shown by "git status":
>
>   $ git status
>   # On branch next
>   # Your branch is ahead of 'origin/next' by 8 commits.
>   ...

right, but it can only ne used for the current branch.

> "git branch -v" is already looking at the information, but it
> prints only the "ahead/behind" summary. E.g.,:
>
>   $ git branch -v
>     bar    1e0672d [behind 5] some commit
>   * baz    dccc1cd [ahead 1, behind 3] other commit
>     foo    787d5a8 [ahead 1] another commit
>     master a0e632e actual upstream master
>
> It would be pretty trivial to make it do something fancier. The
> (extremely rough) patch below shows the tracking branch when
> double-verbosity is given:
>
>   $ git branch -vv
>   * next 2d44318 [origin/next: ahead 9] branch -vv wip

I like it!

> So the questions are:
>
>   - is this worth it? The verbose information is already available via
>     git status, but only for the current branch.

I think it's a very usefull information.
I feel like it would be nice to have this information being part of
the basic git branch output and not associated to the -vv option.

>   - should it be the default with "-v", or require "-vv"? It take up a
>     bit of screen real estate, which is already in short supply for
>     "branch -v"

How about be just part of the default git branch output?


>   - in both the "status" and "branch" cases, we show nothing if they
>     are equivalent. I guess you would want to see
>
>       * next 2d44318 [origin/next] branch -vv wip
>
>     or
>
>       * next 2d44318 [origin/next: uptodate] branch -vv wip

Sure.

Thanks!

Ciao,
-- 
Paolo
http://paolo.ciarrocchi.googlepages.com/
http://mypage.vodafone.it/

^ permalink raw reply

* [PATCH v2] prints elements of C code in the git repository
From: Roel Kluin @ 2009-04-06 22:09 UTC (permalink / raw)
  To: Johannes Schindelin, peff, mike.ralphson; +Cc: git

This script searches the definition of elements of C and dumps them to
stdout. It now uses the ctags tags file. Thanks for previous comments,
Is this better?

Usage examples:

In your kernel source directory run to create your tags file:
scripts/tags.sh tags

Say the get-def.sh script lives in `../git/contrib/'.
To print the function definitions of kmalloc, do:
../git/contrib/get-def.sh -f kmalloc

You can search for a function with a specific multiline pattern:
../git/contrib/get-def.sh -f kmalloc "/size.*SLUB_DMA/p"

Maybe you want to search for any function within a directory
with a pattern. You may want to use definitions in get-def.sh:
source ../git/contrib/get-def.sh

bad_unsigned="`simple_sed \
	"unsigned ([^;{}()]*, )*($V)[#...#]\2 (<|>=) 0[^x]"`"
bad_unsigned_test="/$bad_unsigned/{
p
s/^.*$bad_unsigned.*$/Due to variable \2/p
}"

../git/contrib/get-def.sh -f "$V" kernel/ "$bad_unsigned_test" |
less

Since frequently searching for functions is slow you may want
to convert all functions to single lines and pipe that to a file
that can subsequently be parsed more quickly.

warning: this command may take a long time (once):
../git/contrib/get-def.sh -f "$V" -- git-ls-files "*.[ch]" \
"s/($S|$comm1|$comm2)*([\\]?\n|$comm1|$S$S)($S|$comm1)*/ /g;
p;" > ../allfuncs

And then for instance do:
sed -n -r "/$bad_unsigned_test/{
p
s/^.*$bad_unsigned_test.*$/Due to variable \2/p
}" ../allfuncs | less
------------------------------>8-------------8<---------------------------------
commit e61ffb20dffa95025e61e2706603a7c72fcad37f
Author: Roel Kluin <roel.kluin@gmail.com>
Date:   Mon Apr 6 23:58:28 2009 +0200

    This script searches the definition of elements of C and dumps them to
    stdout. It requires ctags and bash.
    
    As invoking it with -? will tell:
    
    USAGE: git get-def [OPTION]... PATTERN [FILE|DIRECTORY]... [SEDSCRIPT]
    print elements of C code with name PATTERN, an extended regular expression. If
    SEDSCRIPT is provided, it puts the entire element in the hold space before the
    execution of SEDSCRIPT.
    
    
    Options to specify which element(s) should be printed:
            -c      class name
            -d      define
            -f      function or method name
            -g      enumeration
            -m      member (of structure or class data)
            -s      structure
            -t      typedef
            -u      union
            -v      variable
            -D      only non-macro defines
            -M      only macro defines
    
    Signed-off-by: Roel Kluin <roel.kluin@gmail.com>
---
diff --git a/contrib/get-def.sh b/contrib/get-def.sh
new file mode 100755
index 0000000..9428003
--- /dev/null
+++ b/contrib/get-def.sh
@@ -0,0 +1,254 @@
+#!/bin/bash
+# FIXME: make C++ style members
+
+int="[0-9]"
+hex="[a-f0-9]"
+hEx="[A-Fa-f0-9]"
+HEX="[A-F0-9]"
+upp="[A-Z]"
+up_="[A-Z_]"
+low="[a-z]"
+lo_="[a-z_]"
+alp="[A-Za-z]"
+al_="[A-Za-z_]"
+ALN="[A-Z0-9]"
+AN_="[A-Z0-9_]"
+aln="[A-Za-z0-9]"
+an_="[A-Za-z0-9_]"
+
+em='!'			# because of bash bang
+
+D="$int*\.?$int+x?$hex*[uUlL]{0,3}[fF]?"		# a number, float or hex
+# more strict and catches it (costs one backreference for (git )grep)
+SD="($int+[uUlLfF]?|$int+[uU]?[lL][lL]?|0x$hex+|0x$HEX+|$int+[lL][lL][uU]|$int*\.$int+[fF]?)"
+
+V="$al_+$an_*"		# variable/function name (or definition)
+K="$up_+$AN_*"		# definition (in capitals)
+
+# to catch variables that are members or arrays:
+W="[a-zA-Z0-9_>.-]*"
+SW="$V(\[[^][]*\]|\[[^][]*\[[^][]*\][^][]*\]|\.$V|->$V)*"	 # more strict, 1 backref
+
+s="[[:space:]]*"
+S="[[:space:]]+"
+
+# useful to ensure the end of a variable name:
+Q="[^[:alnum:]_]"
+Q2="[^[:alnum:]_>.]" # the '>' is tricky, it's an operator as well
+
+# match comments
+comm1="\/\*([^*]+|\**[^*/])*\*+\/"			# 1 backref
+comm2="\/\/([^\n]+|[n\\]+)*"				# 1 backref
+
+# match the end of the line, including comments:
+cendl="$s($comm1|$comm2|$s)*$"			 	# 3 backrefs
+cendln="$s($comm1|$comm2|$s)*($|\n)"			# 4 backrefs
+
+# strings and characters can contain things we want to match
+str="\"([^\\\"]+|\\\\.)*\""				# 1 backref
+ch1="'[^\\']'"
+ch2="'\\\\.[^']*'"
+ch="$ch1|$ch2"
+
+# match something that is not comment, string or character (c-code):
+ccode="([^\"'/]+|\/[^*\"'/]|\/?$comm1|\/?$ch1|\/?$ch2|\/?$str)*"		# 3 backrefs
+ccoden="([^\"'/]+|\/[^*\"'/]|\/?$comm1|\/?$ch1|\/?$ch2|\/?$str|\/?$comm2)*"	# 4 backrefs
+
+nps="[^()]*"
+nstdps="(\($nps(\($nps(\($nps(\($nps(\($nps\)$nps)*\)$nps)*\)$nps)*\)$nps)*\)$nps)*"
+npz="$nps$nstdps"
+nnps="\($npz\)"
+
+ncs="[^}{]*"
+nstdcs="(\{$ncs(\{$ncs(\{$ncs(\{$ncs(\{$ncs\}$ncs)*\}$ncs)*\}$ncs)*\}$ncs)*\}$ncs)*"
+ncz="$ncs$nstdcs"
+nncs="\{$ncz\}"
+
+delimitstr="s/([][{}(|)+*?\\/.^])/\\\\\1/g"
+delimit()
+{
+	sed -r "$delimitstr"
+}
+
+# excludes testing in strings, chars and comment
+excl_code()
+{
+	local incl=""
+	for f in "${@:3}"; do
+		incl="$incl|\/?$f";
+	done
+	echo "([^$1\"'/$2]*$incl|\/[^$1\"*'/$2]*|\/?$comm1|\/?$ch1|\/?$ch2|\/?$str|\/?$comm2)*"
+}
+
+# usage: nestc "(" ")" [number]
+nestc()
+{
+	local i;
+	[ $# -eq 1 ] && i=5 || i=$3;
+	# first and 2nd are flipped to enable matching
+	# square brackets "]["
+	local p="$(excl_code "$2$1" "${@:4}")"
+	local ret="$p"
+	while [ $i -gt 0 ]; do
+		ret="${p}([$1]${ret}[$2]${p})*"
+		i=$(($i-1));
+	done
+	echo "$ret"
+}
+
+simple_sed()
+{
+	l="${1//\(...\)/\($(nestc "(" ")" 8 | delimit)\)}"
+	l="${1//\{...\}/\($(nestc "{" "}" 12 | delimit)\)}"
+	l="${l//[[]#...#[]]/$Q$ccode$Q2}"
+	l="${l//[[]...[&|][&|][]]/$s($(nestc "(" ")" 5 | delimit)[&|][&|])?$s}"
+	l="${l//[[][&|][&|]...[]]/$s([&|][&|]$(nestc "(" ")" 5 | delimit))?$s}"
+	l="${l//[[]...[]]/$ccode}"
+	l="${l//[[](\{...)\*[]]/(\{$(nestc "{" "}" 12))*}"
+	l="${l//[[](...\})\*[]]/($(nestc "{" "}" 12)\})*}"
+	echo "$l" | sed -r "
+		:a
+		s/([[:alnum:]])[[:space:]]+([[:alnum:]])/\1[[:space:]]+\2/g
+		s/[[:space:]]+/[[:space:]]*/g
+		$!{
+			N; ba
+		}"
+}
+
+usage()
+{
+cat << EOF
+USAGE: git get-def [OPTION]... PATTERN [FILE|DIRECTORY]... [SEDSCRIPT]
+
+print elements of C code with name PATTERN, an extended regular expression. If
+SEDSCRIPT is provided, it puts the entire element in the hold space before the
+execution of SEDSCRIPT.
+
+Options to specify which element(s) should be printed:
+	-c	class name
+	-d	define
+	-f	function or method name
+	-g	enumeration
+	-m	member (of structure or class data)
+	-s	structure
+	-t	typedef
+	-u	union
+	-v	variable
+	-D	only non-macro defines
+	-M	only macro defines
+	-?	print this help
+
+EOF
+}
+
+sedstr_matches()
+{
+	# TODO: distinction between simple defines and macros
+	local shead="$(nestc "(" ")" 5)"
+	local head="$(nestc "(" ")" 10)"
+	local body="$(nestc "{" "}" 10)"
+	local SP="$S|$comm1|[\\]"
+
+	local wrd="$V(($SP)?\($shead\))?"
+	local fret="($SP)*($wrd($SP|\*)+)+"
+	local A="($SP)*($wrd($SP)+)*"
+	local B="($SP)+($wrd($SP))*"
+	local C="(($SP)+$wrd)*($SP)*"
+	local t=
+	local match=
+	local pr=":__print;${3}"
+	for t in ${1//|/ }; do
+		case "$t" in
+			"c") match="^${A}class($B$2($C)?\{$body\}|($C)?\{$body\}$A$2)($C)?;";;
+			"d") match="^$s#(${SP})*define(${SP})+$2(($S|\().*[^\\])?$" ;;
+			"D") match="^$s#(${SP})*define(${SP})+$2($S.*[^\\])?$" ;;
+			"M") match="^$s#(${SP})*define(${SP})+$2\(.*[^\\]$" ;;
+			"f") match="^$fret$2($SP)*\($shead\)($SP)*\{$body\}" ;;
+			"g") match="^${A}enum($B$2($C)?\{$body\}|($C)?\{$body\}$A$2)($C)?;";;
+			"m") match="^$fret$2($SP)*[;=]";;
+			"s") match="^${A}struct($B$2($C)?\{$body\}|($C)?\{$body\}$A$2)($C)?;";;
+			"t") match="^($SP)*typedef(($B)?\{$body\}|($SP)+)$A$2($C)?;$cendl" ;;
+			"u") match="^${A}union($B$2($C)?\{$body\}|($C)?\{$body\}$A$2)($C)?;";;
+			"v") match="^$fret$2($SP)*[;=]";;
+		esac
+		t="${t//[DM]/d}"
+		pr=":__$t;/$match/${em}{H;N;b__$t};b__print;
+$pr"
+	done
+	echo "$pr"
+}
+
+parse_tags()
+{
+	# TODO: other limits, e.g. limit="\tfile:" for local functions
+	local limit="(	.*)?"
+	local l=
+	#		  name	file	query		type
+	for l in $(grep -E "^$1	($2)	[^	]+	(${3//[DM]/d})$limit$" "tags" |
+			sort -k2 | tr "\t " "@\`"); do
+		local n="${l%%@*}"
+		l="${l#*@}"
+		local f="${l%%@*}"
+		local t="${l#*;\"@}"
+		if [ "$f" != "$oldf" ]; then
+			if [ -n "$oldf" ]; then
+				sed -r -n "${sedstr}b;$4" "$oldf"
+				[ $? -ne 0 ] && echo "Error in $oldf"
+			fi
+			local sedstr=
+			local oldf="$f"
+		fi
+		l="${l%;\"*}"
+		l="${l#*@}"
+		[ "${l:0:2}" = "/^" ] && l="/^`echo "${l:2:$((${#l}-3))}" | delimit`/"
+		sedstr="${l//\`/ }b__${t:0:1};$sedstr"
+	done
+	[ -n "$sedstr" ] && sed -r -n "${sedstr}b;$4" "$oldf"
+}
+
+parse_opts()
+{
+	local fl=			# file list
+	local name=
+	local getstr=
+	local script=
+
+	while [ $# -ne 0 ]; do
+		while getopts "cdDMfgmstuv" optname; do
+			case "$optname" in
+				c|d|D|M|f|g|m|s|t|u|v) getstr="${getstr:+$getstr|}$optname" ;;
+				"?") usage; exit 0; ;;
+			esac
+		done
+		shift $((OPTIND-1))
+		[ $# -eq 0 ] && break;
+		OPTIND=0
+		if [ -f "$1" ]; then
+			fl="${fl:+$fl|}$1";
+		elif [ -d "$1" ]; then
+			fl="${fl:+$fl|}${1}[^	]+";
+		else
+			if [ -z "$name" ]; then
+				name="$1";
+			else
+				script="$1"
+			fi
+		fi
+		shift
+	done
+	[ -z "$name" ] && usage;
+	getstr="${getstr:=c|d|f|g|m|s|t|u|v}"
+	local pr="`sedstr_matches "$getstr" "$name" "${script:=p;}"`"
+	fl="${fl:=[^	]+}"
+	parse_tags "$name" "${fl//\//\\/}" "$getstr" "$pr"
+}
+
+
+#main
+if [ "$0" != "-bash" ]; then
+	if [ -f "tags" ]; then
+		parse_opts "$@"
+	else
+		echo "No tags file found";
+	fi
+fi

^ permalink raw reply related

* Re: [PATCH 07/14] difftool: add a -y shortcut for --no-prompt
From: Markus Heidelberg @ 2009-04-06 22:17 UTC (permalink / raw)
  To: David Aguilar; +Cc: gitster, git, charles
In-Reply-To: <1239006689-14695-8-git-send-email-davvid@gmail.com>

David Aguilar, 06.04.2009:
> diff --git a/contrib/difftool/git-difftool.txt b/contrib/difftool/git-difftool.txt
> index 2b7bc03..4dff529 100644
> --- a/contrib/difftool/git-difftool.txt
> +++ b/contrib/difftool/git-difftool.txt
> @@ -3,35 +3,32 @@ git-difftool(1)
>  
>  NAME
>  ----
> -git-difftool - compare changes using common merge tools
> +git-difftool - Show changes using common diff tools
>  
>  SYNOPSIS
>  --------
> -'git difftool' [--tool=<tool>] [--no-prompt] ['git diff' options]
> +'git difftool' [-t|--tool=<tool>] [-y|--no-prompt] [<'git diff' options>]

"-t <tool>" would be more correct than only "-t". But I'm not sure if it
should go in there, mergetool doesn't have it either. It's only the
synopsis, is there any "official" guideline on how much to include
there and whether to avoid different options with the same meaning?

^ permalink raw reply

* Re: non-ascii filenames issue
From: Dmitry Potapov @ 2009-04-06 22:33 UTC (permalink / raw)
  To: Johannes Schindelin; +Cc: Peter Krefting, Teemu Likonen, git
In-Reply-To: <alpine.DEB.1.00.0904061109330.10279@pacific.mpi-cbg.de>

On Mon, Apr 06, 2009 at 11:12:35AM +0200, Johannes Schindelin wrote:
>
> Most Russian programmers I know do not run in a UTF-8 locale.

Actually, on Linux, people gradually switching to UTF-8 from koi8-r,
but on Windows MSCRT does not support UTF-8, so you do have much choice
here but to use Windows-1251. BTW, the upcoming Cygwin 1.7 is going to
have UTF-8 as the default locale. So, IMHO, UTF-8 is the only reasonable
choice for internal file name representation...

Dmitry

^ permalink raw reply

* Re: [PATCH] perl: add new module Git::Config for cached 'git config' access
From: Sam Vilain @ 2009-04-06 22:50 UTC (permalink / raw)
  To: Frank Lichtenheld; +Cc: git, Petr Baudis
In-Reply-To: <20090406092942.GW17706@mail-vs.djpig.de>

On Mon, 2009-04-06 at 11:29 +0200, Frank Lichtenheld wrote:
> On Mon, Apr 06, 2009 at 11:46:15AM +1200, Sam Vilain wrote:
> > +	my ($fh, $c) = $git->command_output_pipe(
> > +		'config', ( $which ? ("--$which") : () ),
> > +		'--list',
> > +	       );
> Any reason why you don't use --null here? The output of --list without --null
> is not reliably parsable, since people can put newlines in values.

No particularly good reason :-)

Subject: [PATCH] perl: make Git::Config use --null

Use the form of 'git-config' designed for parsing by modules like
this for safety with values containing embedded line feeds.

Signed-off-by: Sam Vilain <sam.vilain@catalyst.net.nz>
---
 perl/Git/Config.pm |    6 ++++--
 t/t9700/config.t   |    4 ++++
 2 files changed, 8 insertions(+), 2 deletions(-)

diff --git a/perl/Git/Config.pm b/perl/Git/Config.pm
index a0a6a41..a35d9f3 100644
--- a/perl/Git/Config.pm
+++ b/perl/Git/Config.pm
@@ -179,12 +179,14 @@ sub read {
 
 	my ($fh, $c) = $git->command_output_pipe(
 		'config', ( $which ? ("--$which") : () ),
-		'--list',
+		 '--null', '--list',
 	       );
 	my $read_state = {};
 
+	local($/)="\0";
 	while (<$fh>) {
-		my ($item, $value) = m{(.*?)=(.*)};
+		my ($item, $value) = m{(.*?)\n((?s:.*))\0}
+			or die "failed to parse it; \$_='$_'";
 		my $sl = \( $read_state->{$item} );
 		if (!defined $$sl) {
 			$$sl = $value;
diff --git a/t/t9700/config.t b/t/t9700/config.t
index 395a5c9..f0f7d2d 100644
--- a/t/t9700/config.t
+++ b/t/t9700/config.t
@@ -16,6 +16,7 @@ in_empty_repo sub {
 	$git->command_oneline("config", "foo.intval", "12g");
 	$git->command_oneline("config", "foo.false.val", "false");
 	$git->command_oneline("config", "foo.true.val", "yes");
+	$git->command_oneline("config", "multiline.val", "hello\nmultiline.val=world");
 
 	my $conf = Git::Config->new();
 	ok($conf, "constructed a new Git::Config");
@@ -92,6 +93,9 @@ in_empty_repo sub {
 	is($unset, undef,
 	   "boolean thaw - not present");
 
+	like($conf->config("multiline.val"), qr{\n},
+	     "parsing multi-line values");
+
 	$git->command_oneline("config", "foo.intval", "12g");
 	$git->command_oneline("config", "foo.falseval", "false");
 	$git->command_oneline("config", "foo.trueval", "on");
-- 
debian.1.5.6.1

^ permalink raw reply related

* [PATCH] Documentation: Introduce "upstream branch"
From: Santi Béjar @ 2009-04-06 23:24 UTC (permalink / raw)
  To: git


Signed-off-by: Santi Béjar <santi@agolina.net>
---
 Documentation/config.txt           |    2 +-
 Documentation/glossary-content.txt |    6 ++++++
 2 files changed, 7 insertions(+), 1 deletions(-)

diff --git a/Documentation/config.txt b/Documentation/config.txt
index 3afd124..f3ebd2f 100644
--- a/Documentation/config.txt
+++ b/Documentation/config.txt
@@ -1215,7 +1215,7 @@ push.default::
 * `matching` push all matching branches.
   All branches having the same name in both ends are considered to be
   matching. This is the default.
-* `tracking` push the current branch to the branch it is tracking.
+* `tracking` push the current branch to its upstream branch.
 * `current` push the current branch to a branch of the same name.
 
 rebase.stat::
diff --git a/Documentation/glossary-content.txt b/Documentation/glossary-content.txt
index 4fc1cf1..86be3ae 100644
--- a/Documentation/glossary-content.txt
+++ b/Documentation/glossary-content.txt
@@ -449,6 +449,12 @@ This commit is referred to as a "merge commit", or sometimes just a
 	An <<def_object,object>> which is not <<def_reachable,reachable>> from a
 	<<def_branch,branch>>, <<def_tag,tag>>, or any other reference.
 
+[[def_upstream_branch]]upstream branch::
+	The default <<def_branch,branch>> that is merged/rebased into another
+	branch. It is configured via branch.<name>.remote and
+	branch.<name>.merge. If the upstream branch of 'A' is 'origin/B' it is
+	sometimes refered as "'A' is tracking 'origin/B'".
+
 [[def_working_tree]]working tree::
 	The tree of actual checked out files.  The working tree is
 	normally equal to the <<def_HEAD,HEAD>> plus any local changes
-- 
1.6.1.258.g7ff14

^ permalink raw reply related

* Re: [PATCH v2 14/14] difftool/mergetool: refactor commands to use git-mergetool--lib
From: Markus Heidelberg @ 2009-04-06 23:37 UTC (permalink / raw)
  To: David Aguilar; +Cc: gitster, git, benji, charles
In-Reply-To: <1239010228-21315-1-git-send-email-davvid@gmail.com>

David Aguilar, 06.04.2009:
> diff --git a/git-mergetool--lib.sh b/git-mergetool--lib.sh

> +check_unchanged () {
> +	if merge_mode; then
> +		if test "$MERGED" -nt "$BACKUP"; then
> +			status=0
> +		else
> +			while true; do
> +				echo "$MERGED seems unchanged."
> +				printf "Was the merge successful? [y/n] "
> +				read answer < /dev/tty
> +				case "$answer" in
> +				y*|Y*) status=0; break ;;
> +				n*|N*) status=1; break ;;
> +				esac
> +			done
> +		fi
> +	else
> +		status=0
> +	fi
> +	return $status
> +}

The return value is currently never used.

> +run_merge_tool () {
> +	base_present="$2"
> +	if diff_mode; then
> +		base_present="false"
> +	fi
> +	if test -z "$base_present"; then
> +		base_present="true"
> +	fi

The second if is never true, so isn't necessary. run_merge_tool() is
called with $2 = true or false in mergetool and $2 = "" in difftool.

But I wonder, if it would be better to change the proceeding in the
case-esac in the next hunk below:

Currently it is:
    if $base_present
        mergetool with base
    else
        if $merge_mode
            mergetool without base
        else
            difftool
        fi
    fi

Maybe better:
    if $merge_mode
        if $base_present
            mergetool with base
        else
            mergetool without base
        fi
    else
        difftool
    fi

Then the first if can vanish as well and $base_present doesn't have to
be set to false in diff_mode.

And check_unchanged() doesn't have to be called in diff_mode any more,
$status could be set to 0 by default and doesn't have to be touched when
in diff_mode. Only in merge_mode git-mergetool has to know, whether the
merge went fine.

Then it will be:
    if $merge_mode
        touch $BACKUP
        if $base_present
            mergetool with base
        else
            mergetool without base
        fi
	check_unchanged
    else
        difftool
    fi

or:
    if $merge_mode
        if $base_present
            mergetool with base
        else
            mergetool without base
        fi
	status=$?
    else
        difftool
    fi

Sorry for coming so late with this.

> +	case "$1" in
> +	kdiff3)
> +		if $base_present; then
> +			("$merge_tool_path" --auto \
> +			 --L1 "$MERGED (Base)" --L2 "$MERGED (Local)" --L3 "$MERGED (Remote)" \
> +			 -o "$MERGED" "$BASE" "$LOCAL" "$REMOTE" > /dev/null 2>&1)
> +		else
> +			if merge_mode; then
> +				("$merge_tool_path" --auto \
> +				 --L1 "$MERGED (Local)" \
> +				 --L2 "$MERGED (Remote)" \
> +				 -o "$MERGED" "$LOCAL" "$REMOTE" \
> +				> /dev/null 2>&1)
> +			else
> +				("$merge_tool_path" --auto \
> +				 --L1 "$MERGED (A)" \
> +				 --L2 "$MERGED (B)" \
> +				 "$LOCAL" "$REMOTE" \
> +				> /dev/null 2>&1)
> +			fi
> +		fi
> +		status=$?
> +		;;
> +	kompare)
> +		"$merge_tool_path" "$LOCAL" "$REMOTE"
> +		status=$?
> +		;;
> +	tkdiff)
> +		if $base_present; then
> +			"$merge_tool_path" -a "$BASE" -o "$MERGED" "$LOCAL" "$REMOTE"
> +		else
> +			if merge_mode; then
> +				"$merge_tool_path" -o "$MERGED" "$LOCAL" "$REMOTE"
> +			else
> +				"$merge_tool_path" "$LOCAL" "$REMOTE"
> +			fi
> +		fi
> +		status=$?
> +		;;
> +	meld)
> +		if merge_mode; then
> +			touch "$BACKUP"
> +			"$merge_tool_path" "$LOCAL" "$MERGED" "$REMOTE"
> +		else
> +			"$merge_tool_path" "$LOCAL" "$REMOTE"
> +		fi
> +		check_unchanged
> +		;;
> +	diffuse)
> +		if merge_mode; then
> +			touch "$BACKUP"
> +		fi
> +		if $base_present; then
> +			"$merge_tool_path" "$LOCAL" "$MERGED" "$REMOTE" "$BASE" | cat
> +		else
> +			if merge_mode; then
> +				"$merge_tool_path" "$LOCAL" "$MERGED" "$REMOTE" | cat
> +			else
> +				"$merge_tool_path" "$LOCAL" "$REMOTE" | cat
> +			fi
> +		fi
> +		check_unchanged
> +		;;
> +	vimdiff)
> +		if merge_mode; then
> +			touch "$BACKUP"
> +			"$merge_tool_path" -d -c "wincmd l" "$LOCAL" "$MERGED" "$REMOTE"
> +			check_unchanged
> +		else
> +			"$merge_tool_path" -d -c "wincmd l" "$LOCAL" "$REMOTE"
> +		fi
> +		;;
> +	gvimdiff)
> +		if merge_mode; then
> +			touch "$BACKUP"
> +			"$merge_tool_path" -d -c "wincmd l" -f "$LOCAL" "$MERGED" "$REMOTE"
> +			check_unchanged
> +		else
> +			"$merge_tool_path" -d -c "wincmd l" -f "$LOCAL" "$REMOTE"
> +		fi
> +		;;
> +	xxdiff)
> +		if merge_mode; then
> +			touch "$BACKUP"
> +		fi
> +		if $base_present; then
> +			"$merge_tool_path" -X --show-merged-pane \
> +			    -R 'Accel.SaveAsMerged: "Ctrl-S"' \
> +			    -R 'Accel.Search: "Ctrl+F"' \
> +			    -R 'Accel.SearchForward: "Ctrl-G"' \
> +			    --merged-file "$MERGED" "$LOCAL" "$BASE" "$REMOTE"
> +		else
> +			if merge_mode; then
> +				"$merge_tool_path" -X $extra \
> +					-R 'Accel.SaveAsMerged: "Ctrl-S"' \
> +					-R 'Accel.Search: "Ctrl+F"' \
> +					-R 'Accel.SearchForward: "Ctrl-G"' \
> +					--merged-file "$MERGED" "$LOCAL" "$REMOTE"
> +			else
> +				"$merge_tool_path" \
> +					-R 'Accel.Search: "Ctrl+F"' \
> +					-R 'Accel.SearchForward: "Ctrl-G"' \
> +					"$LOCAL" "$REMOTE"
> +			fi
> +		fi
> +		check_unchanged
> +		;;
> +	opendiff)
> +		merge_mode && touch "$BACKUP"
> +		if $base_present; then
> +			"$merge_tool_path" "$LOCAL" "$REMOTE" \
> +				-ancestor "$BASE" -merge "$MERGED" | cat
> +		else
> +			if merge_mode; then
> +				"$merge_tool_path" "$LOCAL" "$REMOTE" \
> +					-merge "$MERGED" | cat
> +			else
> +				"$merge_tool_path" "$LOCAL" "$REMOTE" | cat
> +			fi
> +		fi
> +		check_unchanged
> +		;;
> +	ecmerge)
> +		merge_mode && touch "$BACKUP"
> +		if $base_present; then
> +			"$merge_tool_path" "$BASE" "$LOCAL" "$REMOTE" \
> +				--default --mode=merge3 --to="$MERGED"
> +		else
> +			"$merge_tool_path" "$LOCAL" "$REMOTE" \
> +				--default --mode=merge2 --to="$MERGED"
> +		fi
> +		check_unchanged
> +		;;
> +	emerge)
> +		if $base_present; then
> +			"$merge_tool_path" -f emerge-files-with-ancestor-command \
> +				"$LOCAL" "$REMOTE" "$BASE" "$(basename "$MERGED")"
> +		else
> +			"$merge_tool_path" -f emerge-files-command \
> +				"$LOCAL" "$REMOTE" "$(basename "$MERGED")"
> +		fi
> +		status=$?
> +		;;
> +	tortoisemerge)
> +		if $base_present; then
> +			touch "$BACKUP"
> +			"$merge_tool_path" -base:"$BASE" -mine:"$LOCAL" -theirs:"$REMOTE" -merged:"$MERGED"
> +			check_unchanged
> +		else
> +			echo "TortoiseMerge cannot be used without a base" 1>&2
> +			status=1
> +		fi
> +		;;
> +	*)
> +		if test -n "$merge_tool_cmd"; then
> +			if merge_mode &&
> +			test "$merge_tool_trust_exit_code" = "false"; then
> +				touch "$BACKUP"
> +				( eval $merge_tool_cmd )
> +				check_unchanged
> +			else
> +				( eval $merge_tool_cmd )
> +				status=$?
> +			fi
> +		fi
> +		;;
> +	esac
> +	return $status
> +}
> +
> +guess_merge_tool () {
> +	if diff_mode; then
> +		kompare="kompare"
> +	fi
> +	if test -n "$DISPLAY"; then
> +		if test -n "$GNOME_DESKTOP_SESSION_ID" ; then
> +			tools="meld kdiff3 $kompare tkdiff"
> +			tools="$tools xxdiff gvimdiff diffuse"
> +		else
> +			tools="kdiff3 $kompare tkdiff xxdiff"
> +			tools="$tools meld gvimdiff diffuse"
> +		fi
> +	fi

We lost tortoisemerge. And we could add ecmerge. Then every possible
built-in can be detected if installed.

> +	if echo "${VISUAL:-$EDITOR}" | grep emacs > /dev/null 2>&1; then
> +		# $EDITOR is emacs so add emerge as a candidate
> +		tools="$tools emerge opendiff vimdiff"
> +	elif echo "${VISUAL:-$EDITOR}" | grep vim > /dev/null 2>&1; then
> +		# $EDITOR is vim so add vimdiff as a candidate
> +		tools="$tools vimdiff opendiff emerge"
> +	else
> +		tools="$tools opendiff emerge vimdiff"
> +	fi

Why is opendiff here? I thought the graphical tools should go above.
Doesn't have Mac OS $DISPLAY set?

^ permalink raw reply

* Re: Fetching SHA id's instead of named references?
From: Klas Lindberg @ 2009-04-06 23:40 UTC (permalink / raw)
  To: Nicolas Pitre; +Cc: Shawn O. Pearce, Git Users List
In-Reply-To: <alpine.LFD.2.00.0904061245111.6741@xanadu.home>

On Mon, Apr 6, 2009 at 6:55 PM, Nicolas Pitre <nico@cam.org> wrote:

> Why can't you simply fetch the remote from its branch tip and then
> figure out / checkout the particular unnamed reference you wish locally?

It is a pretty sane thing to do, but it makes me a bit nervous that
branches are not immutable. Let's say I decide on a manifest format
where each tree is listed as a branch name plus the current SHA key on
that branch. The branch name is needed to enable fetch, but if the
branch is later renamed because of a change in naming policy, or its
name simply reused to refer to something completely different (*),
then there is no guarantee that the SHA key is reachable through that
branch name.

(*) These situations cannot be discounted in an organization with,
say, a few thousand employees and several tens of really big projects
with considerable overlap. I have to take into account that the right
hand may not know what the left hand is doing all the time.

> Unlike with CVS/SVN, you don't need anything from the remote if you want
> to checkout an old version. In particular, there is no need for you to
> only fetch that old version from the remote.  You just fetch everything
> from the remote and then checkout the particular old version you wish.

Please consider when you have to recreate some particular forest that
you never worked on before, but now you have to fetch and recreate a 3
year old version so that you can work on that critical error report.
And I may really not want to fetch everything. Some projects are just
very very big.

I think that what I would need is either

 * Immutable tags, or
 * A way to maintain sets of indestructible commits based on SHA id's
and a way to fetch them without going through a named reference.

The second option seems better because it would allow for recursion on
submodules and it doesn't pollute the tag name space.

BR / Klas

^ permalink raw reply

* Re: [PATCH 09/14] difftool: move 'git-difftool' out of contrib
From: Markus Heidelberg @ 2009-04-06 23:42 UTC (permalink / raw)
  To: David Aguilar; +Cc: gitster, git, charles
In-Reply-To: <1239006689-14695-10-git-send-email-davvid@gmail.com>

David Aguilar, 06.04.2009:
> diff --git a/Documentation/config.txt b/Documentation/config.txt
> +diff.tool::
> +	Controls which diff tool is used.  `diff.tool` overrides
> +	`merge.tool` when used by linkgit:git-difftool[1] and has
> +	the same valid values as `merge.tool`.

+kompare
-tortoisemerge

^ permalink raw reply

* Re: [RFC/PATCH 0/2] New 'stage' command
From: Junio C Hamano @ 2009-04-07  0:55 UTC (permalink / raw)
  To: Matthieu Moy
  Cc: David Kågedal, git, David Aguilar, Sverre Rabbelier,
	markus.heidelberg, Felipe Contreras
In-Reply-To: <vpqiqlh1p8t.fsf@bauges.imag.fr>

Matthieu Moy <Matthieu.Moy@imag.fr> writes:

> But that doesn't apply to "git diff". Both "git diff" and "git diff
> --cached" work with the index.

It is so often used against HEAD that it is the default for --cached mode.
If it confuses your students, do not teach them "git diff --cached"
without teaching "git diff --cached HEAD" first.

> ... which is everything but intuitive. The option name doesn't tell
> the user what the command is doing.

Surely, I already said that --cached vs --index are not the best words,
didn't I?

But the point was that introducing STAGE and other "ref-looking tokens"
not only does not help the situation at all, but makes it worse.

> I can understand the historical reasons, but I think finding a way to
> get rid of this historical terminology mess should be encourraged.

No, you should aim higher, if you are trying to change things.

Find a way to convey the concepts better, and come up with a way (i.e. set
of options---as I already explained why ref looking tokens is inferiour
than explicit options) that does not break the backward compatibility, and
help new people learn.  I am not interested in the "ref-looking tokens"
because they fail the latter test.

>>    - for all commands, working with work tree is the default, so there is
>>      no --work-tree option (we could add one, if you really want).
>
> Except "git checkout", which takes the index by default, and
> a commit if specified. It makes sense since checking-out from the
> working tree doesn't make sense,...

You say "except X" but you need to qualify "but that default makes sense
for X".  I'd say that is true for all X---so you are saying the default is
sensible, which is good.

> Except "git ls-files", too....

It is a plumbing that only works with the index.  What's your problem?

> See, you complain about special cases with the proposal, but the
> current UI _has_ tons of special cases like this.

The two example you quoted above are neither tons nor special cases.  And
I am not saying that "ref-looking tokens are bad because there are special
cases" anyway.

^ permalink raw reply

* Re: [RFC/PATCH 0/2] New 'stage' command
From: Junio C Hamano @ 2009-04-07  1:02 UTC (permalink / raw)
  To: David Kågedal
  Cc: Felipe Contreras, markus heidelberg, Sverre Rabbelier,
	David Aguilar, git
In-Reply-To: <87skkligzb.fsf@krank.kagedal.org>

David Kågedal <davidk@lysator.liu.se> writes:

>>    - when you want to work with both the index and the work tree at the
>>      same time, you say STAGEANDWORKTREE (the same disambiguation caveat
>>      applies).
>
> No, where did this come from?

"git apply STAGEANDWORKTREE this.patch".  I do not want "for diff you can
use these metavariables to name two things compared, but you can do so
only for diff".

>> Think.  What does "git log STAGE" mean?  Can you explain why it does not
>> make any sense?
>
> As I already explained, you read way to much into my message.

I think the fundamental difference between us is that you are too attached
to the notion of "for diff you can use these metavariables to name two
things compared".  That by itself looks very nice if you only look at the
diff command line, but I do not want "but you can do so only for diff, so
you have to unlearn the metavariables and do thing in different ways for
other commands" part.

^ permalink raw reply

* Re: [PATCH 1/2] git-checkout.txt: fix incorrect statement about HEAD and index
From: Junio C Hamano @ 2009-04-07  1:08 UTC (permalink / raw)
  To: Matthieu Moy; +Cc: git
In-Reply-To: <1239050722-1227-1-git-send-email-Matthieu.Moy@imag.fr>

Thanks.  Both patches look good.

^ permalink raw reply

* Re: [RFC/PATCH 0/2] New 'stage' command
From: Stefan Karpinski @ 2009-04-07  1:36 UTC (permalink / raw)
  To: Junio C Hamano
  Cc: David Kågedal, git, David Aguilar, Sverre Rabbelier,
	markus.heidelberg, Felipe Contreras
In-Reply-To: <7vy6ud4otd.fsf@gitster.siamese.dyndns.org>

On Mon, Apr 6, 2009 at 11:30 AM, Junio C Hamano <gitster@pobox.com> wrote:
> David Kågedal <davidk@lysator.liu.se> writes:
>
>> What do you mean? This was a suggestion for how git diff should
>> work. I fail to see how you would need a WORKTREEANDTHEINDEX there.
>
> You are talking only about "git diff".  I am talking about the whole git
> suite, because you have to worry about how such a proposal would affect
> other parts of the UI.
>
> For example, what, if anything, should be done to "git grep --cached" and
> "git apply --index"?  Leave them unchanged and only change "git diff"?
>
>> I think this is a basic usability issue for a high-level porcelain
>> command such as diff.
>
> I do not think there is any usability issue.  Why do you think saying
> STAGE in all capital makes it easier to _use_ instead of saying --cached
> (or --index-only)?  In either way, you need to understand the underlying
> concept, such as:

There is most definitely a usability issue here. I use git every day
and I *cannot* for the life of me remember all the inconsistent
stage-related oddball commands. I have a number of aliases for them
(similar to what Felipe is proposing) which are the only way I can
remember them. Whenever I find myself using a git repo without those
aliases, I have to fire up the man pages. Trying to explain all of
this to coworkers that use git—honestly, I don't even try to go there.

^ permalink raw reply

* Re: [PATCH] mailmap: resurrect lower-casing of email addresses
From: A Large Angry SCM @ 2009-04-07  2:08 UTC (permalink / raw)
  To: Johannes Schindelin; +Cc: Junio C Hamano, git
In-Reply-To: <alpine.DEB.1.00.0904061114420.10279@pacific.mpi-cbg.de>

Johannes Schindelin wrote:
> Hi,
> 
> On Fri, 3 Apr 2009, A Large Angry SCM wrote:
> 
>> Sorry, this is not a flame war (and as Peff already sent a response that 
>> superior to my own) so I'll let Junio decide.
> 
> Thanks for keeping a cool head where I failed.  My sincere apologies.
> 
>> However, to keep the peace (and as a thank you for all the hard work to 
>> date, I'll say that I'm scheduled to be be Germany and Munich the first 
>> 10 days in October and I'll buy the first $100 dollars in drinks at any 
>> meet that participate in (as a thank you to all the hard work for git 
>> that has been performed) that may happen that I participate in).
> 
> I'll take you up on that!

s/Germany and Munich/Berlin and Munich/

^ permalink raw reply

* git over http not re-authenticating after 301 redirect?
From: Paul Vincent Craven @ 2009-04-07  2:14 UTC (permalink / raw)
  To: git

When I do a git-push from a repository I set up, I get:

craven@craven-desktop:~/docs$ git push
Unable to create branch path
http://username:password@server.simpson.edu/my_repo.git/info
Error: cannot lock existing info/refs
error: failed to push some refs to
'http://username:password@server.simpson.edu/my_repo.git/'

The web log shows:
10.1.21.232 - username [06/Apr/2009:21:24:04 -0500] "PROPFIND
/my_repo.git/ HTTP/1.1" 207 559 "-" "git/1.5.6.3"
10.1.21.232 - username [06/Apr/2009:21:24:04 -0500] "HEAD
/my_repo.git/info/refs HTTP/1.1" 200 - "-" "git/1.5.6.3"
10.1.21.232 - username [06/Apr/2009:21:24:04 -0500] "HEAD
/my_repo.git/objects/info/packs HTTP/1.1" 200 - "-" "git/1.5.6.3"
10.1.21.232 - username [06/Apr/2009:21:24:04 -0500] "MKCOL
/my_repo.git/info HTTP/1.1" 301 383 "-" "git/1.5.6.3"
10.1.21.232 - - [06/Apr/2009:21:24:04 -0500] "MKCOL /my_repo.git/info/
HTTP/1.1" 401 536 "-" "git/1.5.6.3"

Note that after the 301 redirect, I don't seem to have a username sent
anymore. I'm not sure this is the issue, but is seems like a
possibility.

I have the same issue on other computers that have cloned the repository.

The /my_repo.git/info/ directory does exist.

I thought I had this working the first day I set it up, but now it no
longer does. If someone could point me in the correct direction, I'd
appreciate it.

-- 
Paul Vincent Craven

^ permalink raw reply

* Re: Fetching SHA id's instead of named references?
From: Nicolas Pitre @ 2009-04-07  2:34 UTC (permalink / raw)
  To: Klas Lindberg; +Cc: Shawn O. Pearce, Git Users List
In-Reply-To: <33f4f4d70904061640j1b03c499x1765da1a72a411f3@mail.gmail.com>

[-- Attachment #1: Type: TEXT/PLAIN, Size: 3664 bytes --]

On Tue, 7 Apr 2009, Klas Lindberg wrote:

> On Mon, Apr 6, 2009 at 6:55 PM, Nicolas Pitre <nico@cam.org> wrote:
> 
> > Why can't you simply fetch the remote from its branch tip and then
> > figure out / checkout the particular unnamed reference you wish locally?
> 
> It is a pretty sane thing to do, but it makes me a bit nervous that
> branches are not immutable. Let's say I decide on a manifest format
> where each tree is listed as a branch name plus the current SHA key on
> that branch. The branch name is needed to enable fetch, but if the
> branch is later renamed because of a change in naming policy, or its
> name simply reused to refer to something completely different (*),
> then there is no guarantee that the SHA key is reachable through that
> branch name.

In git terms, this is called "history rewriting".  And you really don't 
want to do that if your repository is pulled by other people, unless 
there is an explicit statement about that fact.

Still, if you fetch all branches from the remote (which is the default 
behavior anyway), then the branch you're interested in will always 
contain the particular commit you're looking for, regardless of the name 
of the branch.  While it is true that branches may not be immutable, any 
commit they collectively refer to still are immutable.

If the remote has deleted the only branch through which your particular 
commit of interest was reachable, then of course pulling all branches 
from the remote won't hhelp you.  But nor would a fetch with the 
particular commit's SHA1 because it may well have been pruned from the 
remote repository at that point.

> (*) These situations cannot be discounted in an organization with,
> say, a few thousand employees and several tens of really big projects
> with considerable overlap. I have to take into account that the right
> hand may not know what the left hand is doing all the time.

Thing is, with the distributed nature of git, nothing prevents you from 
keeping a local version of the commit you're interested in.  Unlike with 
a central repository where someone else might delete a branch you need, 
with git you will still have access to that particular commit locally 
regardless if the remote repository has deleted it or not.

> > Unlike with CVS/SVN, you don't need anything from the remote if you want
> > to checkout an old version. In particular, there is no need for you to
> > only fetch that old version from the remote.  You just fetch everything
> > from the remote and then checkout the particular old version you wish.
> 
> Please consider when you have to recreate some particular forest that
> you never worked on before, but now you have to fetch and recreate a 3
> year old version so that you can work on that critical error report.
> And I may really not want to fetch everything. Some projects are just
> very very big.

There is nothing a tool can do for you if someone is determined to be 
stupid with it.  In other words, don't delete a branch if it contains 
important stuff.  You may rename it if you wish.  And if you don't want 
to fetch everything then you may always find out about the right branch 
to pull with "git branch --contains <SHA1>".

> I think that what I would need is either
> 
>  * Immutable tags, or
>  * A way to maintain sets of indestructible commits based on SHA id's
> and a way to fetch them without going through a named reference.
> 
> The second option seems better because it would allow for recursion on
> submodules and it doesn't pollute the tag name space.

Maybe.  But as others already explained, there are technical reasons 
that makes such a solution undesirable.


Nicolas

^ permalink raw reply

* [PATCH 2/3] rev-list: remove last static vars used in "show_commit"
From: Christian Couder @ 2009-04-06 20:28 UTC (permalink / raw)
  To: Junio C Hamano; +Cc: git, Johannes Schindelin
In-Reply-To: <20090407040854.4338.94304.chriscool@tuxfamily.org>

This patch removes the last static variables that were used in
the "show_commit" function.

To do that, we create a new "rev_list_info" struct that we will pass
in the "void *data" argument to "show_commit".

This means that we have to change the first argument to
"show_bisect_vars" too.

While at it, we also remove a "struct commit_list *list" variable
in "cmd_rev_list" that is not really needed.

Signed-off-by: Christian Couder <chriscool@tuxfamily.org>
---
 bisect.c           |    6 +++++-
 bisect.h           |   14 ++++++++------
 builtin-rev-list.c |   42 +++++++++++++++++++++---------------------
 3 files changed, 34 insertions(+), 28 deletions(-)

diff --git a/bisect.c b/bisect.c
index 69f8860..4d2a150 100644
--- a/bisect.c
+++ b/bisect.c
@@ -535,8 +535,12 @@ static void bisect_rev_setup(struct rev_info *revs, const char *prefix)
 int bisect_next_vars(const char *prefix)
 {
 	struct rev_info revs;
+	struct rev_list_info info;
 	int reaches = 0, all = 0;
 
+	memset(&info, 0, sizeof(info));
+	info.revs = &revs;
+
 	bisect_rev_setup(&revs, prefix);
 
 	if (prepare_revision_walk(&revs))
@@ -547,6 +551,6 @@ int bisect_next_vars(const char *prefix)
 	revs.commits = find_bisection(revs.commits, &reaches, &all,
 				      !!skipped_sha1_nr);
 
-	return show_bisect_vars(&revs, reaches, all,
+	return show_bisect_vars(&info, reaches, all,
 				BISECT_SHOW_TRIED | BISECT_SHOW_STRINGED);
 }
diff --git a/bisect.h b/bisect.h
index f5d1067..b1c334d 100644
--- a/bisect.h
+++ b/bisect.h
@@ -14,12 +14,14 @@ extern struct commit_list *filter_skipped(struct commit_list *list,
 #define BISECT_SHOW_TRIED	(1<<1)
 #define BISECT_SHOW_STRINGED	(1<<2)
 
-/*
- * The flag BISECT_SHOW_ALL should not be set if this function is called
- * from outside "builtin-rev-list.c" as otherwise it would use
- * static "revs" from this file.
- */
-extern int show_bisect_vars(struct rev_info *revs, int reaches, int all,
+struct rev_list_info {
+	struct rev_info *revs;
+	int show_timestamp;
+	int hdr_termination;
+	const char *header_prefix;
+};
+
+extern int show_bisect_vars(struct rev_list_info *info, int reaches, int all,
 			    int flags);
 
 extern int bisect_next_vars(const char *prefix);
diff --git a/builtin-rev-list.c b/builtin-rev-list.c
index cd6f6b8..244b73e 100644
--- a/builtin-rev-list.c
+++ b/builtin-rev-list.c
@@ -42,21 +42,18 @@ static const char rev_list_usage[] =
 "    --bisect-all"
 ;
 
-static int show_timestamp;
-static int hdr_termination;
-static const char *header_prefix;
-
 static void finish_commit(struct commit *commit, void *data);
 static void show_commit(struct commit *commit, void *data)
 {
-	struct rev_info *revs = data;
+	struct rev_list_info *info = data;
+	struct rev_info *revs = info->revs;
 
 	graph_show_commit(revs->graph);
 
-	if (show_timestamp)
+	if (info->show_timestamp)
 		printf("%lu ", commit->date);
-	if (header_prefix)
-		fputs(header_prefix, stdout);
+	if (info->header_prefix)
+		fputs(info->header_prefix, stdout);
 
 	if (!revs->graph) {
 		if (commit->object.flags & BOUNDARY)
@@ -138,7 +135,7 @@ static void show_commit(struct commit *commit, void *data)
 			}
 		} else {
 			if (buf.len)
-				printf("%s%c", buf.buf, hdr_termination);
+				printf("%s%c", buf.buf, info->hdr_termination);
 		}
 		strbuf_release(&buf);
 	} else {
@@ -236,11 +233,13 @@ static void show_tried_revs(struct commit_list *tried, int stringed)
 	printf(stringed ? "' &&\n" : "'\n");
 }
 
-int show_bisect_vars(struct rev_info *revs, int reaches, int all, int flags)
+int show_bisect_vars(struct rev_list_info *info, int reaches, int all,
+		     int flags)
 {
 	int cnt;
 	char hex[41] = "", *format;
 	struct commit_list *tried;
+	struct rev_info *revs = info->revs;
 
 	if (!revs->commits && !(flags & BISECT_SHOW_TRIED))
 		return 1;
@@ -264,7 +263,7 @@ int show_bisect_vars(struct rev_info *revs, int reaches, int all, int flags)
 		strcpy(hex, sha1_to_hex(revs->commits->item->object.sha1));
 
 	if (flags & BISECT_SHOW_ALL) {
-		traverse_commit_list(revs, show_commit, show_object, revs);
+		traverse_commit_list(revs, show_commit, show_object, info);
 		printf("------\n");
 	}
 
@@ -298,7 +297,7 @@ int show_bisect_vars(struct rev_info *revs, int reaches, int all, int flags)
 int cmd_rev_list(int argc, const char **argv, const char *prefix)
 {
 	struct rev_info revs;
-	struct commit_list *list;
+	struct rev_list_info info;
 	int i;
 	int read_from_stdin = 0;
 	int bisect_list = 0;
@@ -313,6 +312,9 @@ int cmd_rev_list(int argc, const char **argv, const char *prefix)
 	revs.commit_format = CMIT_FMT_UNSPECIFIED;
 	argc = setup_revisions(argc, argv, &revs, NULL);
 
+	memset(&info, 0, sizeof(info));
+	info.revs = &revs;
+
 	quiet = DIFF_OPT_TST(&revs.diffopt, QUIET);
 	for (i = 1 ; i < argc; i++) {
 		const char *arg = argv[i];
@@ -322,7 +324,7 @@ int cmd_rev_list(int argc, const char **argv, const char *prefix)
 			continue;
 		}
 		if (!strcmp(arg, "--timestamp")) {
-			show_timestamp = 1;
+			info.show_timestamp = 1;
 			continue;
 		}
 		if (!strcmp(arg, "--bisect")) {
@@ -352,19 +354,17 @@ int cmd_rev_list(int argc, const char **argv, const char *prefix)
 	}
 	if (revs.commit_format != CMIT_FMT_UNSPECIFIED) {
 		/* The command line has a --pretty  */
-		hdr_termination = '\n';
+		info.hdr_termination = '\n';
 		if (revs.commit_format == CMIT_FMT_ONELINE)
-			header_prefix = "";
+			info.header_prefix = "";
 		else
-			header_prefix = "commit ";
+			info.header_prefix = "commit ";
 	}
 	else if (revs.verbose_header)
 		/* Only --header was specified */
 		revs.commit_format = CMIT_FMT_RAW;
 
-	list = revs.commits;
-
-	if ((!list &&
+	if ((!revs.commits &&
 	     (!(revs.tag_objects||revs.tree_objects||revs.blob_objects) &&
 	      !revs.pending.nr)) ||
 	    revs.diff)
@@ -387,14 +387,14 @@ int cmd_rev_list(int argc, const char **argv, const char *prefix)
 					      bisect_find_all);
 
 		if (bisect_show_vars)
-			return show_bisect_vars(&revs, reaches, all,
+			return show_bisect_vars(&info, reaches, all,
 						bisect_show_all ? BISECT_SHOW_ALL : 0);
 	}
 
 	traverse_commit_list(&revs,
 			     quiet ? finish_commit : show_commit,
 			     quiet ? finish_object : show_object,
-			     &revs);
+			     &info);
 
 	return 0;
 }
-- 
1.6.2.2.537.g3b83b

^ permalink raw reply related

* [PATCH 1/3] list-objects: add "void *data" parameter to show functions
From: Christian Couder @ 2009-04-06 19:28 UTC (permalink / raw)
  To: Junio C Hamano; +Cc: git, Johannes Schindelin
In-Reply-To: <20090407040819.4338.4291.chriscool@tuxfamily.org>

The goal of this patch is to get rid of the "static struct rev_info
revs" static variable in "builtin-rev-list.c".

To do that, we need to pass the revs to the "show_commit" function
in "builtin-rev-list.c" and this in turn means that the
"traverse_commit_list" function in "list-objects.c" must be passed
functions pointers to functions with 2 parameters instead of one.

So we have to change all the callers and all the functions passed
to "traverse_commit_list".

Anyway this makes the code more clean and more generic, so it
should be a good thing in the long run.

Signed-off-by: Christian Couder <chriscool@tuxfamily.org>
---
 builtin-pack-objects.c |    6 ++--
 builtin-rev-list.c     |   68 ++++++++++++++++++++++++-----------------------
 list-objects.c         |    9 +++---
 list-objects.h         |    6 ++--
 upload-pack.c          |    6 ++--
 5 files changed, 49 insertions(+), 46 deletions(-)

diff --git a/builtin-pack-objects.c b/builtin-pack-objects.c
index 50f8cc1..8c5eaba 100644
--- a/builtin-pack-objects.c
+++ b/builtin-pack-objects.c
@@ -1901,13 +1901,13 @@ static void read_object_list_from_stdin(void)
 
 #define OBJECT_ADDED (1u<<20)
 
-static void show_commit(struct commit *commit)
+static void show_commit(struct commit *commit, void *data)
 {
 	add_object_entry(commit->object.sha1, OBJ_COMMIT, NULL, 0);
 	commit->object.flags |= OBJECT_ADDED;
 }
 
-static void show_object(struct object_array_entry *p)
+static void show_object(struct object_array_entry *p, void *data)
 {
 	add_preferred_base_object(p->name);
 	add_object_entry(p->item->sha1, p->item->type, p->name, 0);
@@ -2071,7 +2071,7 @@ static void get_object_list(int ac, const char **av)
 	if (prepare_revision_walk(&revs))
 		die("revision walk setup failed");
 	mark_edges_uninteresting(revs.commits, &revs, show_edge);
-	traverse_commit_list(&revs, show_commit, show_object);
+	traverse_commit_list(&revs, show_commit, show_object, NULL);
 
 	if (keep_unreachable)
 		add_objects_in_unpacked_packs(&revs);
diff --git a/builtin-rev-list.c b/builtin-rev-list.c
index eb34147..cd6f6b8 100644
--- a/builtin-rev-list.c
+++ b/builtin-rev-list.c
@@ -42,72 +42,72 @@ static const char rev_list_usage[] =
 "    --bisect-all"
 ;
 
-static struct rev_info revs;
-
 static int show_timestamp;
 static int hdr_termination;
 static const char *header_prefix;
 
-static void finish_commit(struct commit *commit);
-static void show_commit(struct commit *commit)
+static void finish_commit(struct commit *commit, void *data);
+static void show_commit(struct commit *commit, void *data)
 {
-	graph_show_commit(revs.graph);
+	struct rev_info *revs = data;
+
+	graph_show_commit(revs->graph);
 
 	if (show_timestamp)
 		printf("%lu ", commit->date);
 	if (header_prefix)
 		fputs(header_prefix, stdout);
 
-	if (!revs.graph) {
+	if (!revs->graph) {
 		if (commit->object.flags & BOUNDARY)
 			putchar('-');
 		else if (commit->object.flags & UNINTERESTING)
 			putchar('^');
-		else if (revs.left_right) {
+		else if (revs->left_right) {
 			if (commit->object.flags & SYMMETRIC_LEFT)
 				putchar('<');
 			else
 				putchar('>');
 		}
 	}
-	if (revs.abbrev_commit && revs.abbrev)
-		fputs(find_unique_abbrev(commit->object.sha1, revs.abbrev),
+	if (revs->abbrev_commit && revs->abbrev)
+		fputs(find_unique_abbrev(commit->object.sha1, revs->abbrev),
 		      stdout);
 	else
 		fputs(sha1_to_hex(commit->object.sha1), stdout);
-	if (revs.print_parents) {
+	if (revs->print_parents) {
 		struct commit_list *parents = commit->parents;
 		while (parents) {
 			printf(" %s", sha1_to_hex(parents->item->object.sha1));
 			parents = parents->next;
 		}
 	}
-	if (revs.children.name) {
+	if (revs->children.name) {
 		struct commit_list *children;
 
-		children = lookup_decoration(&revs.children, &commit->object);
+		children = lookup_decoration(&revs->children, &commit->object);
 		while (children) {
 			printf(" %s", sha1_to_hex(children->item->object.sha1));
 			children = children->next;
 		}
 	}
-	show_decorations(&revs, commit);
-	if (revs.commit_format == CMIT_FMT_ONELINE)
+	show_decorations(revs, commit);
+	if (revs->commit_format == CMIT_FMT_ONELINE)
 		putchar(' ');
 	else
 		putchar('\n');
 
-	if (revs.verbose_header && commit->buffer) {
+	if (revs->verbose_header && commit->buffer) {
 		struct strbuf buf = STRBUF_INIT;
-		pretty_print_commit(revs.commit_format, commit,
-				    &buf, revs.abbrev, NULL, NULL,
-				    revs.date_mode, 0);
-		if (revs.graph) {
+		pretty_print_commit(revs->commit_format, commit,
+				    &buf, revs->abbrev, NULL, NULL,
+				    revs->date_mode, 0);
+		if (revs->graph) {
 			if (buf.len) {
-				if (revs.commit_format != CMIT_FMT_ONELINE)
-					graph_show_oneline(revs.graph);
+				if (revs->commit_format != CMIT_FMT_ONELINE)
+					graph_show_oneline(revs->graph);
 
-				graph_show_commit_msg(revs.graph, &buf);
+				graph_show_commit_msg(revs->graph, &buf);
 
 				/*
 				 * Add a newline after the commit message.
@@ -125,7 +125,7 @@ static void show_commit(struct commit *commit)
 				 * format doesn't explicitly end in a newline.)
 				 */
 				if (buf.len && buf.buf[buf.len - 1] == '\n')
-					graph_show_padding(revs.graph);
+					graph_show_padding(revs->graph);
 				putchar('\n');
 			} else {
 				/*
@@ -133,7 +133,7 @@ static void show_commit(struct commit *commit)
 				 * the rest of the graph output for this
 				 * commit.
 				 */
-				if (graph_show_remainder(revs.graph))
+				if (graph_show_remainder(revs->graph))
 					putchar('\n');
 			}
 		} else {
@@ -142,14 +142,14 @@ static void show_commit(struct commit *commit)
 		}
 		strbuf_release(&buf);
 	} else {
-		if (graph_show_remainder(revs.graph))
+		if (graph_show_remainder(revs->graph))
 			putchar('\n');
 	}
 	maybe_flush_or_die(stdout, "stdout");
-	finish_commit(commit);
+	finish_commit(commit, data);
 }
 
-static void finish_commit(struct commit *commit)
+static void finish_commit(struct commit *commit, void *data)
 {
 	if (commit->parents) {
 		free_commit_list(commit->parents);
@@ -159,20 +159,20 @@ static void finish_commit(struct commit *commit)
 	commit->buffer = NULL;
 }
 
-static void finish_object(struct object_array_entry *p)
+static void finish_object(struct object_array_entry *p, void *data)
 {
 	if (p->item->type == OBJ_BLOB && !has_sha1_file(p->item->sha1))
 		die("missing blob object '%s'", sha1_to_hex(p->item->sha1));
 }
 
-static void show_object(struct object_array_entry *p)
+static void show_object(struct object_array_entry *p, void *data)
 {
 	/* An object with name "foo\n0000000..." can be used to
 	 * confuse downstream "git pack-objects" very badly.
 	 */
 	const char *ep = strchr(p->name, '\n');
 
-	finish_object(p);
+	finish_object(p, data);
 	if (ep) {
 		printf("%s %.*s\n", sha1_to_hex(p->item->sha1),
 		       (int) (ep - p->name),
@@ -264,7 +264,7 @@ int show_bisect_vars(struct rev_info *revs, int reaches, int all, int flags)
 		strcpy(hex, sha1_to_hex(revs->commits->item->object.sha1));
 
 	if (flags & BISECT_SHOW_ALL) {
-		traverse_commit_list(revs, show_commit, show_object);
+		traverse_commit_list(revs, show_commit, show_object, revs);
 		printf("------\n");
 	}
 
@@ -297,6 +297,7 @@ int show_bisect_vars(struct rev_info *revs, int reaches, int all, int flags)
 
 int cmd_rev_list(int argc, const char **argv, const char *prefix)
 {
+	struct rev_info revs;
 	struct commit_list *list;
 	int i;
 	int read_from_stdin = 0;
@@ -391,8 +392,9 @@ int cmd_rev_list(int argc, const char **argv, const char *prefix)
 	}
 
 	traverse_commit_list(&revs,
-		quiet ? finish_commit : show_commit,
-		quiet ? finish_object : show_object);
+			     quiet ? finish_commit : show_commit,
+			     quiet ? finish_object : show_object,
+			     &revs);
 
 	return 0;
 }
diff --git a/list-objects.c b/list-objects.c
index c8b8375..208a4cb 100644
--- a/list-objects.c
+++ b/list-objects.c
@@ -137,8 +137,9 @@ void mark_edges_uninteresting(struct commit_list *list,
 }
 
 void traverse_commit_list(struct rev_info *revs,
-			  void (*show_commit)(struct commit *),
-			  void (*show_object)(struct object_array_entry *))
+			  show_commit_fn show_commit,
+			  show_object_fn show_object,
+			  void *data)
 {
 	int i;
 	struct commit *commit;
@@ -146,7 +147,7 @@ void traverse_commit_list(struct rev_info *revs,
 
 	while ((commit = get_revision(revs)) != NULL) {
 		process_tree(revs, commit->tree, &objects, NULL, "");
-		show_commit(commit);
+		show_commit(commit, data);
 	}
 	for (i = 0; i < revs->pending.nr; i++) {
 		struct object_array_entry *pending = revs->pending.objects + i;
@@ -173,7 +174,7 @@ void traverse_commit_list(struct rev_info *revs,
 		    sha1_to_hex(obj->sha1), name);
 	}
 	for (i = 0; i < objects.nr; i++)
-		show_object(&objects.objects[i]);
+		show_object(&objects.objects[i], data);
 	free(objects.objects);
 	if (revs->pending.nr) {
 		free(revs->pending.objects);
diff --git a/list-objects.h b/list-objects.h
index 0f41391..47fae2e 100644
--- a/list-objects.h
+++ b/list-objects.h
@@ -1,11 +1,11 @@
 #ifndef LIST_OBJECTS_H
 #define LIST_OBJECTS_H
 
-typedef void (*show_commit_fn)(struct commit *);
-typedef void (*show_object_fn)(struct object_array_entry *);
+typedef void (*show_commit_fn)(struct commit *, void *);
+typedef void (*show_object_fn)(struct object_array_entry *, void *);
 typedef void (*show_edge_fn)(struct commit *);
 
-void traverse_commit_list(struct rev_info *revs, show_commit_fn, show_object_fn);
+void traverse_commit_list(struct rev_info *, show_commit_fn, show_object_fn, void *);
 
 void mark_edges_uninteresting(struct commit_list *, struct rev_info *, show_edge_fn);
 
diff --git a/upload-pack.c b/upload-pack.c
index 4d7357f..a28a0c4 100644
--- a/upload-pack.c
+++ b/upload-pack.c
@@ -66,7 +66,7 @@ static ssize_t send_client_data(int fd, const char *data, ssize_t sz)
 }
 
 static FILE *pack_pipe = NULL;
-static void show_commit(struct commit *commit)
+static void show_commit(struct commit *commit, void *data)
 {
 	if (commit->object.flags & BOUNDARY)
 		fputc('-', pack_pipe);
@@ -78,7 +78,7 @@ static void show_commit(struct commit *commit)
 	commit->buffer = NULL;
 }
 
-static void show_object(struct object_array_entry *p)
+static void show_object(struct object_array_entry *p, void *data)
 {
 	/* An object with name "foo\n0000000..." can be used to
 	 * confuse downstream git-pack-objects very badly.
@@ -134,7 +134,7 @@ static int do_rev_list(int fd, void *create_full_pack)
 	if (prepare_revision_walk(&revs))
 		die("revision walk setup failed");
 	mark_edges_uninteresting(revs.commits, &revs, show_edge);
-	traverse_commit_list(&revs, show_commit, show_object);
+	traverse_commit_list(&revs, show_commit, show_object, NULL);
 	fflush(pack_pipe);
 	fclose(pack_pipe);
 	return 0;
-- 
1.6.2.2.537.g3b83b

^ permalink raw reply related

* [PATCH 3/3] rev-list: add "int bisect_show_flags" in "struct rev_list_info"
From: Christian Couder @ 2009-04-07  3:08 UTC (permalink / raw)
  To: Junio C Hamano; +Cc: git, Johannes Schindelin
In-Reply-To: <20090407040854.4338.40055.chriscool@tuxfamily.org>

This is a cleanup patch to make it easier to use the
"show_bisect_vars" function and take advantage of the rev_list_info
struct.

Signed-off-by: Christian Couder <chriscool@tuxfamily.org>
---
 bisect.c           |    4 ++--
 bisect.h           |    6 +++---
 builtin-rev-list.c |   11 ++++-------
 3 files changed, 9 insertions(+), 12 deletions(-)

diff --git a/bisect.c b/bisect.c
index 4d2a150..58f7e6f 100644
--- a/bisect.c
+++ b/bisect.c
@@ -540,6 +540,7 @@ int bisect_next_vars(const char *prefix)
 
 	memset(&info, 0, sizeof(info));
 	info.revs = &revs;
+	info.bisect_show_flags = BISECT_SHOW_TRIED | BISECT_SHOW_STRINGED;
 
 	bisect_rev_setup(&revs, prefix);
 
@@ -551,6 +552,5 @@ int bisect_next_vars(const char *prefix)
 	revs.commits = find_bisection(revs.commits, &reaches, &all,
 				      !!skipped_sha1_nr);
 
-	return show_bisect_vars(&info, reaches, all,
-				BISECT_SHOW_TRIED | BISECT_SHOW_STRINGED);
+	return show_bisect_vars(&info, reaches, all);
 }
diff --git a/bisect.h b/bisect.h
index b1c334d..fdba913 100644
--- a/bisect.h
+++ b/bisect.h
@@ -9,20 +9,20 @@ extern struct commit_list *filter_skipped(struct commit_list *list,
 					  struct commit_list **tried,
 					  int show_all);
 
-/* show_bisect_vars flags */
+/* bisect_show_flags flags in struct rev_list_info */
 #define BISECT_SHOW_ALL		(1<<0)
 #define BISECT_SHOW_TRIED	(1<<1)
 #define BISECT_SHOW_STRINGED	(1<<2)
 
 struct rev_list_info {
 	struct rev_info *revs;
+	int bisect_show_flags;
 	int show_timestamp;
 	int hdr_termination;
 	const char *header_prefix;
 };
 
-extern int show_bisect_vars(struct rev_list_info *info, int reaches, int all,
-			    int flags);
+extern int show_bisect_vars(struct rev_list_info *info, int reaches, int all);
 
 extern int bisect_next_vars(const char *prefix);
 
diff --git a/builtin-rev-list.c b/builtin-rev-list.c
index 244b73e..193993c 100644
--- a/builtin-rev-list.c
+++ b/builtin-rev-list.c
@@ -233,10 +233,9 @@ static void show_tried_revs(struct commit_list *tried, int stringed)
 	printf(stringed ? "' &&\n" : "'\n");
 }
 
-int show_bisect_vars(struct rev_list_info *info, int reaches, int all,
-		     int flags)
+int show_bisect_vars(struct rev_list_info *info, int reaches, int all)
 {
-	int cnt;
+	int cnt, flags = info->bisect_show_flags;
 	char hex[41] = "", *format;
 	struct commit_list *tried;
 	struct rev_info *revs = info->revs;
@@ -303,7 +302,6 @@ int cmd_rev_list(int argc, const char **argv, const char *prefix)
 	int bisect_list = 0;
 	int bisect_show_vars = 0;
 	int bisect_find_all = 0;
-	int bisect_show_all = 0;
 	int quiet = 0;
 
 	git_config(git_default_config, NULL);
@@ -334,7 +332,7 @@ int cmd_rev_list(int argc, const char **argv, const char *prefix)
 		if (!strcmp(arg, "--bisect-all")) {
 			bisect_list = 1;
 			bisect_find_all = 1;
-			bisect_show_all = 1;
+			info.bisect_show_flags = BISECT_SHOW_ALL;
 			revs.show_decorations = 1;
 			continue;
 		}
@@ -387,8 +385,7 @@ int cmd_rev_list(int argc, const char **argv, const char *prefix)
 					      bisect_find_all);
 
 		if (bisect_show_vars)
-			return show_bisect_vars(&info, reaches, all,
-						bisect_show_all ? BISECT_SHOW_ALL : 0);
+			return show_bisect_vars(&info, reaches, all);
 	}
 
 	traverse_commit_list(&revs,
-- 
1.6.2.2.537.g3b83b

^ permalink raw reply related

* Re: [question] how can i verify whether a local branch is tracking a remote branch?
From: Jeff King @ 2009-04-07  4:41 UTC (permalink / raw)
  To: Paolo Ciarrocchi; +Cc: git
In-Reply-To: <4d8e3fd30904061500m7857f0f1i2b76a2113f30c562@mail.gmail.com>

On Tue, Apr 07, 2009 at 12:00:20AM +0200, Paolo Ciarrocchi wrote:

> > So the questions are:
> >
> >   - is this worth it? The verbose information is already available via
> >     git status, but only for the current branch.
> 
> I think it's a very usefull information.
> I feel like it would be nice to have this information being part of
> the basic git branch output and not associated to the -vv option.

I'm not sure we should disrupt the simplicity of the current "git
branch" output. I would be curious to hear what others think.

-Peff

^ permalink raw reply

* [PATCH 0/3] remove static vars from "builtin-rev-list.c"
From: Christian Couder @ 2009-04-07  4:50 UTC (permalink / raw)
  To: Junio C Hamano; +Cc: git, Johannes Schindelin

This patch series removes all static variables from
"builtin-rev-list.c" except the usage string.

This cleans up the code and should please Dscho.

It also makes it possible to remove restrictions on using the
"sho_bisect_vars" function.


  list-objects: add "void *data" parameter to show functions
  rev-list: remove last static vars used in "show_commit"
  rev-list: add "int bisect_show_flags" in "struct rev_list_info"

 bisect.c               |    8 +++-
 bisect.h               |   18 ++++----
 builtin-pack-objects.c |    6 +-
 builtin-rev-list.c     |  109 ++++++++++++++++++++++++------------------------
 list-objects.c         |    9 ++--
 list-objects.h         |    6 +-
 upload-pack.c          |    6 +-
 7 files changed, 84 insertions(+), 78 deletions(-)

PS: Sorry but it looks like the script I used to send this series has some bugs.
First the date in the email are wrong, and then I have to resend this cover letter
because it did not appear on the mailing list.

^ permalink raw reply

* Re: [PATCH] mailmap: resurrect lower-casing of email addresses
From: Marius Storm-Olsen @ 2009-04-07  5:52 UTC (permalink / raw)
  To: Johannes Schindelin; +Cc: git, gitster
In-Reply-To: <f182fb1700e8dea15459fd02ced2a6e5797bec99.1238458535u.git.johannes.schindelin@gmx.de>

[-- Attachment #1: Type: text/plain, Size: 687 bytes --]

Johannes Schindelin said the following on 31.03.2009 02:18:
> Commit 0925ce4(Add map_user() and clear_mailmap() to mailmap) broke the
> lower-casing of email addresses.  This mostly did not matter if your
> .mailmap has only lower-case email addresses;  However, we did not
> require .mailmap to contain lowercase-only email addresses.
> 
> Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>

Ouch! Sorry for missing that part! IMO, it would be correct to simply 
restore previous behavior to lowercase the whole email, so:

Ack-by: Marius Storm-Olsen <marius@trolltech.com>

-- 
.marius [@trolltech.com]
'if you know what you're doing, it's not research'


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 187 bytes --]

^ permalink raw reply


This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox