* Re: [PATCH v5]
From: Adam Brewster @ 2008-07-06 2:49 UTC (permalink / raw)
To: git; +Cc: Junio C Hamano
In-Reply-To: <7vskunpyqz.fsf@gitster.siamese.dyndns.org>
>
> Yeah, it is simply a bad taste to use helper in builtin-A from builtin-B.
> More library-ish files such as revision.c are better home for utility
> functions to be shared between builtins and commands.
>
> Here is what I queued.
>
Thank you.
> By the way did you compile test your fix before sending?
>
I ran make and test, but I didn't notice the warnings that prompted
the question. I also forgot to re-check it after re-working the
commits to put everything in order.
> -- >8 --
Thank you again for your help and patience in dealing with my multiple
failed attempts to get this right.
Adam
^ permalink raw reply
* [PATCH 0/5] hg-to-git fixes
From: Miklos Vajna @ 2008-07-06 3:15 UTC (permalink / raw)
To: Stelian Pop; +Cc: Junio C Hamano, git
Hi,
I just noticed that hg-to-git was not updated to use dash-less git
commands, which now causes problems on 'next'. If I was at it, I fixed a
few minor issues I noticed as well.
Miklos Vajna (5):
hg-to-git: avoid raising a string exception
hg-to-git: abort if the project directory is not a hg repo
hg-to-git: rewrite "git-frotz" to "git frotz"
hg-to-git: use git init instead of git init-db
hg-to-git: use git rev-parse instead of git show
contrib/hg-to-git/hg-to-git.py | 27 +++++++++++++++------------
1 files changed, 15 insertions(+), 12 deletions(-)
^ permalink raw reply
* [PATCH 2/5] hg-to-git: abort if the project directory is not a hg repo
From: Miklos Vajna @ 2008-07-06 3:15 UTC (permalink / raw)
To: Stelian Pop; +Cc: Junio C Hamano, git
In-Reply-To: <cover.1215313871.git.vmiklos@frugalware.org>
Check the exit code of the first hg command, and abort to avoid a later
ValueError exception.
Signed-off-by: Miklos Vajna <vmiklos@frugalware.org>
---
contrib/hg-to-git/hg-to-git.py | 5 ++++-
1 files changed, 4 insertions(+), 1 deletions(-)
diff --git a/contrib/hg-to-git/hg-to-git.py b/contrib/hg-to-git/hg-to-git.py
index 25d9941..130b1c4 100755
--- a/contrib/hg-to-git/hg-to-git.py
+++ b/contrib/hg-to-git/hg-to-git.py
@@ -106,7 +106,10 @@ if state:
else:
print 'State does not exist, first run'
-tip = os.popen('hg tip --template "{rev}"').read()
+sock = os.popen('hg tip --template "{rev}"')
+tip = sock.read()
+if sock.close():
+ sys.exit(1)
if verbose:
print 'tip is', tip
--
1.5.6.1.322.ge904b.dirty
^ permalink raw reply related
* [PATCH 1/5] hg-to-git: avoid raising a string exception
From: Miklos Vajna @ 2008-07-06 3:15 UTC (permalink / raw)
To: Stelian Pop; +Cc: Junio C Hamano, git
In-Reply-To: <cover.1215313871.git.vmiklos@frugalware.org>
This fixes the following warning:
hg-to-git.py:92: DeprecationWarning: raising a string exception is deprecated
Signed-off-by: Miklos Vajna <vmiklos@frugalware.org>
---
contrib/hg-to-git/hg-to-git.py | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/contrib/hg-to-git/hg-to-git.py b/contrib/hg-to-git/hg-to-git.py
index f68ef72..25d9941 100755
--- a/contrib/hg-to-git/hg-to-git.py
+++ b/contrib/hg-to-git/hg-to-git.py
@@ -89,7 +89,7 @@ try:
if o in ('-v', '--verbose'):
verbose = True
if len(args) != 1:
- raise('params')
+ raise Exception('params')
except:
usage()
sys.exit(1)
--
1.5.6.1.322.ge904b.dirty
^ permalink raw reply related
* [PATCH 3/5] hg-to-git: rewrite "git-frotz" to "git frotz"
From: Miklos Vajna @ 2008-07-06 3:15 UTC (permalink / raw)
To: Stelian Pop; +Cc: Junio C Hamano, git
In-Reply-To: <cover.1215313871.git.vmiklos@frugalware.org>
This is not just nice but necessary since git-frotz is no longer in
PATH.
Signed-off-by: Miklos Vajna <vmiklos@frugalware.org>
---
contrib/hg-to-git/hg-to-git.py | 20 ++++++++++----------
1 files changed, 10 insertions(+), 10 deletions(-)
diff --git a/contrib/hg-to-git/hg-to-git.py b/contrib/hg-to-git/hg-to-git.py
index 130b1c4..61540ef 100755
--- a/contrib/hg-to-git/hg-to-git.py
+++ b/contrib/hg-to-git/hg-to-git.py
@@ -152,7 +152,7 @@ for cset in range(1, int(tip) + 1):
if not hgvers.has_key("0"):
print 'creating repository'
- os.system('git-init-db')
+ os.system('git init-db')
# loop through every hg changeset
for cset in range(int(tip) + 1):
@@ -194,10 +194,10 @@ for cset in range(int(tip) + 1):
if cset != 0:
if hgbranch[str(cset)] == "branch-" + str(cset):
print 'creating new branch', hgbranch[str(cset)]
- os.system('git-checkout -b %s %s' % (hgbranch[str(cset)], hgvers[parent]))
+ os.system('git checkout -b %s %s' % (hgbranch[str(cset)], hgvers[parent]))
else:
print 'checking out branch', hgbranch[str(cset)]
- os.system('git-checkout %s' % hgbranch[str(cset)])
+ os.system('git checkout %s' % hgbranch[str(cset)])
# merge
if mparent:
@@ -206,7 +206,7 @@ for cset in range(int(tip) + 1):
else:
otherbranch = hgbranch[parent]
print 'merging', otherbranch, 'into', hgbranch[str(cset)]
- os.system(getgitenv(user, date) + 'git-merge --no-commit -s ours "" %s %s' % (hgbranch[str(cset)], otherbranch))
+ os.system(getgitenv(user, date) + 'git merge --no-commit -s ours "" %s %s' % (hgbranch[str(cset)], otherbranch))
# remove everything except .git and .hg directories
os.system('find . \( -path "./.hg" -o -path "./.git" \) -prune -o ! -name "." -print | xargs rm -rf')
@@ -215,9 +215,9 @@ for cset in range(int(tip) + 1):
os.system('hg update -C %d' % cset)
# add new files
- os.system('git-ls-files -x .hg --others | git-update-index --add --stdin')
+ os.system('git ls-files -x .hg --others | git update-index --add --stdin')
# delete removed files
- os.system('git-ls-files -x .hg --deleted | git-update-index --remove --stdin')
+ os.system('git ls-files -x .hg --deleted | git update-index --remove --stdin')
# commit
os.system(getgitenv(user, date) + 'git commit --allow-empty -a -F %s' % filecomment)
@@ -225,20 +225,20 @@ for cset in range(int(tip) + 1):
# tag
if tag and tag != 'tip':
- os.system(getgitenv(user, date) + 'git-tag %s' % tag)
+ os.system(getgitenv(user, date) + 'git tag %s' % tag)
# delete branch if not used anymore...
if mparent and len(hgchildren[str(cset)]):
print "Deleting unused branch:", otherbranch
- os.system('git-branch -d %s' % otherbranch)
+ os.system('git branch -d %s' % otherbranch)
# retrieve and record the version
- vvv = os.popen('git-show --quiet --pretty=format:%H').read()
+ vvv = os.popen('git show --quiet --pretty=format:%H').read()
print 'record', cset, '->', vvv
hgvers[str(cset)] = vvv
if hgnewcsets >= opt_nrepack and opt_nrepack != -1:
- os.system('git-repack -a -d')
+ os.system('git repack -a -d')
# write the state for incrementals
if state:
--
1.5.6.1.322.ge904b.dirty
^ permalink raw reply related
* [PATCH 5/5] hg-to-git: use git rev-parse instead of git show
From: Miklos Vajna @ 2008-07-06 3:15 UTC (permalink / raw)
To: Stelian Pop; +Cc: Junio C Hamano, git
In-Reply-To: <cover.1215313871.git.vmiklos@frugalware.org>
'show' is a high-level command, scripts are better if they use
'rev-parse'.
Signed-off-by: Miklos Vajna <vmiklos@frugalware.org>
---
contrib/hg-to-git/hg-to-git.py | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/contrib/hg-to-git/hg-to-git.py b/contrib/hg-to-git/hg-to-git.py
index 7b03204..0ecb38b 100755
--- a/contrib/hg-to-git/hg-to-git.py
+++ b/contrib/hg-to-git/hg-to-git.py
@@ -233,7 +233,7 @@ for cset in range(int(tip) + 1):
os.system('git branch -d %s' % otherbranch)
# retrieve and record the version
- vvv = os.popen('git show --quiet --pretty=format:%H').read()
+ vvv = os.popen('git rev-parse HEAD').read()
print 'record', cset, '->', vvv
hgvers[str(cset)] = vvv
--
1.5.6.1.322.ge904b.dirty
^ permalink raw reply related
* [PATCH 4/5] hg-to-git: use git init instead of git init-db
From: Miklos Vajna @ 2008-07-06 3:15 UTC (permalink / raw)
To: Stelian Pop; +Cc: Junio C Hamano, git
In-Reply-To: <cover.1215313871.git.vmiklos@frugalware.org>
Signed-off-by: Miklos Vajna <vmiklos@frugalware.org>
---
contrib/hg-to-git/hg-to-git.py | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/contrib/hg-to-git/hg-to-git.py b/contrib/hg-to-git/hg-to-git.py
index 61540ef..7b03204 100755
--- a/contrib/hg-to-git/hg-to-git.py
+++ b/contrib/hg-to-git/hg-to-git.py
@@ -152,7 +152,7 @@ for cset in range(1, int(tip) + 1):
if not hgvers.has_key("0"):
print 'creating repository'
- os.system('git init-db')
+ os.system('git init')
# loop through every hg changeset
for cset in range(int(tip) + 1):
--
1.5.6.1.322.ge904b.dirty
^ permalink raw reply related
* Re: [PATCH 0/5] git_config_string janitorial conversions.
From: Christian Couder @ 2008-07-06 3:47 UTC (permalink / raw)
To: Brian Hetro; +Cc: git, gitster
In-Reply-To: <cover.1215234749.git.whee@smaertness.net>
Le samedi 5 juillet 2008, Brian Hetro a écrit :
> These patches are related to the git_config_string "janitorial" work.
Your patches look good to me.
By the way, your first patch in the series seems to fix a bug:
> int git_commit_config(const char *k, const char *v, void *cb)
> {
> - if (!strcmp(k, "commit.template")) {
> - if (!v)
> - return config_error_nonbool(v);
It should have been:
- return config_error_nonbool(k);
> - template_file = xstrdup(v);
> - return 0;
> - }
> + if (!strcmp(k, "commit.template"))
> + return git_config_string(&template_file, k, v);
There is the same bug in "wt-status.c". I will send a fix for this one.
So (for the patch series):
Tested-by: Christian Couder <chriscool@tuxfamily.org>
Thanks,
Christian.
^ permalink raw reply
* [PATCH] Fix "config_error_nonbool" used with value instead of key
From: Christian Couder @ 2008-07-06 4:10 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Brian Hetro, git
The function "config_error_nonbool", that is defined in "config.c",
is used to report an error when a config key in the config file
should have a corresponding value but it hasn't.
So the parameter to this function should be the key and not the
value, because the value is undefined. And it could crash if the
value is used.
This patches fixes two occurences where the value was passed
instead of the key.
Signed-off-by: Christian Couder <chriscool@tuxfamily.org>
---
builtin-tag.c | 2 +-
wt-status.c | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/builtin-tag.c b/builtin-tag.c
index e675206..3c97c69 100644
--- a/builtin-tag.c
+++ b/builtin-tag.c
@@ -260,7 +260,7 @@ static int git_tag_config(const char *var, const char *value, void *cb)
{
if (!strcmp(var, "user.signingkey")) {
if (!value)
- return config_error_nonbool(value);
+ return config_error_nonbool(var);
set_signingkey(value);
return 0;
}
diff --git a/wt-status.c b/wt-status.c
index 28c9e63..e7d42d0 100644
--- a/wt-status.c
+++ b/wt-status.c
@@ -399,7 +399,7 @@ int git_status_config(const char *k, const char *v, void *cb)
}
if (!strcmp(k, "status.showuntrackedfiles")) {
if (!v)
- return config_error_nonbool(v);
+ return config_error_nonbool(k);
else if (!strcmp(v, "no"))
show_untracked_files = SHOW_NO_UNTRACKED_FILES;
else if (!strcmp(v, "normal"))
--
1.5.6.1.205.gc094f
^ permalink raw reply related
* [PATCH] INSTALL: Update section about git-frotz form.
From: Miklos Vajna @ 2008-07-06 4:28 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
The old text stated that 'git-frotz' can be always used instead of 'git
frotz' which is no longer true.
Signed-off-by: Miklos Vajna <vmiklos@frugalware.org>
---
INSTALL | 18 ++++++------------
1 files changed, 6 insertions(+), 12 deletions(-)
diff --git a/INSTALL b/INSTALL
index 4a4e13f..0efb4b7 100644
--- a/INSTALL
+++ b/INSTALL
@@ -27,20 +27,14 @@ Issues of note:
- git normally installs a helper script wrapper called "git", which
conflicts with a similarly named "GNU interactive tools" program.
- Tough. Either don't use the wrapper script, or delete the old GNU
- interactive tools. None of the core git stuff needs the wrapper,
- it's just a convenient shorthand and while it is documented in some
- places, you can always replace "git commit" with "git-commit"
- instead.
-
- But let's face it, most of us don't have GNU interactive tools, and
- even if we had it, we wouldn't know what it does. I don't think it
- has been actively developed since 1997, and people have moved over to
+ Let's face it, most of us don't have GNU interactive tools, and even
+ if we had it, we wouldn't know what it does. I don't think it has
+ been actively developed since 1997, and people have moved over to
graphical file managers.
- NOTE: As of gnuit-4.9.2, the GNU interactive tools package has been
- renamed. You can compile gnuit with the --disable-transition
- option and then it will not conflict with git.
+ In addition, as of gnuit-4.9.2, the GNU interactive tools package has
+ been renamed. You can compile gnuit with the --disable-transition
+ option and then it will not conflict with git.
- You can use git after building but without installing if you
wanted to. Various git commands need to find other git
--
1.5.6.1.322.ge904b.dirty
^ permalink raw reply related
* Re: finding deleted file names
From: Geoff Russell @ 2008-07-06 4:54 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Jeff King, Mikael Magnusson, git
In-Reply-To: <7v1w2aw2lt.fsf@gitster.siamese.dyndns.org>
On 7/4/08, Junio C Hamano <gitster@pobox.com> wrote:
> "Geoff Russell" <geoffrey.russell@gmail.com> writes:
>
> > ... I've made a bunch of changes to a repository, a few weeks later I
>
> > figure I've deleted a file I need but am not really sure of its name. So
> > I want to list the files that I've deleted during the past few weeks.
>
>
> $ git log --pretty=oneline --diff-filter=D --name-only -M --since=90.days
This is good, but on my version 1.5.5.1, is giving the commit-ids +
comments as well
as the names.
e.g.,
58d331dc02da635a60be5911dd98510f350718ad deleted: 999
modified: frepas.tex
LEAFLETS/999
1b7e44fb572297bd5a6f240864dcec292fa158b0 after caption added
LEAFLETS/xxx.tex
Cheers,
Geoff
>
>
--
6 Fifth Ave,
St Morris, S.A. 5068
Australia
Ph: 041 8805 184 / 08 8332 5069
^ permalink raw reply
* Re: About -X<option>
From: Junio C Hamano @ 2008-07-06 4:57 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Pieter de Bie, Miklos Vajna, git
In-Reply-To: <alpine.DEB.1.00.0807060342550.3557@eeepc-johanness>
Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> Isn't that obvious? -X looks like a short option, but the rest of that
> string does not consist of aggregated short options.
Ah, I see. Then the issue is not about "not easy to code" but about "not
being consistent". We should care much more deeply about the latter.
We can change it to "--X<option>[=<value>]" and "-X option[=<value>]"; the
topic is still young, not even documented properly IIRC, and is not
scheduled for 'master' any time soon yet.
^ permalink raw reply
* Re: finding deleted file names
From: Junio C Hamano @ 2008-07-06 5:17 UTC (permalink / raw)
To: geoffrey.russell; +Cc: Junio C Hamano, Jeff King, Mikael Magnusson, git
In-Reply-To: <93c3eada0807052154j9de9074s8c5625fb7507b96e@mail.gmail.com>
"Geoff Russell" <geoffrey.russell@gmail.com> writes:
> On 7/4/08, Junio C Hamano <gitster@pobox.com> wrote:
>> "Geoff Russell" <geoffrey.russell@gmail.com> writes:
>>
>> > ... I've made a bunch of changes to a repository, a few weeks later I
>>
>> > figure I've deleted a file I need but am not really sure of its name. So
>> > I want to list the files that I've deleted during the past few weeks.
>>
>>
>> $ git log --pretty=oneline --diff-filter=D --name-only -M --since=90.days
>
> This is good, but on my version 1.5.5.1, is giving the commit-ids +
> comments as well
> as the names.
Oh, I very much intended to give them, as --since=90.days is very broad
that you would want to know which exact commit to learn when the found
change was made anyway.
^ permalink raw reply
* [ANNOUNCE] GIT 1.5.6.2
From: Junio C Hamano @ 2008-07-06 5:34 UTC (permalink / raw)
To: git; +Cc: linux-kernel
The latest maintenance release GIT 1.5.6.2 are available at the usual
places:
http://www.kernel.org/pub/software/scm/git/
git-1.5.6.2.tar.{gz,bz2} (source tarball)
git-htmldocs-1.5.6.2.tar.{gz,bz2} (preformatted docs)
git-manpages-1.5.6.2.tar.{gz,bz2} (preformatted docs)
The RPM binary packages for a few architectures are also provided as
courtesy. As the machine I cut them at kernel.org has been updated to FC9
recently, their filenames now have .fc9. in them.
RPMS/$arch/git-*-1.5.6.2-1.fc9.$arch.rpm (RPM)
There still are a handful more fixes queued for 'maint' so we might see
another maintenance release, 1.5.6.3, not too far in the future.
----------------------------------------------------------------
Changes since v1.5.6.1 are as follows:
Avery Pennarun (1):
git-svn: avoid filling up the disk with temp files.
Björn Steinbrink (1):
git cat-file: Fix memory leak in batch mode
Eric Wong (1):
git-svn: don't sanitize remote names in config
Jeff King (3):
fetch: report local storage errors in status table
doc/rev-parse: clarify reflog vs --until for specifying revisions
fetch: give a hint to the user when local refs fail to update
Jochen Voss (1):
avoid off-by-one error in run_upload_archive
Joey Hess (1):
fix git config example syntax
Johannes Schindelin (2):
clone: respect url.insteadOf setting in global configs
clone: respect the settings in $HOME/.gitconfig and /etc/gitconfig
Junio C Hamano (9):
Allow "git-reset path" when unambiguous
diff --check: do not discard error status upon seeing a good line
git-shell: accept "git foo" form
GIT 1.5.4.6
GIT 1.5.5.5
Start draft release notes for 1.5.6.2
Work around gcc warnings from curl headers
Fix executable bits in t/ scripts
GIT 1.5.6.2
Shawn O. Pearce (1):
Fix describe --tags --long so it does not segfault
Thomas Rast (1):
Fix 'git show' on signed tag of signed tag of commit
^ permalink raw reply
* Re: [PATCH] git daemon: avoid calling syslog() from a signal handler
From: Junio C Hamano @ 2008-07-06 6:08 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Brian Foster, git
In-Reply-To: <alpine.DEB.1.00.0807060337480.3557@eeepc-johanness>
Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
>> The question was not about the millisecond typo, but about why time-out
>> at all.
>
> Because I do not want to change the semantics!
>
> ATM, in those cases where it works (as opposed to hanging!), git-daemon
> --verbose reports in the syslog when a client disconnected, possibly with
> an error. It does so with a timestamp so that you can see how long the
> connection lasted. That is what logs are useful for.
>
> Now, syslog has timestamps at second-resolution (at least here it does),
> and I wanted to imitate that.
Yes, we do not want to change the semantics, but that is not a reason for
an unused daemon to wake up every second, isn't it?
> The alternative would be to deprive all users of an (mostly) accurate
> timestamp of the disconnect time.
>
>> Another way would be to set up a pipe to ourself that is included in the
>> poll() and write a byte to the pipe from the signal handler.
>
> It still would need to break out of the poll(), in which case the effect
> would be _exactly_ the same,...
I do not think so.
In the solution I suggested, you would set up a pipe to yourself, and give
the read end of the pipe and the accepting socket to poll() with infinite
timeout. And when you do reap in the signal handler, you write a byte to
the write end of the pipe (and that would be the only codepath that would
write to that pipe). That would make the pipe you are polling redable,
and allow you to break out of poll(). When poll() returns thusly, you
notice you are in that condition and read out that byte to keep the pipe
clean, and do the check_dead_children() thing.
That way, you would wake up only when you actually have something useful
to do. Otherwise you will stay dormant, waiting for something to happen,
either by socket becoming ready to accept, or child dying and raising
SIGCHLD.
I agree that it is a bit too elaborate change that we do not want to have
in 'maint'.
Even then, for 'maint', we probably would at least want something like
this on top of your patch, so that when we know we have absolutely nothing
to do, we do not have to spin.
daemon.c | 4 +++-
1 files changed, 3 insertions(+), 1 deletions(-)
diff --git a/daemon.c b/daemon.c
index 6dc96aa..ce3a6f5 100644
--- a/daemon.c
+++ b/daemon.c
@@ -944,6 +944,7 @@ static int service_loop(int socknum, int *socklist)
for (;;) {
int i;
+ int timeout;
/*
* This 1-sec timeout could lead to idly looping but it is
@@ -952,7 +953,8 @@ static int service_loop(int socknum, int *socklist)
* to ourselves that we poll, and write to the fd from child_handler()
* to wake us up (and consume it when the poll() returns...
*/
- i = poll(pfd, socknum, 1000);
+ timeout = (children_spawned != children_deleted) ? 1000 : -1;
+ i = poll(pfd, socknum, timeout);
if (i < 0) {
if (errno != EINTR) {
error("poll failed, resuming: %s",
^ permalink raw reply related
* Re: [PATCH] better git-submodule status output
From: Junio C Hamano @ 2008-07-06 6:19 UTC (permalink / raw)
To: Lars Hjemli, Ping Yin, Mark Levedahl; +Cc: git, Sylvain Joyeux
In-Reply-To: <20080701150119.GE5852@joyeux>
Sylvain Joyeux <sylvain.joyeux@dfki.de> writes:
> This patch makes the output of git-submodule more useful to handle the
> management of a repository using multiple submodules. Namely, it
> displays informations about how the current checked out version relates
> to the registered one (i.e. direct parent, direct child, "just
> different", registered revision does not exist), and displays if the
> submodules contain uncommitted changes.
>
> This (among other things) allows to do git-submodule update while
> knowing exactly what will happen.
> --
> Sylvain
>
>>From 16553a9b210a956b0af961d55a9cf06f1b9b8114 Mon Sep 17 00:00:00 2001
> From: Sylvain Joyeux <sylvain.joyeux@dfki.de>
> Date: Tue, 1 Jul 2008 16:01:01 +0200
> Subject: [PATCH] more information in git-submodule status output
>
> This commit adds more information in the 'status' output of
> git-submodule. More specifically, it displays different flags if the
> submodule and the registered revision are direct parents (> and <,
> depending on which is the ancestor), if they are not direct parents (+)
> or if the registered revision cannot be found (i.e. if submodule update
> would fail, '!')
>
> Finally, it shows if the submodule contains uncommitted changes (M flag)
Which one is the commit message ;-)?
People who rely on working submodule support, do you have any feedback on
this patch? I do not use submodule myself, so it is hard for me to judge
how much value (if any) this patch is adding to the real world use of the
status subcommand.
> @@ -97,7 +110,7 @@ for details.
>
> AUTHOR
> ------
> -Written by Lars Hjemli <hjemli@gmail.com>
> +Written by Lars Hjemli <hjemli@gmail.com> and Sylvain Joyeux <sylvain.joyeux@m4x.org>
That is somehow inconsistent with what
git-shortlog -s -n -e --no-merges git-submodule.sh
tells me.
Honestly, I'd prefer (1) drop these "AUTHOR" lines, or (2) only list the
primary author or two.
> diff --git a/git-submodule.sh b/git-submodule.sh
> index 3eb78cc..e2b91f6 100755
> --- a/git-submodule.sh
> +++ b/git-submodule.sh
> @@ -562,20 +566,40 @@ cmd_status()
> ...
> if git diff-files --quiet -- "$path"
> then
> - say " $sha1 $path$revname"
> + say " $unclean $sha1 $path$revname"
> else
> + head=$(unset GIT_DIR; cd "$path" && git rev-parse --verify HEAD)
> + common=$(unset GIT_DIR; cd "$path" && git merge-base HEAD $sha1)
> + if test -z "$common"; then
> + common=$(unset GIT_DIR; cd "$path" && git-fetch -q &&
> + git merge-base HEAD $sha1)
> + fi
This "fetch" feels very wrong. The user did not ask you to change the
state of the repository, but this will silently change the remote tracking
branches. The repository after all might be unreachable.
^ permalink raw reply
* Re: [PATCH] fix "git-submodule add a/b/c/repository"
From: Junio C Hamano @ 2008-07-06 6:27 UTC (permalink / raw)
To: Sylvain Joyeux; +Cc: Lars Hjemli, Ping Yin, Mark Levedahl, git
In-Reply-To: <20080701150025.GD5852@joyeux>
Sylvain Joyeux <sylvain.joyeux@dfki.de> writes:
> The 'master' version of git-submodule.sh fails to see that
> a/b/c/repository is an already existing repository and messes up the
> whole thing. The following patch fixes that.
> --
> Sylvain
>
>>From 2bca2e17a01cd81ce30f81750583ab943ab57ff0 Mon Sep 17 00:00:00 2001
> From: Sylvain Joyeux <sylvain.joyeux@dfki.de>
> Date: Tue, 1 Jul 2008 16:45:04 +0200
> Subject: [PATCH] fix submodule add for non-toplevel in-project directories
>
> This patch fixes git-submodule add for submodules that
> already exist in the current package tree, in a folder
> which is not at toplevel, i.e.:
>
> git submodule add a/b/c/repository
Which one is the commit log message ;-)?
Perhaps Documentation/SubmittingPatches needs a review?
> +test_expect_success 'adding an already-existing repository deep in the directory hierarchy' '
> +
> + mkdir dir0 &&
> + mkdir dir0/dir1 &&
> + git clone init dir0/dir1/init &&
> + git-submodule add dir0/dir1/init &&
> + git-submodule status | grep "dir0/dir1/init"
> +'
I am not sure if this is fixing a sane use case. "submodule add" is
documented to take:
'git submodule' [--quiet] add [-b branch] [--] <repository> [<path>]
and you are adding at dir0/dir1/init a submodule that will interact with "init"
repository, so shouldn't that command line be something like:
git submodule add init dir0/dir1/init
???
Confused..
^ permalink raw reply
* Re: [ANNOUNCE] GIT 1.5.6.2
From: Jakub Narebski @ 2008-07-06 8:09 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vy74fo9t4.fsf@gitster.siamese.dyndns.org>
Junio C Hamano <gitster@pobox.com> writes:
> The RPM binary packages for a few architectures are also provided as
> courtesy. As the machine I cut them at kernel.org has been updated to FC9
> recently, their filenames now have .fc9. in them.
>
> RPMS/$arch/git-*-1.5.6.2-1.fc9.$arch.rpm (RPM)
This unfortunately includes also SRPMS (.src.rpm), even though the
source RPM from git repository is not distribution specific. I think
that src.rpm should drop '.fc9.' from name
--
Jakub Narebski
Poland
ShadeHawk on #git
^ permalink raw reply
* Re: [RFC/PATCH] Fix t7601-merge-pull-config.sh on AIX
From: Brian Gernhardt @ 2008-07-06 8:15 UTC (permalink / raw)
To: Miklos Vajna
Cc: Junio C Hamano, Johannes Schindelin, Olivier Marin, git,
Mike Ralphson
In-Reply-To: <1215267838-19402-1-git-send-email-vmiklos@frugalware.org>
On Jul 5, 2008, at 10:23 AM, Miklos Vajna wrote:
> The test failed on AIX (and likely other OS, such as apparently OSX)
> where wc -l outputs whitespace.
ACK. This test does break on OS X and this patch fixes it.
Took me a while to realize why it was saying "8: command not found".
Apparently "resolve_count= 8" means something very different than
"resolve_count=8". Then I remembered seeing a patch recently that hit
conflict_count and I didn't have to think about how to fix it.
Thanks,
~~ Brian
^ permalink raw reply
* Commit message for 1240f94 has mail headers
From: Brian Gernhardt @ 2008-07-06 8:00 UTC (permalink / raw)
To: Git Mailing List
The commit message for 1240f94 (next~2^2~1 in my repo) reads as follows:
----- 8< -----
Add new test case to ensure git-merge prepends the custom merge
message
7b9b8a456462c83.1214581610.git.vmiklos@frugalware.org>
In-Reply-To: <cover.1214581610.git.vmiklos@frugalware.org>
References: <cover.1214581610.git.vmiklos@frugalware.org>
X-Pobox-Pass: vmiklos@frugalware.org is whitelisted
X-ICG-Account-ID: 77302942
Xref: gitster.siamese.dyndns.org git-review:1871
Lines: 55
There was no test for this before, so the testsuite passed, even
in case
the merge summary was missing from the merge commit message.
Signed-off-by: Miklos Vajna <vmiklos@frugalware.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
----- 8< -----
I don't think all those mail headers are supposed to be in there. I
don't know if it's too late to fix that, but I thought you should know.
~~ Brian
^ permalink raw reply
* [PATCH v2] Make rebase save ORIG_HEAD if changing current branch
From: Brian Gernhardt @ 2008-07-06 8:40 UTC (permalink / raw)
To: Git List; +Cc: Junio C Hamano
This makes rebase act a little more like merge when working on the
current branch. This is particularly useful for `git pull --rebase`
Signed-off-by: Brian Gernhardt <benji@silverinsanity.com>
---
If I followed the discussion the last time I sent this in correctly,
the two issues were:
- Ugly "echo > ORIG_HEAD" instead of pretty "git update-ref ORIG_HEAD"
- Setting ORIG_HEAD at the wrong place
Let me know if there are any other issues.
git-rebase.sh | 1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/git-rebase.sh b/git-rebase.sh
index e2d85ee..44db7e6 100755
--- a/git-rebase.sh
+++ b/git-rebase.sh
@@ -434,3 +434,4 @@ do
done
finish_rb_merge
+git update-ref ORIG_HEAD $orig_head
--
1.5.6.1.324.gc55f7
^ permalink raw reply related
* Re: [PATCH 14/14] Build in merge
From: Junio C Hamano @ 2008-07-06 8:50 UTC (permalink / raw)
To: Miklos Vajna; +Cc: git, Johannes Schindelin, Olivier Marin
In-Reply-To: <0cde1e7c930589364318b2d0344b345453e23586.1214918017.git.vmiklos@frugalware.org>
Miklos Vajna <vmiklos@frugalware.org> writes:
> diff --git a/builtin-merge.c b/builtin-merge.c
> new file mode 100644
> index 0000000..b261993
> --- /dev/null
> +++ b/builtin-merge.c
> @@ -0,0 +1,1158 @@
> +/*
> + * Builtin "git merge"
> + *
> + * Copyright (c) 2008 Miklos Vajna <vmiklos@frugalware.org>
> + *
> + * Based on git-merge.sh by Junio C Hamano.
> + */
> +
> +#include "cache.h"
> +#include "parse-options.h"
> +#include "builtin.h"
> +#include "run-command.h"
> +#include "path-list.h"
> +#include "diff.h"
> +#include "refs.h"
> +#include "commit.h"
> +#include "diffcore.h"
> +#include "revision.h"
> +#include "unpack-trees.h"
> +#include "cache-tree.h"
> +#include "dir.h"
> +#include "utf8.h"
> +#include "log-tree.h"
> +#include "color.h"
> +
> +enum strategy {
> + DEFAULT_TWOHEAD = 1,
> + DEFAULT_OCTOPUS = 2,
> + NO_FAST_FORWARD = 4,
> + NO_TRIVIAL = 8
> +};
Usually "enum foo" consists of possible values of "foo". But this is
not a list of strategies. These are possible attributes to strategies.
> +static const char * const builtin_merge_usage[] = {
> + "git-merge [options] <remote>...",
> + "git-merge [options] <msg> HEAD <remote>",
> + NULL
> +};
> +
> +static int show_diffstat = 1, option_log, squash;
> +static int option_commit = 1, allow_fast_forward = 1;
> +static int allow_trivial = 1, have_message;
> +static struct strbuf merge_msg;
> +static struct commit_list *remoteheads;
> +static unsigned char head[20], stash[20];
> +static struct path_list use_strategies;
> +static const char *branch;
> +
> +static struct path_list_item strategy_items[] = {
> + { "recur", (void *)NO_TRIVIAL },
> + { "recursive", (void *)(DEFAULT_TWOHEAD | NO_TRIVIAL) },
> + { "octopus", (void *)DEFAULT_OCTOPUS },
> + { "resolve", (void *)0 },
> + { "stupid", (void *)0 },
> + { "ours", (void *)(NO_FAST_FORWARD | NO_TRIVIAL) },
> + { "subtree", (void *)(NO_FAST_FORWARD | NO_TRIVIAL) },
> +};
> +static struct path_list strategies = { strategy_items,
> + ARRAY_SIZE(strategy_items), 0, 0 };
This declaration is funnily line-wrapped.
static struct path_list strategies = {
strategy_items, ARRAY_SIZE(strategy_items), 0, 0,
};
But more problematic is that a path_list is inherently a dynamic data
structure (you can add and it reallocs), and this use of relying on the
knowledge that you happen to never add anything (nor subtract anything)
from the list is a mere hack. If on the other hand you (and more
importantly other people who touch this implementation later) will never
add or remove items from this "strategies" array, you should make sure at
the interface level that nobody can -- one way to do so is not to abuse
path_list for something like this.
Come to think of it, wasn't the reason why the earlier "Why do you need
such distracting casts all over the place?" issue came up in another patch
because of this kind of (ab)use of path_list, which is an inappropriate
data structure for the job?
You would perhaps define:
#define DEFAULT_TWOHEAD (1<<0)
#define DEFAULT_OCTOPUS (1<<1)
#define NO_FAST_FORWARD (1<<2)
#define NO_TRIVIAL (1<<3)
static struct strategy {
char *name;
unsigned attr;
} all_strategy[] = {
{ "octopus", DEFAULT_OCTOPUS },
{ "ours", (NO_FAST_FORWARD | NO_TRIVIAL) },
{ "recur", NO_TRIVIAL },
{ "recursive", (DEFAULT_TWOHEAD | NO_TRIVIAL) },
{ "resolve", 0 },
{ "stupid", 0 },
{ "subtree", (NO_FAST_FORWARD | NO_TRIVIAL) },
};
And "unsorted_path_list_lookup()" can now become much more natural,
perhaps:
static struct strategy *get_strategy(const char *name);
which has a more natural function signature and much better name.
Then, you would keep an array of pointers into all_strategy[] array to
represent the list of "-s strategy" given by the user:
static struct strategy *use_strategy;
static int use_strategy_alloc, use_strategy_nr;
and have a function that use s the standard ALLOC_GROW() and friends to
grow this. The function will be named and written more naturally
(i.e. path_list_append_strategy() can go) --- this does not have anything
to do with path_list, but it is about "merge strategy".
But 99.9% of the time you would not have more than one elements ;-).
^ permalink raw reply
* [PATCH] branch -v: Prevent garbage output on remote refs
From: Brian Gernhardt @ 2008-07-06 9:24 UTC (permalink / raw)
To: Git List; +Cc: Junio C Hamano
The stat string was only initialized if the ref was local, but was
always used in a printf. This meant that whatever data was on the
stack got printed. In the case of "branch -av", this was probably the
tracking information of the last local branch. If the case of "branch
-rv", this was "@???" in my case.
Signed-off-by: Brian Gernhardt <benji@silverinsanity.com>
---
After looking through the second get of changes I pulled, I tried this:
$ git branch -av
* master 3195299 [ahead 1] Make rebase save ORIG_HEAD if changing current branch
origin/HEAD 08b51f5 [ahead 1] Merge branch 'qq/maint'
origin/gitk-for-paulus 7d8856d [ahead 1] gitk: Update German translation.
Huh. That doesn't look right... Let's try just showing the remotes:
$ git branch -rv
origin/HEAD 08b51f5 @???Merge branch 'qq/maint'
origin/gitk-for-paulus 7d8856d @???gitk: Update German translation.
That's definately not good.
I guess that other people either have a compiler that is more careful about
clearing stack variables, or don't use "branch -v".
builtin-branch.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/builtin-branch.c b/builtin-branch.c
index e9423d1..470c59f 100644
--- a/builtin-branch.c
+++ b/builtin-branch.c
@@ -327,7 +327,7 @@ static void print_ref_item(struct ref_item *item, int maxwidth, int verbose,
if (verbose) {
struct strbuf subject;
const char *sub = " **** invalid ref ****";
- char stat[128];
+ char stat[128] = "";
strbuf_init(&subject, 0);
--
1.5.6.2.336.g3195
^ permalink raw reply related
* Re: [ANNOUNCE] GIT 1.5.6.2
From: Junio C Hamano @ 2008-07-06 9:30 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git
In-Reply-To: <m38wwffn3b.fsf@localhost.localdomain>
Jakub Narebski <jnareb@gmail.com> writes:
> Junio C Hamano <gitster@pobox.com> writes:
>
>> The RPM binary packages for a few architectures are also provided as
>> courtesy. As the machine I cut them at kernel.org has been updated to FC9
>> recently, their filenames now have .fc9. in them.
>>
>> RPMS/$arch/git-*-1.5.6.2-1.fc9.$arch.rpm (RPM)
>
> This unfortunately includes also SRPMS (.src.rpm), even though the
> source RPM from git repository is not distribution specific. I think
> that src.rpm should drop '.fc9.' from name
It is whatever rpmbuild command does. Not my problem.
Having said that, I vaguely recall some people from non Fedora nor RH
distros based on RPM were talking about how their .spec file would be
different from the one for FC. Presumably the resulting SRPM would be
also distro specific, wouldn't it?
^ permalink raw reply
* Re: [PATCH 14/14] Build in merge
From: Junio C Hamano @ 2008-07-06 9:43 UTC (permalink / raw)
To: Miklos Vajna; +Cc: git, Johannes Schindelin, Olivier Marin
In-Reply-To: <7vej67jt1e.fsf@gitster.siamese.dyndns.org>
Junio C Hamano <gitster@pobox.com> writes:
> You would perhaps define:
>
> #define DEFAULT_TWOHEAD (1<<0)
> #define DEFAULT_OCTOPUS (1<<1)
> #define NO_FAST_FORWARD (1<<2)
> #define NO_TRIVIAL (1<<3)
>
> static struct strategy {
> char *name;
> unsigned attr;
> } all_strategy[] = {
> { "octopus", DEFAULT_OCTOPUS },
> { "ours", (NO_FAST_FORWARD | NO_TRIVIAL) },
> { "recur", NO_TRIVIAL },
> { "recursive", (DEFAULT_TWOHEAD | NO_TRIVIAL) },
> { "resolve", 0 },
> { "stupid", 0 },
> { "subtree", (NO_FAST_FORWARD | NO_TRIVIAL) },
> };
>
> And "unsorted_path_list_lookup()" can now become much more natural,
> perhaps:
>
> static struct strategy *get_strategy(const char *name);
>
> which has a more natural function signature and much better name.
>
> Then, you would keep an array of pointers into all_strategy[] array to
> represent the list of "-s strategy" given by the user:
>
> static struct strategy *use_strategy;
> static int use_strategy_alloc, use_strategy_nr;
Sorry, I have an obvious typo here. "use_strategy" will be dynamic array
of pointers into all_strategy[] so its definition would be:
static struct strategy **use_strategy;
> and have a function that use s the standard ALLOC_GROW() and friends to
> grow this. The function will be named and written more naturally
> (i.e. path_list_append_strategy() can go) --- this does not have anything
> to do with path_list, but it is about "merge strategy".
^ 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