* Re: What's cooking in git.git (Aug 2009, #05; Wed, 26)
From: Daniel Barkalow @ 2009-08-31 17:06 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vskfat07h.fsf@alter.siamese.dyndns.org>
On Sat, 29 Aug 2009, Junio C Hamano wrote:
> Daniel Barkalow <barkalow@iabervon.org> writes:
>
> >> There was a discussion that suggests that the use of colon ':' before vcs
> >> helper name needs to be corrected. Nothing happened since.
> >
> > I believe the outcome of that discussion was:
> >
> > - We want to keep supporting using regular location URLs that are URLs of
> > git repositories (e.g., http://git.savannah.gnu.org/cgit/xboard.git),
> > and we probably want to do it with a helper which runs when
> > run_command() is given "remote-<scheme>". I think installing hardlinks
> > in EXECPATH ended up being the best implementation here.
>
> That is different from what I recall.
>
> I think you said <scheme> in the above to mean that in the general URL
> syntax, <scheme> refers to the token before the colon, and you would be
> feeding the rest (i.e. after the colon, and for many <scheme>'s it
> typically begins with //) to the scheme.
>
> A flaw with this that was pointed out was that this conflicts with the
> scp-like syntax. A remote.$name.url of foo:bar/baz could name
> $HOME/bar/baz on host foo (perhaps a nickname in .ssh/config), or the
> source "foo" helper recognizes with the name bar/baz.
>
> If I recall correctly, suggestions made later in the discussion were to
> use either <helper>+ or <helper>:: as the prefix to avoid this issue, and
> use it to choose remote-<helper> (and I think I probably would vote for
> double-colon, if only to avoid confusion with our own earlier misdesigned
> syntax git+ssh://), so the canonical syntax would be:
(with the syntax <helper>+, "git+ssh://" would specify the helper "git",
which is as good an explicit identifier of the internal handling as any)
>
> <helper>::<whatever is fed to the helper, typicall a URL>
>
> while we would support obvious short-hands for transports we traditionally
> supported without explicit "<helper>::" prefix when we choose to eject it
> from "built-in" set of transports.
>
> E.g. http://git.savannah.gnu.org/cgit/xboard.git would be handled by curl
> based walker, so if you spell it in the very canonical form, the url would
> be curl::http://git.savannah.gnu.org/cgit/xboard.git, but nobody has to
> use it. Instead, the transport dispatcher internally recognizes http://
> and picks the curl based walker helper, which is remote-curl without any
> extra hardlinks.
If the policy is that we're going to have "traditionally supported"
schemes, where the internal code knows what helper supports them, I can
fix up the series so that the curl-based helper is named "curl", and we
can say that the check for "http://", "ftp://", and "https://" is
recognizing traditionally-supported schemes, and we can defer coming up
with what the syntax for the explicit handler selection is. (For that
matter, if there's a // after the colon, it's obviously not a
handy ssh-style location, since the second slash would do nothing)
I think you're right that we decided that things we used to support
internally are a special case, and there's no need to try to generalize
them to be the general mechanism (even though I think we simultaneously
worked out how to implement the design we were abandoning, which confused
my memory).
> > - We want to support a separate "vcs" option for cases where repositories
> > in the foreign system need to be addressed through the combination of a
> > bunch of options, which will be read from the configuration by the
> > helper. The helper which gets run is "remote-<value of vcs option>".
> > This is in pu.
>
> After you explained this in the thread (I think for the second time), I
> see no problem with this, except that I think to support this we should
> notice and raise an error when we see a remote has both vcs and url,
> because the only reason we would want to say "vcs", if I recall your
> explanation correctly, is that such a transport does not have the concept
> of URL, i.e. a well defined single string that identifies the repository.
A user who mostly uses Perforce as a foreign repositories but is using a
SVN repo on occasion might want to use "vcs" regardless, but I agree with
forcing the helper to use a different option for the case of a URL that
git isn't going to look at. That is, you ought to be able to use:
[remote "origin"]
vcs = svn
(something) = http://svn.savannah.gnu.org/...
But "(something)" shouldn't be "url".
So my changes will be:
- name the curl-based helper executable "git-remote-curl", and run it for
traditionally supported schemes by special-case.
- prohibit using both "vcs" and "url" in a remote.
Agreed?
-Daniel
*This .sig left intentionally blank*
^ permalink raw reply
* Re: clong an empty repo over ssh causes (harmless) fatal
From: Jeff King @ 2009-08-31 16:41 UTC (permalink / raw)
To: Sitaram Chamarty; +Cc: Matthieu Moy, git
In-Reply-To: <2e24e5b90908310730u53ee27d3nd2b66c1f58202e7@mail.gmail.com>
On Mon, Aug 31, 2009 at 08:00:41PM +0530, Sitaram Chamarty wrote:
> > Maybe you have an older version of Git?
>
> Had 1.6.4, just tried with 1.6.4.2 -- the error is still there, exactly so.
>
> Anything I can do to provide more info?
IIRC, the message you are seeing comes when the _server_ is an older
version of git. It is harmless, though.
-Peff
^ permalink raw reply
* Re: clong an empty repo over ssh causes (harmless) fatal
From: Matthieu Moy @ 2009-08-31 14:47 UTC (permalink / raw)
To: Sitaram Chamarty; +Cc: git
In-Reply-To: <2e24e5b90908310730u53ee27d3nd2b66c1f58202e7@mail.gmail.com>
Sitaram Chamarty <sitaramc@gmail.com> writes:
> To start with, this is Mandriva 2009.1, kernel 2.6.29, git built from
> scratch locally (not an RPM or something). Should I try some other
> things like strace?
Setting $GIT_TRACE to 2 can help, too. The problem is that the git
instance you want to debug is the remote one, I don't know if there's
a better way to do that than putting a wrapper script for
git-upload-pack ...
--
Matthieu
^ permalink raw reply
* Re: clong an empty repo over ssh causes (harmless) fatal
From: Sitaram Chamarty @ 2009-08-31 14:30 UTC (permalink / raw)
To: Matthieu Moy; +Cc: git
In-Reply-To: <vpqskf8z0rj.fsf@bauges.imag.fr>
[apologies if you get this twice]
On Mon, Aug 31, 2009 at 4:52 PM, Matthieu Moy <Matthieu.Moy@imag.fr> wrote:
>
> Sitaram Chamarty <sitaramc@gmail.com> writes:
>
> > Hello,
> >
> > Cloning an empty repo seems to produce a spurious error.
> > The repo still seems fine though.
>
> Can't reproduce here:
>
> $ git clone ssh://.../tmp/empty cloned
> Initialized empty Git repository in /tmp/cloned/.git/
> warning: You appear to have cloned an empty repository.
> $ git --version
> git version 1.6.4.187.gd399.dirty
>
> Maybe you have an older version of Git?
Had 1.6.4, just tried with 1.6.4.2 -- the error is still there, exactly so.
Anything I can do to provide more info?
To start with, this is Mandriva 2009.1, kernel 2.6.29, git built from
scratch locally (not an RPM or something). Should I try some other
things like strace? It's too minor to bother, if that's all it is,
assuming it's not a symptom of something larger :)
>
> --
> Matthieu
^ permalink raw reply
* [PATCH] git-submodule and --upload-pack
From: Giulio Eulisse @ 2009-08-31 13:52 UTC (permalink / raw)
To: git
Ciao,
There was a thread a while ago aboyt having --upload-pack support for
git-submodule.
Given that there was no followup (as far as I can tell) and I needed
pretty much
the same functionality I ported Jason's patch to work on top of 1.6.4.2.
Comments?
Ciao,
Giulio
--
diff --git a/Documentation/git-submodule.txt b/Documentation/git-
submodule.txt
index 683ba1a..50aa930 100644
--- a/Documentation/git-submodule.txt
+++ b/Documentation/git-submodule.txt
@@ -9,8 +9,8 @@ git-submodule - Initialize, update or inspect submodules
SYNOPSIS
--------
[verse]
-'git submodule' [--quiet] add [-b branch]
- [--reference <repository>] [--] <repository> <path>
+'git submodule' [--quiet] add [-b branch]
+ [-u <git-upload-pack>] [--receive-pack <git-receive-
pack>] [--reference <repository>] [--] <repository> <path>
'git submodule' [--quiet] status [--cached] [--] [<path>...]
'git submodule' [--quiet] init [--] [<path>...]
'git submodule' [--quiet] update [--init] [-N|--no-fetch] [--rebase]
@@ -164,6 +164,19 @@ OPTIONS
--branch::
Branch of repository to add as submodule.
+--upload-pack <upload-pack>::
+-u <upload-pack>::
+ When given, and the repository to clone from is accessed
+ via ssh, this specifies a non-default path for the
+ 'git-upload-pack' program on the remote end. See
+ linkgit:git-fetch-pack[1].
+
+--receive-pack <receive-pack>::
+ When given, and the repository to clone from is accessed
+ via ssh, this specifies a non-default path for the
+ 'git-receive-pack' program on the remote end. See
+ linkgit:git-push[1].
+
--cached::
This option is only valid for status and summary commands. These
commands typically use the commit found in the submodule HEAD, but
diff --git a/Documentation/gitmodules.txt b/Documentation/gitmodules.txt
index 5daf750..bf982a6 100644
--- a/Documentation/gitmodules.txt
+++ b/Documentation/gitmodules.txt
@@ -30,6 +30,14 @@ submodule.<name>.path::
submodule.<name>.url::
Defines an url from where the submodule repository can be cloned.
+submodule.<name>.receivepack::
+ The default program to execute on the remote side when pushing. See
+ option \--receive-pack of linkgit:git-push[1].
+
+submodule.<name>.uploadpack::
+ The default program to execute on the remote side when fetching. See
+ option \--upload-pack of linkgit:git-fetch-pack[1].
+
submodule.<name>.update::
Defines what to do when the submodule is updated by the superproject.
If 'checkout' (the default), the new commit specified in the
@@ -41,7 +49,6 @@ submodule.<name>.update::
This config option is overridden if 'git submodule update' is given
the '--merge' or '--rebase' options.
-
EXAMPLES
--------
@@ -53,12 +60,16 @@ Consider the following .gitmodules file:
[submodule "libbar"]
path = include/bar
- url = git://bar.com/git/lib.git
+ url = ssh://bar.com/~/git/lib.git
+ uploadpack = /home/you/bin/git-upload-pack-wrapper
+ receivepack = /home/you/bin/git-receive-pack-wrapper
This defines two submodules, `libfoo` and `libbar`. These are
expected to
be checked out in the paths 'include/foo' and 'include/bar', and for
both
submodules an url is specified which can be used for cloning the
submodules.
+For `libbar`, packs are retrieved and stored via the upload and receive
+wrappers, respectively.
SEE ALSO
--------
diff --git a/git-submodule.sh b/git-submodule.sh
index ebed711..25edd59 100755
--- a/git-submodule.sh
+++ b/git-submodule.sh
@@ -82,6 +82,8 @@ module_clone()
path=$1
url=$2
reference="$3"
+ uploadpack=$4
+ receivepack=$5
# If there already is a directory at the submodule path,
# expect it to be empty (since that is the default checkout
@@ -97,13 +99,30 @@ module_clone()
test -e "$path" &&
die "A file already exist at path '$path'"
+ uploadpackCmd=""
+
+ if test "$uploadpack"
+ then
+ uploadpackCmd="--upload-pack $uploadpack"
+ fi
+
if test -n "$reference"
then
- git-clone "$reference" -n "$url" "$path"
+ git-clone $uploadpackCmd "$reference" -n "$url" "$path"
else
- git-clone -n "$url" "$path"
+ git-clone $uploadpackCmd -n "$url" "$path"
fi ||
die "Clone of '$url' into submodule path '$path' failed"
+ if test "$uploadpack"
+ then
+ git config -f "${path}/.git/config" remote.origin.uploadpack
"$uploadpack" ||
+ echo " Warn: Failed to set uploadpack for '$url' in submodule
path '$path'."
+ fi
+ if test "$receivepack"
+ then
+ git config -f "${path}/.git/config" remote.origin.receivepack
"$receivepack" ||
+ echo " Warn: Failed to set receivepack for '$url' in submodule
path '$path'."
+ fi
}
#
@@ -136,6 +155,16 @@ cmd_add()
reference="$1"
shift
;;
+ -u|--upload-pack)
+ case "$2" in '') usage ;; esac
+ uploadpack=$2
+ shift
+ ;;
+ --receive-pack)
+ case "$2" in '') usage ;; esac
+ receivepack=$2
+ shift
+ ;;
--)
shift
break
@@ -206,9 +235,17 @@ cmd_add()
;;
esac
git config submodule."$path".url "$url"
+ if test "$uploadpack"
+ then
+ git config submodule."$path".uploadpack "$uploadpack"
+ fi
+ if test "$receivepack"
+ then
+ git config submodule."$path".receivepack "$receivepack"
+ fi
else
- module_clone "$path" "$realrepo" "$reference" || exit
+ module_clone "$path" "$realrepo" "$reference" "$uploadpack"
"$receivepack" || exit
(
unset GIT_DIR
cd "$path" &&
@@ -224,7 +261,19 @@ cmd_add()
die "Failed to add submodule '$path'"
git config -f .gitmodules submodule."$path".path "$path" &&
- git config -f .gitmodules submodule."$path".url "$repo" &&
+ git config -f .gitmodules submodule."$path".url "$repo" ||
+ die "Failed to register submodule '$path'"
+
+ if test "$uploadpack"
+ then
+ git config -f .gitmodules submodule."$path".uploadpack
"$uploadpack" ||
+ die "Failed to register submodule '$path'"
+ fi
+ if test "$receivepack"
+ then
+ git config -f .gitmodules submodule."$path".receivepack
"$receivepack" ||
+ die "Failed to register submodule '$path'"
+ fi
git add .gitmodules ||
die "Failed to register submodule '$path'"
}
@@ -299,6 +348,19 @@ cmd_init()
git config submodule."$name".url "$url" ||
die "Failed to register url for submodule path '$path'"
+ uploadpack=$(git config -f .gitmodules submodule."$name".uploadpack)
+ receivepack=$(git config -f .gitmodules
submodule."$name".receivepack)
+ if test "$uploadpack"
+ then
+ git config submodule."$name".uploadpack "$uploadpack" ||
+ echo " Warn: Failed to set uploadpack for '$url' in submodule
path '$path'."
+ fi
+ if test "$receivepack"
+ then
+ git config submodule."$name".receivepack "$receivepack" ||
+ echo " Warn: Failed to set receivepack for '$url' in submodule
path '$path'."
+ fi
+
upd="$(git config -f .gitmodules submodule."$name".update)"
test -z "$upd" ||
git config submodule."$name".update "$upd" ||
@@ -384,7 +446,8 @@ cmd_update()
if ! test -d "$path"/.git -o -f "$path"/.git
then
- module_clone "$path" "$url" "$reference"|| exit
+ module_clone "$path" "$url" "$reference" "$(git config
submodule."$name".uploadpack)" \
+ "$(git config
submodule."$name".receivepack)" || exit
subsha1=
else
subsha1=$(unset GIT_DIR; cd "$path" &&
@@ -738,6 +801,18 @@ cmd_sync()
remote=$(get_default_remote)
say "Synchronizing submodule url for '$name'"
git config remote."$remote".url "$url"
+ uploadpack=$(git config -f .gitmodules submodule."$name".uploadpack)
+ receivepack=$(git config -f .gitmodules
submodule."$name".receivepack)
+ if test "$uploadpack"
+ then
+ git config submodule."$name".uploadpack "$uploadpack" ||
+ echo " Warn: Failed to set uploadpack for '$url' in submodule
path '$name'."
+ fi
+ if test "$receivepack"
+ then
+ git config submodule."$name".receivepack "$receivepack" ||
+ echo " Warn: Failed to set receivepack for '$url' in
submodule path '$name'."
+ fi
)
fi
done
^ permalink raw reply related
* Re: [script] find largest pack objects
From: Antony Stubbs @ 2009-08-31 13:25 UTC (permalink / raw)
To: Nicolas Pitre; +Cc: git
In-Reply-To: <alpine.LFD.2.00.0907092332030.21547@xanadu.home>
Sorry Nicolas,
Completely missed your message amongst the torrent of the git mailing
list - which I'm now unsubscribed from.. But sure, I'll ad this to my
todo list :)
Cheers,
Antony Stubbs,
sharca.com
On 10/07/2009, at 5:34 AM, Nicolas Pitre wrote:
> On Fri, 10 Jul 2009, Antony Stubbs wrote:
>
>> Blog post about git pruning history and finding large objects in
>> your repo:
>> http://stubbisms.wordpress.com/2009/07/10/git-script-to-show-largest-pack-objects-and-trim-your-waist-line/
>>
>> This is a script I put together after migrating the Spring Modules
>> project
>> from CVS, using git-cvsimport (which I also had to patch, to get to
>> work on OS
>> X / MacPorts). I wrote it because I wanted to get rid of all the
>> large jar
>> files, and documentation etc, that had been put into source
>> control. However,
>> if _large files_ are deleted in the latest revision, then they can
>> be hard to
>> track down.
>>
>> #!/bin/bash
>> #set -x
>>
>> # Shows you the largest objects in your repo's pack file.
>> # Written for osx.
>> #
>> # @see
>> http://stubbisms.wordpress.com/2009/07/10/git-script-to-show-largest-pack-objects-and-trim-your-waist-line/
>> # @author Antony Stubbs
>>
>> # set the internal field spereator to line break, so that we can
>> iterate
>> easily over the verify-pack output
>> IFS=$'\n';
>>
>> # list all objects including their size, sort by size, take top 10
>> objects=`git verify-pack -v .git/objects/pack/pack-*.idx | grep -v
>> chain |
>> sort -k3nr | head`
>>
>> echo "All sizes are in kB's. The pack column is the size of the
>> object,
>> compressed, inside the pack file."
>>
>> output="size,pack,SHA,location"
>> for y in $objects
>> do
>> # extract the size in bytes
>> size=$((`echo $y | cut -f 5 -d ' '`/1024))
>> # extract the compressed size in bytes
>> compressedSize=$((`echo $y | cut -f 6 -d ' '`/1024))
>> # extract the SHA
>> sha=`echo $y | cut -f 1 -d ' '`
>> # find the objects location in the repository tree
>> other=`git rev-list --all --objects | grep $sha`
>> #lineBreak=`echo -e "\n"`
>> output="${output}\n${size},${compressedSize},${other}"
>> done
>>
>> echo -e $output | column -t -s ', '
>
> This is certainly useful. Mind submitting a patch adding this
> script to
> contrib/stats/ ?
>
>
> Nicolas
^ permalink raw reply
* Question about git-svn
From: martin liste larsson @ 2009-08-31 13:01 UTC (permalink / raw)
To: git
I have a problem using git-svn. Is this the right place to ask then?
I have followed Andy Delcambre's
http://herebeforeatreplies.com/2008/03/04/git-svn-workflow.html, but
it seems that not all my tags and branches are being imported from svn
to (local) git. That is, 'git branch -a' gives much less output (about
half) of the combination 'svn list http://repos/branches' and 'svn
list http://repos/tags'. What's missing seems to be the newest
branches and tags.
M.
^ permalink raw reply
* Re: [PATCH] fast-import.c: Silence build warning
From: Sverre Rabbelier @ 2009-08-31 12:29 UTC (permalink / raw)
To: Michael Wookey; +Cc: git
In-Reply-To: <d2e97e800908310421u7de8ae58o361bd64a026384bf@mail.gmail.com>
Heya,
On Mon, Aug 31, 2009 at 04:21, Michael Wookey<michaelwookey@gmail.com> wrote:
> Provide a dummy variable to keep the compiler happy.
Should we not instead check the value?
--
Cheers,
Sverre Rabbelier
^ permalink raw reply
* Re: What IDEs are you using to develop git?
From: Rustom Mody @ 2009-08-31 11:36 UTC (permalink / raw)
To: git
In-Reply-To: <1251655664.31273.4.camel@localhost>
On Sun, Aug 30, 2009 at 11:37 PM, Daniele Segato
<daniele.bilug@gmail.com> wrote:
>
> Il giorno mar, 25/08/2009 alle 13.47 +0100, John Tapsell ha scritto:
> > 2009/8/25 Frank Münnich <git@frank-muennich.com>:
> > > One thing I would like to ask you: what, if any, IDEs are you working with?
> >
> > I think everyone just uses vim/emacs :-)
>
> I can't get how would one take vim or emacs instead of an IDE like
> Eclipse.
> That's probably because I'm mainingly a Java developer and i don't know
> vim/emacs very much.
>
> What are the advantages of developing git with vim/emacs over an IDE?
>
> Cheers,
> Daniele
How much mouse do you use and how much keyboard?
And now read http://steve.yegge.googlepages.com/effective-emacs.
Note: vi is ergonomically superior to emacs (shortest keystrokes, no
mouse at all) but emacs can do more than vi
^ permalink raw reply
* Re: clong an empty repo over ssh causes (harmless) fatal
From: Matthieu Moy @ 2009-08-31 11:22 UTC (permalink / raw)
To: Sitaram Chamarty; +Cc: git
In-Reply-To: <slrnh9nc4e.6bn.sitaramc@sitaramc.homelinux.net>
Sitaram Chamarty <sitaramc@gmail.com> writes:
> Hello,
>
> Cloning an empty repo seems to produce a spurious error.
> The repo still seems fine though.
Can't reproduce here:
$ git clone ssh://.../tmp/empty cloned
Initialized empty Git repository in /tmp/cloned/.git/
warning: You appear to have cloned an empty repository.
$ git --version
git version 1.6.4.187.gd399.dirty
Maybe you have an older version of Git?
--
Matthieu
^ permalink raw reply
* [PATCH] fast-import.c: Silence build warning
From: Michael Wookey @ 2009-08-31 11:21 UTC (permalink / raw)
To: git
gcc 4.3.3 (Ubuntu 9.04) warns that the return value of strtoul() was not
checked by issuing the following notice:
warning: ignoring return value of ‘strtoul’, declared with attribute
warn_unused_result
Provide a dummy variable to keep the compiler happy.
Signed-off-by: Michael Wookey <michaelwookey@gmail.com>
---
fast-import.c | 5 +++--
1 files changed, 3 insertions(+), 2 deletions(-)
diff --git a/fast-import.c b/fast-import.c
index 7ef9865..1386e75 100644
--- a/fast-import.c
+++ b/fast-import.c
@@ -1744,10 +1744,11 @@ static int validate_raw_date(const char *src,
char *result, int maxlen)
{
const char *orig_src = src;
char *endp;
+ unsigned long int unused;
errno = 0;
- strtoul(src, &endp, 10);
+ unused = strtoul(src, &endp, 10);
if (errno || endp == src || *endp != ' ')
return -1;
@@ -1755,7 +1756,7 @@ static int validate_raw_date(const char *src,
char *result, int maxlen)
if (*src != '-' && *src != '+')
return -1;
- strtoul(src + 1, &endp, 10);
+ unused = strtoul(src + 1, &endp, 10);
if (errno || endp == src || *endp || (endp - orig_src) >= maxlen)
return -1;
--
1.6.4.2.236.gf324c
^ permalink raw reply related
* clong an empty repo over ssh causes (harmless) fatal
From: Sitaram Chamarty @ 2009-08-31 11:14 UTC (permalink / raw)
To: git
Hello,
Cloning an empty repo seems to produce a spurious error.
The repo still seems fine though.
Any thoughts?
$ git clone ssh://sitaram@localhost/home/sitaram/t/a b
Initialized empty Git repository in /home/sitaram/t/b/.git/
sitaram@localhost's password:
warning: You appear to have cloned an empty repository.
fatal: The remote end hung up unexpectedly
Thanks,
Sitaram
^ permalink raw reply
* Re: What IDEs are you using to develop git?
From: Martin Langhoff @ 2009-08-31 10:21 UTC (permalink / raw)
To: Howard Miller; +Cc: Daniele Segato, John Tapsell, Frank Münnich, git
In-Reply-To: <26ae428a0908301206s38b36901y6027486f0d780ebc@mail.gmail.com>
On Sun, Aug 30, 2009 at 9:06 PM, Howard
Miller<howard@e-learndesign.co.uk> wrote:
> With a bit of learning
> can can do most of the stuff that an IDE does, usually faster and with
> less fuss.
Ditto. And with a very modest screen size. Modern IDEs need a huge
monitor, and then more, just to show what they want to show you.
Not what you need.
So when working on webapps, I normally keep my editor (usually an
emacs variant) window small, and have lots of terminal windows tracing
relevant logs (webserver, db server) and 3~4 webbrowsers logged in as
different users.
When working on git itself, it's much easier -- as all you need is
your editor and your terminal to compile & debug so for a simple task
like git itself, an IDE might even work ;-)
cheers,
m
--
martin.langhoff@gmail.com
martin@laptop.org -- School Server Architect
- ask interesting questions
- don't get distracted with shiny stuff - working code first
- http://wiki.laptop.org/go/User:Martinlanghoff
^ permalink raw reply
* Re: What's cooking in git.git (Aug 2009, #06; Sun, 30)
From: Johan Herland @ 2009-08-31 9:32 UTC (permalink / raw)
To: git; +Cc: Junio C Hamano
In-Reply-To: <7viqg48nxi.fsf@alter.siamese.dyndns.org>
On Monday 31 August 2009, Junio C Hamano wrote:
> [Stalled]
>
> * jh/notes (2009-08-27) 12 commits.
> - Add '%N'-format for pretty-printing commit notes
> - Add flags to get_commit_notes() to control the format of the note
> string - notes.c: Implement simple memory pooling of leaf nodes
> - Selftests verifying semantics when loading notes trees with various
> fanouts - Teach the notes lookup code to parse notes trees with various
> fanout schemes - t3302-notes-index-expensive: Speed up create_repo()
> - fast-import: Add support for importing commit notes
> - Teach "-m <msg>" and "-F <file>" to "git notes edit"
> - Add an expensive test for git-notes
> - Speed up git notes lookup
> - Add a script to edit/inspect notes
> - Introduce commit notes
>
> I heard the cvs-helper series depends on this one. It seems that the
> fan-out strategy is being rethought?
Yes, I'm experimenting with various mixes of date-based and commit_sha1-
based fanouts. Will send a new series when I have some results to show.
Might not have time to finish before next weekend, though.
Have fun! :)
...Johan
--
Johan Herland, <johan@herland.net>
www.herland.net
^ permalink raw reply
* Re: What IDEs are you using to develop git?
From: Erik Faye-Lund @ 2009-08-31 8:29 UTC (permalink / raw)
To: Robin Rosenberg; +Cc: Daniele Segato, John Tapsell, Frank Münnich, git
In-Reply-To: <200908302329.11264.robin.rosenberg.lists@dewire.com>
On Sun, Aug 30, 2009 at 11:29 PM, Robin
Rosenberg<robin.rosenberg.lists@dewire.com> wrote:
> VIM and Emacs are really IDE's. In particular you can login to emacs directly
> and never leave it until you log out. Besdides all you pogramming tools you
> have your email and (yes) your mp3 player there. That's pretty integrated to me.
One could argue that some of these features makes them Integrated
Dicking-around Environments instead of Integrated Development
Environments ;)
--
Erik "kusma" Faye-Lund
kusmabite@gmail.com
(+47) 986 59 656
^ permalink raw reply
* how to skip branches on git svn clone/fetch when there are errors
From: Daniele Segato @ 2009-08-31 8:26 UTC (permalink / raw)
To: Git Mailing List
Hi,
I'm trying to clone a big repository.
I follow this steps:
git init
git svn init svn://svn.mydomain.com/path/to/repo -T HEAD -b BRANCHES -t TAGS
vim .git/config # edited the svn-remote config as follow (add /root to
branches and tag) to match the repo structure
[svn-remote "svn"]
url = svn://svn.mydomain.com
fetch = path/to/repo/HEAD/root:refs/remotes/svn/trunk
branches = path/to/repo/BRANCHES/*/root:refs/remotes/svn/*
tags = path/to/repo/TAGS/*/root:refs/remotes/svn/tags/*
git svn fetch
When I reach revision ~7500 (I don't remember the exact number) I get an error:
$ git svn fetch
Use of uninitialized value in concatenation (.) or string at
/usr/lib/perl5/SVN/Core.pm line 584.
Authorization failed: at /usr/bin/git-svn line 1415
After some debugging I found out the reason is something strange on
the SVN server: there is a folder in the SVN that give an error when
trying to access:
$ svn info svn://svn.mydomain.com/path/to/repo/BRANCHES/V2.1-A
svn: Authorization failed
The same error with svn list.
I don't know what's wrong with that branch but I just want to skip it...
I tried modifying the .git/config svn-remote configuration adding this:
ignore-paths = path\\/to\\/repo\\/BRANCHES\\/V2\\.1-A
and re-launching git svn fetch.
I had no luck.
Ho do I skip a path on the svn repository?
(I can't provide the real svn repo because it is password protected
and I can't give you the access)
Thanks,
Regards,
Daniele
^ permalink raw reply
* Re: [BUG] git stash refuses to save after "add -N"
From: Yann Dirson @ 2009-08-31 8:16 UTC (permalink / raw)
To: Jeff King; +Cc: Junio C Hamano, Yann Dirson, git
In-Reply-To: <20090831050554.GA17197@coredump.intra.peff.net>
> On Sun, Aug 30, 2009 at 10:03:07PM -0700, Junio C Hamano wrote:
>
>> > - "-f" is kind of vague. Would people expect it to force aspects of
>> > the stash? Should it be "--intent-as-empty"?
>>
>> I am not sure if asking for positive confirmation with "-f" is even
>> worth
>> it. As you pointed out in your earlier message, which prompted me to
>> respond with a patch, when this codepath is exercised, the user is in a
>> rush, and I do not see what else the user would want to do other than
>> including it in the stash by rerunning with -f.
>
> I guess it was just to mitigate my fear that we are somehow creating a
> stash that will confuse people when they apply it. But really that fear
> is probably unjustified.
Well, indeed each time I use "add -N" it is mostly to get "git diff" show
me the contents of the new file as part of my WIP, so it would not make
much difference to me if "add -N" would just add the file as empty to the
index in the first place.
Out of curiosity, does anyone make any use of the current difference
between not-added-yet and added-as-empty ?
^ permalink raw reply
* Re: What IDEs are you using to develop git?
From: Andreas Ericsson @ 2009-08-31 8:11 UTC (permalink / raw)
To: Daniele Segato; +Cc: John Tapsell, Frank Münnich, git
In-Reply-To: <1251655664.31273.4.camel@localhost>
Daniele Segato wrote:
> Il giorno mar, 25/08/2009 alle 13.47 +0100, John Tapsell ha scritto:
>> 2009/8/25 Frank Münnich <git@frank-muennich.com>:
>>> One thing I would like to ask you: what, if any, IDEs are you working with?
>> I think everyone just uses vim/emacs :-)
>
> I can't get how would one take vim or emacs instead of an IDE like
> Eclipse.
> That's probably because I'm mainingly a Java developer and i don't know
> vim/emacs very much.
>
> What are the advantages of developing git with vim/emacs over an IDE?
>
Pre-trained fingers in my case. I quite like simple IDE's such as Geany,
but I get so annoyed when emacs keybindings don't work, or when the auto-
indentation doesn't do what I want it to do that I just revert back to
my simple editor instead.
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
Considering the successes of the wars on alcohol, poverty, drugs and
terror, I think we should give some serious thought to declaring war
on peace.
^ permalink raw reply
* Re: A note from the maintainer: Follow-up questions (MaintNotes)
From: Andreas Ericsson @ 2009-08-31 8:05 UTC (permalink / raw)
To: David Chanters; +Cc: git
In-Reply-To: <ac3d41850908301519s2cf8a45auf11fb4c9285c0cb5@mail.gmail.com>
David Chanters wrote:
> Hi,
>
> [Please retain a Cc back to me as I am not currently subscribed to the
> mailing list.]
>
> I've recently been intrigued with workflows, and have read quite a bit
> about them, including various references on git-scm.com,
> gitworkflows(7), and the email "A note from the maintainer" which I
> have some questions on. I'll paste random quotes from that and just
> ask my question, I think, so apologies up front of it reads a little
> disjointed.
>
> I'd often wondered when I have read various posts of the git mailing
> list on gmane, just how it is I am supposed to track:
>
> dc/some-topic-feature
>
> ... Junio, are these topic branches ones you actively have somewhere
> in your own private checkout? Yes, I appreciate that when I read a
> given post to the mailing list, you or other people will sometimes
> make reference to these topic branches, but what do I do if I am
> interested in finding out about one of them? Indeed, perhaps even
> before getting to that question, how do you go about creating and
> maintaining these topic branches -- are you making heavy use of "git
> am"?
>
> I ask because of the following snippet from "MaintNotes":
>
> The two branches "master" and "maint" are never rewound, and
> "next" usually will not be either (this automatically means the
> topics that have been merged into "next" are usually not
> rebased, and you can find the tip of topic branches you are
> interested in from the output of "git log next"). You should be
> able to safely track them.
>
> I am not sure if there's any real use-case for this, but I will ask
> anyway: is the above saying that I am able to *checkout* one of these
> topic-branches just from their presence in "next" alone?
Yes. "git log --grep=dc/some-topic-feature next" would point you to
the merge commit where it gets merged to 'next'. Then you can simply
do "git checkout -b dc/some-topic-feature (the-located-commit)^2" to
create the branch "dc/some-topic-feature" as it was when Junio merged
it. This relies on Junio not tampering with the commit messages git
creates when merging, but since there's no real need for that anyway,
it's a fairly safe practice.
>
> To continue:
>
> The "pu" (proposed updates) branch bundles all the remainder of
> topic branches. The "pu" branch, and topic branches that are
> only in "pu", are subject to rebasing in general. By the above
> definition of how "next" works, you can tell that this branch
> will contain quite experimental and obviously broken stuff.
>
> I'm obviously missing something here -- but why is rebasing these
> existing topic branches (I assume on top of "pu") more useful than
> just merging them into "pu" -- like you do with "next"?
>
Because topics in 'pu' can be dropped on the floor, and are worked
on quite a lot more than the ones in next. Undoing a merge is quite
a lot of work as opposed to just rebuilding the history without that
merge. It's also a lot nicer to have a cleaner history in 'next',
since that makes it easier to merge things to 'master' in such a way
that bisection works nicely.
> When a topic that was in "pu" proves to be in testable shape, it
> graduates to "next". I do this with:
>
> git checkout next
> git merge that-topic-branch
>
> Sometimes, an idea that looked promising turns out to be not so
> good and the topic can be dropped from "pu" in such a case.
>
> Ah -- so if I have this straight in my head -- you continually form
> the local topic-branch on its own branch, and then just merge it into
> "next" only when you know that topic branch is satisfactory?
I *think* the topic branches live until they're merged to master, or
until they're dropped (although I could well imagine them staying
behind quite some time after being dropped). I haven't heard Junio
talk about this afair, but that's how I would do it anyways.
> That
> being the case -- again, I assume the use of "git am" for the topic
> branch?
I should think so, although once a patch is applied in its final
form it'll no longer be necessary to use "git am". It'll be easier
to just use rebase on the topic branch(es), or cherry-pick individual
commits from them in order to get only certain benefits of them.
This isn't *very* usual, but it does happen from time to time that
topic branches refactor something first and then adds a feature on
top of that.
> If regular readers of the git mailing list wish to track this
> topic branch, can they do so from you only until it's merged into
> "next"?
>
Topics that make it to master can be tracked indefinitely. 'next'
is never merged directly to master, since the topics brewing on
next get different amounts of testing and feedback. Junio just
merges the topics to master as they go through all the review and
testing they're thought to need. Try
git log --grep="Merge branch '" master
and you'll see what I mean, or have a look using gitk.
> And a related question: If you decide a given topic in pu is declared
> to "be dropped", is this done by rebasing (as you mentioned earlier)
> so as to remove any trace of the topic branch ever having been in
> "pu", or am I reading too much into "dropping" here? :)
>
AFAIU, 'pu' is dropped in its entirety and re-built from the top of 'next'
by the rather simple expedient of "git reset --hard next" and then merging,
one by one, all branches that aren't already merged to maint, master or
next. Git can list such branches so it's no great chore. Naturally, Junio
knows his way fairly well around git and has scripts to do much of this
work for him.
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
Considering the successes of the wars on alcohol, poverty, drugs and
terror, I think we should give some serious thought to declaring war
on peace.
^ permalink raw reply
* Re: [Vcs-fast-import-devs] bzr to git syncing
From: Ian Clatworthy @ 2009-08-31 7:49 UTC (permalink / raw)
To: Alex Bennee; +Cc: Sverre Rabbelier, David Reitter, vcs-fast-import-devs, git
In-Reply-To: <fabb9a1e0908281049t64f06a2r5efa114c7bcdc468@mail.gmail.com>
Sverre Rabbelier wrote:
> Heya,
>
> [+vcs-fast-import-devs]
>
> On Fri, Aug 28, 2009 at 10:47, Alex Bennee<kernel-hacker@bennee.com> wrote:
>> 2009/8/28 Sverre Rabbelier <srabbelier@gmail.com>:
>>> On Fri, Aug 28, 2009 at 09:02, Alex Bennee<kernel-hacker@bennee.com> wrote:
>>>> I've attached the fast-import crash I'm seeing. Are you seeing the
>>>> same sort of failure?
>>> The program you used to generate the stream (I assume git-bzr?) is
>>> generating an invalid mode, git understands '100644', '100755',
>>> '120000', and '160000'; the mode in the stream, '040000', is not
>>> something we understand.
>> Yeah, it seems in bzr land it mean new directory which we don't care
>> about.
> This seems like a fine case for the new 'feature' command on bzr's export side.
Hmm - I only added that 040000 stuff late last week and it *should* only
be output if you explicitly ask for extended metadata from bzr
fast-export via the --no-plain option? If that's not the case, please
raise a bug here: https://bugs.launchpad.net/bzr-fastimport.
Ian C.
^ permalink raw reply
* Re: [PATCH] Documentation/git-add.txt: Explain --patch option in layman terms
From: Jari Aalto @ 2009-08-31 7:46 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, jari.aalto
In-Reply-To: <7vbplw28js.fsf@alter.siamese.dyndns.org>
Junio C Hamano <gitster@pobox.com> writes:
I apologize if you though I did not read. I did, but I the separate
paragraph order did not meet here as you might have intended.
To recap, your suggestion, if read correct:
--patch:
-p::
Review the difference between the index and the work tree, and add
modified contents to the index interactively by choosing which
patch hunks to use.
Run ``add --interactive``, but bypass the initial command menu and
directly jump to `patch` subcommand. See ``Interactive mode'' for
details.
For more direct first line, howabout:
--patch:
-p::
In a modified work tree, choose interactively which patch hunks to
add. This gives a change to review the difference between the
index and the work before adding modified contents to the index.
This effectively runs ``add --interactive``, but bypass the
initial command menu and directly jump to `patch` subcommand.
See ``Interactive mode'' for details.
Jari
^ permalink raw reply
* Re: git-svn-Cloning repository with complex nesting
From: Daniele Segato @ 2009-08-31 7:41 UTC (permalink / raw)
To: Git Mailing List
On Thu, Aug 27, 2009 at 10:32 AM, Daniele Segato<daniele.bilug@gmail.com> wrote:
> Hi, this is my first message in the list: this may be a newbie
> question and my English may not be very good.
to prove my sentence:
the subject should have been "git-svn-Cloning repository with
_complex_ nesting" :-)
I received help on IRC (#git) and managed to setup the svn-remote in
an acceptable way
> I've an SVN repository structured like this:
>
> http://<url>/path/to/repo
> |
> HEAD
> |----- root
> |
> BRANCHES
> |----- V1.0
> | |----- root
> |
> |----- V1.1
> | |----- root
> |
> |----- V1.2
> | |----- root
> |
> |----- DEV
> | |----- FEATURE1
> | | |----- root
> | |
> | |----- FEATURE2
> | | |----- root
> | |
> | |----- FEATURE3
> | |----- root
> |
> |----- BUILDS
> |----- BUILD1
> | |----- root
> |
> |----- BUILD2
> | |----- root
> |
> |----- BUILD3
> |----- root
this is my setting:
git init
git svn init svn://svn.mydomain.com/path/to/repo -T HEAD -b BRANCHES -t TAGS
vim .git/config # edited the svn-remote config as follow:
[svn-remote "svn"]
url = svn://svn.mydomain.com
fetch = path/to/repo/HEAD/root:refs/remotes/svn/trunk
branches = path/to/repo/BRANCHES/*/root:refs/remotes/svn/*
tags = path/to/repo/TAGS/*/root:refs/remotes/svn/tags/*
git svn fetch
it seems to work as expected: only those branches that has a "root"
folder got downloaded and fetched.
I still couldn't retrieve the DEV/FEATUREx branches in that way.
On IRC they told me I can add another line for branches:
branches = path/to/repo/BRANCHES/*/*/root:refs/remotes/svnbis/*
but I haven't been successful on this. They told me that I can add
multiple branches lines only on newer versions of git.
Probably that's the reason for that.
I have git version 1.5.6.5.
It is not a big deal: I can live without those branches even if I'll
like to have them too.
I have another problem now on that SVN repo but I'll open another
topic about that because it is not related.
Regards,
Daniele
^ permalink raw reply
* Re: [PATCH] Documentation/git-add.txt: Explain --patch option in layman terms
From: Junio C Hamano @ 2009-08-31 7:32 UTC (permalink / raw)
To: Jari Aalto; +Cc: git
In-Reply-To: <873a78a2dc.fsf@jondo.cante.net>
Jari Aalto <jari.aalto@cante.net> writes:
> I could offer patches, but not in any time frame to do it in one-swoop
> do-it-all patch. To distribute time and effort to do so, it would be
> sensible to handle one manual at a time. The whole work would eventually
> get done.
Yeah, that's the spirit, and that is why I said you do not necessarily
have to do all the work yourself. It would be expected of that volunteer
to keep an eye on patches other helpful folks may send to cover the issue,
vet them to make sure they do not introduce silly typos, AsciiDoc
breakages, and needless conflicts.
As to guidelines, I think your "spell all top-level headlines in caps" is
a reasonable one, as "man" backend for AsciiDoc does that anyway.
For the ancient "Synopsis" issue, SD5-XCU-ERN-97 would be a reasonable
guideline to follow (http://www.opengroup.org/austin/docs/austin_325.txt).
> There could be section in TODO.
>
> RFH - Request for help: Manual page adjustments
>
> - If you have some spare time, the following manual pages adjustment
> is needed for all git manuals ....
>
> Or 2-weekly RFH post could announce the need. That would be one way to
> coordinate participants.
I would leave such a procedural issue to the volunteer who heads the
effort to decide. If you are asking me to decide, then you are not
volunteering yourself, but you are volunteering _me_ for the job ;-).
Thanks.
^ permalink raw reply
* Re: [PATCH] Documentation/git-add.txt: Explain --patch option in layman terms
From: Jari Aalto @ 2009-08-31 7:06 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vr5usyj3i.fsf@alter.siamese.dyndns.org>
Junio C Hamano <gitster@pobox.com> writes:
> Jari Aalto <jari.aalto@cante.net> writes:
>
>> I think the convention used in git's manual pages deviate from the
>> standard practise. We could make the git manual pages into line of:
>>
>> - write all the first level headings in all caps: "HEADING LIKE THIS"
>> - write second level heading: start Upper-lower: "Heading like this"
>>
>> Cf. rsync(1), ssh(1) etc. many pages prior git's existense.
>
[URL: That's a separate issue. The resolution hung in the air how to
proceed]
Please be patient. I understand that you have lot work. I do care,
therefore I take the time to suggest some chnages.
> Are you volunteering to coordinate such a change (in other words, you do
> not necessarily have to do _all_ the work yourself, alone)
We need resolution first. What would you think about that change?
I could offer patches, but not in any time frame to do it in one-swoop
do-it-all patch. To distribute time and effort to do so, it would be
sensible to handle one manual at a time. The whole work would eventually
get done.
There could be section in TODO.
RFH - Request for help: Manual page adjustments
- If you have some spare time, the following manual pages adjustment
is needed for all git manuals ....
Or 2-weekly RFH post could announce the need. That would be one way to
coordinate participants.
Jari
^ permalink raw reply
* What's cooking in git.git (Aug 2009, #06; Sun, 30)
From: Junio C Hamano @ 2009-08-31 7:03 UTC (permalink / raw)
To: git
Here are the topics that have been cooking. Commits prefixed with '-' are
only in 'pu' while commits prefixed with '+' are in 'next'. The ones
marked with '.' do not appear in any of the integration branches, but I am
still holding onto them.
After the 1.6.5 cycle, the next release will be 1.7.0, and we will push
out the planned "push safety" change. 1.7.0 would be a good time to
introduce "justifiable" changes that are not strictly backward compatible.
During 1.6.5 cycle, 'next' will hold topics meant for 1.6.5 and 1.7.0.
--------------------------------------------------
[Graduated to "master"]
* wl/insta-mongoose (2009-08-21) 1 commit
(merged to 'next' on 2009-08-25 at da1d566)
+ Add support for the Mongoose web server.
* as/maint-graph-interesting-fix (2009-08-21) 2 commits.
(merged to 'next' on 2009-08-25 at 9d5e215)
+ Add tests for rev-list --graph with options that simplify history
+ graph API: fix bug in graph_is_interesting()
* jc/maint-unpack-objects-strict (2009-08-13) 1 commit.
(merged to 'next' on 2009-08-23 at 38eb750)
+ Fix "unpack-objects --strict"
* jh/submodule-foreach (2009-08-20) 9 commits
(merged to 'next' on 2009-08-20 at 671bea4)
+ git clone: Add --recursive to automatically checkout (nested) submodules
+ t7407: Use 'rev-parse --short' rather than bash's substring expansion notation
(merged to 'next' on 2009-08-18 at f4a881d)
+ git submodule status: Add --recursive to recurse into nested submodules
+ git submodule update: Introduce --recursive to update nested submodules
+ git submodule foreach: Add --recursive to recurse into nested submodules
+ git submodule foreach: test access to submodule name as '$name'
+ Add selftest for 'git submodule foreach'
+ git submodule: Cleanup usage string and add option parsing to cmd_foreach()
+ git submodule foreach: Provide access to submodule name, as '$name'
* lt/block-sha1 (2009-08-17) 4 commits
(merged to 'next' on 2009-08-18 at 67a1ce8)
+ remove ARM and Mozilla SHA1 implementations
+ block-sha1: guard gcc extensions with __GNUC__
+ make sure byte swapping is optimal for git
+ block-sha1: make the size member first in the context struct
* np/maint-1.6.3-deepen (2009-08-24) 1 commit.
(merged to 'next' on 2009-08-25 at 8e383d4)
+ fix simple deepening of a repo
* jk/maint-1.6.3-checkout-unborn (2009-08-24) 1 commit.
(merged to 'next' on 2009-08-25 at 5f29625)
+ checkout: do not imply "-f" on unborn branches
* mm/reset-report (2009-08-21) 2 commits
(merged to 'next' on 2009-08-25 at f2a4424)
+ reset: make the reminder output consistent with "checkout"
+ Rename REFRESH_SAY_CHANGED to REFRESH_IN_PORCELAIN.
* jc/shortstatus (2009-08-15) 11 commits
(merged to 'next' on 2009-08-15 at 7e40766)
+ git commit --dry-run -v: show diff in color when asked
+ Documentation/git-commit.txt: describe --dry-run
(merged to 'next' on 2009-08-12 at 53bda17)
+ wt-status: collect untracked files in a separate "collect" phase
+ Make git_status_config() file scope static to builtin-commit.c
+ wt-status: move wt_status_colors[] into wt_status structure
+ wt-status: move many global settings to wt_status structure
+ commit: --dry-run
(merged to 'next' on 2009-08-06 at fe8cb94)
+ status: show worktree status of conflicted paths separately
+ wt-status.c: rework the way changes to the index and work tree are summarized
+ diff-index: keep the original index intact
+ diff-index: report unmerged new entries
(this branch is used by jc/1.7.0-status.)
--------------------------------------------------
[New Topics]
* jc/upload-pack-hook (2009-08-28) 2 commits
- upload-pack: feed "kind [clone|fetch]" to post-upload-pack hook
- upload-pack: add a trigger for post-upload-pack hook
I do not know if the distinction between fetching some but not all refs
and fetching full set of refs into an empty repository is something worth
making, so in that sense the tip commit is somewhat iffy.
One reason this series makes me somewhat uneasy is that Tom, the original
starter of the discussion went dark after sending a proposed patch. Maybe
he has been too busy, but I have been hoping that GitHub as a stakeholder
has somebody who monitors the list when he is not available.
Does anybody from GitHub have any input? Is there something that needs to
be improved to fill GitHub's needs? Does GitHub want to stick to its own
fork, and were all these discussions for improvements unwanted?
* jk/clone-b (2009-08-26) 1 commit
(merged to 'next' on 2009-08-30 at 10a68d1)
+ clone: add --branch option to select a different HEAD
* pk/import-dirs (2009-08-24) 1 commit
- Add script for importing bits-and-pieces to Git.
This version makes me suspect that the author might regret the choice of
the import format that does not allow escaping of paths, nor does not
allow leading blanks for readability without changing semantics, both of
which make it somewhat limiting and error prone. These issues will be
hard to rectify without breaking the backward compatibility, for a tool
that could otherwise turn out to be useful.
As a contrib/ material, I probably shouldn't be too worried about these
issues, but I am keeping this out of 'next' for now, just in case the
author chooses to polish the usability of the tool for general audience.
It is a different story if the submission was just throwing out a one-time
hack in the open in the hope that some other people might find it useful,
but without any intention of maintaining it. But then I do not have a
strong reason to keep this in my tree, either. The mailing list archive
is a more suitable storage media for such a patch.
--------------------------------------------------
[Stalled]
* jh/notes (2009-08-27) 12 commits.
- Add '%N'-format for pretty-printing commit notes
- Add flags to get_commit_notes() to control the format of the note string
- notes.c: Implement simple memory pooling of leaf nodes
- Selftests verifying semantics when loading notes trees with various fanouts
- Teach the notes lookup code to parse notes trees with various fanout schemes
- t3302-notes-index-expensive: Speed up create_repo()
- fast-import: Add support for importing commit notes
- Teach "-m <msg>" and "-F <file>" to "git notes edit"
- Add an expensive test for git-notes
- Speed up git notes lookup
- Add a script to edit/inspect notes
- Introduce commit notes
I heard the cvs-helper series depends on this one. It seems that the
fan-out strategy is being rethought?
* js/stash-dwim (2009-07-27) 1 commit.
(merged to 'next' on 2009-08-16 at 67896c4)
+ Make 'git stash -k' a short form for 'git stash save --keep-index'
(this branch is used by tr/reset-checkout-patch.)
* tr/reset-checkout-patch (2009-08-27) 9 commits.
(merged to 'next' on 2009-08-27 at d314281)
+ Make test case number unique
(merged to 'next' on 2009-08-18 at e465bb3)
+ tests: disable interactive hunk selection tests if perl is not available
(merged to 'next' on 2009-08-16 at 67896c4)
+ DWIM 'git stash save -p' for 'git stash -p'
+ Implement 'git stash save --patch'
+ Implement 'git checkout --patch'
+ Implement 'git reset --patch'
+ builtin-add: refactor the meat of interactive_add()
+ Add a small patch-mode testing library
+ git-apply--interactive: Refactor patch mode code
(this branch uses js/stash-dwim.)
There was a discussion on better DWIMmery for the above two topics to (1)
forbid "git stash save --anything-with-dash" and (2) redirect with any
option "git stash --opt" to "git stash save --opt", to keep it flexible
and safe at the same time. I think it is a sane thing to do, but nothing
has happened lately.
* db/vcs-helper (2009-08-09) 17 commits
- Allow helpers to request marks for fast-import
- Allow helpers to report in "list" command that the ref is unchanged
- Add support for "import" helper command
- transport-helper_init(): fix a memory leak in error path
- Add a config option for remotes to specify a foreign vcs
- Allow programs to not depend on remotes having urls
- Allow fetch to modify refs
- Use a function to determine whether a remote is valid
- Use a clearer style to issue commands to remote helpers
(merged to 'next' on 2009-08-07 at f3533ba)
+ Makefile: install hardlinks for git-remote-<scheme> supported by libcurl if possible
+ Makefile: do not link three copies of git-remote-* programs
+ Makefile: git-http-fetch does not need expat
(merged to 'next' on 2009-08-06 at 15da79d)
+ http-fetch: Fix Makefile dependancies
+ Add transport native helper executables to .gitignore
(merged to 'next' on 2009-08-05 at 33d491e)
+ git-http-fetch: not a builtin
+ Use an external program to implement fetching with curl
+ Add support for external programs for handling native fetches
(this branch is used by jh/cvs-helper.)
We had a few messages on what the list consensus was with this series. My
impression, after going back to the archive, is that there wasn't.
* jn/gitweb-blame (2009-08-06) 3 commits
- gitweb: Create links leading to 'blame_incremental' using JavaScript
- gitweb: Incremental blame (WIP)
- gitweb: Add optional "time to generate page" info in footer
Ajax-y blame WIP
--------------------------------------------------
[Cooking]
* je/send-email-no-subject (2009-08-05) 1 commit
(merged to 'next' on 2009-08-30 at b6455c2)
+ send-email: confirm on empty mail subjects
The existing tests to covers the positive case (i.e. as long as the user
says "yes" to the "do you really want to send this message that lacks
subject", the message is sent) of this feature, but the feature itself
needs its own test to verify the negative case (i.e. does it correctly
stop if the user says "no"?)
* lt/approxidate (2009-08-30) 6 commits
(merged to 'next' on 2009-08-30 at e016e3d)
+ fix approxidate parsing of relative months and years
+ tests: add date printing and parsing tests
+ refactor test-date interface
+ Add date formatting and parsing functions relative to a given time
(merged to 'next' on 2009-08-26 at 62853f9)
+ Further 'approxidate' improvements
+ Improve on 'approxidate'
Fixes a few "reasonably formatted but thus-far misparsed" date strings.
With tests by Peff, this should be ready for -rc0.
* mr/gitweb-snapshot (2009-08-25) 3 commits
(merged to 'next' on 2009-08-30 at e4edd0b)
+ gitweb: add t9501 tests for checking HTTP status codes
+ gitweb: split test suite into library and tests
+ gitweb: improve snapshot error handling
* jc/mailinfo-scissors (2009-08-26) 5 commits
(merged to 'next' on 2009-08-30 at 5fc6248)
+ mailinfo.scissors: new configuration
+ am/mailinfo: Disable scissors processing by default
+ Documentation: describe the scissors mark support of "git am"
+ Teach mailinfo to ignore everything before -- >8 -- mark
+ builtin-mailinfo.c: fix confusing internal API to mailinfo()
I didn't pick up the patch to simplify the definition of scissors. I do
not have strong opinion on it either way, but the list would hopefully
decide it before too long.
* tf/diff-whitespace-incomplete-line (2009-08-23) 2 commits.
(merged to 'next' on 2009-08-26 at 4fc7784)
+ xutils: Fix xdl_recmatch() on incomplete lines
+ xutils: Fix hashing an incomplete line with whitespaces at the end
Will merge.
* cc/sequencer-rebase-i (2009-08-28) 15 commits
- rebase -i: use "git sequencer--helper --cherry-pick"
- sequencer: add "--cherry-pick" option to "git sequencer--helper"
- sequencer: add "do_commit()" and related functions working on "next_commit"
- pick: libify "pick_help_msg()"
- revert: libify cherry-pick and revert functionnality
- rebase -i: use "git sequencer--helper --fast-forward"
- sequencer: let "git sequencer--helper" callers set "allow_dirty"
- sequencer: add "--fast-forward" option to "git sequencer--helper"
- sequencer: add "do_fast_forward()" to perform a fast forward
- rebase -i: use "git sequencer--helper --reset-hard"
- sequencer: add "--reset-hard" option to "git sequencer--helper"
- sequencer: add "reset_almost_hard()" and related functions
- rebase -i: use "git sequencer--helper --make-patch"
- sequencer: add "make_patch" function to save a patch
- sequencer: add "builtin-sequencer--helper.c"
Migrating "rebase -i" bit by bit to C.
* jh/cvs-helper (2009-08-18) 7 commits
- More fixes to the git-remote-cvs installation procedure
- Fix the Makefile-generated path to the git_remote_cvs package in git-remote-cvs
- Add simple selftests of git-remote-cvs functionality
- git-remote-cvs: Remote helper program for CVS repositories
- 2/2: Add Python support library for CVS remote helper
- 1/2: Add Python support library for CVS remote helper
- Basic build infrastructure for Python scripts
(this branch uses db/vcs-helper.)
Builds on db/vcs-helper (which is stalled, so this cannot move further at
the moment). There is a re-roll planned, so I did not pick up test fixes
from Brandon myself.
* sr/gfi-options (2009-08-27) 6 commits
- fast-import: test the new option command
- fast-import: add option command
- fast-import: test the new feature command
- fast-import: add feature command
- fast-import: put marks reading in it's own function
- fast-import: put option parsing code in separate functions
Re-rolled, based on an off-list discussion I was/am not aware of.
Looked ready for 'next'.
* nd/sparse (2009-08-20) 19 commits
- sparse checkout: inhibit empty worktree
- Add tests for sparse checkout
- read-tree: add --no-sparse-checkout to disable sparse checkout support
- unpack-trees(): ignore worktree check outside checkout area
- unpack_trees(): apply $GIT_DIR/info/sparse-checkout to the final index
- unpack-trees(): "enable" sparse checkout and load $GIT_DIR/info/sparse-checkout
- unpack-trees.c: generalize verify_* functions
- unpack-trees(): add CE_WT_REMOVE to remove on worktree alone
- Introduce "sparse checkout"
- dir.c: export excluded_1() and add_excludes_from_file_1()
- excluded_1(): support exclude files in index
- unpack-trees(): carry skip-worktree bit over in merged_entry()
- Read .gitignore from index if it is skip-worktree
- Avoid writing to buffer in add_excludes_from_file_1()
- Teach Git to respect skip-worktree bit (writing part)
- Teach Git to respect skip-worktree bit (reading part)
- Introduce "skip-worktree" bit in index, teach Git to get/set this bit
- Add test-index-version
- update-index: refactor mark_valid() in preparation for new options
--------------------------------------------------
[For 1.7.0]
* jc/1.7.0-status (2009-08-15) 3 commits
(merged to 'next' on 2009-08-22 at b3507bb)
+ git status: not "commit --dry-run" anymore
+ git stat -s: short status output
+ git stat: the beginning of "status that is not a dry-run of commit"
With this, "git status" is no longer "git commit --preview".
* jc/1.7.0-send-email-no-thread-default (2009-08-22) 1 commit
(merged to 'next' on 2009-08-22 at 5106de8)
+ send-email: make --no-chain-reply-to the default
* jc/1.7.0-diff-whitespace-only-status (2009-08-30) 4 commits.
(merged to 'next' on 2009-08-30 at 0623572)
+ diff.c: fix typoes in comments
(merged to 'next' on 2009-08-27 at 81fb2bd)
+ Make test case number unique
(merged to 'next' on 2009-08-02 at 9c08420)
+ diff: Rename QUIET internal option to QUICK
+ diff: change semantics of "ignore whitespace" options
This changes exit code from "git diff --ignore-whitespace" and friends
when there is no actual output. It is a backward incompatible change, but
we could argue that it is a bugfix.
* jc/1.7.0-push-safety (2009-02-09) 2 commits
(merged to 'next' on 2009-08-02 at 38b82fe)
+ Refuse deleting the current branch via push
+ Refuse updating the current branch in a non-bare repository via push
--------------------------------------------------
[I have been too busy to purge these]
* jc/log-tz (2009-03-03) 1 commit.
- Allow --date=local --date=other-format to work as expected
Maybe some people care about this. I dunno.
* jc/mailinfo-remove-brackets (2009-07-15) 1 commit.
- mailinfo: -b option keeps [bracketed] strings that is not a [PATCH] marker
Maybe some people care about this. I dunno.
* ar/maint-1.6.2-merge-recursive-d-f (2009-05-11) 2 commits.
. Fix for a merge where a branch has an F->D transition
. Add a reminder test case for a merge with F/D transition
* jc/merge-convert (2009-01-26) 1 commit.
. git-merge-file: allow converting the results for the work tree
* lt/read-directory (2009-05-15) 3 commits.
. Add initial support for pathname conversion to UTF-8
. read_directory(): infrastructure for pathname character set conversion
. Add 'fill_directory()' helper function for directory traversal
* ps/blame (2009-03-12) 1 commit.
. blame.c: start libifying the blame infrastructure
* pb/tracking (2009-07-16) 7 commits.
. branch.c: if remote is not config'd for branch, don't try delete push config
. branch, checkout: introduce autosetuppush
. move deletion of merge configuration to branch.c
. remote: add per-remote autosetupmerge and autosetuprebase configuration
. introduce a struct tracking_config
. branch: install_branch_config and struct tracking refactoring
. config: allow false and true values for branch.autosetuprebase
Has been ejected from 'pu' for some time, expecting a reroll.
* ne/rev-cache (2009-08-21) 6 commits
. support for path name caching in rev-cache
. full integration of rev-cache into git, completed test suite
. administrative functions for rev-cache, start of integration into git
. support for non-commit object caching in rev-cache
. basic revision cache system, no integration or features
. man page and technical discussion for rev-cache
Updated but seems to break upload-pack tests when merged to 'pu'; given
what this series touches, breakages in that area are expected.
May discard if a working reroll comes, to give it a fresh start.
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox