* Re: [RFC/PATCH] gitweb: link to toggle 'no merges' option
From: Jakub Narebski @ 2009-12-17 21:14 UTC (permalink / raw)
To: Giuseppe Bilotta; +Cc: git
In-Reply-To: <cb7bb73a0912171241j56ecd2f1y3dc66cf3b86bd784@mail.gmail.com>
Giuseppe Bilotta wrote:
> 2009/12/17 Jakub Narebski <jnareb@gmail.com>:
>> On Thu, 17 Dec 2009 10:05 +0100, Giuseppe Bilotta wrote:
[...]
>>> + my $can_have_merges = grep(/^$action$/, @{$allowed_options{'--no-merges'}});
>>> + my $has_merges = !grep(/^--no-merges$/, @extra_options);
>>> +
>>
>> Wouldn't it be better to use straight
>>
>> + my $no_merges = grep(/^--no-merges$/, @extra_options);
>>
>> Because $has_merges is true also for example for 'tree' view... which
>> absolutely doesn't make any sense whatsoever.
>
> The reason why I have two vars is that one checks if we care about the
> option, and the other is to see if it's enabled or not. We don't want
> the 'show merges' toggle to appear in view which don't handle the
> --no-merge option.
Perhaps I didn't made myself clear.
What I wanted to ask is to switch $has_merges to $no_merges, not to remove
$can_have_merges. Its a question of semantics of $has_merges, which do not
mean that action has (handles) merges.
This is of course the question of style, but I think this would make code
more maintainable.
Of course if you go %extra_options hash route this issue wouldn't matter.
--
Jakub Narebski
Poland
^ permalink raw reply
* Re: [PATCH] Let format-patch and rebase ignore trivial merges.
From: Bernhard R. Link @ 2009-12-17 21:48 UTC (permalink / raw)
To: git; +Cc: Johannes Sixt
In-Reply-To: <4B2A1895.2000803@viscovery.net>
* Johannes Sixt <j.sixt@viscovery.net> [091217 12:40]:
> > I want the default for format-patch changed.
>
> I do not see why format-patch would have to be changed. The case that you
> outline (a merge -s ours happened and you want to follow only one parent)
> is rare enough
While it is rare, the result format-patch currently produces is quite a
desaster without any need.
> and even more rarly will somebody want to apply format-patch to such a history.
> But I guess that you are actually not interested in format-patch per se,
> but rather in rebase (which uses format-patch).
I'm looking for a nice way to store the history of a patches in a Debian package.
Currently the best way is to use quilt and store the patches in git.
Topgit is quite overkill, git directly preserving history means no way to
export sane patches. And git rebase -i means losing history of previous
states and pullability.
An way to combine those is doing many trivial merges, but that kills
rebase and format-patch. (While the patch exporting for creating the
debian source packages could change to the right directory and give the
proper arguments, needing to remember the extra argument and teaching
anyone else involved how to call it to get what to sent to upstream
is annoying).
> I haven't looked at the code, but wouldn't it be matter of "if we do not
> have any pathspec, add '.'" *after* all options are parsed?
That's what I would say my patch is doing.
> git rev-list -- . works in a bare repository, too. If you hard-code "-- ."
> in the rev-list invocations in git-rebase[--interactive], then it cannot
> be said that this works "by chance" due to cd_to_toplevel.
It works in a bare repository. But it does not work when called from a
subdirectory of the working dir.
The easiest way I see to express generally
git rev-list --prune-tree $args
is
topdir=$(git rev-parse --show-cdup)
if test -z "$topdir" ; then
topdir=.
fi
set -- $args
while test $# -gt 0 ; do
if test "x$1" = "x--" ; then
break
fi
shift
done
if test $# -gt 1 ; then
git rev-list $args
elif test $# -eq 1 ; then
git rev-list $args $topdir
else
git rev-list $args -- $topdir
fi
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: Junio C Hamano @ 2009-12-17 22:44 UTC (permalink / raw)
To: Johannes Sixt; +Cc: Bernhard R. Link, git
In-Reply-To: <4B29106C.1040501@viscovery.net>
Johannes Sixt <j.sixt@viscovery.net> writes:
> Please do not set Mail-Followup-To (and use reply-to-all to keep the Cc list).
>
> Bernhard R. Link schrieb:
>> --prune-tree makes rev-list without paths equivalent to
>> "git rev-list $options -- ." (or .. or ../.. and so on,
>> if you are in some subdirectory).
>> This is the new default for format-patch and rebase
>
> Why do you need a new option when you can just add "-- ." to the rev-list
> invocation?
I agree that --[no-]prune-tree options are unnecessary. The patch to
builtin-log.c, the second hunk to revision.c, and revision.h would be
sufficient and all others should be dropped. Instead, the shell script
Porcelains can simply add "-- ." at the end of their rev-list invocations.
That way, we don't have to add anything to the documentation either.
But I wonder if it is an indication of something screwy in the workflow,
if a branch that merges others with "-s ours" is where the patches for
upstream submission is taken from with format-patch, or what is rebased
and internally gets its patches extracted with format-patch.
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.
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.
^ permalink raw reply
* [RFC PATCH] Record a single transaction for conflicting push operations
From: Catalin Marinas @ 2009-12-17 23:22 UTC (permalink / raw)
To: git; +Cc: Gustav Hållberg, Karl Wiberg
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 | 5 +++--
t/t3103-undo-hard.sh | 4 ++--
2 files changed, 5 insertions(+), 4 deletions(-)
diff --git a/stgit/lib/transaction.py b/stgit/lib/transaction.py
index 30a153b..fad5ab4 100644
--- a/stgit/lib/transaction.py
+++ b/stgit/lib/transaction.py
@@ -232,8 +232,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:
+ if not self.__conflicting_push:
+ write(self.__msg)
+ else:
self.__patches = _TransPatchMap(self.__stack)
self.__conflicting_push()
write(self.__msg + ' (CONFLICT)')
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))"
'
^ permalink raw reply related
* [PATCH] am: fix patch format detection for Thunderbird "Save As" emails
From: Stephen Boyd @ 2009-12-17 23:58 UTC (permalink / raw)
To: git; +Cc: Junio C Hamano
The patch detection wants to inspect all the headers of a rfc2822 message
and ensure that they look like header field names. The headers are always
separated from the message body with a blank line. When Thunderbird3 saves
the message the blank line separating the headers from the body includes a
CR. The patch detection is failing because a CRLF doesn't match /^$/. Fix
this by allowing a CR to exist on the separating line.
---
I'm not sure how portable \r in a sed invocation is. Perhaps just checking
that l1, l2, and l3 are rfc2822 header fields (or indented lines) is better
than trying to check all of the headers?
This seems related to
am fails to apply patches for files with CRLF lineendings
http://article.gmane.org/gmane.comp.version-control.git/135229
but seems necessary because check_patch_format() is called before any
splitting with mailsplit is done (where I assume the fix for the issue
will be done).
git-am.sh | 2 +-
t/t4150-am.sh | 15 +++++++++++++++
2 files changed, 16 insertions(+), 1 deletions(-)
diff --git a/git-am.sh b/git-am.sh
index 4838cdb..bb106b7 100755
--- a/git-am.sh
+++ b/git-am.sh
@@ -204,7 +204,7 @@ check_patch_format () {
# discarding the indented remainder of folded lines,
# and see if it looks like that they all begin with the
# header field names...
- sed -n -e '/^$/q' -e '/^[ ]/d' -e p "$1" |
+ sed -n -e '/^\r*$/q' -e '/^[ ]/d' -e p "$1" |
sane_egrep -v '^[!-9;-~]+:' >/dev/null ||
patch_format=mbox
fi
diff --git a/t/t4150-am.sh b/t/t4150-am.sh
index 8296605..578bc81 100755
--- a/t/t4150-am.sh
+++ b/t/t4150-am.sh
@@ -83,6 +83,12 @@ test_expect_success setup '
echo "X-Fake-Field: Line Three" &&
git format-patch --stdout first | sed -e "1d"
} > patch1.eml &&
+ {
+ echo "X-Fake-Field: Line One" &&
+ echo "X-Fake-Field: Line Two" &&
+ echo "X-Fake-Field: Line Three" &&
+ git format-patch --stdout first | sed -e "1d"
+ } | sed -e "s/$/\r/" > patch1-crlf.eml &&
sed -n -e "3,\$p" msg >file &&
git add file &&
test_tick &&
@@ -123,6 +129,15 @@ test_expect_success 'am applies patch e-mail not in a mbox' '
test "$(git rev-parse second^)" = "$(git rev-parse HEAD^)"
'
+test_expect_success 'am applies patch e-mail not in a mbox with CRLF' '
+ git checkout first &&
+ git am patch1-crlf.eml &&
+ ! test -d .git/rebase-apply &&
+ test -z "$(git diff second)" &&
+ test "$(git rev-parse second)" = "$(git rev-parse HEAD)" &&
+ test "$(git rev-parse second^)" = "$(git rev-parse HEAD^)"
+'
+
GIT_AUTHOR_NAME="Another Thor"
GIT_AUTHOR_EMAIL="a.thor@example.com"
GIT_COMMITTER_NAME="Co M Miter"
--
1.6.6.rc3.1.g8df51
^ permalink raw reply related
* [PATCH 1/2] api-strbuf.txt: fix typos and document launch_editor()
From: Stephen Boyd @ 2009-12-18 0:05 UTC (permalink / raw)
To: git; +Cc: Junio C Hamano
Signed-off-by: Stephen Boyd <bebarino@gmail.com>
---
Documentation/technical/api-strbuf.txt | 10 ++++++++--
1 files changed, 8 insertions(+), 2 deletions(-)
diff --git a/Documentation/technical/api-strbuf.txt b/Documentation/technical/api-strbuf.txt
index 7438149..a0e0f85 100644
--- a/Documentation/technical/api-strbuf.txt
+++ b/Documentation/technical/api-strbuf.txt
@@ -12,7 +12,7 @@ strbuf API actually relies on the string being free of NULs.
strbufs has some invariants that are very important to keep in mind:
-. The `buf` member is never NULL, so you it can be used in any usual C
+. The `buf` member is never NULL, so it can be used in any usual C
string operations safely. strbuf's _have_ to be initialized either by
`strbuf_init()` or by `= STRBUF_INIT` before the invariants, though.
+
@@ -55,7 +55,7 @@ Data structures
* `struct strbuf`
-This is string buffer structure. The `len` member can be used to
+This is the string buffer structure. The `len` member can be used to
determine the current length of the string, and `buf` member provides access to
the string itself.
@@ -253,3 +253,9 @@ same behaviour as well.
comments are considered contents to be removed or not.
`launch_editor`::
+
+ Launch the user preferred editor to edit a file and fill the buffer
+ with the file's contents upon the user completing their editing. The
+ third argument can be used to set the environment which the editor is
+ run in. If the buffer is NULL the editor is launched as usual but the
+ file's contents are not read into the buffer upon completion.
--
1.6.6.rc3.1.g8df51
^ permalink raw reply related
* [PATCH 2/2] technical-docs: document hash API
From: Stephen Boyd @ 2009-12-18 0:05 UTC (permalink / raw)
To: git; +Cc: Junio C Hamano
In-Reply-To: <1261094729-24128-1-git-send-email-bebarino@gmail.com>
Signed-off-by: Stephen Boyd <bebarino@gmail.com>
---
Documentation/technical/api-hash.txt | 50 ++++++++++++++++++++++++++++++++-
1 files changed, 48 insertions(+), 2 deletions(-)
diff --git a/Documentation/technical/api-hash.txt b/Documentation/technical/api-hash.txt
index c784d3e..e5061e0 100644
--- a/Documentation/technical/api-hash.txt
+++ b/Documentation/technical/api-hash.txt
@@ -1,6 +1,52 @@
hash API
========
-Talk about <hash.h>
+The hash API is a collection of simple hash table functions. Users are expected
+to implement their own hashing.
-(Linus)
+Data Structures
+---------------
+
+`struct hash_table`::
+
+ The hash table structure. The `array` member points to the hash table
+ entries. The `size` member counts the total number of valid and invalid
+ entries in the table. The `nr` member keeps track of the number of
+ valid entries.
+
+`struct hash_table_entry`::
+
+ An opaque structure representing an entry in the hash table. The `hash`
+ member is the entry's hash key and the `ptr` member is the entry's
+ value.
+
+Functions
+---------
+
+`init_hash`::
+
+ Initialize the hash table.
+
+`free_hash`::
+
+ Release memory associated with the hash table.
+
+`insert_hash`::
+
+ Insert a pointer into the hash table. If an entry with that hash
+ already exists, a pointer to the existing entry's value is returned.
+ Otherwise NULL is returned. This allows callers to implement
+ chaining, etc.
+
+`lookup_hash`::
+
+ Lookup an entry in the hash table. If an entry with that hash exists
+ the entry's value is returned. Otherwise NULL is returned.
+
+`for_each_hash`::
+
+ Call a function for each entry in the hash table. The function is
+ expected to take the entry's value as its only argument and return an
+ int. If the function returns a negative int the loop is aborted
+ immediately. Otherwise, the return value is accumulated and the sum
+ returned upon completion of the loop.
--
1.6.6.rc3.1.g8df51
^ permalink raw reply related
* Re: [RFC/PATCH] branch: new option --will-track
From: Junio C Hamano @ 2009-12-18 0:07 UTC (permalink / raw)
To: Dave Olszewski; +Cc: git
In-Reply-To: <1260956399-13802-1-git-send-email-cxreg@pobox.com>
Dave Olszewski <cxreg@pobox.com> writes:
> A common question from users creating branches in an environment where
> they intend to push the branch to a shared bare repository, and then
> later pull commits from upstream into the branch that they initially
> created, is how do they create the branch with this tracking info
> already set up.
We try reasonably hard not to force users to make a decision before it
gets absolutely necessary [*1*]. This option seems to only help users who
can decide upfront upon "git branch" time if the branch is worth sharing
with others and if the name of the branch will be the final one, and
people who forget to give this new option when they ran "git branch", or
those who changed their mind as to what the newly created branch with this
option should interact with, will still need to use "git config" to update
the settings.
Not very nice, not because it solves only a part of the problem, but
because it force users to decide early and not change their mind.
Instead perhaps we would want to add an option to retarget an existing
branch any time the user wants, e.g. "git branch --reconfigure"? Once we
have such an option, people who *can* decide upfront can use that feature
when creating a new branch at the same time.
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.
Having said all that, I am not very interested in topics on the mechanism
that updates or uses these variables, as I tend to avoid relying on them
myself, and instead teach people to spell them out (which seems to foster
better understanding of what goes on, with reduced user confusion).
Hence, I wouldn't claim I have thought things through in this area, and
the above is just me thinking aloud [*2*].
[Footnote]
*1* There are ample examples, ranging from detached HEAD (you do not have
to decide if the experiment you are going to do deserves a separate branch
to store the result permanently) to the separation between commit and push
(what you commit does not have to be perfect and you have a chance to tidy
them up before publishing).
*2* IOW don't take my "I am not interested" as "patches in this area have
little chance of getting applied."
^ permalink raw reply
* Re: [PATCH] am: fix patch format detection for Thunderbird "Save As" emails
From: Junio C Hamano @ 2009-12-18 0:15 UTC (permalink / raw)
To: Stephen Boyd; +Cc: git
In-Reply-To: <1261094299-22930-1-git-send-email-bebarino@gmail.com>
Stephen Boyd <bebarino@gmail.com> writes:
> I'm not sure how portable \r in a sed invocation is.
Not very portable.
Adding
tr -d '\015' <"$1" |
in front of the original "sed" invocation might be a better choice.
> but seems necessary because check_patch_format() is called before any
> splitting with mailsplit is done (where I assume the fix for the issue
> will be done).
I agree that the way non-native mbox format was bolted onto "am" is
somewhat unfortunate.
^ permalink raw reply
* Re: [PATCH 1/2] api-strbuf.txt: fix typos and document launch_editor()
From: Miklos Vajna @ 2009-12-18 0:42 UTC (permalink / raw)
To: Stephen Boyd; +Cc: git, Junio C Hamano
In-Reply-To: <1261094729-24128-1-git-send-email-bebarino@gmail.com>
[-- Attachment #1: Type: text/plain, Size: 342 bytes --]
On Thu, Dec 17, 2009 at 04:05:28PM -0800, Stephen Boyd <bebarino@gmail.com> wrote:
> Signed-off-by: Stephen Boyd <bebarino@gmail.com>
> ---
> Documentation/technical/api-strbuf.txt | 10 ++++++++--
> 1 files changed, 8 insertions(+), 2 deletions(-)
Thanks, I really should have read these sentences once again before
sending them in. ;-)
[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* Re: how can I push a sub-tree
From: Zhi Li @ 2009-12-18 0:55 UTC (permalink / raw)
To: Tay Ray Chuan; +Cc: git
In-Reply-To: <be6fef0d0912170214u433769e3ucf8180022aa72fb3@mail.gmail.com>
Hi,
Not sub-module, but sub-tree.
My problems are:
$ git remote add rack_remote git@github.com:schacon/rack.git
$ git fetch rack_remote
$ git branch rack_branch rack_remote/master
$ git read-tree --prefix=rack/ -u rack_branch
Now in master branch, I have a sub-tree rack. Later I modified
something in rack sub-tree. Then, how could I push my changes to
rack_remote?
Thanks
Zhi
On Thu, Dec 17, 2009 at 6:14 PM, Tay Ray Chuan <rctay89@gmail.com> wrote:
> Hi,
>
> On Thu, Dec 17, 2009 at 5:50 PM, Zhi Li <lizhi1215@gmail.com> wrote:
>> I tried to find a way to push a sub-tree. In section 6.7 of "Pro Git",
>> there's a way for pulling a git sub-tree. But I have not found the
>> opposite: push a git sub-tree. Can someone help me?
>
> I've not read the book, but perhaps you mean submodules?
>
> If so, refer to the part in the git submodule tutorial that describes
> how to make changes within a submodule on the GitWiki at
> http://git.or.cz/gitwiki/GitSubmoduleTutorial.
>
> --
> Cheers,
> Ray Chuan
>
^ permalink raw reply
* Re: how can I push a sub-tree
From: Zhi Li @ 2009-12-18 2:05 UTC (permalink / raw)
To: Tay Ray Chuan; +Cc: git
In-Reply-To: <2986b3940912171655t397f90b2tf28bac3555181292@mail.gmail.com>
Hi,
I found a way to do it, but I do not know whether it is the simplest.
In master branch, run "git cat-file -p" several times to find rack
sub-tree sha. Then check-out branch "rack_branch", run "git read-tree
sha". The sha is that one just get by "git cat-file -p". Finally,
git-commit, git-push...
Cheers,
Zhi
On Fri, Dec 18, 2009 at 8:55 AM, Zhi Li <lizhi1215@gmail.com> wrote:
> Hi,
>
> Not sub-module, but sub-tree.
>
> My problems are:
> $ git remote add rack_remote git@github.com:schacon/rack.git
> $ git fetch rack_remote
> $ git branch rack_branch rack_remote/master
> $ git read-tree --prefix=rack/ -u rack_branch
>
> Now in master branch, I have a sub-tree rack. Later I modified
> something in rack sub-tree. Then, how could I push my changes to
> rack_remote?
>
> Thanks
> Zhi
>
> On Thu, Dec 17, 2009 at 6:14 PM, Tay Ray Chuan <rctay89@gmail.com> wrote:
>> Hi,
>>
>> On Thu, Dec 17, 2009 at 5:50 PM, Zhi Li <lizhi1215@gmail.com> wrote:
>>> I tried to find a way to push a sub-tree. In section 6.7 of "Pro Git",
>>> there's a way for pulling a git sub-tree. But I have not found the
>>> opposite: push a git sub-tree. Can someone help me?
>>
>> I've not read the book, but perhaps you mean submodules?
>>
>> If so, refer to the part in the git submodule tutorial that describes
>> how to make changes within a submodule on the GitWiki at
>> http://git.or.cz/gitwiki/GitSubmoduleTutorial.
>>
>> --
>> Cheers,
>> Ray Chuan
>>
>
^ 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
* 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: 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: 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: 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: 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: 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: 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: [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: [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: 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] 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: [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
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