* 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: 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
* [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
* 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
* 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
* 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
* [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
* 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
* 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
* 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: [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 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 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: [RFC PATCH] Record a single transaction for conflicting push operations
From: Karl Wiberg @ 2009-12-18 9:23 UTC (permalink / raw)
To: Catalin Marinas; +Cc: git, Gustav Hållberg
In-Reply-To: <20091217232212.4869.43002.stgit@toshiba-laptop>
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.
--
Karl Wiberg, kha@treskal.com
subrabbit.wordpress.com
www.treskal.com/kalle
^ permalink raw reply
* Re: Endianness bug in git-svn or called component?
From: Nathaniel W Filardo @ 2009-12-18 9:05 UTC (permalink / raw)
To: Andreas Schwab; +Cc: Nathaniel W Filardo, git
In-Reply-To: <20091204202928.GW17192@gradx.cs.jhu.edu>
[-- Attachment #1: Type: text/plain, Size: 2214 bytes --]
On Fri, Dec 04, 2009 at 03:29:28PM -0500, Nathaniel W Filardo wrote:
> On Fri, Dec 04, 2009 at 09:16:40PM +0100, Andreas Schwab wrote:
> > Nathaniel W Filardo <nwf@cs.jhu.edu> writes:
> >
> > > On this machine,
> > >
> > > mirrors hydra:/tank0/mirrors/misc% uname -a
> > > FreeBSD hydra.priv.oc.ietfng.org 9.0-CURRENT FreeBSD 9.0-CURRENT #13: Sat Nov 14 19:40:25 EST 2009 root@hydra.priv.oc.ietfng.org:/systank/obj/systank/src/sys/NWFKERN sparc64
> > >
> > > attempting to fetch from an svn source yields the following error:
> > >
> > > rs hydra:/tank0/mirrors/misc% git svn init -s https://joshua.svn.sourceforge.net/svnroot/joshua test-joshua
> > > Initialized empty Git repository in /tank0/mirrors/misc/test-joshua/.git/
> > > mirrors hydra:/tank0/mirrors/misc% cd test-joshua
> > > mirrors hydra:/tank0/mirrors/misc/test-joshua% git svn fetch
> > > A scripts/distributedLM/config.template
> > > [...]
> > > A build.xml
> > > r1 = fe84a7d821ec6d92da75133ac7ad1deb476b6484 (refs/remotes/trunk)
> > > error: index uses extension, which we do not understand
> > > fatal: index file corrupt
> > > write-tree: command returned error: 128
> >
> > I could not reproduce that on powerpc (both 32bit and 64bit).
> >
> > Andreas.
I got some free time and tracked it down. The following one-line delta
fixes this issue for me; AIUI on sparc64 "unsigned long" is 8 bits and in
the wrong endianness for the memcpy trick to work as written? I could be
sligntly off in my assessment of the problem, tho'.
index 1bbaf1c..9033dd3 100644
--- a/read-cache.c
+++ b/read-cache.c
@@ -1322,7 +1322,7 @@ int read_index_from(struct index_state *istate, const char *path)
* extension name (4-byte) and section length
* in 4-byte network byte order.
*/
- unsigned long extsize;
+ uint32_t extsize;
memcpy(&extsize, (char *)mmap + src_offset + 4, 4);
extsize = ntohl(extsize);
if (read_index_extension(istate,
--nwf;
[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply related
* Re: [RFC/PATCH] branch: new option --will-track
From: Junio C Hamano @ 2009-12-18 7:16 UTC (permalink / raw)
To: Andreas Krey; +Cc: Dave Olszewski, git
In-Reply-To: <20091218061851.GA10221@inner.home.ulmdo.de>
Andreas Krey <a.krey@gmx.de> writes:
> On Thu, 17 Dec 2009 16:07:08 +0000, Junio C Hamano wrote:
> ...
>> Also "git pull --remember $there $this" might be a good way to tell the
>> configuration mechanism from the UI to remember that "I always want to
>> merge $this branch from $there while on the branch I am currently on", and
>> its implementation may probably use "git branch --reconfigure" internally.
>
> Actually my favorite would be 'git push --track $there', pushing
> the current local branch to $there and setting up tracking. That
> way the tracking decision need not be made before the remote
> branch actually exists.
Yeah, it may be useful, but that belongs to the same "in addition to the
most flexible form, we might want to _also_ do so" category, as the one
that makes "git pull" remember.
The advantage of remembering upon the first pull is that the request to
remember doesn't involve any "push is reverse of pull" indirection.
Instead, it is exactly what the user actually has done once: "I'm doing
this once, remember it for me". Compared to it, I think it is less
obvious to make the first push remember its reverse [*1*].
Another issue that you need to think about is how you will allow users to
set up "integrate with merge or rebase" when making "push" remember.
An option with "pull" would make it much more obvious what is going on, as
the user would say "git pull --rebase --remember $there $this" if rebasing
is desired, and that is what is going to be remembered; again that is
thanks to the "I'm doing this once, remember it for me" semantics.
[Footnote]
*1* I am not saying "if you have 'pull --remember' you don't need 'push
--remember'" or vice versa. As long as each (judged individually) makes
sense we could have both.
^ permalink raw reply
* Re: [RFC/PATCH] branch: new option --will-track
From: Andreas Krey @ 2009-12-18 6:18 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Dave Olszewski, git
In-Reply-To: <7vaaxhdu1f.fsf@alter.siamese.dyndns.org>
On Thu, 17 Dec 2009 16:07:08 +0000, Junio C Hamano wrote:
...
> Also "git pull --remember $there $this" might be a good way to tell the
> configuration mechanism from the UI to remember that "I always want to
> merge $this branch from $there while on the branch I am currently on", and
> its implementation may probably use "git branch --reconfigure" internally.
Actually my favorite would be 'git push --track $there', pushing
the current local branch to $there and setting up tracking. That
way the tracking decision need not be made before the remote
branch actually exists.
Andreas
^ permalink raw reply
* Re: core.autocrlf & Cygwin - files incorrectly flagged as modified
From: Robin Rosenberg @ 2009-12-18 6:06 UTC (permalink / raw)
To: David Antliff; +Cc: git
In-Reply-To: <loom.20091218T033941-445@post.gmane.org>
fredagen den 18 december 2009 03.43.05 skrev David Antliff:
> Robin Rosenberg writes:
> > tisdag 15 december 2009 23:24:15 skrev David Antliff:
> > > The problem is that sometimes, after a git-clone, the output of
> > > git-status and git-diff shows entire files as being different. However
> > > these files have not been modified by the user - only git has had a
> > > chance to change them (due to autocrlf=true). But surely if git has
> > > converted the file automatically, it should know that it has to
> > > compensate for this when comparing with the local repository?
> >
> > AFAIK, this happens if you have CRLF line endings in the blobs in the
> > repo.
>
> Oh? That could very well be true - how would such line endings get into a
> blob? I'm pretty sure everyone is using autocrlf=true which should convert
> all line endings to LF on commit, but perhaps there's another way to get
> CRLF line endings into a blob?
>
> If autocrlf=false, files are committed as-is (I believe), so this would be
> one way to end up committing such files. But as far as I know, nobody has
> turned that option off in our group.
EGit works this way at the moment.
Conversion tools might do this.
Some Eclipse plugins produce files with CRLF regardless on platform and on
non-Windows the core.autocrlf flags is false by default.
-- robin
^ permalink raw reply
* Re: git-reflog 70 minutes at 100% cpu and counting
From: Steven Noonan @ 2009-12-18 4:26 UTC (permalink / raw)
To: Nicolas Pitre; +Cc: Eric Paris, Jeff King, git
In-Reply-To: <alpine.LFD.2.00.0912172255500.23173@xanadu.home>
On Thu, Dec 17, 2009 at 7:57 PM, Nicolas Pitre <nico@fluxnic.net> wrote:
> On Thu, 17 Dec 2009, Steven Noonan wrote:
>
>> On Thu, Dec 17, 2009 at 7:33 PM, Nicolas Pitre <nico@fluxnic.net> wrote:
>> > On Thu, 17 Dec 2009, Eric Paris wrote:
>> >
>> >> This alone almost certainly tells me how I broke it.
>> >>
>> >> For quite some time (a period of months) linux-next was broken and I had
>> >> to carry a patch to ACPI to make it boot. I dropped that patch at the
>> >> head of my stgit trees in all of my repositories. So I wouldn't be at
>> >> all surprised to learn that eventually kernel-2 found that object in
>> >> kernel-1. Sometime when I dropped that patch from kernel-1 (because it
>> >> finally got fixed upstream) I can see how it broke.
>> >>
>> >> But now that patch shouldn't be needed by any tree since I have long
>> >> since dropped it from the stgit stack. So if we cleaned up all of the
>> >> useless objects in this tree I bet this object wouldn't be needed. Not
>> >> exactly a situation that I'd expect git to be able to dig out of itself
>> >> thought.
>> >
>> > I let the script I provided previously ran for a while. And the commit
>> > I found to contain the missing object belongs to
>> > refs/patches/fsnotify/fsnotify-group-priorities.log. So I simply
>> > deleted that branch entirely and now the repack can proceed. And with a
>> > 'git gc --aggressive' the 1.2GB repository shrank to a mere 5.2 MB. :-)
>> > Of course I didn't bring back all the reflogs though. But I would
>> > have expected a repository reduction of the same magnitude even with
>> > them.
>> >
>>
>> Are we talking about the same Linux kernel repository as before?
>
> As before in this thread.
>
>> Because if so, that reduction in size doesn't make any sense to me.
>
> Sure it does.
>
>> The smallest size I've seen for the Linux kernel repository (in the
>> past year) is 250MB.
>
> Depends if you have an alternate repository from which you may borrow
> objects from, which was the case here. In that context, 1.2 GB of disk
> space was completely insane.
>
Ahh. That makes sense. I should really read up on alternates then.
- Steven
^ permalink raw reply
* Re: git-reflog 70 minutes at 100% cpu and counting
From: Nicolas Pitre @ 2009-12-18 3:57 UTC (permalink / raw)
To: Steven Noonan; +Cc: Eric Paris, Jeff King, git
In-Reply-To: <f488382f0912171944m6c7d7fdas8fe2b12755358b@mail.gmail.com>
[-- Attachment #1: Type: TEXT/PLAIN, Size: 1965 bytes --]
On Thu, 17 Dec 2009, Steven Noonan wrote:
> On Thu, Dec 17, 2009 at 7:33 PM, Nicolas Pitre <nico@fluxnic.net> wrote:
> > On Thu, 17 Dec 2009, Eric Paris wrote:
> >
> >> This alone almost certainly tells me how I broke it.
> >>
> >> For quite some time (a period of months) linux-next was broken and I had
> >> to carry a patch to ACPI to make it boot. I dropped that patch at the
> >> head of my stgit trees in all of my repositories. So I wouldn't be at
> >> all surprised to learn that eventually kernel-2 found that object in
> >> kernel-1. Sometime when I dropped that patch from kernel-1 (because it
> >> finally got fixed upstream) I can see how it broke.
> >>
> >> But now that patch shouldn't be needed by any tree since I have long
> >> since dropped it from the stgit stack. So if we cleaned up all of the
> >> useless objects in this tree I bet this object wouldn't be needed. Not
> >> exactly a situation that I'd expect git to be able to dig out of itself
> >> thought.
> >
> > I let the script I provided previously ran for a while. And the commit
> > I found to contain the missing object belongs to
> > refs/patches/fsnotify/fsnotify-group-priorities.log. So I simply
> > deleted that branch entirely and now the repack can proceed. And with a
> > 'git gc --aggressive' the 1.2GB repository shrank to a mere 5.2 MB. :-)
> > Of course I didn't bring back all the reflogs though. But I would
> > have expected a repository reduction of the same magnitude even with
> > them.
> >
>
> Are we talking about the same Linux kernel repository as before?
As before in this thread.
> Because if so, that reduction in size doesn't make any sense to me.
Sure it does.
> The smallest size I've seen for the Linux kernel repository (in the
> past year) is 250MB.
Depends if you have an alternate repository from which you may borrow
objects from, which was the case here. In that context, 1.2 GB of disk
space was completely insane.
Nicolas
^ permalink raw reply
* Re: git-reflog 70 minutes at 100% cpu and counting
From: Eric Paris @ 2009-12-18 3:55 UTC (permalink / raw)
To: Nicolas Pitre; +Cc: Jeff King, git
In-Reply-To: <alpine.LFD.2.00.0912172149020.23173@xanadu.home>
On Thu, 2009-12-17 at 22:33 -0500, Nicolas Pitre wrote:
> On Thu, 17 Dec 2009, Eric Paris wrote:
>
> > This alone almost certainly tells me how I broke it.
> >
> > For quite some time (a period of months) linux-next was broken and I had
> > to carry a patch to ACPI to make it boot. I dropped that patch at the
> > head of my stgit trees in all of my repositories. So I wouldn't be at
> > all surprised to learn that eventually kernel-2 found that object in
> > kernel-1. Sometime when I dropped that patch from kernel-1 (because it
> > finally got fixed upstream) I can see how it broke.
> >
> > But now that patch shouldn't be needed by any tree since I have long
> > since dropped it from the stgit stack. So if we cleaned up all of the
> > useless objects in this tree I bet this object wouldn't be needed. Not
> > exactly a situation that I'd expect git to be able to dig out of itself
> > thought.
>
> I let the script I provided previously ran for a while. And the commit
> I found to contain the missing object belongs to
> refs/patches/fsnotify/fsnotify-group-priorities.log.
At least when I thought it was in ACPI I could imagine what I had done
wrong. Now I'm not so sure.
In any case, I've redesigned with a clear alternative repo that I never
work in and a cron job to clean up garbage every night. So hopefully
noone will hear from me again.
Nicolas, thanks so much for hunting this down!
-Eric
> So I simply
> deleted that branch entirely and now the repack can proceed. And with a
> 'git gc --aggressive' the 1.2GB repository shrank to a mere 5.2 MB. :-)
> Of course I didn't bring back all the reflogs though. But I would
> have expected a repository reduction of the same magnitude even with
> them.
>
>
> Nicolas
^ permalink raw reply
* Re: git-reflog 70 minutes at 100% cpu and counting
From: Eric Paris @ 2009-12-18 3:52 UTC (permalink / raw)
To: Steven Noonan; +Cc: Nicolas Pitre, Jeff King, git
In-Reply-To: <f488382f0912171944m6c7d7fdas8fe2b12755358b@mail.gmail.com>
On Thu, 2009-12-17 at 19:44 -0800, Steven Noonan wrote:
> On Thu, Dec 17, 2009 at 7:33 PM, Nicolas Pitre <nico@fluxnic.net> wrote:
> > On Thu, 17 Dec 2009, Eric Paris wrote:
> >
> >> This alone almost certainly tells me how I broke it.
> >>
> >> For quite some time (a period of months) linux-next was broken and I had
> >> to carry a patch to ACPI to make it boot. I dropped that patch at the
> >> head of my stgit trees in all of my repositories. So I wouldn't be at
> >> all surprised to learn that eventually kernel-2 found that object in
> >> kernel-1. Sometime when I dropped that patch from kernel-1 (because it
> >> finally got fixed upstream) I can see how it broke.
> >>
> >> But now that patch shouldn't be needed by any tree since I have long
> >> since dropped it from the stgit stack. So if we cleaned up all of the
> >> useless objects in this tree I bet this object wouldn't be needed. Not
> >> exactly a situation that I'd expect git to be able to dig out of itself
> >> thought.
> >
> > I let the script I provided previously ran for a while. And the commit
> > I found to contain the missing object belongs to
> > refs/patches/fsnotify/fsnotify-group-priorities.log. So I simply
> > deleted that branch entirely and now the repack can proceed. And with a
> > 'git gc --aggressive' the 1.2GB repository shrank to a mere 5.2 MB. :-)
> > Of course I didn't bring back all the reflogs though. But I would
> > have expected a repository reduction of the same magnitude even with
> > them.
> >
>
> Are we talking about the same Linux kernel repository as before?
> Because if so, that reduction in size doesn't make any sense to me.
> The smallest size I've seen for the Linux kernel repository (in the
> past year) is 250MB.
Remember that the real code object are in an alternative repository
which isn't going to shrink like this. (A nicely packed repo with the
majority of the objects in question is around 500M)
^ permalink raw reply
* Re: git-reflog 70 minutes at 100% cpu and counting
From: Steven Noonan @ 2009-12-18 3:44 UTC (permalink / raw)
To: Nicolas Pitre; +Cc: Eric Paris, Jeff King, git
In-Reply-To: <alpine.LFD.2.00.0912172149020.23173@xanadu.home>
On Thu, Dec 17, 2009 at 7:33 PM, Nicolas Pitre <nico@fluxnic.net> wrote:
> On Thu, 17 Dec 2009, Eric Paris wrote:
>
>> This alone almost certainly tells me how I broke it.
>>
>> For quite some time (a period of months) linux-next was broken and I had
>> to carry a patch to ACPI to make it boot. I dropped that patch at the
>> head of my stgit trees in all of my repositories. So I wouldn't be at
>> all surprised to learn that eventually kernel-2 found that object in
>> kernel-1. Sometime when I dropped that patch from kernel-1 (because it
>> finally got fixed upstream) I can see how it broke.
>>
>> But now that patch shouldn't be needed by any tree since I have long
>> since dropped it from the stgit stack. So if we cleaned up all of the
>> useless objects in this tree I bet this object wouldn't be needed. Not
>> exactly a situation that I'd expect git to be able to dig out of itself
>> thought.
>
> I let the script I provided previously ran for a while. And the commit
> I found to contain the missing object belongs to
> refs/patches/fsnotify/fsnotify-group-priorities.log. So I simply
> deleted that branch entirely and now the repack can proceed. And with a
> 'git gc --aggressive' the 1.2GB repository shrank to a mere 5.2 MB. :-)
> Of course I didn't bring back all the reflogs though. But I would
> have expected a repository reduction of the same magnitude even with
> them.
>
Are we talking about the same Linux kernel repository as before?
Because if so, that reduction in size doesn't make any sense to me.
The smallest size I've seen for the Linux kernel repository (in the
past year) is 250MB.
- Steven
^ permalink raw reply
* Re: git-reflog 70 minutes at 100% cpu and counting
From: Nicolas Pitre @ 2009-12-18 3:33 UTC (permalink / raw)
To: Eric Paris; +Cc: Jeff King, git
In-Reply-To: <1261067369.2868.10.camel@localhost>
On Thu, 17 Dec 2009, Eric Paris wrote:
> This alone almost certainly tells me how I broke it.
>
> For quite some time (a period of months) linux-next was broken and I had
> to carry a patch to ACPI to make it boot. I dropped that patch at the
> head of my stgit trees in all of my repositories. So I wouldn't be at
> all surprised to learn that eventually kernel-2 found that object in
> kernel-1. Sometime when I dropped that patch from kernel-1 (because it
> finally got fixed upstream) I can see how it broke.
>
> But now that patch shouldn't be needed by any tree since I have long
> since dropped it from the stgit stack. So if we cleaned up all of the
> useless objects in this tree I bet this object wouldn't be needed. Not
> exactly a situation that I'd expect git to be able to dig out of itself
> thought.
I let the script I provided previously ran for a while. And the commit
I found to contain the missing object belongs to
refs/patches/fsnotify/fsnotify-group-priorities.log. So I simply
deleted that branch entirely and now the repack can proceed. And with a
'git gc --aggressive' the 1.2GB repository shrank to a mere 5.2 MB. :-)
Of course I didn't bring back all the reflogs though. But I would
have expected a repository reduction of the same magnitude even with
them.
Nicolas
^ permalink raw reply
* Re: core.autocrlf & Cygwin - files incorrectly flagged as modified
From: David Antliff @ 2009-12-18 2:43 UTC (permalink / raw)
To: git
In-Reply-To: <200912170800.35752.robin.rosenberg@dewire.com>
Robin Rosenberg writes:
> tisdag 15 december 2009 23:24:15 skrev David Antliff:
> > The problem is that sometimes, after a git-clone, the output of git-status
> > and git-diff shows entire files as being different. However these files
> > have not been modified by the user - only git has had a chance to change
> > them (due to autocrlf=true). But surely if git has converted the file
> > automatically, it should know that it has to compensate for this when
> > comparing with the local repository?
>
> AFAIK, this happens if you have CRLF line endings in the blobs in the repo.
Oh? That could very well be true - how would such line endings get into a blob?
I'm pretty sure everyone is using autocrlf=true which should convert all line
endings to LF on commit, but perhaps there's another way to get CRLF line
endings into a blob?
If autocrlf=false, files are committed as-is (I believe), so this would be one
way to end up committing such files. But as far as I know, nobody has turned
that option off in our group.
^ 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