* Re: [PATCH 2/2] read-tree: at least one tree-ish argument is required
From: Johannes Sixt @ 2009-12-18 9:51 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Git Mailing List
In-Reply-To: <4B274C3A.4060808@viscovery.net>
You have queued 1/2 (filter-branch: remove an unnecessary use of
'git read-tree') of this 2-patch series, but I haven't seen any comments
about this 2/2 nor is it queued. Did it fall through the cracks?
--- 8< ---
From: Johannes Sixt <j6t@kdbg.org>
Date: Tue, 15 Dec 2009 09:21:53 +0100
Subject: [PATCH] read-tree: at least one tree-ish argument is required
Previously, it was possible to run read-tree without any arguments,
whereupon it purged the index!
Signed-off-by: Johannes Sixt <j6t@kdbg.org>
---
builtin-read-tree.c | 3 +++
1 files changed, 3 insertions(+), 0 deletions(-)
diff --git a/builtin-read-tree.c b/builtin-read-tree.c
index 50413ca..31623b9 100644
--- a/builtin-read-tree.c
+++ b/builtin-read-tree.c
@@ -125,6 +125,9 @@ int cmd_read_tree(int argc, const char **argv,
stage = opts.merge = 1;
}
+ if (argc == 0)
+ usage_with_options(read_tree_usage, read_tree_options);
+
for (i = 0; i < argc; i++) {
const char *arg = argv[i];
--
1.6.6.rc3.54.g0f72d
^ permalink raw reply related
* Re: [PATCH] Let format-patch and rebase ignore trivial merges.
From: Bernhard R. Link @ 2009-12-18 13:06 UTC (permalink / raw)
To: git; +Cc: Junio C Hamano
In-Reply-To: <7vaaxhfcfe.fsf@alter.siamese.dyndns.org>
* Junio C Hamano <gitster@pobox.com> [091217 23:44]:
[order of replies changed for the sake of answers]
> On the other hand, a branch that will be rebased to keep up with others is
> by definition private, and I don't see a reason to mark with "-s ours" to
> cauterize history of an unrelated side branch that tried to do something
> similar to what the branch is trying to achieve in that setting. You can
> instead ignore such a side branch and not merge with it. So I don't know
> how a sane history you are going to rebase ends up containing a "-s ours"
> merge to begin with.
Think of a team working to prepare a complicated change that is to be
presented as multiple easily reviewable patches.
If you do something like that alone on a single computer, you will
usually have a branch, collect some commits and merge fixes for previous
commits together with rebase -i. If it takes a longer time you also
rebase to upstream from time to time, fixing all the conflicts and so
on. (You can also just collect and hope to still separate them into
different patches at the end, but that usually gets messy in my
experience).
Those rebases will make you lose some history, which you can work around
by having some extra branches with older states. If you work on
different computers, pulling and pushing the current state of the branch
around needs special care as the non-fast-forward needed all the time
might also easily overwrite and newer with an older state (and keeping
track of the older branches is a big mess unless you have one central
repository).
If there are multiple people working on this, things will not get
easier. In this case having the new clean branch containing a trivial merge
with second parent the old history will both allow easy push and pull
and keep the history so one can look at older states.
(see http://marc.info/?l=git&m=125959221911443&w=2)
A special case for this are modifications in Debian packages. The
patches have to be rebased to every new upstream, while at the same
time should always be in a state so they can be sent upstream and
upstream can pick some of them. (And ideally the debian source package
does include the patches as nice topic separated patch files, so other
distributions/users can easily pick those independent of what vcs they
use).
> A branch that merges with "-s ours" is typically done so that others can
> pull and build against (and "-s ours" is used to cauterize the history of
> a bad side branch), and good bits merged into it would also have come from
> a different clean branch that is merged into that branch. It might make
> more sense to format-patch that clean branch when preparing for upstream
> submission, than the "aggregated mesh of commits" branch with "-s ours"
> fix-ups.
format-patch has to choose a parent. Choosing the first one make the
most sense for me (as the first is the only real 'special' one).
In the workflows I envision the first parent would also be the one with
the clean history.
Hochachtungsvoll,
Bernhard R. Link
--
"Never contain programs so few bugs, as when no debugging tools are available!"
Niklaus Wirth
^ permalink raw reply
* Re: [PATCH] Let format-patch and rebase ignore trivial merges.
From: Johannes Sixt @ 2009-12-18 13:22 UTC (permalink / raw)
To: git; +Cc: Junio C Hamano
In-Reply-To: <20091218130603.GA6193@pcpool00.mathematik.uni-freiburg.de>
Please do not cull Cc list.
Bernhard R. Link schrieb:
> format-patch has to choose a parent. Choosing the first one make the
> most sense for me (as the first is the only real 'special' one).
> In the workflows I envision the first parent would also be the one with
> the clean history.
Then use
git format-patch --first-parent upstream..
-- Hannes
^ permalink raw reply
* Re: [PATCH] Let format-patch and rebase ignore trivial merges.
From: Bernhard R. Link @ 2009-12-18 14:47 UTC (permalink / raw)
To: Johannes Sixt; +Cc: git, Junio C Hamano
In-Reply-To: <4B2B8213.1090104@viscovery.net>
* Johannes Sixt <j.sixt@viscovery.net> [091218 14:22]:
> > format-patch has to choose a parent. Choosing the first one make the
> > most sense for me (as the first is the only real 'special' one).
> > In the workflows I envision the first parent would also be the one with
> > the clean history.
>
> Then use
>
> git format-patch --first-parent upstream..
As already described in the thread my mail contained a link to, this
will miss patches if there were also real merges (which there will).
But the point that there is only a --first-parent and no --last-parent
shows that the first parent is special, so format-patch should choose
the first one.
Hochachtungsvoll,
Bernhard R. Link
--
Please do not CC me if also sending to git@vger.kernel.org.
^ permalink raw reply
* Re: git svn clone just stops
From: Pascal Obry @ 2009-12-18 15:00 UTC (permalink / raw)
To: Eric Wong; +Cc: Mark Jerkovic, git
In-Reply-To: <20091216081514.GB26038@dcvr.yhbt.net>
Eric,
> Not without error messages of some sort. git svn was designed with poor
> network conditions in mind and clone is resumable, so you can just
> resume like this:
>
> cd project.git && git svn fetch
What about --revision option. I mean if I have this clone interrupted:
$ git svn clone --revision=345:HEAD svn+ssh://...
Should I specify --revision when restarting with fetch? I think I had an
issue with this...
Maybe some other options are also to be passed to fetch?
Thanks.
--
--|------------------------------------------------------
--| Pascal Obry Team-Ada Member
--| 45, rue Gabriel Peri - 78114 Magny Les Hameaux FRANCE
--|------------------------------------------------------
--| http://www.obry.net - http://v2p.fr.eu.org
--| "The best way to travel is by means of imagination"
--|
--| gpg --keyserver keys.gnupg.net --recv-key F949BD3B
^ permalink raw reply
* How to commit bug fixes from old revisions
From: Richard Rossel @ 2009-12-18 15:02 UTC (permalink / raw)
To: git
Hi,
I'm confused with how to commit bug fixes from old tagged version.
Lets says that I have a serie of tags (v1.0, v1.1, v1.2, v2.0) in master,
and there is a bug from v.1.2. The bug was fixed, but I don't
want to merge to v2.0, because there are not compatibles. The bug fixed
should be
tagged as v1.3
So the question is how to commit between revisions( in the example,
between v.1.2 and v2.0),
without made any change in the HEAD of master (v2.0)
Or maybe the solution is to separate the versions in different branches
or different repos.
Thanks for the help
--
Richard Rossel
Software Engineer at Airsage Inc.
Valparaiso - Chile
^ permalink raw reply
* [PATCH v2] Let format-patch and rebase ignore trivial merges.
From: Bernhard R. Link @ 2009-12-18 15:11 UTC (permalink / raw)
To: git; +Cc: Junio C Hamano, Johannes Sixt
In-Reply-To: <7vaaxhfcfe.fsf@alter.siamese.dyndns.org>
As git rebase and git format-patch linearize commits,
having the same change in different branches causes in the
best case duplicate patches in the produced series and in the
worst case conflicts. If there are trivial merges involved
(i.e. merges that do not change the tree), then this patch
will cause git to only look at one branch, thereby avoiding
duplicates and reducing the chance of conflicts.
Signed-off-by: Bernhard R. Link <brlink@debian.org>
---
builtin-log.c | 1 +
git-rebase--interactive.sh | 2 +-
git-rebase.sh | 2 +-
revision.c | 7 ++++++-
revision.h | 1 +
5 files changed, 10 insertions(+), 3 deletions(-)
diff --git a/builtin-log.c b/builtin-log.c
index 1766349..efc2f40 100644
--- a/builtin-log.c
+++ b/builtin-log.c
@@ -960,6 +960,7 @@ int cmd_format_patch(int argc, const char **argv, const char *prefix)
rev.diff = 1;
rev.combine_merges = 0;
rev.ignore_merges = 1;
+ rev.prune_tree = 1;
DIFF_OPT_SET(&rev.diffopt, RECURSIVE);
rev.subject_prefix = fmt_patch_subject_prefix;
diff --git a/git-rebase--interactive.sh b/git-rebase--interactive.sh
index 0bd3bf7..e5c134b 100755
--- a/git-rebase--interactive.sh
+++ b/git-rebase--interactive.sh
@@ -703,7 +703,7 @@ first and then run 'git rebase --continue' again."
fi
git rev-list $MERGES_OPTION --pretty=oneline --abbrev-commit \
--abbrev=7 --reverse --left-right --topo-order \
- $REVISIONS | \
+ $REVISIONS -- . | \
sed -n "s/^>//p" | while read shortsha1 rest
do
if test t != "$PRESERVE_MERGES"
diff --git a/git-rebase.sh b/git-rebase.sh
index b121f45..dab6949 100755
--- a/git-rebase.sh
+++ b/git-rebase.sh
@@ -539,7 +539,7 @@ echo "$head_name" > "$dotest/head-name"
echo "$GIT_QUIET" > "$dotest/quiet"
msgnum=0
-for cmt in `git rev-list --reverse --no-merges "$revisions"`
+for cmt in `git rev-list --reverse --no-merges "$revisions" -- .`
do
msgnum=$(($msgnum + 1))
echo "$cmt" > "$dotest/cmt.$msgnum"
diff --git a/revision.c b/revision.c
index a8a3c3a..b27b682 100644
--- a/revision.c
+++ b/revision.c
@@ -1408,8 +1408,13 @@ int setup_revisions(int argc, const char **argv, struct rev_info *revs, const ch
}
}
- if (prune_data)
+ if (prune_data) {
revs->prune_data = get_pathspec(revs->prefix, prune_data);
+ } else if (revs->prune_tree) {
+ /* limit whole tree (limits trivial merges to one side) */
+ static const char *whole_tree[2] = { "", NULL };
+ revs->prune_data = whole_tree;
+ }
if (revs->def == NULL)
revs->def = def;
diff --git a/revision.h b/revision.h
index d368003..d007aaa 100644
--- a/revision.h
+++ b/revision.h
@@ -38,6 +38,7 @@ struct rev_info {
/* Traversal flags */
unsigned int dense:1,
prune:1,
+ prune_tree:1,
no_merges:1,
merges_only:1,
no_walk:1,
^ permalink raw reply related
* Re: How to commit bug fixes from old revisions
From: Howard Miller @ 2009-12-18 15:15 UTC (permalink / raw)
To: Richard Rossel; +Cc: git
In-Reply-To: <4B2B996D.9070302@inf.utfsm.cl>
2009/12/18 Richard Rossel <rrossel@inf.utfsm.cl>:
> Hi,
> I'm confused with how to commit bug fixes from old tagged version.
> Lets says that I have a serie of tags (v1.0, v1.1, v1.2, v2.0) in master,
> and there is a bug from v.1.2. The bug was fixed, but I don't
> want to merge to v2.0, because there are not compatibles. The bug fixed
> should be
> tagged as v1.3
>
> So the question is how to commit between revisions( in the example, between
> v.1.2 and v2.0),
> without made any change in the HEAD of master (v2.0)
>
> Or maybe the solution is to separate the versions in different branches or
> different repos.
I think it depends on how you look at it. The tag implies that v1.3
is a fixed release but what you say implies a branch. What I would do
is have a (say) '1.3_RELEASE" branch and that has the various fixes
merged on it. To put it another way, does your fix mean that there'll
be a v1.3.1? If so you would be tagging that on the 1.3 branch
(probably).
HTH
^ permalink raw reply
* Re: [RFC PATCH] Record a single transaction for conflicting push operations
From: Catalin Marinas @ 2009-12-18 15:49 UTC (permalink / raw)
To: Karl Wiberg; +Cc: git, Gustav Hållberg
In-Reply-To: <b8197bcb0912180123l4657839ctc121636af3724bee@mail.gmail.com>
2009/12/18 Karl Wiberg <kha@treskal.com>:
> On Fri, Dec 18, 2009 at 12:22 AM, Catalin Marinas
> <catalin.marinas@gmail.com> wrote:
>
>> StGit commands resulting in a conflicting patch pushing record two
>> transactions in the log (with one of them being inconsistent with
>> HEAD != top). Undoing such operations requires two "stg undo"
>> (possibly with --hard) commands which is unintuitive. This patch
>> changes such operations to only record one log entry and "stg undo"
>> reverts the stack to the state prior to the operation.
>
> Hmm, OK. It was convenient to be able to undo just the last
> conflicting step, but I guess the increase in UI complexity wasn't
> worth it.
>
> I think your patch doesn't go quite far enough, though.
> self.__conflicting_push is currently set to a function that will do
> the extra updates that take us from the first to the second state to
> save in the log; if we'll be saving at only one point, we might as
> well run those updates immediately instead of deferring them. In other
> words, the entire __conflicting_push variable could be removed.
See below for an updated patch:
Record a single transaction for conflicting push operations
From: Catalin Marinas <catalin.marinas@gmail.com>
StGit commands resulting in a conflicting patch pushing record two
transactions in the log (with one of them being inconsistent with HEAD
!= top). Undoing such operations requires two "stg undo" (possibly with
--hard) commands which is unintuitive. This patch changes such
operations to only record one log entry and "stg undo" reverts the stack
to the state prior to the operation.
Signed-off-by: Catalin Marinas <catalin.marinas@gmail.com>
Cc: Gustav Hållberg <gustav@virtutech.com>
Cc: Karl Wiberg <kha@treskal.com>
---
stgit/lib/transaction.py | 14 +++++---------
t/t3101-reset-hard.sh | 2 +-
t/t3103-undo-hard.sh | 4 ++--
3 files changed, 8 insertions(+), 12 deletions(-)
diff --git a/stgit/lib/transaction.py b/stgit/lib/transaction.py
index 30a153b..ea85d5d 100644
--- a/stgit/lib/transaction.py
+++ b/stgit/lib/transaction.py
@@ -90,7 +90,6 @@ class StackTransaction(object):
self.__applied = list(self.__stack.patchorder.applied)
self.__unapplied = list(self.__stack.patchorder.unapplied)
self.__hidden = list(self.__stack.patchorder.hidden)
- self.__conflicting_push = None
self.__error = None
self.__current_tree = self.__stack.head.data.tree
self.__base = self.__stack.base
@@ -232,10 +231,9 @@ class StackTransaction(object):
self.__stack.patchorder.hidden = self.__hidden
log.log_entry(self.__stack, msg)
old_applied = self.__stack.patchorder.applied
- write(self.__msg)
- if self.__conflicting_push != None:
- self.__patches = _TransPatchMap(self.__stack)
- self.__conflicting_push()
+ if not self.__conflicts:
+ write(self.__msg)
+ else:
write(self.__msg + ' (CONFLICT)')
if print_current_patch:
_print_current_patch(old_applied, self.__applied)
@@ -371,12 +369,10 @@ class StackTransaction(object):
# We've just caused conflicts, so we must allow them in
# the final checkout.
self.__allow_conflicts = lambda trans: True
-
- # Save this update so that we can run it a little later.
- self.__conflicting_push = update
+ self.__patches = _TransPatchMap(self.__stack)
+ update()
self.__halt("%d merge conflict(s)" % len(self.__conflicts))
else:
- # Update immediately.
update()
def push_tree(self, pn):
diff --git a/t/t3101-reset-hard.sh b/t/t3101-reset-hard.sh
index bd97b3a..45e86dc 100755
--- a/t/t3101-reset-hard.sh
+++ b/t/t3101-reset-hard.sh
@@ -47,7 +47,7 @@ test_expect_success 'Try to reset with --hard' '
stg reset --hard master.stgit^~1 &&
stg status a > actual.txt &&
test_cmp expected.txt actual.txt &&
- test "$(echo $(stg series))" = "> p1 - p2 - p3"
+ test "$(echo $(stg series))" = "+ p1 + p2 > p3"
'
test_done
diff --git a/t/t3103-undo-hard.sh b/t/t3103-undo-hard.sh
index 2d0f382..df14b1f 100755
--- a/t/t3103-undo-hard.sh
+++ b/t/t3103-undo-hard.sh
@@ -46,11 +46,11 @@ test_expect_success 'Try to undo without --hard' '
cat > expected.txt <<EOF
EOF
-test_expect_failure 'Try to undo with --hard' '
+test_expect_success 'Try to undo with --hard' '
stg undo --hard &&
stg status a > actual.txt &&
test_cmp expected.txt actual.txt &&
- test "$(echo $(stg series))" = "> p1 - p2 - p3" &&
+ test "$(echo $(stg series))" = "+ p1 + p2 > p3" &&
test "$(stg id)" = "$(stg id $(stg top))"
'
--
Catalin
^ permalink raw reply related
* git remote set-head not working?
From: Eugene Sajine @ 2009-12-18 16:25 UTC (permalink / raw)
To: git
Hi,
i have a repo cloned from the server with two branches master and qa.
$git remote show origin
tells me that the HEAD branch is master.
When i try to execute
$ git remote set-head origin qa
It prints nothing and "git remote show origin" still prints that HEAD
branch is master.
Could you, please, advise if I am i missing something.
I'm working on Linux with git-1.6.4.4
Thanks,
Eugene
^ permalink raw reply
* [PATCHv2 1/6] gitweb: Load checking
From: Jakub Narebski @ 2009-12-18 16:36 UTC (permalink / raw)
To: J.H.; +Cc: git, John 'Warthog9' Hawley
In-Reply-To: <200912111109.17047.jnareb@gmail.com>
From: John 'Warthog9' Hawley <warthog9@kernel.org>
This changes slightly the behavior of gitweb, so that it verifies
that the box isn't inundated with before attempting to serve gitweb.
If the box is overloaded, it basically returns a 503 Server Unavailable
until the load falls below the defined threshold. This helps dramatically
if you have a box that's I/O bound, reaches a certain load and you
don't want gitweb, the I/O hog that it is, increasing the pain the
server is already undergoing.
This behavior is controlled by $maxload configuration variable.
Default is a load of 300, which for most cases should never be hit.
Unset it (set it to undefined value, i.e. undef) to turn off checking.
Currently it requires that '/proc/loadavg' file exists, otherwise the
load check is bypassed (load is taken to be 0). So platforms that do
not implement '/proc/loadavg' currently cannot use this feature.
Signed-off-by: John 'Warthog9' Hawley <warthog9@kernel.org>
Signed-off-by: Jakub Narebski <jnareb@gmail.com>
---
This is my take on this patch, with all my concerns taken into
consideration... well, all except describing alterante approaches
to straight using /proc/loadavg.
Differences to original version by John 'Warthog9' Hawley (J.H.):
* Slightly improved wording in commit message and in comments
* $maxload described in gitweb/README, in "Gitweb config file variables"
section
* You can use '$maxload = undef;' to turn off load checking
* Error page for too high load is generated using die_error, which had
to be extended to handle 503 Service Unavailable HTTP error code
gitweb/README | 7 ++++++-
gitweb/gitweb.perl | 39 +++++++++++++++++++++++++++++++++++----
2 files changed, 41 insertions(+), 5 deletions(-)
diff --git a/gitweb/README b/gitweb/README
index e34ee79..6c2c8e1 100644
--- a/gitweb/README
+++ b/gitweb/README
@@ -174,7 +174,7 @@ not include variables usually directly set during build):
Base URL for relative URLs in pages generated by gitweb,
(e.g. $logo, $favicon, @stylesheets if they are relative URLs),
needed and used only for URLs with nonempty PATH_INFO via
- <base href="$base_url>. Usually gitweb sets its value correctly,
+ <base href="$base_url">. Usually gitweb sets its value correctly,
and there is no need to set this variable, e.g. to $my_uri or "/".
* $home_link
Target of the home link on top of all pages (the first part of view
@@ -228,6 +228,11 @@ not include variables usually directly set during build):
repositories from launching cross-site scripting (XSS) attacks. Set this
to true if you don't trust the content of your repositories. The default
is false.
+ * $maxload
+ Used to set the maximum load that we will still respond to gitweb queries.
+ If server load exceed this value then return "503 Service Unavaliable" error.
+ Server load is taken to be 0 if gitweb cannot determine its value. Set it to
+ undefined value to turn it off. The default is 300.
Projects list file format
diff --git a/gitweb/gitweb.perl b/gitweb/gitweb.perl
index 7e477af..a0f0444 100755
--- a/gitweb/gitweb.perl
+++ b/gitweb/gitweb.perl
@@ -221,6 +221,12 @@ our %avatar_size = (
'double' => 32
);
+# Used to set the maximum load that we will still respond to gitweb queries.
+# If server load exceed this value then return "503 server busy" error.
+# If gitweb cannot determined server load, it is taken to be 0.
+# Leave it undefined (or set to 'undef') to turn off load checking.
+our $maxload = 300;
+
# You define site-wide feature defaults here; override them with
# $GITWEB_CONFIG as necessary.
our %feature = (
@@ -551,6 +557,26 @@ if (-e $GITWEB_CONFIG) {
do $GITWEB_CONFIG_SYSTEM if -e $GITWEB_CONFIG_SYSTEM;
}
+# Get loadavg of system, to compare against $maxload.
+# Currently it requires '/proc/loadavg' present to get loadavg;
+# if it is not present it returns 0, which means no load checking.
+sub get_loadavg {
+ open my $fd, '<', '/proc/loadavg'
+ or return 0;
+ my @load = split(/\s+/, scalar <$fd>);
+ close $fd;
+
+ # The first three columns measure CPU and IO utilization of the last one,
+ # five, and 10 minute periods. The fourth column shows the number of
+ # currently running processes and the total number of processes in the m/n
+ # format. The last column displays the last process ID used.
+ return $load[0] || 0;
+}
+
+if (defined $maxload && get_loadavg() > $maxload) {
+ die_error(503, "The load average on the server is too high");
+}
+
# version of the core git binary
our $git_version = qx("$GIT" --version) =~ m/git version (.*)$/ ? $1 : "unknown";
$number_of_git_cmds++;
@@ -3354,14 +3380,19 @@ sub git_footer_html {
# 500: The server isn't configured properly, or
# an internal error occurred (e.g. failed assertions caused by bugs), or
# an unknown error occurred (e.g. the git binary died unexpectedly).
+# 503: The server is currently unavailable (because it is overloaded,
+# or down for maintenance). Generally, this is a temporary state.
sub die_error {
my $status = shift || 500;
my $error = shift || "Internal server error";
- my %http_responses = (400 => '400 Bad Request',
- 403 => '403 Forbidden',
- 404 => '404 Not Found',
- 500 => '500 Internal Server Error');
+ my %http_responses = (
+ 400 => '400 Bad Request',
+ 403 => '403 Forbidden',
+ 404 => '404 Not Found',
+ 500 => '500 Internal Server Error',
+ 503 => '503 Service Unavailable',
+ );
git_header_html($http_responses{$status});
print <<EOF;
<div class="page_body">
--
1.6.5.3
^ permalink raw reply related
* Re: git remote set-head not working?
From: Jeff King @ 2009-12-18 16:53 UTC (permalink / raw)
To: Eugene Sajine; +Cc: Jay Soffian, git
In-Reply-To: <76c5b8580912180825t17bfc90eq20dfc05cafa8c02e@mail.gmail.com>
On Fri, Dec 18, 2009 at 11:25:54AM -0500, Eugene Sajine wrote:
> i have a repo cloned from the server with two branches master and qa.
>
> $git remote show origin
>
> tells me that the HEAD branch is master.
>
> When i try to execute
>
> $ git remote set-head origin qa
>
> It prints nothing and "git remote show origin" still prints that HEAD
> branch is master.
>
> Could you, please, advise if I am i missing something.
Hmm. It probably worked, but what you are being shown is a bit
confusing.
"git remote show" will actually query the remote server to find where
its HEAD is pointing. But "git remote set-head" is about changing your
_local_ idea of where the remote head is pointing (in general, "git
remote" does not change anything on the remote side. It is about
managing the local configuration of your remotes).
AFAICT, there is no way to use "git remote" to query the result of your
set-head. And the "show" output makes no distinction between the two.
Perhaps we should print both in "git remote show" if they differ.
Something like:
HEAD branch: qa (remote points to "master")
or
HEAD branch (local): qa
HEAD branch (remote): master
That would clear up the confusion of what is happening. Whether that is
what you actually wanted, I don't know. If you want to be able to refer
to "origin/qa" as "origin", then you're fine. But if you wanted to
actually change the remote repository's idea of HEAD so that further
clones will clone "qa" by default, then you can't do that with "git
remote". You would have to go to the remote repository and run "git
symbolic-ref", I think.
-Peff
^ permalink raw reply
* How to exclude files from "git diff"
From: H.J. Lu @ 2009-12-18 17:09 UTC (permalink / raw)
To: git
Hi,
I have some bookkeeping files in my git repository. How do I
exclude them from "git diff"? Does "git diff" support
# git diff --exclude="foo.*.bar*"
Please CC me since I am not on the git mailing list.
Thanks.
--
H.J.
^ permalink raw reply
* Re: git remote set-head not working?
From: Eugene Sajine @ 2009-12-18 17:38 UTC (permalink / raw)
To: Jeff King; +Cc: Jay Soffian, git, Eugene Sajine
In-Reply-To: <20091218165302.GA1746@sigill.intra.peff.net>
> Hmm. It probably worked, but what you are being shown is a bit
> confusing.
>
> "git remote show" will actually query the remote server to find where
> its HEAD is pointing. But "git remote set-head" is about changing your
> _local_ idea of where the remote head is pointing (in general, "git
> remote" does not change anything on the remote side. It is about
> managing the local configuration of your remotes).
>
> AFAICT, there is no way to use "git remote" to query the result of your
> set-head. And the "show" output makes no distinction between the two.
>
> Perhaps we should print both in "git remote show" if they differ.
> Something like:
>
> HEAD branch: qa (remote points to "master")
>
> or
>
> HEAD branch (local): qa
> HEAD branch (remote): master
>
> That would clear up the confusion of what is happening. Whether that is
> what you actually wanted, I don't know. If you want to be able to refer
> to "origin/qa" as "origin", then you're fine. But if you wanted to
> actually change the remote repository's idea of HEAD so that further
> clones will clone "qa" by default, then you can't do that with "git
> remote". You would have to go to the remote repository and run "git
> symbolic-ref", I think.
>
> -Peff
>
Yes. I was trying to change the HEAD on the bare remote (origin) repo
and the concept here is really confusing.
Firstly, when i cloned from some repo "clone" comand is setting HEAD
branch for remote in accordance to where the HEAD is pointing on
origin side. I just recently realized that and i'm not sure it is best
thing to do - i think it should default to origin/master first, if it
doesn't exist then to where the HEAD is pointing.
Secondly, I don't really understand what is the purpose of "git remote
set-head" if the change cannot be transferred to the actual origin
repo, so it will start serving another branch as default? I might not
have access to the server to perform git symbolic-ref on my bare repo
(imagine the repo on github), so it might be not an option.
The problem with this is that it can be screwed up easily (i did
it;)), but the fix is not trivial.
Scenario i hit was:
My colleague created bare repo on the server and performed some
commits and pushed. We've got 3 branches on the server: master, qa and
featureX The repo got screwed up - i was unable to clone because of
repository corruption (another story probably for Shawn as there was
Egit involved;) )
So i tried to recover I cloned from my colleague, but his head was
pointing to featureX so I've got this featureX, when i was expecting
to see master.
I realized that i have to add master and qa as tracking branches for
origin/master and origin/qa.
Then i deleted corrupted server repo, created bare repo using "clone
--bare" and put it on the server. But i didn't know that i have to
checkout to master branch in order for it to be default branch served
from the server before cloning. So i ended up with the featureX being
default HEAD on the server.
That was not user friendly stuff...
And here i am trying to change this setting on the server...
Thanks,
Eugene
^ permalink raw reply
* repo corruption - Egit's fault?
From: Eugene Sajine @ 2009-12-18 18:06 UTC (permalink / raw)
To: git, Shawn O. Pearce
Hi,
We have imported a project from CVS. Then created a bare repo and
placed on the central server. From the server repos are served via git
protocol for push and pull operations (no SSH is involved for intranet
set up)
After this operations there were several extensive changes made (3
commits but they were pretty big) in development branch which were
then pushed to the server. So the branch was pushed too.
All changes and commits and pushes were performed under eclipse 3.5
using Egit plugin v0.5.
After it I could not clone this repo from the server as it was giving
me an error like this (I will shorten it up a bit using “…” as I have
no way to copy paste):
$git clone git://server/repo.git
Initialized empty git…
remote:counting…done
remote:compressing…done
remote: aborting due to possible repository corruption on the remote side.
Receiving object: 100% …done
Resolving deltas: 100% …done
error: waitpid (async) failed
fatal: error in sideband demultiplexer (I know right words to curse now;))
When I’m looking at the bare repo in CGit it shows me Bad object:
and object SHA-1 instead of the tree.
As the only difference between this project and about 30 others was
that there was an additional branch pushed via Egit I suspect that
this is what screwed up things, but I ‘m not sure… I’m in progress of
testing it I don’t know if I will be able to reproduce.
Please, advise if this can be fixed and which options I have if it
will happen again (how to properly and quickly restore bare repo)
Thanks,
Eugene
^ permalink raw reply
* Re: [PATCH 2/2] read-tree: at least one tree-ish argument is required
From: Junio C Hamano @ 2009-12-18 18:11 UTC (permalink / raw)
To: Johannes Sixt; +Cc: Git Mailing List
In-Reply-To: <4B2B5085.1050906@viscovery.net>
Johannes Sixt <j.sixt@viscovery.net> writes:
> You have queued 1/2 (filter-branch: remove an unnecessary use of
> 'git read-tree') of this 2-patch series, but I haven't seen any comments
> about this 2/2 nor is it queued. Did it fall through the cracks?
No. I think saying "is not allowed" is going a bit too far [*1*]. The
documentation does not list it as a commonly useful thing, that's all.
When a user wants to have an empty index, and does not want to touch files
under $GIT_DIR with any non-git tools (e.g. "rm -f $GIT_DIR/index) for
some religious reasons, "read-tree" without a tree would be one valid way
to do so [*2*]. That is not documented (the synopsis section even hints
that read-tree wants to take at least one tree), and I think it is a
problem that the documentation does not match what the program actually
allows.
The approach taken by [2/2] is to match the program to the documentation
by forbidding what has been allowed and what people may have been relying
on being able to do,
It was obvious that the line removed by [1/2] was a no-op not only in the
usual case but also in an error case (i.e. when the user does not have
write access to the repository), as I wrote in my review of the patch.
Compared to that, I do not think it is cut-and-dried clear that [2/2] is
the right kind of improvement. An alternative approach to document the
zero-tree case would be a valid way to address the documentation mismatch
problem.
We need to make arguments like "'read-tree' given by mistake to empty the
index is risky", "'read-tree' as 'rm -f $GIT_DIR/index' replacement has
little value", and "'read-tree' as 'rm -f $GIT_DIR/index' replacement is
the best way to get an empty index" to weigh pros and cons between two
possible approaches before deciding which way to go, but in a pre-release
freeze, I wasn't in the mood to be one who is doing the arguments myself.
[Footnote]
*1* Didn't I say that somewhere?
*2* I suspect "rm --cached ." might be another, but it would probably be
much more expensive.
^ permalink raw reply
* Re: repo corruption - Egit's fault?
From: Shawn O. Pearce @ 2009-12-18 18:16 UTC (permalink / raw)
To: Eugene Sajine; +Cc: git
In-Reply-To: <76c5b8580912181006p2aef9d2fj95bb4c8456d965b@mail.gmail.com>
Eugene Sajine <euguess@gmail.com> wrote:
> When I???m looking at the bare repo in CGit ??it shows me ??Bad object:
> and object SHA-1 instead of ??the tree.
>
> As the only difference between this project and about 30 others was
> that there was an additional branch pushed via Egit I suspect that
> this is what screwed up things, but I ???m not sure??? I???m in progress of
> testing it I don???t know if I will be able to reproduce.
Its a somewhat known problem, but thus far has only shown up in
contexts where I'm unable to get enough data to debug the problem.
https://bugs.eclipse.org/bugs/show_bug.cgi?id=286653
> Please, advise if this can be fixed and which options I have if it
> will happen again (how to properly and quickly restore bare repo)
Delete the branch and repush it. The bug is that EGit didn't push
all of the objects needed by the branch. If you put the missing
objects from the source client into the server repository, it'll
be fine.
To prevent this in the future, you can force a server to check during
push by enabling receive.fsckObjects in the server repository's
configuration file. A broken EGit client will have the push
rejected immediately.
--
Shawn.
^ permalink raw reply
* Re: [PATCH v2] Let format-patch and rebase ignore trivial merges.
From: Junio C Hamano @ 2009-12-18 18:23 UTC (permalink / raw)
To: Bernhard R. Link; +Cc: git, j.sixt
In-Reply-To: <20091218151102.GB7211@pcpool00.mathematik.uni-freiburg.de>
"Bernhard R. Link" <brlink@debian.org> writes:
[offtopic: weren't you already asked not to try redirecting away direct
responses to you by using M-F-T and wasting time of people who do want to
respond directly to you? Please don't.]
> As git rebase and git format-patch linearize commits,
> having the same change in different branches causes in the
> best case duplicate patches in the produced series and in the
> worst case conflicts. If there are trivial merges involved
> (i.e. merges that do not change the tree), then this patch
> will cause git to only look at one branch, thereby avoiding
> duplicates and reducing the chance of conflicts.
The patch text itself from the cursory review looks Ok (I haven't thought
things through yet, let alone applying it, though).
One issue in the proposed commit log message above is that "trivial merge"
is an established technical term that means something very different from
"resulting tree of the merge matches exactly one of the parents' tree",
and it needs to be reworded. In this case it is easy [*1*]. Drop
everything after "If there are ...", and add something like this as a
separate paragraph:
Avoid outputting duplicate patches by ignoring all other parents when
the merge result matches exactly one of the parents.
The code comment also needs to be adjusted.
Thanks.
[Footnote]
*1* It is a good habit to acquire to question yourself if you can omit "X"
altogether and just say "Y" after writing "X (i.e. Y)".
^ permalink raw reply
* Re: repo corruption - Egit's fault?
From: Eugene Sajine @ 2009-12-18 18:30 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: git
In-Reply-To: <20091218181613.GA10687@spearce.org>
> To prevent this in the future, you can force a server to check during
> push by enabling receive.fsckObjects in the server repository's
> configuration file. A broken EGit client will have the push
> rejected immediately.
>
> --
> Shawn.
>
Thank you for prompt answer, Shawn!
The problem is that as i'm maintaining multiple repos and their
quantity will grow i would need to apply this setting site wide. Do
you know if i can specify this service for git daemon? It seems like
in git deamon docs this service is not listed, but just in case the
docs are not up to date... I really don't want to set this up for
every repo manually...
Thanks,
Eugene
^ permalink raw reply
* Re: repo corruption - Egit's fault?
From: Eugene Sajine @ 2009-12-18 18:51 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: git
In-Reply-To: <76c5b8580912181030k56cb7dd7l811c0a0d4773d309@mail.gmail.com>
> Thank you for prompt answer, Shawn!
>
> The problem is that as i'm maintaining multiple repos and their
> quantity will grow i would need to apply this setting site wide. Do
> you know if i can specify this service for git daemon? It seems like
> in git deamon docs this service is not listed, but just in case the
> docs are not up to date... I really don't want to set this up for
> every repo manually...
>
> Thanks,
> Eugene
>
I found it.
$ git config --global receive.fsckObjects true
should do the trick.
Thanks,
Eugene
^ permalink raw reply
* Re: [PATCH 2/2] read-tree: at least one tree-ish argument is required
From: Johannes Sixt @ 2009-12-18 19:04 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Git Mailing List
In-Reply-To: <7v4onoywws.fsf@alter.siamese.dyndns.org>
On Freitag, 18. Dezember 2009, Junio C Hamano wrote:
> Johannes Sixt <j.sixt@viscovery.net> writes:
> > You have queued 1/2 (filter-branch: remove an unnecessary use of
> > 'git read-tree') of this 2-patch series, but I haven't seen any comments
> > about this 2/2 nor is it queued. Did it fall through the cracks?
>
> No. I think saying "is not allowed" is going a bit too far [*1*].
Yes, you said that, but in response to the footnote in 1/2.
> The
> documentation does not list it as a commonly useful thing, that's all.
IMO, not only is it not useful, but it is also dangerous - it erases the
index!
> When a user wants to have an empty index, and does not want to touch files
> under $GIT_DIR with any non-git tools (e.g. "rm -f $GIT_DIR/index) for
> some religious reasons, "read-tree" without a tree would be one valid way
> to do so [*2*].
> *2* I suspect "rm --cached ." might be another, but it would probably be
> much more expensive.
For an operation like this, shouldn't we advocate this alternate instruction
(which explicitly tells what is wanted) rather than the implicit and
undocumented operation of parameter-less read-tree?
> We need to make arguments like "'read-tree' given by mistake to empty the
> index is risky", "'read-tree' as 'rm -f $GIT_DIR/index' replacement has
> little value", and "'read-tree' as 'rm -f $GIT_DIR/index' replacement is
> the best way to get an empty index" to weigh pros and cons between two
> possible approaches before deciding which way to go, but in a pre-release
> freeze, I wasn't in the mood to be one who is doing the arguments myself.
Sorry to drag you into this discussion, but I felt this change is maint-worthy
(because the behavior is not only risky, but dangerous).
-- Hannes
^ permalink raw reply
* [RFC/PATCHv2 2/6] gitweb: Add option to force version match
From: Jakub Narebski @ 2009-12-18 19:18 UTC (permalink / raw)
To: git
Cc: John 'Warthog9' Hawley, John 'Warthog9' Hawley,
Jakub Narebski
In-Reply-To: <m3y6l9dbop.fsf@localhost.localdomain>
From: John 'Warthog9' Hawley <warthog9@kernel.org>
This adds $git_versions_must_match variable, which is set to true
value checks that we are running on the same version of git that we
shipped with, and if not throw '500 Internal Server Error' error.
What is checked is the version of gitweb (embedded in building
gitweb.cgi), against version of runtime git binary used.
Gitweb can usually run with a mismatched git install. This is more
here to give an obvious warning as to whats going on vs. silently
failing.
By default this feature is turned off.
Signed-off-by: John 'Warthog9' Hawley <warthog9@kernel.org>
Signed-off-by: Jakub Narebski <jnareb@gmail.com>
---
I don't quite see the reason behind such option, and I think that
error (instead of for example warning) on version mismatch is too much.
This is an RFC because formatting of error page is a bit rough, and
(ab)uses exist CSS classes instead of creating new classnames for
semantic markup.
Differences from original version, by J.H.:
* Changed name and flipped meaning of config variable, from
$missmatch_git to $git_versions_must_match
* $git_versions_must_match is boolean flag - do not compare with an
empty string.
* Changed error message a bit, fixed style, added entry in README
gitweb/README | 3 +++
gitweb/gitweb.perl | 33 +++++++++++++++++++++++++++++++++
2 files changed, 36 insertions(+), 0 deletions(-)
diff --git a/gitweb/README b/gitweb/README
index 6c2c8e1..608b0f8 100644
--- a/gitweb/README
+++ b/gitweb/README
@@ -233,6 +233,9 @@ not include variables usually directly set during build):
If server load exceed this value then return "503 Service Unavaliable" error.
Server load is taken to be 0 if gitweb cannot determine its value. Set it to
undefined value to turn it off. The default is 300.
+ * $git_versions_must_match
+ If set, gitweb fails with 500 Internal Server Error if the version of gitweb
+ doesn't match version of git binary. The default is false.
Projects list file format
diff --git a/gitweb/gitweb.perl b/gitweb/gitweb.perl
index 3222131..b9bd865 100755
--- a/gitweb/gitweb.perl
+++ b/gitweb/gitweb.perl
@@ -221,6 +221,9 @@ our %avatar_size = (
'double' => 32
);
+# If it is true, exit if gitweb version and git binary version don't match
+our $git_versions_must_match = 0;
+
# Used to set the maximum load that we will still respond to gitweb queries.
# If server load exceed this value then return "503 server busy" error.
# If gitweb cannot determined server load, it is taken to be 0.
@@ -581,6 +584,36 @@ if (defined $maxload && get_loadavg() > $maxload) {
our $git_version = qx("$GIT" --version) =~ m/git version (.*)$/ ? $1 : "unknown";
$number_of_git_cmds++;
+# Throw an error if git versions does not match, if $git_versions_must_match is true.
+if ($git_versions_must_match &&
+ $git_version ne $version) {
+ git_header_html('500 - Internal Server Error');
+ my $admin_contact =
+ defined $ENV{'SERVER_ADMIN'} ? ", $ENV{'SERVER_ADMIN'}," : '';
+ print <<"EOT";
+<div class="page_body">
+<br /><br />
+500 - Internal Server Error
+<br />
+</div>
+<hr />
+<div class="readme">
+<h1 align="center">*** Warning ***</h1>
+<p>
+This version of gitweb was compiled for <b>@{[esc_html($version)]}</b>,
+however git version <b>@{[esc_html($git_version)]}</b> was found on server,
+and administrator requested strict version checking.
+</p>
+<p>
+Please contact the server administrator${admin_contact} to either configure
+gitweb to allow mismatched versions, or update git or gitweb installation.
+</p>
+</div>
+EOT
+ git_footer_html();
+ exit;
+}
+
$projects_list ||= $projectroot;
# ======================================================================
--
1.6.5.3
^ permalink raw reply related
* Re: [PATCH 2/2] read-tree: at least one tree-ish argument is required
From: Sverre Rabbelier @ 2009-12-18 19:24 UTC (permalink / raw)
To: Johannes Sixt; +Cc: Junio C Hamano, Git Mailing List
In-Reply-To: <200912182004.25520.j.sixt@viscovery.net>
Heya,
On Fri, Dec 18, 2009 at 13:04, Johannes Sixt <j.sixt@viscovery.net> wrote:
> Sorry to drag you into this discussion, but I felt this change is maint-worthy
> (because the behavior is not only risky, but dangerous).
I agree, shouldn't such a dangerous function at least require a flag?
'git read-tree --empty' or something?
--
Cheers,
Sverre Rabbelier
^ permalink raw reply
* Re: [PATCH 2/2] read-tree: at least one tree-ish argument is required
From: Junio C Hamano @ 2009-12-18 19:32 UTC (permalink / raw)
To: Johannes Sixt; +Cc: Git Mailing List
In-Reply-To: <200912182004.25520.j.sixt@viscovery.net>
Johannes Sixt <j.sixt@viscovery.net> writes:
> Sorry to drag you into this discussion, but I felt this change is
> maint-worthy (because the behavior is not only risky, but dangerous).
>
> -- Hannes
In short, that is where we differ, as I don't think it is dangerous at
all in the "maint-worthy" sense.
"read-tree" without -m is to "populate the index from emptiness with given
trees". Unless you are hit by the bug in the auto-correction (whose fix
was maint-worthy), nobody would say read-tree without parameter and expect
that it wouldn't touch the index.
Sure, it will empty the index, so it is dangerous in the same sense that
"reset --hard" is dangerous because it will wipe all your local changes,
or "rm -rf it" will remove everything underneath it. But these are all
features that are "dangerous if you didn't mean to do so but wanted to do
something else."
Removal of such features might turn out to be maint-worthy but
Previously, it was possible to run read-tree without any arguments,
whereupon it purged the index!
doesn't justify it well enough.
^ permalink raw reply
* Re: [PATCH 2/2] read-tree: at least one tree-ish argument is required
From: Sverre Rabbelier @ 2009-12-18 19:37 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Johannes Sixt, Git Mailing List
In-Reply-To: <7voclwxemf.fsf@alter.siamese.dyndns.org>
Heya,
On Fri, Dec 18, 2009 at 13:32, Junio C Hamano <gitster@pobox.com> wrote:
> Sure, it will empty the index, so it is dangerous in the same sense that
> "reset --hard" is dangerous because it will wipe all your local changes,
> or "rm -rf it" will remove everything underneath it.
With the difference that both 'reset --hard' and 'rm -rf' need a flag
to do their destructive work? Although 'git reset' might be just as
destructive if you've been using 'git add -p' a lot or something,
mhh...
--
Cheers,
Sverre Rabbelier
^ 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