* Re: [PATCH] git-cherry: make <upstream> parameter optional
From: Markus Heidelberg @ 2008-12-30 13:37 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git
In-Reply-To: <alpine.DEB.1.00.0812301411480.30769@pacific.mpi-cbg.de>
Johannes Schindelin, 30.12.2008:
> Hi,
>
> On Mon, 29 Dec 2008, Markus Heidelberg wrote:
>
> > The upstream branch <upstream> now defaults to the first tracked
> > remote branch, which is set by the configuration variables
> > branch.<name>.remote and branch.<name>.merge of the current branch.
> >
> > Without such a remote branch, the command "git cherry [-v]" fails with
> > usage output as before and an additional message.
> >
> > Signed-off-by: Markus Heidelberg <markus.heidelberg@web.de>
>
> This would be a massively visible user interface change. At the moment,
> it does this (which I like):
>
> $ git cherry-pick
> usage: git cherry-pick [options] <commit-ish>
>
> -n, --no-commit don't automatically commit
> -e, --edit edit the commit message
> -x append commit name when cherry-picking
> -r no-op (backward compatibility)
> -s, --signoff add Signed-off-by:
> -m, --mainline <n> parent number
>
> Opposed,
> Dscho
The patch was about git-cherry, not git-cherry-pick.
Markus
^ permalink raw reply
* Re: [PATCH] git-cherry: make <upstream> parameter optional
From: Johannes Schindelin @ 2008-12-30 13:44 UTC (permalink / raw)
To: Markus Heidelberg; +Cc: git
In-Reply-To: <200812301437.06726.markus.heidelberg@web.de>
Hi,
On Tue, 30 Dec 2008, Markus Heidelberg wrote:
> Johannes Schindelin, 30.12.2008:
>
> > On Mon, 29 Dec 2008, Markus Heidelberg wrote:
> >
> > > The upstream branch <upstream> now defaults to the first tracked
> > > remote branch, which is set by the configuration variables
> > > branch.<name>.remote and branch.<name>.merge of the current branch.
> > >
> > > Without such a remote branch, the command "git cherry [-v]" fails
> > > with usage output as before and an additional message.
> > >
> > > Signed-off-by: Markus Heidelberg <markus.heidelberg@web.de>
> >
> > This would be a massively visible user interface change. At the moment,
> > it does this (which I like):
> >
> > $ git cherry-pick
> > usage: git cherry-pick [options] <commit-ish>
> >
> > -n, --no-commit don't automatically commit
> > -e, --edit edit the commit message
> > -x append commit name when cherry-picking
> > -r no-op (backward compatibility)
> > -s, --signoff add Signed-off-by:
> > -m, --mainline <n> parent number
>
> The patch was about git-cherry, not git-cherry-pick.
Oops.
Sorry,
Dscho
P.S.: This certainly will not be the last time that I am bitten by the
closeness of the names "cherry" (which I _never_ use) and "cherry-pick",
which I use frequently. Even worse: the rev-list option that could make
that stand-alone plumbing command "cherry" obsolete is called
_--cherry-pick_, of all things...
^ permalink raw reply
* Re: [PATCH] git-cherry: make <upstream> parameter optional
From: demerphq @ 2008-12-30 14:02 UTC (permalink / raw)
To: markus.heidelberg; +Cc: git
In-Reply-To: <200812291845.20500.markus.heidelberg@web.de>
2008/12/29 Markus Heidelberg <markus.heidelberg@web.de>:
> The upstream branch <upstream> now defaults to the first tracked
> remote branch, which is set by the configuration variables
> branch.<name>.remote and branch.<name>.merge of the current branch.
>
> Without such a remote branch, the command "git cherry [-v]" fails with
> usage output as before and an additional message.
>
> Signed-off-by: Markus Heidelberg <markus.heidelberg@web.de>
FWIW: I would find this useful. Thanks for writing it.
Yves
--
perl -Mre=debug -e "/just|another|perl|hacker/"
^ permalink raw reply
* Re: why still no empty directory support in git
From: Michael Gaber @ 2008-12-30 14:21 UTC (permalink / raw)
To: Git Mailing List
In-Reply-To: <alpine.DEB.1.00.0812301308530.30769@pacific.mpi-cbg.de>
[-- Attachment #1: Type: text/plain, Size: 446 bytes --]
Johannes Schindelin schrieb:
> Hi,
>
> On Tue, 30 Dec 2008, Ping Yin wrote:
>
>> Yes, i know this topic has been discussed for many times.
>
> We have empty directory support in Git. It works like this: for
> directories that you do want to keep, you add an empty .gitignore file.
>
> No problem at all,
> Dscho
well if i understood him correctly his use-case would soon remove that
.whatever-file so it doesn't solve the problem
Michael
[-- Attachment #2: S/MIME Cryptographic Signature --]
[-- Type: application/x-pkcs7-signature, Size: 3656 bytes --]
^ permalink raw reply
* [PATCH] Pass --upload-pack and --receive-pack through submodules.
From: Jason Riedy @ 2008-12-30 15:09 UTC (permalink / raw)
To: git; +Cc: Jason Riedy
In-Reply-To: <1230605055-30723-1-git-send-email-jason@acm.org>
While I no longer have to worry about a zillion ancient OS versions,
I now have to worry about a remote site where I cannot control the
path for non-interactive shells. Thus, submodules need to handle
explicitly specified git-upload-pack and git-receive-pack programs.
There may be a fun shell quoting dance to avoid the extra conditionals.
Any such dance would be even more confusing to read.
Signed-off-by: Jason Riedy <jason@acm.org>
---
Sorry; I forgot the documentation patch last time. And it might be
better just to copy the entire submodule config directly to the remote
section...
Documentation/git-submodule.txt | 15 +++++++-
Documentation/gitmodules.txt | 13 ++++++-
git-submodule.sh | 81 +++++++++++++++++++++++++++++++++++++--
t/t7404-submodule-packbin.sh | 53 +++++++++++++++++++++++++
4 files changed, 156 insertions(+), 6 deletions(-)
create mode 100755 t/t7404-submodule-packbin.sh
diff --git a/Documentation/git-submodule.txt b/Documentation/git-submodule.txt
index 2f207fb..9e2de16 100644
--- a/Documentation/git-submodule.txt
+++ b/Documentation/git-submodule.txt
@@ -9,7 +9,7 @@ git-submodule - Initialize, update or inspect submodules
SYNOPSIS
--------
[verse]
-'git submodule' [--quiet] add [-b branch] [--] <repository> <path>
+'git submodule' [--quiet] add [-b branch] [-u <git-upload-pack>] [--receive-pack <git-receive-pack>] [--] <repository> <path>
'git submodule' [--quiet] status [--cached] [--] [<path>...]
'git submodule' [--quiet] init [--] [<path>...]
'git submodule' [--quiet] update [--init] [--] [<path>...]
@@ -159,6 +159,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 d1a17e2..3387951 100644
--- a/Documentation/gitmodules.txt
+++ b/Documentation/gitmodules.txt
@@ -30,6 +30,13 @@ 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].
EXAMPLES
--------
@@ -42,12 +49,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 2f47e06..1a8a968 100755
--- a/git-submodule.sh
+++ b/git-submodule.sh
@@ -90,6 +90,8 @@ module_clone()
{
path=$1
url=$2
+ uploadpack=$3
+ receivepack=$4
# If there already is a directory at the submodule path,
# expect it to be empty (since that is the default checkout
@@ -105,8 +107,23 @@ module_clone()
test -e "$path" &&
die "A file already exist at path '$path'"
- git-clone -n "$url" "$path" ||
+ if test "$uploadpack"
+ then
+ git-clone --upload-pack $uploadpack -n "$url" "$path"
+ else
+ git-clone -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
}
#
@@ -130,6 +147,16 @@ cmd_add()
-q|--quiet)
quiet=1
;;
+ -u|--upload-pack)
+ case "$2" in '') usage ;; esac
+ uploadpack=$2
+ shift
+ ;;
+ --receive-pack)
+ case "$2" in '') usage ;; esac
+ receivepack=$2
+ shift
+ ;;
--)
shift
break
@@ -191,9 +218,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" || exit
+ module_clone "$path" "$realrepo" "$uploadpack" "$receivepack" || exit
(unset GIT_DIR; cd "$path" && git checkout -f -q ${branch:+-b "$branch" "origin/$branch"}) ||
die "Unable to checkout submodule '$path'"
fi
@@ -202,7 +237,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'"
}
@@ -277,6 +324,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
+
say "Submodule '$name' ($url) registered for path '$path'"
done
}
@@ -330,7 +390,8 @@ cmd_update()
if ! test -d "$path"/.git -o -f "$path"/.git
then
- module_clone "$path" "$url" || exit
+ module_clone "$path" "$url" "$(git config submodule."$name".uploadpack)" \
+ "$(git config submodule."$name".receivepack)" || exit
subsha1=
else
subsha1=$(unset GIT_DIR; cd "$path" &&
@@ -655,6 +716,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
diff --git a/t/t7404-submodule-packbin.sh b/t/t7404-submodule-packbin.sh
new file mode 100755
index 0000000..d46b3e6
--- /dev/null
+++ b/t/t7404-submodule-packbin.sh
@@ -0,0 +1,53 @@
+#!/bin/sh
+#
+# Copyright (c) 2008 E. Jason Riedy
+#
+
+test_description='git submodule with explicit pack programs
+
+These tests exercise git submodule with --upload-pack and --receive-pack arguments.
+'
+
+. ./test-lib.sh
+
+test_expect_success setup '
+ echo file > file &&
+ git add file &&
+ test_tick &&
+ git commit -m upstream
+ git clone . super &&
+ git clone super submodule &&
+ (cd super &&
+ git submodule add --upload-pack "${GIT_EXEC_PATH}/git-upload-pack" --receive-pack "${GIT_EXEC_PATH}/git-receive-pack" ../submodule submodule &&
+ test_tick &&
+ git commit -m "submodule"
+ ) &&
+ git clone super super-clone &&
+ (cd super-clone && git submodule update --init)
+'
+
+test_expect_success 'push submodule change' '
+ (cd super &&
+ cd submodule &&
+ git checkout master &&
+ echo second line >> file &&
+ test_tick &&
+ git commit -a -m "change submodule inside" &&
+ git push origin +master:pushed
+ )
+'
+
+test_expect_success 'pull submodule change' '
+ (cd submodule &&
+ git pull . pushed &&
+ echo second line >> file &&
+ test_tick &&
+ git commit -a -m "change submodule outside"
+ ) &&
+ (cd super &&
+ cd submodule &&
+ git pull origin master
+ )
+'
+
+test_done
--
1.6.1.60.g1f086.dirty
^ permalink raw reply related
* [PATCH rfc v2] git-sh-setup: Fix scripts whose PWD is a symlink to a work-dir on OS X
From: Marcel M. Cary @ 2008-12-30 15:10 UTC (permalink / raw)
To: git; +Cc: gitster, jnareb, ae, j.sixt, Marcel M. Cary
In-Reply-To: <CC0158BE-219B-4E09-9B3B-A2D1B66132AC@silverinsanity.com>
On Mac OS X and possibly BSDs, /bin/pwd reads PWD from the environment
if available and shows the logical path by default rather than the
physical one.
Unset PWD before running /bin/pwd in both cd_to_toplevel and its
test.
Still use the external /bin/pwd because in my Bash on Linux,
the builtin pwd prints the same result whether or not PWD is set.
---
Brian Gernhardt wrote:
> I didn't pay attention to this at the time, but I just tried to build a
> new version of git and noticed this...
>
>> + ..|../*|*/..|*/../*)
>> + # Interpret $cdup relative to the physical, not logical,
>> cwd.
>> + # Probably /bin/pwd is more portable than passing -P to
>> cd or pwd.
>> + phys="$(/bin/pwd)/$cdup"
>> + ;;
>
> This is a non-portable construct. Notably, on OS X (and possibly some
> BSDs) /bin/pwd does not give the physical path, but $(/bin/pwd -P)
> does.
Ouch!
Junio C Hamano wrote:
> Having said that, I think it would probably be better to bite the
> bullet and start using "cd -P" soon after 1.6.1 goes final, and at the
> same time existing places that use "cd `pwd`" as a workaround if there
> are some.
Perhaps it's time to start using "cd -P" with the recent release of
1.6.1. But maybe it's also worth finding a fix that doesn't rely on it
for any maintenance release of 1.6 that might happen?
Brian Gernhardt wrote:
> We may have to build this string ourselves with a --show-cd-absolute
> for portability.
Some options I considered:
(1) We could implement --show-cd-absolute in the short term, with the
expectation of removing it we switch to "cd -P". Not sure it would
really work to try to remove a switch, even if it were undocumented, or
documented as deprecated.
(2) We could check the output of /bin/pwd for ".." and if they are still
present, add the "-P". But I suppose there's no guarantee "-P" would
work, and I shy away from additional analysis of the path because I
don't want to miss an edge case.
(3) We could unset PWD before running /bin/pwd. (Note that in my Bash,
the pwd *builtin* prints the same result whether or not I unset PWD
first.) I suppose it's possible some /bin/pwd dies when PWD is unset or
something, but that seems unlikely.
From
http://developer.apple.com/DOCUMENTATION/Darwin/Reference/ManPages/man1/pwd.1.html
> The -L option does not work unless the PWD environment variable is
> exported by the shell.
I like option 3 best. Any thoughts?
I sent the first rev of this patch to just Brian. It didn't have
either of the unit test changes. He said it fixed all but t2300.3,
where cd_to_toplevel doesn't actually "cd", so I made the same change
to the unit test itself. Can someone with OS X try running the test
suite with v2 of this patch? I don't have OS X readily available.
Marcel
git-sh-setup.sh | 2 +-
t/t2300-cd-to-toplevel.sh | 4 ++--
2 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/git-sh-setup.sh b/git-sh-setup.sh
index f07d96b..2142308 100755
--- a/git-sh-setup.sh
+++ b/git-sh-setup.sh
@@ -96,7 +96,7 @@ cd_to_toplevel () {
..|../*|*/..|*/../*)
# Interpret $cdup relative to the physical, not logical, cwd.
# Probably /bin/pwd is more portable than passing -P to cd or pwd.
- phys="$(/bin/pwd)/$cdup"
+ phys="$(unset PWD; /bin/pwd)/$cdup"
;;
*)
# There's no "..", so no need to make things absolute.
diff --git a/t/t2300-cd-to-toplevel.sh b/t/t2300-cd-to-toplevel.sh
index beddb4e..e42cbfe 100755
--- a/t/t2300-cd-to-toplevel.sh
+++ b/t/t2300-cd-to-toplevel.sh
@@ -10,12 +10,12 @@ test_cd_to_toplevel () {
cd '"'$1'"' &&
. git-sh-setup &&
cd_to_toplevel &&
- [ "$(/bin/pwd)" = "$TOPLEVEL" ]
+ [ "$(unset PWD; /bin/pwd)" = "$TOPLEVEL" ]
)
'
}
-TOPLEVEL="$(/bin/pwd)/repo"
+TOPLEVEL="$(unset PWD; /bin/pwd)/repo"
mkdir -p repo/sub/dir
mv .git repo/
SUBDIRECTORY_OK=1
--
1.6.0.3
^ permalink raw reply related
* Re: why still no empty directory support in git
From: Ping Yin @ 2008-12-30 15:36 UTC (permalink / raw)
To: Robin Rosenberg; +Cc: Jeff Whiteside, Asheesh Laroia, Git Mailing List
In-Reply-To: <200812300758.41988.robin.rosenberg.lists@dewire.com>
On Tue, Dec 30, 2008 at 2:58 PM, Robin Rosenberg
<robin.rosenberg.lists@dewire.com> wrote:
> You can have an empty tree, but the index doesn't store them,
> so they would be lost on checkout/commit. Linus sketched a solution,
> but nobody took the bait. Seems doable if anyone really wants it, but
> I'm certain it adds a lot of special cases.
>
> Look for a discussion [RFC PATCH] Re: Empty directories... posted on 2007-07-19.
> It's in the middle of a long thread.
>
Thanks for pointing me to that thread. For other's convenience, the
begin of the thread is
http://article.gmane.org/gmane.comp.version-control.git/52813
^ permalink raw reply
* Re: for newbs = little exercise / tutorial / warmup for windows and other non-sophisticated new Git users :-)
From: Zorba @ 2008-12-30 16:07 UTC (permalink / raw)
To: git
In-Reply-To: <3ab397d0812291505v77824e6fvdecebc80f38a5f89@mail.gmail.com>
"Jeff Whiteside" <jeff.m.whiteside@gmail.com> wrote in message
news:3ab397d0812291505v77824e6fvdecebc80f38a5f89@mail.gmail.com...
hi zorb,
you have done a great justice here to inadvertently explaining the
learning curve of git, through a few mistakes, especially for ppl
behind in their scm use. i enjoyed reading your blog posts though, as
they remind me of myself, not long ago.
you have a couple of mistakes i think you should correct.
-"Imagine a project with 4 versions, made up of various configurations
of the three files."
this line implies that you have branches (the word configurations).
you should be focusing, at first, on a project that has a set number
of files, and the content merely changes. ideally, you don't often
add and rm files across versions. also, the project doesn't really
have 4 versions, like windows has 4 different versions of vista, the
project has 3 old versions and 1 new version.
** ok, I've changed "configurations" as its overloaded in the context of
older SCMs.
Point taken about changing content not containers. However changing content
is easier, and therefore less need for a tutorial
Also this write-up is basically a "note to self", that I've cleaned up in
case someone else can find it useful, and the problem I was solving was a
problem that involved containers changing.
I've explained the context for going the way of containers now in the
write-up.
I've covered off your concern for ppl thinking we have 4x current versions
(ie. branches) with "4 progressively more recent versions"
"Setup a git index in the project directory"
-this implies you're talking about the index. you're not. you're
talking about the repository. either make it clear that the index is
an intermediary staging area, or ignore its existence and change all
git-add && git-commit references to git-commit -a references. this
will ease the user of older scms into git.
** Don't forget they'll have read the tutorial and/or user-guide, and the
concepts of an index and staging are fairly easy to pick up.
I'll keep it in, and make sure I refer to it as you suggest.
-"Rollback to each of the versions, starting with version A"
this is bad. you're saying rollback. to others that have used scms,
this will mean, "retrieve an older copy", but in git, this is DELETING
all the versions after the version that you "rollback" to. your blog
post shouldn't discuss the git-reset --hard command at all, since
you're rewriting history, which is dangerous. afaik, most scms don't
allow you to rewrite history. to "rollback" to an older version you
should use checkout the git-checkout command. maybe the git reset
-–hard HEAD is okay to include... but it won't be immediately obvious
to new users why it does what it does... this nomenclature was likely
not the best choice whenever it was made.
** have now promoted git-checkout as the way to review older versions
I've left git-reset in there, for my own notes as much as anything, but not
suggesting it be used as some sort of cursor to move the HEAD up and down
the branch
NB getting some funny results with git-checkout near the head of the branch
- will investigatge and report
u're talking sdf
On Sat, Dec 27, 2008 at 5:29 PM, Zorba <cr@altmore.co.uk> wrote:
>
> tidied up the formatting, added a few more comments where needed, fixed
> errors/lack of clarity
>
> "Zorba" <cr@altmore.co.uk> wrote in message
> news:gj68a0$u56$3@ger.gmane.org...
> > Here is a little exercise / tutorial / warm-up for someone starting out
> > with Git. If you're anyting like me you may find the tutorials etc. on
> > git.or.cz a bit daunting. I recommend you try this after reading the
> > user
> > manual but before tearing your hair out trying to follow all the
> > examples
> > in the user manual. After you've followed this simple workflow, then go
> > back to the more advanced stuff in the tutorials and user manuals (like
> > cloning repositories and creating and merging branches).
> >
> > I created this exercise to try and model our workflow and what we wanted
> > to use git for = tracking a project with multiple files where the
> > filebase
> > might change frequently from one version to the next.
> >
> > http://siliconmouth.wordpress.com/category/nerdy/
> >
> > look for December 27, 2008 or "git warmup"
> >
> >
>
>
>
> --
> To unsubscribe from this list: send the line "unsubscribe git" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: many git sites homepages megabytes big
From: jidanni @ 2008-12-30 15:57 UTC (permalink / raw)
To: mail; +Cc: git, jnareb, pasky
In-Reply-To: <4959FFA2.4050403@cup.kalibalik.dk>
>>>>> "AM" == Anders Melchiorsen <mail@cup.kalibalik.dk> writes:
AM> For the specific case of repo.or.cz, I guess that turning on HTTP
AM> compression might help a lot.
It's the billion bytes to the innocents' browser that huts the most.
Bad to put such large homepages into browsers.
^ permalink raw reply
* Re: git clone - failing on cygwin with git:// but not with ssh://
From: Joe Casadonte @ 2008-12-30 16:40 UTC (permalink / raw)
To: git
Joe Casadonte <jcasadonte <at> northbound-train.com> writes:
> D:\temp>git clone git://foobar/otminfmyproj.git
> Initialized empty Git repository in /cygdrive/d/temp/foobar/.git/
> fatal: read error (Socket operation on non-socket)
> fatal: early EOF
> fatal: index-pack failed
>
> I've turned on verbose logging in the daemon and I see the following
> messages:
>
> Dec 27 17:31:53 foobar git-daemon: [30327] Connection from 192.168.1.102:2598
> Dec 27 17:31:53 foobar git-daemon: [30327] Extended attributes (16 bytes) exist <host=foobar>
> Dec 27 17:31:53 foobar git-daemon: [30327] Request upload-pack for '/myproj.git'
> Dec 27 17:31:55 foobar git-daemon: [30327] Disconnected (with error)
>
> Running the clone via ssh protocol from test client #2 works, though:
>
> D:\temp>git clone ssh://root <at> foobar/nfs02/git/myproj
> Initialized empty Git repository in /cygdrive/d/temp/myproj/.git/
> remote: Counting objects: 104, done.
> remote: Compressing objects: 100% (72/72), done.
> remote: Total 104 (delta 22), reused 104 (delta 22)
> Receiving objects: 100% (104/104), 76.97 KiB | 9 KiB/s, done.
> Resolving deltas: 100% (22/22), done.
>
> The same test machine has cloned from a different linux server via the
> git protocol just fine.
Looking for a little help, please. Is this not a legitimate git issue? Can
anyone at least help me diagnose the issue? Please?
--
Regards,
joe
Joe Casadonte
jcasadonte@northbound-train.com
------------------------------------------------------------------------------
Llama Fresh Farms => http://www.northbound-train.com
Ramblings of a Gay Man => http://www.northbound-train.com/ramblings
Emacs Stuff => http://www.northbound-train.com/emacs.html
Music CD Trading => http://www.northbound-train.com/cdr.html
------------------------------------------------------------------------------
Live Free, that's the message!
------------------------------------------------------------------------------
^ permalink raw reply
* new home for libgit2 project
From: Shawn O. Pearce @ 2008-12-30 17:04 UTC (permalink / raw)
To: git
I've (mostly) moved libgit2 to repo.or.cz (thanks Pieter for
releasing the mirror, thanks Pasky for the free hosting!):
http://repo.or.cz/w/libgit2.git
git://repo.or.cz/libgit2.git
Thus far its able to format and parse SHA-1 strings, and read
loose objects from a repository. It also doesn't compile on
Mac OS X as the Mach-O file format doesn't support the use of
__thread declarations on variables...
--
Shawn.
^ permalink raw reply
* Re: for newbs = little exercise / tutorial / warmup for windows and other non-sophisticated new Git users :-)
From: Zorba @ 2008-12-30 17:22 UTC (permalink / raw)
To: git
In-Reply-To: <gjdh0r$n3c$4@ger.gmane.org>
Ok, when I do
$ rm *.*
$ git checkout versionA .
I'm getting ABC.txt, AC.txt, BC.txt
which is wrong as only the first two files went into version A
Paradoxically
$ rm *.*
$ git reset --hard versionA
produces the desired result!
I picked up a few cases like this with git-checkout today. Usually a file or
two gets copied into the working tree that shouldn't have been (and I'm
clearing the working tree before each checkout, so its not "leftovers", its
defo git-checkout doing it)
Its coming back to me now - when I was writing my "warm-up" I tried both
git-checkout and git-reset, to do my "rollbacks" and git-checkout produced a
few inconsistent results like above, so I decided to stick with git-reset
(this was before I knew the dangers of git-reset of course!) for "safety".
Could it be that all the "vandalism" I've perpetrated to the history by
resetting in a FORWARD direction could have corrupted the history somehow ?
Even so, you'd expect something vanilla like $ git checkout not to be
affected.
I'm gonna try the checkouts without doing any resetting beforehand (i.e. no
messing with the history) to see if I can reproduce this.
"Zorba" <cr@altmore.co.uk> wrote in message
news:gjdh0r$n3c$4@ger.gmane.org...
** have now promoted git-checkout as the way to review older versions
I've left git-reset in there, for my own notes as much as anything, but not
suggesting it be used as some sort of cursor to move the HEAD up and down
the branch
NB getting some funny results with git-checkout near the head of the branch
- will investigatge and report
^ permalink raw reply
* Re: for newbs = little exercise / tutorial / warmup for windows and other non-sophisticated new Git users :-)
From: Zorba @ 2008-12-30 17:44 UTC (permalink / raw)
To: git
In-Reply-To: <gjdlcl$5no$4@ger.gmane.org>
So I deleted the repo and the working tree, restarted the git bash (i.e.
wiped the slate clean) and started my little warm up workflow again, getting
as far as just created and tagged versionD.
So lets do some checking out
$ rm *.*
$ git checkout versionA .
gives ABC.txt, AC.txt = correct
however...
$ rm *.*
$ git checkout versionB .
gives ABC.txt, AC.txt, BC.txt
which is wrong
running gitk confirms that AC.txt should not be in versionB
!!!!
^ permalink raw reply
* Re: for newbs = little exercise / tutorial / warmup for windows and other non-sophisticated new Git users :-)
From: Jeff Whiteside @ 2008-12-30 18:35 UTC (permalink / raw)
To: Zorba; +Cc: git
In-Reply-To: <gjdmm6$9oj$4@ger.gmane.org>
> commit -a detects that files have been deleted, and takes them out of the index !
> could also have used $ git rm <specific files> and then $ git commit ..
hey! i like your changes! the post is pretty polished now. the only
thing else i would change (srysry), is the above. "-a detects that
files have been deleted" -> heh, not true. you don't need -a here;
it does something else.
okay i just recreated your repo and did the same thing. with your
syntax "git checkout versionA ." i got the same result, and i'm not
sure why, but i think it was because of the detached head.
good news, use "git checkout versionA", not "git checkout versionA ."
(so, use it wihtout the dot), and you should be back in working order.
the other (good?) news is that you probably _do_ want to be using git
reset --hard in your case, because you're trying to build up a history
from some project, so you do want to erase some faulty commits after
you bodge something or miss some files.
the bad news is that my opinion is that you should probably move on
with your life, because my own past tells me that you'll never
actually use those old project versions, hahah :p
^ permalink raw reply
* Re: for newbs = little exercise / tutorial / warmup for windows and other non-sophisticated new Git users :-)
From: Daniel Barkalow @ 2008-12-30 19:42 UTC (permalink / raw)
To: Zorba; +Cc: git
In-Reply-To: <gj68a0$u56$3@ger.gmane.org>
On Sat, 27 Dec 2008, Zorba wrote:
> Here is a little exercise / tutorial / warm-up for someone starting out with
> Git. If you're anyting like me you may find the tutorials etc. on git.or.cz
> a bit daunting. I recommend you try this after reading the user manual but
> before tearing your hair out trying to follow all the examples in the user
> manual. After you've followed this simple workflow, then go back to the more
> advanced stuff in the tutorials and user manuals (like cloning repositories
> and creating and merging branches).
>
> I created this exercise to try and model our workflow and what we wanted to
> use git for = tracking a project with multiple files where the filebase
> might change frequently from one version to the next.
One thing I find unrealistic about this example is that you've got BC.txt
and C.txt when you're creating version A, and you've even copied them to
the working directory. In real life, you'd almost certainly not create the
files until you're preparing the version that includes them, at least if
your history is version A, version B, version C. (Now, it's possible that
your history is "create a bunch of files", "create version A without
BC.txt and C.txt"; in parallel to version A, create version B without
AC.txt and C.txt; but that's a different process entirely.)
I think the exercise would come out much more easily if you only created
ABC.txt and AC.txt at the beginning, made version A, added BC.txt and
removed AC.txt, made version B, created C.txt and recovered AC.txt, and
made version C; this is, I believe, what would actually happen.
If you're having trouble with "git commit" putting you in a lousy editor,
somebody probably needs to do better packaging. "git commit" (without the
-m) should open up the best editor available on your computer, but it
doesn't seem to have a good idea about your preferences for editors. Of
course, part of the problem is people who don't like that editor rarely
use the command line on Windows. Do you have a good editor for Windows?
How have you specified it, if so?
-Daniel
*This .sig left intentionally blank*
^ permalink raw reply
* [PATCH,RESEND] objects to be pruned immediately don't have to be loosened
From: Nicolas Pitre @ 2008-12-30 19:45 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
When there is no grace period before pruning unreferenced objects, it is
pointless to push those objects in their loose form just to delete them
right away.
Also be more explicit about the possibility of using "now" in the
gc.pruneexpire config variable (needed for the above behavior to
happen).
Signed-off-by: Nicolas Pitre <nico@cam.org>
diff --git a/Documentation/config.txt b/Documentation/config.txt
index 7408bb2..ea0cd97 100644
--- a/Documentation/config.txt
+++ b/Documentation/config.txt
@@ -702,7 +702,9 @@ gc.packrefs::
gc.pruneexpire::
When 'git-gc' is run, it will call 'prune --expire 2.weeks.ago'.
- Override the grace period with this config variable.
+ Override the grace period with this config variable. The value
+ "now" may be used to disable this grace period and always prune
+ unreachable objects immediately.
gc.reflogexpire::
'git-reflog expire' removes reflog entries older than
diff --git a/builtin-gc.c b/builtin-gc.c
index 781df60..f8eae4a 100644
--- a/builtin-gc.c
+++ b/builtin-gc.c
@@ -188,7 +188,9 @@ static int need_to_gc(void)
* there is no need.
*/
if (too_many_packs())
- append_option(argv_repack, "-A", MAX_ADD);
+ append_option(argv_repack,
+ !strcmp(prune_expire, "now") ? "-a" : "-A",
+ MAX_ADD);
else if (!too_many_loose_objects())
return 0;
@@ -243,7 +245,9 @@ int cmd_gc(int argc, const char **argv, const char *prefix)
"run \"git gc\" manually. See "
"\"git help gc\" for more information.\n");
} else
- append_option(argv_repack, "-A", MAX_ADD);
+ append_option(argv_repack,
+ !strcmp(prune_expire, "now") ? "-a" : "-A",
+ MAX_ADD);
if (pack_refs && run_command_v_opt(argv_pack_refs, RUN_GIT_CMD))
return error(FAILED_RUN, argv_pack_refs[0]);
^ permalink raw reply related
* Re: git clone - failing on cygwin with git:// but not with ssh://
From: Junio C Hamano @ 2008-12-30 19:54 UTC (permalink / raw)
To: Joe Casadonte; +Cc: git
In-Reply-To: <u7i5hy5ti.fsf@terrapin.northbound-train.com>
"Joe Casadonte" <jcasadonte@northbound-train.com> writes:
> Looking for a little help, please. Is this not a legitimate git issue? Can
> anyone at least help me diagnose the issue? Please?
I think "git on Cygwin" is as legitimate as git on anything else, but at
the same time my guess is that it is a combination of the fact that
everybody is busy with other things around the end of year , and that
probably there are not many "git on Cygwin" experts monitoring the list to
begin with.
Sorry, I do not work on Cygwin (nor Windows in general). "fatal: read
error (Socket operation on non-socket)" sounds like it is coming from
pkt-line.c::safe_read() on the downloading side (i.e. git-clone).
Googling for that error message seems to indicate that it seems to a
rather common error message on wide variety of programs running on Cygwin.
C.f.
http://www.google.com/search?&q=%22Socket+operation+on+non-socket%22+site%3Acygwin.com
^ permalink raw reply
* Re: git clone - failing on cygwin with git:// but not with ssh://
From: Joe Casadonte @ 2008-12-30 20:01 UTC (permalink / raw)
To: git
In-Reply-To: <u7i5hy5ti.fsf@terrapin.northbound-train.com>
On 30 Dec 2008, Joe Casadonte wrote:
> Looking for a little help, please. Is this not a legitimate git
> issue? Can anyone at least help me diagnose the issue? Please?
My apologies to the group -- I wasn't really cognizant of the fact
that its only been 3 days since my first email. That has now been
made abundantly clear to me :)
I've been working on getting git working full-bore since the middle of
last week, of which this issue is just part of it, and I'm quickly
running out of time (Jan 5 I have to ditch this and go back to my
normal tasks). All the days are blurring together.....
Anyhow, thanks for *your* patience with me, despite the lack of
manners on my end. A happy & safe New Years to all!
--
Regards,
joe
Joe Casadonte
jcasadonte@northbound-train.com
------------------------------------------------------------------------------
Llama Fresh Farms => http://www.northbound-train.com
Ramblings of a Gay Man => http://www.northbound-train.com/ramblings
Emacs Stuff => http://www.northbound-train.com/emacs.html
Music CD Trading => http://www.northbound-train.com/cdr.html
------------------------------------------------------------------------------
Live Free, that's the message!
------------------------------------------------------------------------------
^ permalink raw reply
* [PATCH v2] builtin-shortlog.c: use string_list_append(), and don't strdup unnecessarily
From: Adeodato Simó @ 2008-12-30 20:25 UTC (permalink / raw)
To: git, gitster; +Cc: Johannes Schindelin, Adeodato Simó
In-Reply-To: <alpine.DEB.1.00.0812301319140.30769@pacific.mpi-cbg.de>
Make cleanup in insert_one_record() use string_list_append(), instead of
duplicating its code. Because of this, do not free the "util" member when
clearing the "onelines" string lists: with the new code path it is not
initialized to any value (was being initialized to NULL previously).
Also, avoid unnecessary strdup() calls when inserting names in log->list.
This list always has "strdup_strings" activated, hence strdup'ing namebuf is
unnecessary. This change also removes a latent memory leak in the old code.
NB: The duplicated code mentioned above predated the appearance of
string_list_append().
Signed-off-by: Adeodato Simó <dato@net.com.org.es>
---
> FWIW I like the patch, but would like it even more if the strdup() removal
> was squashed in (with an explanation in the commit message).
Ok, I myself prefer it the other way, but here it is. :-)
builtin-shortlog.c | 19 +++----------------
1 files changed, 3 insertions(+), 16 deletions(-)
diff --git a/builtin-shortlog.c b/builtin-shortlog.c
index d03f14f..90e76ae 100644
--- a/builtin-shortlog.c
+++ b/builtin-shortlog.c
@@ -36,7 +36,6 @@ static void insert_one_record(struct shortlog *log,
const char *dot3 = log->common_repo_prefix;
char *buffer, *p;
struct string_list_item *item;
- struct string_list *onelines;
char namebuf[1024];
size_t len;
const char *eol;
@@ -68,12 +67,9 @@ static void insert_one_record(struct shortlog *log,
snprintf(namebuf + len, room, " %.*s", maillen, boemail);
}
- buffer = xstrdup(namebuf);
- item = string_list_insert(buffer, &log->list);
+ item = string_list_insert(namebuf, &log->list);
if (item->util == NULL)
item->util = xcalloc(1, sizeof(struct string_list));
- else
- free(buffer);
/* Skip any leading whitespace, including any blank lines. */
while (*oneline && isspace(*oneline))
@@ -104,16 +100,7 @@ static void insert_one_record(struct shortlog *log,
}
}
- onelines = item->util;
- if (onelines->nr >= onelines->alloc) {
- onelines->alloc = alloc_nr(onelines->nr);
- onelines->items = xrealloc(onelines->items,
- onelines->alloc
- * sizeof(struct string_list_item));
- }
-
- onelines->items[onelines->nr].util = NULL;
- onelines->items[onelines->nr++].string = buffer;
+ string_list_append(buffer, item->util);
}
static void read_from_stdin(struct shortlog *log)
@@ -323,7 +310,7 @@ void shortlog_output(struct shortlog *log)
}
onelines->strdup_strings = 1;
- string_list_clear(onelines, 1);
+ string_list_clear(onelines, 0);
free(onelines);
log->list.items[i].util = NULL;
}
--
1.6.1.307.g07803
^ permalink raw reply related
* Re: git-ls-files -l
From: Linus Torvalds @ 2008-12-30 20:32 UTC (permalink / raw)
To: Jakub Narebski; +Cc: jidanni, git
In-Reply-To: <m3wsdiaptg.fsf@localhost.localdomain>
On Tue, 30 Dec 2008, Jakub Narebski wrote:
>
> I think it would be easy to add '-l' also to git-ls-files. Please
> remember to provide size only for blobs, as provoding size for trees
> would make it harder to change to future packv4, where tree objects
> would be stored deconstructed.
Personally, more than "git ls-files -l", I've occasionally wanted a real
"git ls" that really looks more like "ls". That includes:
- turning a list of files in a subdirectory into a "directory" entry
(which is not very natural for "git ls-files" as an index operation,
since the index is fundamentally flat).
- yes, adding "-l" as an option, but really showing the stat information.
Right now, you can do "git ls-files --stage", and it will show a kind
of extended information, but while it shows the mode, it doesn't show
the owner/timestamp/etc parts of the index, and those are sometimes
interesting.
Btw, the "ls-tree -l" format is not nice. Don't use it as a basis
to pattern "ls -l" (or if you want to just extend ls-tree, whatever).
Linus
^ permalink raw reply
* What's cooking in git.git (Dec 2008, #04; Mon, 29)
From: Junio C Hamano @ 2008-12-30 20:59 UTC (permalink / raw)
To: git
with '-' are only in 'pu' while commits prefixed with '+' are
in 'next'. The ones marked with '.' do not appear in any of the branches,
but I am still holding onto them.
The topics list the commits in reverse chronological order. The topics
meant to be merged to the maintenance series have "maint-" in their names.
----------------------------------------------------------------
[New Topics]
* nd/grep-assume-unchanged (Sat Dec 27 15:21:03 2008 +0700) 2 commits
- grep: grep cache entries if they are "assume unchanged"
- grep: support --no-ext-grep to test builtin grep
* rs/diff-ihc (Sun Dec 28 19:45:32 2008 +0100) 1 commit
+ diff: add option to show context between close hunks
* as/maint-shortlog-cleanup (Wed Dec 24 17:34:44 2008 +0100) 2 commits
- builtin-shortlog.c: do not unnecessarily strdup before insertion
in list
- builtin-shortlog.c: use string_list_append() instead of
duplicating its code
* js/maint-merge-recursive-r-d-conflict (Mon Dec 22 23:10:20 2008 +0100) 1 commit
+ merge-recursive: mark rename/delete conflict as unmerged
* kk/maint-http-push (Tue Dec 23 11:31:15 2008 +0300) 1 commit
+ http-push: support full URI in handle_remote_ls_ctx()
* jc/maint-ls-tree (Thu Dec 25 16:54:23 2008 -0800) 1 commit
+ ls-tree: add --full-tree option
* mh/maint-sendmail-cc-doc (Mon Dec 29 00:37:25 2008 +0100) 1 commit
+ doc/git-send-email: mention sendemail.cc config variable
----------------------------------------------------------------
[Stalled and may need help and prodding to go forward]
* wp/add-patch-find (Thu Nov 27 04:08:03 2008 +0000) 3 commits
. In add --patch, Handle K,k,J,j slightly more gracefully.
. Add / command in add --patch
. git-add -i/-p: Change prompt separater from slash to comma
I am still holding onto this earlier topic to add '/' subcommand to allow
finding a hunk with given text, but I'd rather not merge/rebase it on top
of wp/add-p-goto series myself. Waiting for a reroll.
* kb/am-directory (Fri Aug 29 15:27:50 2008 -0700) 1 commit
. git-am: Pass the --directory option through to git-apply
A reroll of this by Simon Schubert triggered a series to fix a parameter
propagation bug, and another reroll to add "git am --directory=path/"
should be much easier now. I am not likely to use the feature myself, so
it is up to intrested volunteers to carry it forward.
* ds/uintmax-config (Mon Nov 3 09:14:28 2008 -0900) 1 commit
- autoconf: Enable threaded delta search when pthreads are supported
This automatically enables threaded delta search code when autoconf
detects pthreads are usable. I haven't heard neither positive nor
negative comments from minority platforms that might be harmed.
* jc/blame (Wed Jun 4 22:58:40 2008 -0700) 2 commits
+ blame: show "previous" information in --porcelain/--incremental
format
+ git-blame: refactor code to emit "porcelain format" output
This gives Porcelains (like gitweb) the information on the commit _before_
the one that the final blame is laid on, which should save them one
rev-parse to dig further. The line number in the "previous" information
may need refining, and sanity checking code for reference counting may
need to be resurrected before this can move forward.
----------------------------------------------------------------
[Actively cooking]
* mk/gitweb-feature (Mon Dec 15 22:16:19 2008 -0800) 1 commit
- gitweb: unify boolean feature subroutines
* cb/merge-recursive-fix (Mon Dec 15 02:41:24 2008 -0800) 3 commits
+ Merge branch 'cb/maint-merge-recursive-fix' into cb/merge-
recursive-fix
+ merge-recursive: do not clobber untracked working tree garbage
+ modify/delete conflict resolution overwrites untracked file
* cb/maint-merge-recursive-fix (Sun Dec 14 19:40:09 2008 -0800) 2 commits
+ merge-recursive: do not clobber untracked working tree garbage
+ modify/delete conflict resolution overwrites untracked file
* js/notes (Sat Dec 20 13:06:03 2008 +0100) 4 commits
- Add an expensive test for git-notes
- Speed up git notes lookup
- Add a script to edit/inspect notes
- Introduce commit notes
* wp/add-p-goto (Thu Dec 4 10:22:40 2008 +0000) 2 commits
+ Add 'g' command to go to a hunk
+ Add subroutine to display one-line summary of hunks
* jn/gitweb-blame (Thu Dec 11 01:33:29 2008 +0100) 3 commits
- gitweb: cache $parent_commit info in git_blame()
- gitweb: A bit of code cleanup in git_blame()
- gitweb: Move 'lineno' id from link to row element in git_blame
Jakub seemed to feel they are not yet ready.
* mv/um-pdf (Wed Dec 10 23:44:50 2008 +0100) 1 commit
+ Add support for a pdf version of the user manual
I do not have a new enough combination of dblatex and asciidoc myself but
this may help interested people.
* sc/gitweb-category (Fri Dec 12 00:45:12 2008 +0100) 3 commits
- gitweb: Optional grouping of projects by category
- gitweb: Split git_project_list_body in two functions
- gitweb: Modularized git_get_project_description to be more generic
* gb/gitweb-patch (Thu Dec 18 08:13:19 2008 +0100) 4 commits
- gitweb: link to patch(es) view in commit(diff) and (short)log view
- gitweb: add patches view
- gitweb: change call pattern for git_commitdiff
- gitweb: add patch view
----------------------------------------------------------------
[Graduated to "master"]
* js/rebase-i-p (Mon Dec 15 11:05:31 2008 +0100) 2 commits
+ rebase -i -p: Fix --continue after a merge could not be redone
+ Show a failure of rebase -p if the merge had a conflict
* np/auto-thread (Mon Dec 15 20:44:30 2008 +0100) 3 commits
+ Force t5302 to use a single thread
+ pack-objects: don't use too many threads with few objects
+ autodetect number of CPUs by default when using threads
* lt/reset-merge (Wed Dec 3 18:00:12 2008 -0800) 2 commits
+ Document "git-reset --merge"
+ Add 'merge' mode to 'git reset'
----------------------------------------------------------------
[Will merge to "master" soon]
* cb/mergetool (Fri Dec 12 21:48:41 2008 +0000) 4 commits
+ mergetool: Don't keep temporary merge files unless told to
+ mergetool: Add prompt to continue after failing to merge a file
+ Add -y/--no-prompt option to mergetool
+ Fix some tab/space inconsistencies in git-mergetool.sh
I have been waiting for comments from the original author and other
interested parties, but haven't heard anything yet. This tool is on the
fringe from my point of view anyway, so I'll push them out to 'master'
soon. If there is a breakage that annoys real people, we will hear from
them, and we can take it from there.
----------------------------------------------------------------
[On Hold]
* nd/narrow (Sun Nov 30 17:54:38 2008 +0700) 17 commits
- wt-status: show sparse checkout info
- Introduce default sparse patterns (core.defaultsparse)
- checkout: add new options to support sparse checkout
- clone: support sparse checkout with --sparse-checkout option
- unpack_trees(): add support for sparse checkout
- unpack_trees(): keep track of unmerged entries
- Introduce "sparse patterns"
- Merge branch 'master' into nd/narrow
- t2104: touch portability fix
- grep: skip files outside sparse checkout area
- checkout_entry(): CE_NO_CHECKOUT on checked out entries.
- Prevent diff machinery from examining worktree outside sparse
checkout
- ls-files: Add tests for --sparse and friends
- update-index: add --checkout/--no-checkout to update
CE_NO_CHECKOUT bit
- update-index: refactor mark_valid() in preparation for new options
- ls-files: add options to support sparse checkout
- Introduce CE_NO_CHECKOUT bit
Kicked out of 'next' by popular demand (see recent discussion on the
interaction between the checkout area and commands such as "grep").
* jc/clone-symref-2 (Sat Nov 29 23:38:21 2008 -0800) 7 commits
- clone: test the new HEAD detection logic
- Merge commit 'HEAD@{2}' into HEAD
- upload-pack: send the HEAD information
- clone: find the current branch more explicitly
- connect.c::read_extra_info(): find where HEAD points at
- connect.c::read_extra_info(): prepare to receive more than server
capabilities
- get_remote_heads(): refactor code to read "server capabilities"
An attempt to extend the fetch protocol to make the logic to detect where
HEAD on the origin site points to more robust.
* cc/bisect-replace (Mon Nov 24 22:20:30 2008 +0100) 9 commits
- bisect: add "--no-replace" option to bisect without using replace
refs
- rev-list: make it possible to disable replacing using "--no-
bisect-replace"
- bisect: use "--bisect-replace" options when checking merge bases
- merge-base: add "--bisect-replace" option to use fixed up revs
- commit: add "bisect_replace_all" prototype to "commit.h"
- rev-list: add "--bisect-replace" to list revisions with fixed up
history
- Documentation: add "git bisect replace" documentation
- bisect: add test cases for "git bisect replace"
- bisect: add "git bisect replace" subcommand
I think a mechanism like this should be added to replace grafts, but it
should always be enabled for normal revision traversal operation, while
always disabled for object enumeration and transfer operation (iow, fsck,
fetch and push should use the real ancestry information recorded in the
underlying objects, while rev-list, log, etc. should always use the
replaced objects). I have a suspicion that even cat-file could honor it.
* jc/send-pack-tell-me-more (Thu Mar 20 00:44:11 2008 -0700) 1 commit
- "git push": tellme-more protocol extension
This seems to have a deadlock during communication between the peers.
Someone needs to pick up this topic and resolve the deadlock before it can
continue.
* jk/renamelimit (Sat May 3 13:58:42 2008 -0700) 1 commit
- diff: enable "too large a rename" warning when -M/-C is explicitly
asked for
This would be the right thing to do for command line use,
but gitk will be hit due to tcl/tk's limitation, so I am holding
this back for now.
* jc/stripspace (Sun Mar 9 00:30:35 2008 -0800) 6 commits
- git-am --forge: add Signed-off-by: line for the author
- git-am: clean-up Signed-off-by: lines
- stripspace: add --log-clean option to clean up signed-off-by:
lines
- stripspace: use parse_options()
- Add "git am -s" test
- git-am: refactor code to add signed-off-by line for the committer
^ permalink raw reply
* [PATCH v3] builtin-shortlog.c: use string_list_append(), and don't strdup unnecessarily
From: Adeodato Simó @ 2008-12-30 21:01 UTC (permalink / raw)
To: git, gitster; +Cc: Johannes Schindelin, Adeodato Simó
In-Reply-To: <1230668722-26394-1-git-send-email-dato@net.com.org.es>
Make insert_one_record() use string_list_append(), instead of duplicating
its code. Because of this, do not free the "util" member when clearing the
"onelines" string lists: with the new code path it is not initialized to
any value (was being initialized to NULL previously).
Also, avoid unnecessary strdup() calls when inserting names in log->list.
This list always has "strdup_strings" activated, hence strdup'ing namebuf is
unnecessary. This change also removes a latent memory leak in the old code.
NB: The duplicated code mentioned above predated the appearance of
string_list_append().
Signed-off-by: Adeodato Simó <dato@net.com.org.es>
---
Now with the obvious mistake in the log fixed, apologies. (s/cleanup in//)
builtin-shortlog.c | 19 +++----------------
1 files changed, 3 insertions(+), 16 deletions(-)
diff --git a/builtin-shortlog.c b/builtin-shortlog.c
index d03f14f..90e76ae 100644
--- a/builtin-shortlog.c
+++ b/builtin-shortlog.c
@@ -36,7 +36,6 @@ static void insert_one_record(struct shortlog *log,
const char *dot3 = log->common_repo_prefix;
char *buffer, *p;
struct string_list_item *item;
- struct string_list *onelines;
char namebuf[1024];
size_t len;
const char *eol;
@@ -68,12 +67,9 @@ static void insert_one_record(struct shortlog *log,
snprintf(namebuf + len, room, " %.*s", maillen, boemail);
}
- buffer = xstrdup(namebuf);
- item = string_list_insert(buffer, &log->list);
+ item = string_list_insert(namebuf, &log->list);
if (item->util == NULL)
item->util = xcalloc(1, sizeof(struct string_list));
- else
- free(buffer);
/* Skip any leading whitespace, including any blank lines. */
while (*oneline && isspace(*oneline))
@@ -104,16 +100,7 @@ static void insert_one_record(struct shortlog *log,
}
}
- onelines = item->util;
- if (onelines->nr >= onelines->alloc) {
- onelines->alloc = alloc_nr(onelines->nr);
- onelines->items = xrealloc(onelines->items,
- onelines->alloc
- * sizeof(struct string_list_item));
- }
-
- onelines->items[onelines->nr].util = NULL;
- onelines->items[onelines->nr++].string = buffer;
+ string_list_append(buffer, item->util);
}
static void read_from_stdin(struct shortlog *log)
@@ -323,7 +310,7 @@ void shortlog_output(struct shortlog *log)
}
onelines->strdup_strings = 1;
- string_list_clear(onelines, 1);
+ string_list_clear(onelines, 0);
free(onelines);
log->list.items[i].util = NULL;
}
--
1.6.1.307.g07803
^ permalink raw reply related
* What's in git.git (Dec 2008, #04; Mon, 29)
From: Junio C Hamano @ 2008-12-30 21:03 UTC (permalink / raw)
To: git
This is the last installment of "What's in" series of the year 2008.
Enjoy a happy new year break, everybody.
* The 'maint' branch has these fixes since v1.6.1.
Adeodato Simó (2):
git-shortlog.txt: improve documentation about .mailmap files
git-send-email.txt: move --format-patch paragraph to a proper location
Devin Doucette (1):
gitweb: Fix export check in git_get_projects_list
Junio C Hamano (1):
Prepare for v1.6.1.1 maintenance release
René Scharfe (7):
daemon: handle freopen() failure
daemon: cleanup: replace loop with if
daemon: cleanup: factor out xstrdup_tolower()
merge-file: handle freopen() failure
pretty: factor out skip_empty_lines()
pretty: factor out format_subject()
pretty: support multiline subjects with format:
Shawn O. Pearce (1):
describe: Avoid unnecessary warning when using --all
jidanni@jidanni.org (1):
Documentation/diff-options.txt: unify options
* The 'master' branch has these since the last announcement
in addition to the above.
Johannes Schindelin (1):
Force t5302 to use a single thread
Junio C Hamano (2):
Document "git-reset --merge"
Start 1.6.2 cycle
Linus Torvalds (1):
Add 'merge' mode to 'git reset'
Nicolas Pitre (2):
autodetect number of CPUs by default when using threads
pack-objects: don't use too many threads with few objects
Teemu Likonen (2):
Fix the building of user-manual.texi and gitman.texi documents
Fix the building of gitman.info document
^ permalink raw reply
* Re: [PATCH v3] Add a commit.signoff configuration option to always use --signoff in commit
From: Junio C Hamano @ 2008-12-30 21:04 UTC (permalink / raw)
To: Adeodato Simó; +Cc: git
In-Reply-To: <1230549405-10000-1-git-send-email-dato@net.com.org.es>
Adeodato Simó <dato@net.com.org.es> writes:
> diff --git a/builtin-revert.c b/builtin-revert.c
> index d48313c..395c7a5 100644
> --- a/builtin-revert.c
> +++ b/builtin-revert.c
> @@ -429,6 +429,8 @@ static int revert_or_cherry_pick(int argc, const char **argv)
> args[i++] = "-n";
> if (signoff)
> args[i++] = "-s";
> + else
> + args[i++] = "--no-signoff";
> if (!edit) {
> args[i++] = "-F";
> args[i++] = defmsg;
Introduction of --no-commit to "git commit" is absolutely necessary for
interactive users if we were to introduce commit.signoff, but I am not
sure about this change and similar ones given to the other Porcelain
commands that use "git commit". They actually started making me think
that commmit.signoff might be more trouble than it is worth.
It is plausible that your workflow is to have others push to your 'mob'
branch and integrating good bits from there by cherry-picking, sort of
like using the 'mob' branch as if they are e-mailed patches. In such a
setup, if you are so forgetful to type "-s" for your commit that you would
want commit.signoff configuration, you would likely to be equally
forgetful to type "-s" for your cherry-pick, and would want to have some
configuration affect how this part of the code works.
I however moderately doubt if the complexity and flexibility of having
rebase.signoff, revert.signoff, and cherry-pick.signoff as independent
options is worth it. I am inclined to think that is too many knobs to
tweak, and it is far simpler to understand and easier to explain if the
single configuration, commit.signoff, applied to every Porcelain that
creates commits.
If we were to go that route, instead of passing --no-signoff when they
invoke "git commit", these commands need to take their own --no-signoff
option instead, and when neither --signoff nor --no-signoff is given, they
just should just invoke "git commit" and let it use the config (if set).
^ permalink raw reply
* Re: for newbs = little exercise / tutorial / warmup for windows and other non-sophisticated new Git users :-)
From: Zorba @ 2008-12-30 21:27 UTC (permalink / raw)
To: git
In-Reply-To: <gjdmm6$9oj$4@ger.gmane.org>
** REPRODUCING Possible bug
rebooted PC, opened a new git bash, and started from scratch - see console
output below
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
Welcome to Git (version 1.6.0.2-preview20080923)
Run 'git help git' to display the help index.
Run 'git help <command>' to display help for specific commands.
conorr@KINKLADZE /w/GITPLATFORM
$ mkdir swproj
conorr@KINKLADZE /w/GITPLATFORM
$ cd swproj
conorr@KINKLADZE /w/GITPLATFORM/swproj
$ cat > ABC.txt
ABC
conorr@KINKLADZE /w/GITPLATFORM/swproj
$ cat > BC.txt
BC
conorr@KINKLADZE /w/GITPLATFORM/swproj
$ cat > AC.txt
AC
conorr@KINKLADZE /w/GITPLATFORM/swproj
$ cat > C.txt
C
conorr@KINKLADZE /w/GITPLATFORM/swproj
$ ls
ABC.txt AC.txt BC.txt C.txt
conorr@KINKLADZE /w/GITPLATFORM/swproj
$ git init
Initialized empty Git repository in w:/GITPLATFORM/swproj/.git/
conorr@KINKLADZE /w/GITPLATFORM/swproj
$ git add *a*.txt
conorr@KINKLADZE /w/GITPLATFORM/swproj
$ git commit -m "version A"
Created initial commit 2b88490: version A
2 files changed, 2 insertions(+), 0 deletions(-)
create mode 100644 ABC.txt
create mode 100644 AC.txt
conorr@KINKLADZE /w/GITPLATFORM/swproj
$ git tag versionA 2b88
conorr@KINKLADZE /w/GITPLATFORM/swproj
$ git rm AC.txt
rm 'AC.txt'
conorr@KINKLADZE /w/GITPLATFORM/swproj
$ git add BC.txt
conorr@KINKLADZE /w/GITPLATFORM/swproj
$ git status
# On branch master
# Changes to be committed:
# (use "git reset HEAD <file>..." to unstage)
#
# deleted: AC.txt
# new file: BC.txt
#
# Untracked files:
# (use "git add <file>..." to include in what will be committed)
#
# C.txt
conorr@KINKLADZE /w/GITPLATFORM/swproj
$ git commit -m "version B"
Created commit c1e1cf8: version B
2 files changed, 1 insertions(+), 1 deletions(-)
delete mode 100644 AC.txt
create mode 100644 BC.txt
conorr@KINKLADZE /w/GITPLATFORM/swproj
$ git tag versionB c1e1
conorr@KINKLADZE /w/GITPLATFORM/swproj
$ git add *c*.txt
conorr@KINKLADZE /w/GITPLATFORM/swproj
$ git commit -m "version C"
Created commit 66c62fd: version C
1 files changed, 1 insertions(+), 0 deletions(-)
create mode 100644 C.txt
conorr@KINKLADZE /w/GITPLATFORM/swproj
$ git tag versionC 66c6
conorr@KINKLADZE /w/GITPLATFORM/swproj
$ rm *.*
conorr@KINKLADZE /w/GITPLATFORM/swproj
$ ls
conorr@KINKLADZE /w/GITPLATFORM/swproj
$ git commit -a -m "version D"
Created commit eee4a13: version D
3 files changed, 0 insertions(+), 3 deletions(-)
delete mode 100644 ABC.txt
delete mode 100644 BC.txt
delete mode 100644 C.txt
conorr@KINKLADZE /w/GITPLATFORM/swproj
$ git tag versionD eee4
conorr@KINKLADZE /w/GITPLATFORM/swproj
$ git status
# On branch master
nothing to commit (working directory clean)
conorr@KINKLADZE /w/GITPLATFORM/swproj
$ git checkout versionA .
conorr@KINKLADZE /w/GITPLATFORM/swproj
$ ls
ABC.txt AC.txt
conorr@KINKLADZE /w/GITPLATFORM/swproj
$ rm *.*
conorr@KINKLADZE /w/GITPLATFORM/swproj
$ git checkout versionB .
conorr@KINKLADZE /w/GITPLATFORM/swproj
$ ls
ABC.txt AC.txt BC.txt
conorr@KINKLADZE /w/GITPLATFORM/swproj
$ rm *.*
conorr@KINKLADZE /w/GITPLATFORM/swproj
$ git checkout versionC .
conorr@KINKLADZE /w/GITPLATFORM/swproj
$ ls
ABC.txt AC.txt BC.txt C.txt
conorr@KINKLADZE /w/GITPLATFORM/swproj
$ rm *.*
conorr@KINKLADZE /w/GITPLATFORM/swproj
$ git checkout versionD .
conorr@KINKLADZE /w/GITPLATFORM/swproj
$ ls
ABC.txt AC.txt BC.txt C.txt
conorr@KINKLADZE /w/GITPLATFORM/swproj
$ gitk
conorr@KINKLADZE /w/GITPLATFORM/swproj
$ comment: gitk shows that versionA & C are correct, but B & D are wrong
^ 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