* Re: diff attribute ignored by show and log -p
From: Nanako Shiraishi @ 2009-12-17 13:17 UTC (permalink / raw)
To: Jay Soffian; +Cc: git
In-Reply-To: <76718490912162123r49f9bd90n8e032c144d0cdbac@mail.gmail.com>
Quoting Jay Soffian <jaysoffian@gmail.com>
>> But is apparently ignored by "git log -p" and "git show" which just
>> use internal diff. Is this behavior intentional?
>
> Ah, --ext-diff, and the reasoning behind requiring it for log/show is
> explained in 72909be.
The need to give --ext-diff is mentioned in 72909be (Add diff-option
--ext-diff, 2007-06-30) but its log message doesn't 'explain' why external
diff isn't used by default and you need to pass that extra option.
Probably --ext-diff should be the default?
--
Nanako Shiraishi
http://ivory.ap.teacup.com/nanako3/
^ permalink raw reply
* Re: [RFC/PATCH] gitweb: link to toggle 'no merges' option
From: Etienne Vallette d'Osia @ 2009-12-17 13:03 UTC (permalink / raw)
To: git
In-Reply-To: <1261040753-4859-1-git-send-email-giuseppe.bilotta@gmail.com>
Oh, this is exactly what I wanted for a long long time...
I hope this feature will be merged soon !
Le 12/17/2009 10:05 AM, Giuseppe Bilotta a écrit :
> In views that support --no-merges, introduce a link that toggles the
> option.
>
> Signed-off-by: Giuseppe Bilotta <giuseppe.bilotta@gmail.com>
>
> ---
> gitweb/gitweb.css | 11 +++++++++++
> gitweb/gitweb.perl | 14 ++++++++++++++
> 2 files changed, 25 insertions(+), 0 deletions(-)
>
> This is something I've been wanting for a while. There are a number of
> things that don't 'click' with this proof of concept, and I'm coming to
> the list to hear the opinion of users and developers on how to improve
> the thing.
>
> The patch is live at http://git.oblomov.eu/, an example affected page is
> http://git.oblomov.eu/git/shortlog
>
> Things that are sure to change:
>
> * the aesthetics and location of the toggle link (it shows on mousehover
> in the title). Other options I've considered are:
> + next to pagination (first | prev | next), either before or after
> the existing entries
> + on mouseover for the table section that refers to the (short)log;
> this would make it possible to put it summary view too, for example
>
> * if you toggle merge view when not on the first page, the reference
> (first) commit in the view is likely to change drastically, which
> causes confusion. I have not found a satisfactory solution for this,
> since the obvious way to 'lock' the view (start paginating from the
> current top commit) prevents prev/next navigation
>
> diff --git a/gitweb/gitweb.css b/gitweb/gitweb.css
> index 50067f2..0da6ef0 100644
> --- a/gitweb/gitweb.css
> +++ b/gitweb/gitweb.css
> @@ -572,3 +572,14 @@ span.match {
> div.binary {
> font-style: italic;
> }
> +
> +span.merge_toggle a {
> + font-size: 66%;
> + color: white !important;
> + font-weight: normal;
> + vertical-align: top;
> + text-decoration:none;
> + visibility: hidden;
> +}
> +
> +*:hover > span.merge_toggle a { visibility:visible }
> diff --git a/gitweb/gitweb.perl b/gitweb/gitweb.perl
> index 7e477af..a63f419 100755
> --- a/gitweb/gitweb.perl
> +++ b/gitweb/gitweb.perl
> @@ -3118,11 +3118,15 @@ sub git_header_html {
> my $status = shift || "200 OK";
> my $expires = shift;
>
> + my $can_have_merges = grep(/^$action$/, @{$allowed_options{'--no-merges'}});
> + my $has_merges = !grep(/^--no-merges$/, @extra_options);
> +
> my $title = "$site_name";
> if (defined $project) {
> $title .= " - " . to_utf8($project);
> if (defined $action) {
> $title .= "/$action";
> + $title .= " (no merges)" unless $has_merges;
> if (defined $file_name) {
> $title .= " - " . esc_path($file_name);
> if ($action eq "tree" && $file_name !~ m|/$|) {
> @@ -3235,6 +3239,16 @@ EOF
> print $cgi->a({-href => href(action=>"summary")}, esc_html($project));
> if (defined $action) {
> print " / $action";
> + if ($can_have_merges) {
> + print " <span class='merge_toggle'>";
> + if ($has_merges) {
> + printf('<a href="%s">hide merges</a>', href(-replay=>1, 'extra_options'=>('--no-merges', @extra_options)));
> + } else {
> + my @href_extra = grep(!/^--no-merges$/, @extra_options);
> + printf('<a href="%s">show merges</a>', href(-replay=>1, 'extra_options'=>@href_extra));
> + }
> + print "</span>";
> + }
> }
> print "\n";
> }
--
Etienne Vallette d'Osia
^ permalink raw reply
* Re: b5227d8 changes meaning of "ls-files -x 'pattern'"
From: Sitaram Chamarty @ 2009-12-17 12:54 UTC (permalink / raw)
To: Jeff King; +Cc: Git Mailing List
In-Reply-To: <20091214182420.GA31594@coredump.intra.peff.net>
On Mon, Dec 14, 2009 at 11:55 PM, Jeff King <peff@peff.net> wrote:
> On Mon, Dec 14, 2009 at 09:21:06PM +0530, Sitaram Chamarty wrote:
>> Before b5227d8, the following two commands would produce different
>> outputs (say on git.git):
>>
>> git ls-files
>> git ls-files -x '*.c'
>>
>> From b5227d8 onward, they produce the same output. The second command
>> no longer excludes *.c files.
>>
>> I was unable to understand the commit message completely but it sounds
>> like this was intentionally changed to do this.
> Yes, it was intentional. Excludes are about untracked files, not about
> restricting parts of the index. The point of the change was to bring
> "ls-files" in harmony with other parts of git. For example, prior to
OK; makes sense -- thanks for the explanation.
> However, for your use case, I can see the utility of an option to limit
> the output of ls-files for a particular invocation. It's just that "-x"
> is tied into the excludes mechanism, which doesn't do that.
>
> I would not be opposed to a patch to add an option that means "exclude
> these index entries from the output list." And for the sake of backwards
I rather doubt if my C skills extend that far these days; I'll figure out
other ways of doing this if I need it :-)
Thanks again,
Sitaram
^ permalink raw reply
* Re: potential null dereference
From: René Scharfe @ 2009-12-17 12:30 UTC (permalink / raw)
To: Jiri Slaby; +Cc: git
In-Reply-To: <4B2783DD.5060301@gmail.com>
Am 15.12.2009 13:41, schrieb Jiri Slaby:
> Hi,
>
> Stanse found the following error in unpack-trees.c:
> dereferencing NULL pointer here.[. * o src_index]
>
> int unpack_trees(unsigned len, struct tree_desc *t, struct
> unpack_trees_options *o)
> {
> int ret;
> static struct cache_entry *dfc;
> ...
> if (o->src_index) { <-- loc0
> o->result.timestamp.sec = o->src_index->timestamp.sec;
> o->result.timestamp.nsec = o->src_index->timestamp.nsec;
> }
> o->merge_size = len;
>
> if (!dfc)
> dfc = xcalloc(1, ((1 + (0) + 8) & ~7));
> o->df_conflict_entry = dfc;
>
> if (len) {
> ...
> }
>
> if (o->merge) {
> while (o->pos < o->src_index->cache_nr) { <-- here
>
> It triggers, because there is a test for o->src_index being NULL at
> loc0, but here, it is dereferenced without a check. Can this happen
> (e.g. does o->merge != NULL imply o->src_index != NULL)?
Running "git grep -w -B70 unpack_trees" and looking for "src_index"
using less' search command showed me that src_index is never NULL when
unpack_trees() is called.
> Further, there is a warning in log-tree.c:
> pointer always points to valid memory here, but checking for not
> NULL.[parents]
>
> static int log_tree_diff(struct rev_info *opt, struct commit *commit,
> struct log_info *log)
> {
> int showed_log;
> struct commit_list *parents;
> unsigned const char *sha1 = commit->object.sha1;
>
> if (!opt->diff && !((&opt->diffopt)->flags & (1 << 14)))
> return 0;
>
>
> parents = commit->parents;
> if (!parents) { <-- loc0
> if (opt->show_root_diff) {
> diff_root_tree_sha1(sha1, "", &opt->diffopt);
> log_tree_diff_flush(opt);
> }
> return !opt->loginfo; <-- loc1
> }
>
> if (parents && parents->next) { <-- here
>
> I.e. if parents was NULL at loc0, we escaped at loc1. But we check
> parents against NULL here again.
The check may be duplicate, but I suspect removing it won't change the
resulting object code -- the compiler should be smart enough to come to
the same conclusion.
Thanks,
René
^ permalink raw reply
* Re: [PATCH] Let format-patch and rebase ignore trivial merges.
From: Johannes Sixt @ 2009-12-17 11:40 UTC (permalink / raw)
To: git
In-Reply-To: <20091217093547.GA25451@pcpool00.mathematik.uni-freiburg.de>
Bernhard R. Link schrieb:
> * Johannes Sixt <j.sixt@viscovery.net> [091216 17:53]:
>> 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 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 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).
> For this I think it is easiest to add a new rev_info flag, as otherwise
> format-patch would need to duplicate parsing the rev_list options
> and either duplicate applying revs->prune_data or changing the argv for
> setup_revisions with some special casing of bare repository and non-bare
> repository cases.
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?
> And when there is that option, I think it is more robust to use that
> in merge -m and merge -i, as "-- ." only does the right thing by chance
> because both only work with a non-bare repository and have
> cd_to_toplevel.
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.
-- Hannes
^ permalink raw reply
* Re: Transplant branch from another repository
From: Jeenu V @ 2009-12-17 11:06 UTC (permalink / raw)
To: git
In-Reply-To: <E1NFVyv-0000EN-Qx@xyzzy.farnsworth.org>
On Tue, Dec 1, 2009 at 10:23 PM, Dale Farnsworth <dale@farnsworth.org> wrote:
> [...]
> Try "cd B; git fetch A a:b"
Thanks.
--
:J
^ permalink raw reply
* Re: how can I push a sub-tree
From: Tay Ray Chuan @ 2009-12-17 10:14 UTC (permalink / raw)
To: Zhi Li; +Cc: git
In-Reply-To: <2986b3940912170150o17118a07i8f91e785c08e2ac9@mail.gmail.com>
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
* how can I push a sub-tree
From: Zhi Li @ 2009-12-17 9:50 UTC (permalink / raw)
To: git
Hi,
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?
BTW, I appologize for not reading archives of this list.
Zhi
^ permalink raw reply
* Re: How do I show only log messages for commits on a specific branch?
From: David Roden @ 2009-12-17 9:20 UTC (permalink / raw)
To: git
In-Reply-To: <20091216101647.GB27373@bc-bd.org>
bd@bc-bd.org wrote:
> imagine this:
>
> --A--*--B (new)
> /
> *--X--*--Y (master)
>
> Now I'd like to list only log messages for A..B (X..B would be okay too).
>
> I know of
>
> git log master..new
>
> however then I need to remember that I branched new of master, and to be
> honest, sometimes I forget.
>
> So how do I:
>
> git please-tell-me-the-branch-I-started-this-branch-from new
>
> Thanks in advance,
I have had wonderful results using
git log new --not master
or
git log new ^master
This is using git 1.6.4.4 and this way of specifying commits is not
mentioned in the man page—it seems to work, though.
David
^ permalink raw reply
* Re: [PATCH] Let format-patch and rebase ignore trivial merges.
From: Bernhard R. Link @ 2009-12-17 9:35 UTC (permalink / raw)
To: git; +Cc: Johannes Sixt
In-Reply-To: <4B29106C.1040501@viscovery.net>
* Johannes Sixt <j.sixt@viscovery.net> [091216 17:53]:
> 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 want the default for format-patch changed.
For this I think it is easiest to add a new rev_info flag, as otherwise
format-patch would need to duplicate parsing the rev_list options
and either duplicate applying revs->prune_data or changing the argv for
setup_revisions with some special casing of bare repository and non-bare
repository cases.
And if there is that rev_info flag I think it is most logical to make
it accessible from the outside.
That also allows to revert to the old format-patch behaviour,
in case someone uses format-patch not to get some appliable patches but
some differently formated log or for something else I cannot imagine.
And when there is that option, I think it is more robust to use that
in merge -m and merge -i, as "-- ." only does the right thing by chance
because both only work with a non-bare repository and have
cd_to_toplevel.
Hochachtungsvoll,
Bernhard R. Link
--
Please do not CC me if git@vger.kernel.org also gets a copy.
^ permalink raw reply
* [RFC/PATCH] gitweb: link to toggle 'no merges' option
From: Giuseppe Bilotta @ 2009-12-17 9:05 UTC (permalink / raw)
To: git; +Cc: jnareb, Giuseppe Bilotta
In views that support --no-merges, introduce a link that toggles the
option.
Signed-off-by: Giuseppe Bilotta <giuseppe.bilotta@gmail.com>
---
gitweb/gitweb.css | 11 +++++++++++
gitweb/gitweb.perl | 14 ++++++++++++++
2 files changed, 25 insertions(+), 0 deletions(-)
This is something I've been wanting for a while. There are a number of
things that don't 'click' with this proof of concept, and I'm coming to
the list to hear the opinion of users and developers on how to improve
the thing.
The patch is live at http://git.oblomov.eu/, an example affected page is
http://git.oblomov.eu/git/shortlog
Things that are sure to change:
* the aesthetics and location of the toggle link (it shows on mousehover
in the title). Other options I've considered are:
+ next to pagination (first | prev | next), either before or after
the existing entries
+ on mouseover for the table section that refers to the (short)log;
this would make it possible to put it summary view too, for example
* if you toggle merge view when not on the first page, the reference
(first) commit in the view is likely to change drastically, which
causes confusion. I have not found a satisfactory solution for this,
since the obvious way to 'lock' the view (start paginating from the
current top commit) prevents prev/next navigation
diff --git a/gitweb/gitweb.css b/gitweb/gitweb.css
index 50067f2..0da6ef0 100644
--- a/gitweb/gitweb.css
+++ b/gitweb/gitweb.css
@@ -572,3 +572,14 @@ span.match {
div.binary {
font-style: italic;
}
+
+span.merge_toggle a {
+ font-size: 66%;
+ color: white !important;
+ font-weight: normal;
+ vertical-align: top;
+ text-decoration:none;
+ visibility: hidden;
+}
+
+*:hover > span.merge_toggle a { visibility:visible }
diff --git a/gitweb/gitweb.perl b/gitweb/gitweb.perl
index 7e477af..a63f419 100755
--- a/gitweb/gitweb.perl
+++ b/gitweb/gitweb.perl
@@ -3118,11 +3118,15 @@ sub git_header_html {
my $status = shift || "200 OK";
my $expires = shift;
+ my $can_have_merges = grep(/^$action$/, @{$allowed_options{'--no-merges'}});
+ my $has_merges = !grep(/^--no-merges$/, @extra_options);
+
my $title = "$site_name";
if (defined $project) {
$title .= " - " . to_utf8($project);
if (defined $action) {
$title .= "/$action";
+ $title .= " (no merges)" unless $has_merges;
if (defined $file_name) {
$title .= " - " . esc_path($file_name);
if ($action eq "tree" && $file_name !~ m|/$|) {
@@ -3235,6 +3239,16 @@ EOF
print $cgi->a({-href => href(action=>"summary")}, esc_html($project));
if (defined $action) {
print " / $action";
+ if ($can_have_merges) {
+ print " <span class='merge_toggle'>";
+ if ($has_merges) {
+ printf('<a href="%s">hide merges</a>', href(-replay=>1, 'extra_options'=>('--no-merges', @extra_options)));
+ } else {
+ my @href_extra = grep(!/^--no-merges$/, @extra_options);
+ printf('<a href="%s">show merges</a>', href(-replay=>1, 'extra_options'=>@href_extra));
+ }
+ print "</span>";
+ }
}
print "\n";
}
--
1.6.3.rc1.192.gdbfcb
^ permalink raw reply related
* first-parent equivalent for show-branch
From: Jeenu V @ 2009-12-17 7:31 UTC (permalink / raw)
To: git
Hi,
I wanted to know if there's a --first-parent equivalent for git
show-branch, where in it shows only the first -parents in a vertical
column. I feel it'd make the display less cluttered.
As of now, I think, a column shows commits in a merged branch, and
even parents of that branch, which makes reading bit uneasy. What
would be preferable instead to show only the first parent in a column
- something like the output of
git log --graph --pretty=oneline --abbrev-commit --first-parent --all
| sed 's#|\|/##g'
along with the header and naming strings of show-branch.
Thanks
--
:J
^ permalink raw reply
* Re: core.autocrlf & Cygwin - files incorrectly flagged as modified
From: Robin Rosenberg @ 2009-12-17 7:00 UTC (permalink / raw)
To: David Antliff; +Cc: git
In-Reply-To: <loom.20091215T225528-115@post.gmane.org>
tisdag 15 december 2009 23:24:15 skrev David Antliff:
> I approached the Cygwin mailing list about this problem, and the package
> maintainer suggested I ask here as well, in case someone can shed some
> light on this.
>
> I am using git-1.6.4.2 (as part of Cygwin-1.7 beta) and I've observed some
> behaviour that seems wrong to me.
>
> When we deployed git on Cygwin, we decided to set core.autocrlf=true, as
> many of our users are working with DOS/Windows files (CRLF endings). Some
> users are using Linux and working on the same code. I'm not actually sure
> why we chose to use this setting - there's a lot of conflicting advice
> around. I think the final decision was made so that kdiff3 would operate
> correctly. However we did go to lengths to ensure that everyone is using
> the same configuration setting.
>
> 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.
-- robin
^ permalink raw reply
* Re: git-reflog 70 minutes at 100% cpu and counting
From: Nicolas Pitre @ 2009-12-17 5:38 UTC (permalink / raw)
To: Eric Paris; +Cc: Jeff King, git
In-Reply-To: <1261003041.2788.142.camel@localhost>
On Wed, 16 Dec 2009, Eric Paris wrote:
> On Wed, 2009-12-16 at 16:06 -0500, Nicolas Pitre wrote:
> > On Wed, 16 Dec 2009, Eric Paris wrote:
> >
> > > On Tue, 2009-12-15 at 22:03 -0500, Nicolas Pitre wrote:
> > > > On Mon, 14 Dec 2009, Eric Paris wrote:
> > > >
> > > > > The alternative repo is slowing pushing up to that same location. That
> > > > > tar is 855838982, so just a tad bit smaller.
> > > >
> > > > It doesn't appear to be complete yet, and not progressing either.
> > >
> > > The alternative repo is now available (but the original is down)
> > >
> > > I tried to run git gc --aggressive last night while I slept and got this
> > > as output, maybe it helps point to a solution/problem? The git reflog
> > > portion ran for 5 hours and 36 minutes and appears to have finished.
> >
> > Yes. I was able to reproduce your issue. And because of the *horrible*
> > repository packing, the reflog expiration process is taking ages when
> > determining object reachability at a rate of one reflog entry every 2
> > seconds or so. With 4214 entries for the fsnotify-syscall branch, and
> > 1352 entries for the fsnotify branch, this already takes up asignificant
> > portion of the actual run time. I'm sure if your repository was
> > properly packed this would take less than a minute.
>
> I'm guessing this is a result of stgit.? These branches really should
> be just a branch from a tag (which exists in kernel-1) and about 30-50
> patches linearly applied on top. I don't know how I get that many
> objects. I'm guessing many/most of them are crap that should be able to
> be cleaned/deleted entirely as the rebasing/pushing/poping/updating that
> stgit does under the covers should have rendered them pointless. Not
> really sure when/how that should/could have happened.
Possible. Commit operations (including patch applications) always
create loose objects because this is fast, with the expectation that
they get collected in a pack later.
> Should I be running git-gc every night?
This is certainly a good thing to do given your heavy stgit usage.
> > Now, repacking doesn't work because...
> >
> > > $ git gc --aggressive
> > > error: Could not read d936ff8a7b0841b51ddf96afa24a30b016824cb2
> > > error: Could not read 29b6c2fb1390b4fd350a5ecc78f1156fc5d91e9f
>
> /me is pretty git dumb, but is there some way to figure out the parents
> or children of these? I just trolled through all of my directories
> doing git show and didn't get any hits. I guess I'll just clean up and
> start over....
Moving the reflog data aside (i.e. mv .git/logs .git/logs.bak) it seems
that d936ff8 is not referenced anymore.
I found the other one as follows:
First I tried
$ git rev-list --all --objects
This resulted in:
[...]
4f7911b0b0dbd187131a109cf00161a0c6a9d727 arch/x86
ea868257c1eabc31e0ea7941efa42b543978b3fa arch/x86/kvm
a0c11ead723956c667172a9f3fb6787684fe7ff5 arch/x86/kvm/paging_tmpl.h
b556b6aad8b1aacfecb1dd4a56dbd389674687b5 arch/x86/kvm/x86.c
68a9733ae3315d7e2bfec2037dfeee4db8a6f6a1 drivers
error: Could not read 29b6c2fb1390b4fd350a5ecc78f1156fc5d91e9f
fatal: bad tree object 29b6c2fb1390b4fd350a5ecc78f1156fc5d91e9f
Because of the way objects are enumerated, we can be pretty sure that
the bad tree object is referenced by the tree object 68a9733a
corresponding to drivers/. Let's verify that:
$ git ls-tree 68a9733a
100644 blob 00cf9553f74065291612b0971337f79995933a06 Kconfig
100644 blob c1bf41737936ab00be4a87563a0bb0638074785d Makefile
040000 tree d4e847de9bf2450842936582ea7cc6778413825b accessibility
040000 tree 29b6c2fb1390b4fd350a5ecc78f1156fc5d91e9f acpi
[...]
Yep, we found it there. So the missing tree object corresponds to
drivers/acpi/. So to find the latest commit to which this particular
tree object is referenced by, we just need to look at the same rev-list
output above (piped into less is handy here) and scroll up until an
object with no name is found. This would usually be the first root tree
object referencing the named objects that follow. Here I get aafb68eb.
To be sure, let's list it so to confirm it really contains a reference
to the 68a9733a drivers tree:
$ git ls-tree aafb68eb
[...]
040000 tree 68a9733ae3315d7e2bfec2037dfeee4db8a6f6a1 drivers
[...]
So yes, we've got the right root tree object. Now finding the
corresponding commit should be easy:
$ git log --all --pretty=raw
Then within less, a search for aafb68eb brings us to this:
commit 2e765e9c87a337131aad3014f9a7e5e878c7d0a0
tree aafb68eb84f96c9ab5697c6e8d10d5006d1e7209
parent a2c2de42295b3ac29758f454a7072338e5555ca3
author Eric Paris <eparis@redhat.com> 1237233261 -0400
committer Eric Paris <eparis@redhat.com> 1237233261 -0400
refresh 64d34c511b1125d9efd2926e683e019f15dec5b4
So this is referenced by a commit that you made on the 1237233261th
second since January 1, 1970 i.e. 2009-03-16 19:54:21 +0000 which is
quite a while ago. Or given the nature of the commit log, this is
probably some stgit branch.
Note that the missing tree didn't necessarily appear with that commit.
Because of the recency ordering from rev-list, all we can say is that
this is the last commit on that particular branch to reference that
tree, but it might have been introduced in the repository way before
that point in time.
Now let's try to find out what branch(es) actually link(s) to this
commit:
$ git branch -a --contains 2e765e9c
This comes empty. This is because 'git branch' looks only in the
refs/heads/ and refs/remotes namespace (or only one of them without -a).
Scripting something around 'git for-each-ref' and 'git merge-base' could
be done, such as:
TARGET=2e765e9c87a337131aad3014f9a7e5e878c7d0a0
git for-each-ref refs/* |
while read sha1 type ref; do
if [ "$(git merge-base $sha1 $TARGET)" = "$TARGET" ]; then
echo "referenced by $type $ref"
fi
done
But this is slow, for the same reason as 'git reflog expire' above. But
letting it run for a while should give you at least one answer.
> > Of course, usage of alternates is recommended _only_ with repositories
> > that are stable, i.e. don't ever add repositories to
> > .git/objects/info/alternates if those repositories are rewinded/rebased
> > and/or branches in them are deleted/replaced. That could be a reason
> > why some objects are now missing from the repository using alternates.
>
> So I'm not sure how I did things wrong. my kernel-1 has those bunch of
> remotes. The linux-next remote, like I said, basically rebases to
> linus' tree, then merges 150 random branches. It tags that tree every
> day and I pull those tags. So I would never expect any objects from
> those remote trees to ever disappear.
Right.
> Now I created branches in kernel-1 and I certainly have done lots of
> things like so
>
> git checkout -b testing remotes/linux-next/master
> [edit]
> git commit -a
> git checkout -b testing1 remotes/linux-next/master
> git branch -D testing
>
> My assumption though was that this wouldn't ever affect my other
> repositories. My other repository branches always started by checking
> out a branch with remotes/*/* as the base.
>
> My understanding was that I would only run into problems if I used
> something on a branch I created myself in the alternatives repo in other
> repos (and I didn't remove remotes)
>
> I guess it's not impossible to believe that at some point in time i
> would have exported patches to and mbox from kernel-1 and applied them
> to kernel-2 or vice versa. I guess this would end up with the same
> objects, right? Then if I deleted the branch in kernel-1 I would have
> problems in kernel-2?
Eventually, yes. After a while the auto repack in kernel2 would notice
that some objects are in kernel1 already and purge them from kernel2.
And if those objects were part of a deleted branch then kernel1 would
get rid of those objects too once the reflog with a reference to that
deleted branch expires. The unsuspecting kernel2 repo then gets broken.
> I guess I'll rebuild my setup
>
> new kernel-alt has just the remotes, and my kernel-1,2,3 all alt to it
> I'll never have local branches in my kernel-alt
> I'll run git-gc every night
> I'll hope to never have problem again.
>
> Sound good?
Yes. And make sure not to fetch rebasing repositories, such as
linux-next, into kernel-alt without keeping a tag for each fetched state
otherwise you'll accumulate unreferenced objects which the other
repositories might rely upon.
Nicolas
^ permalink raw reply
* Re: diff attribute ignored by show and log -p
From: Jay Soffian @ 2009-12-17 5:23 UTC (permalink / raw)
To: git
In-Reply-To: <76718490912162046k36e2a275gaf7672b38c7a63e4@mail.gmail.com>
On Wed, Dec 16, 2009 at 11:46 PM, Jay Soffian <jaysoffian@gmail.com> wrote:
> % cat .git/info/attributes
> *.xib diff=xibdiff
> % cat $(git config diff.xibdiff.command)
> #!/bin/sh
> trap "rm -f \"$2.tmp\" \"$5.tmp\"" 0 1 2 3 15
> ibtool --all "$2" > "$2".tmp
> ibtool --all "$5" > "$5".tmp
> colordiff -u "$2.tmp" "$5.tmp"
>
> Works great for things like:
>
> % git diff <commit1> <commit2> -- /path/to/*.xib
>
> But is apparently ignored by "git log -p" and "git show" which just
> use internal diff. Is this behavior intentional?
Ah, --ext-diff, and the reasoning behind requiring it for log/show is
explained in 72909be.
j.
^ permalink raw reply
* diff attribute ignored by show and log -p
From: Jay Soffian @ 2009-12-17 4:46 UTC (permalink / raw)
To: git
% cat .git/info/attributes
*.xib diff=xibdiff
% cat $(git config diff.xibdiff.command)
#!/bin/sh
trap "rm -f \"$2.tmp\" \"$5.tmp\"" 0 1 2 3 15
ibtool --all "$2" > "$2".tmp
ibtool --all "$5" > "$5".tmp
colordiff -u "$2.tmp" "$5.tmp"
Works great for things like:
% git diff <commit1> <commit2> -- /path/to/*.xib
But is apparently ignored by "git log -p" and "git show" which just
use internal diff. Is this behavior intentional?
j.
^ permalink raw reply
* Re: core.autocrlf & Cygwin - files incorrectly flagged as modified
From: David Antliff @ 2009-12-17 2:01 UTC (permalink / raw)
To: git
In-Reply-To: <be6fef0d0912161705q1ef23634rccdc170d69cf9484@mail.gmail.com>
Tay Ray Chuan writes:
> On Wed, Dec 16, 2009 at 6:24 AM, David Antliff wrote:
> > I suspect what is happening is that the line conversion routine in git
> > might be
> > stripping trailing whitespace, as well as converting the line endings. This
> > operation is not properly accounted for in the reverse direction, and the
> > file is flagged as modified.
>
> I am not a Git expert, but could it be your editor on Windows?
Hi Ray, thank you for responding.
This observation is made immediately after the clone, before any editor (or any
other program) even touches the files. If you can imagine doing a fresh clone
and then immediately doing 'git-status' and seeing modified files, you'd have a
pretty good idea of what I'm seeing. Git itself has somehow marked the files as
modified on check-out. I am fairly certain it's related to trailing whitespace
on one or more lines within the affected files.
If there's no trailing whitespace, git converts the file to CRLF on checkout
and shows no modification (since it knows to convert back when referring to
local repository).
> > Also, as cloned files are converted to DOS-line-endings, by default Cygwins
> > bash cannot run any scripts as they have the wrong line endings. I have to
> > set the 'permanent' bash variable SHELLOPTS to include 'igncr' before bash
> > scripts can run. Perhaps this is wrong and git on Cygwin (with binary
> > mounts) should be converting to UNIX line endings instead?
>
> Again, IANAGE, but according to the manual, this should be expected,
> because Git, when writing to the filesystem, converts LF to CRLF:
>
> If true, makes git convert CRLF at the end of lines in text files to
> LF when reading from the filesystem, and convert in reverse when
> writing to the filesystem.
Yes, perhaps the advice to use autocrlf=true on Cygwin (in binary mount mode,
since in text mode git doesn't work *at all*) is misplaced since Cygwin is not
expecting CRLF endings in that mode. Apparently it's required for apps like
Kdiff3 however... all so confusing really...
The inability to run bash scripts straight out of git when using autocrlf=true
is almost enough to suggest to me that this mode really shouldn't be used in
Cygwin.
> > At one point I tried switching off core.autocrlf for myself but this
> > caused a lot of conflicts due to mismatched line-endings. It seems to me
> > that if we want to switch to this, *everyone* has to do it at once.
>
> Just make this conversion a commit, and depending on your project's
> workflow, push/pull it.
Yes, I think that's how it has to be done. Unfortunately I have 20+ projects
each with many active branches. The entire conversion is possible but it's
going to take a while... :)
> Although the whole file will be marked as changed, you can always
> double-check that only whitespace changes have been made by running
> git-diff with --ignore-space-at-eol or -b.
That's a helpful option - thank you.
I'd be quite interested to know if people are successfully using git in Cygwin
with autocrlf=true, and if so how they are working around these modified-files
and bash-compatibility problems.
Also, is anyone using autocrlf=false in Cygwin successfully?
Thanks again for your reply.
-- David.
^ permalink raw reply
* Re: Git on QNX
From: Sean Boudreau @ 2009-12-17 1:37 UTC (permalink / raw)
To: Tarmigan; +Cc: git, Alex Riesen, mkraai
In-Reply-To: <905315640912161703u3920178cm93851ddc8480ac8@mail.gmail.com>
On Wed, Dec 16, 2009 at 05:03:16PM -0800, Tarmigan wrote:
> On Wed, Dec 16, 2009 at 2:38 PM, Sean Boudreau <seanb@qnx.com> wrote:
> > What version of qnx is this on. <strings.h> is
> > now brought in by <string.h> and the lock() /
> > unlock() prototypes have been removed from <unistd.h>
> > AS OF 6.4.1 (the current release).
>
> Ahh, that's nice. At a client's request, I have been working on QNX 6.3.2.
>
> I just installed 6.4.1 in another VM, and it's a bit different. The
> common way to handle binary packages (iconv and perl) seems to have
> changed to pkg_add so the PATHs I had set might not make sense
> anymore.
>
> Also the weird failing test at t0000.42 seems to be fixed. Funny.
>
> As I might be the only person to run git on 6.3.2 instead of a more
> modern QNX, it might make sense for me to just submit the minimum
> patches needed for QNX 6.4.1 and then carry the strings.h,
> getpagesize, and lock() changes for 6.3.2 on my own.
That's why I spoke up :)
>
> > There's a package for git-4.3.20 here that also has a work around
> > for the SA_RESTART issue.
>
> I think that might be a different program that also used to be named
> "git". I think it has now been renamed gnuit.
You're probably right, try this one:
ftp://ftp.netbsd.org/pub/pkgsrc/packages/QNX/i386/6.4.1_head_20090724/All/scmgit-base-1.6.2.5.tgz
-seanb
^ permalink raw reply
* Re: core.autocrlf & Cygwin - files incorrectly flagged as modified
From: Tay Ray Chuan @ 2009-12-17 1:05 UTC (permalink / raw)
To: David Antliff; +Cc: git
In-Reply-To: <loom.20091215T225528-115@post.gmane.org>
Hi,
On Wed, Dec 16, 2009 at 6:24 AM, David Antliff <david.antliff@gmail.com> wrote:
> I suspect what is happening is that the line conversion routine in git might be
> stripping trailing whitespace, as well as converting the line endings. This
> operation is not properly accounted for in the reverse direction, and the file
> is flagged as modified.
I am not a Git expert, but could it be your editor on Windows?
Not just stripping whitespace; it might be setting the eol to LF
(instead of CRLF) when saving the file.
> Also, as cloned files are converted to DOS-line-endings, by default Cygwin's
> bash cannot run any scripts as they have the wrong line endings. I have to set
> the 'permanent' bash variable SHELLOPTS to include 'igncr' before bash scripts
> can run. Perhaps this is wrong and git on Cygwin (with binary mounts) should be
> converting to UNIX line endings instead?
Again, IANAGE, but according to the manual, this should be expected,
because Git, when writing to the filesystem, converts LF to CRLF:
If true, makes git convert CRLF at the end of lines in text files to
LF when reading from the filesystem, and convert in reverse when
writing to the filesystem.
> At one point I tried switching off core.autocrlf for myself but this caused a
> lot of conflicts due to mismatched line-endings. It seems to me that if we want
> to switch to this, *everyone* has to do it at once.
Just make this conversion a commit, and depending on your project's
workflow, push/pull it.
Although the whole file will be marked as changed, you can always
double-check that only whitespace changes have been made by running
git-diff with --ignore-space-at-eol or -b.
--
Cheers,
Ray Chuan
^ permalink raw reply
* Re: Git on QNX
From: Tarmigan @ 2009-12-17 1:03 UTC (permalink / raw)
To: git; +Cc: Alex Riesen, Sean Boudreau, mkraai
In-Reply-To: <loom.20091216T233122-388@post.gmane.org>
On Wed, Dec 16, 2009 at 2:38 PM, Sean Boudreau <seanb@qnx.com> wrote:
> What version of qnx is this on. <strings.h> is
> now brought in by <string.h> and the lock() /
> unlock() prototypes have been removed from <unistd.h>
> AS OF 6.4.1 (the current release).
Ahh, that's nice. At a client's request, I have been working on QNX 6.3.2.
I just installed 6.4.1 in another VM, and it's a bit different. The
common way to handle binary packages (iconv and perl) seems to have
changed to pkg_add so the PATHs I had set might not make sense
anymore.
Also the weird failing test at t0000.42 seems to be fixed. Funny.
As I might be the only person to run git on 6.3.2 instead of a more
modern QNX, it might make sense for me to just submit the minimum
patches needed for QNX 6.4.1 and then carry the strings.h,
getpagesize, and lock() changes for 6.3.2 on my own.
> There's a package for git-4.3.20 here that also has a work around
> for the SA_RESTART issue.
I think that might be a different program that also used to be named
"git". I think it has now been renamed gnuit.
Thanks,
Tarmigan
^ permalink raw reply
* [ANNOUNCE] Git 1.6.6.rc3
From: Junio C Hamano @ 2009-12-17 0:30 UTC (permalink / raw)
To: git
A release candidate Git 1.6.6.rc3 is available at the usual places
for testing:
http://www.kernel.org/pub/software/scm/git/
git-1.6.6.rc3.tar.{gz,bz2} (source tarball)
git-htmldocs-1.6.6.rc3.tar.{gz,bz2} (preformatted docs)
git-manpages-1.6.6.rc3.tar.{gz,bz2} (preformatted docs)
The RPM binary packages for a few architectures are found in:
testing/git-*-1.6.6.rc3-1.fc11.$arch.rpm (RPM)
Things have really calmed down and hopefully we can give the final release
as holiday present to everybody in time ;-)
----------------------------------------------------------------
Changes since v1.6.6-rc2 are as follows:
Björn Gustavsson (1):
bash: Support new 'git fetch' options
Jeff King (1):
ignore unknown color configuration
Johannes Sixt (1):
help.autocorrect: do not run a command if the command given is junk
Junio C Hamano (7):
Remove post-upload-hook
Fix archive format with -- on the command line
Git 1.6.5.6
Update Release Notes for 1.6.6 to remove old bugfixes
worktree: don't segfault with an absolute pathspec without a work tree
Git 1.6.5.7
Git 1.6.6-rc3
Nanako Shiraishi (1):
Illustrate "filter" attribute with an example
^ permalink raw reply
* [ANNOUNCE] Git 1.6.5.7
From: Junio C Hamano @ 2009-12-17 0:29 UTC (permalink / raw)
To: git
The latest maintenance release Git 1.6.5.7 is available at the
usual places:
http://www.kernel.org/pub/software/scm/git/
git-1.6.5.7.tar.{gz,bz2} (source tarball)
git-htmldocs-1.6.5.7.tar.{gz,bz2} (preformatted docs)
git-manpages-1.6.5.7.tar.{gz,bz2} (preformatted docs)
The RPM binary packages for a few architectures are found in:
RPMS/$arch/git-*-1.6.5.7-1.fc11.$arch.rpm (RPM)
Nothing spectacular to see here, but as I was tagging 1.6.6-rc3 today, I
wanted to push out fixes accumulated on the maintenance branch in a tagged
release. Everything in this release is also in 1.6.6-rc3.
----------------------------------------------------------------
Changes since v1.6.5.6 are as follows:
Jeff King (1):
ignore unknown color configuration
Johannes Sixt (1):
help.autocorrect: do not run a command if the command given is junk
Junio C Hamano (2):
worktree: don't segfault with an absolute pathspec without a work tree
Git 1.6.5.7
Nanako Shiraishi (1):
Illustrate "filter" attribute with an example
^ permalink raw reply
* Re: New Proposal (simple) for Metadata in Git Commits: git-meta
From: Johan Herland @ 2009-12-17 0:26 UTC (permalink / raw)
To: Sam Elliott; +Cc: git, Shawn O. Pearce
In-Reply-To: <20091216163036.GE18319@spearce.org>
On Wednesday 16 December 2009, Shawn O. Pearce wrote:
> Sam Elliott <sam@lenary.co.uk> wrote:
> > On 15 Dec 2009, at 23:05, Shawn O. Pearce wrote:
> >> If you dropped the --git-meta-- tags above, JGit would happily
> >> recognize the awesome: and Github: tags, but it might need a bit
> >> more work to recognize the nested user: tag. Also, you'd be able
> >> to use git-meta on the git and Linux kernel repositories to pull
> >> out and work with Signed-off-by, Acked-by, etc.
> >
> > I'm not entirely sure about this approach. The current implementation
> > also works with PGP-signed tags, where the information is not
> > necessarily going to be at the bottom of the message when i use `git-
> > cat-file -p`. I think it shouldn't be too hard to also have git-meta
> > read any YAML-like data just before the signing message.
>
> Ah, good point. But as you point out, it should be simple enough
> to detect a PGP signature on the bottom and just clip that off the
> end, and then perform the YAML-like data parsing on the footer.
I agree with Shawn's point that it should be possible to do this without
embedding it in custom ---tags---.
I would even try to parse the _entire_ commit message, and then discard
everything that didn't match the "<word>: <free-form value>" format (with
possible continuation lines). Even though this will generate some false
positives (probably non-sensical "key: value" pairs), I don't see this as a
major problem , since most users of this functionality are looking for a
small set of specific keywords (which are even more unlikely to turn up as
false positives)
In future versions of Git, you might also want to check for YAML-like data
in the notes object corresponding to the commit in question (see git-notes
in v1.6.6 for more details on the new notes feature). This would allow users
to add/edit such metadata after the commit was made, without having to
rewrite the commit itself.
Have fun! :)
...Johan
--
Johan Herland, <johan@herland.net>
www.herland.net
^ permalink raw reply
* Re: How do I show only log messages for commits on a specific branch?
From: Miklos Vajna @ 2009-12-17 0:20 UTC (permalink / raw)
To: Elijah Newren; +Cc: bd, git
In-Reply-To: <51419b2c0912161559x4de94464pe06df2845dbe3b78@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 1174 bytes --]
On Wed, Dec 16, 2009 at 04:59:54PM -0700, Elijah Newren <newren@gmail.com> wrote:
> Did you try it with a 'new' branch in your repository that started at
> the beginning of history rather than at some commit? "git log new"
> and "git log new@{30.years.ago}..new" are not the same for me with
> git-1.6.5.5:
>
> $ git init repo
> $ cd repo
> $ echo content> foo && git add foo && git commit -mone foo
> $ echo more content >> foo && git commit -mtwo foo
> $ git checkout -b new master~1
> $ echo stuff >> foo && git commit -mthree foo
> $ git log new@{30.years.ago}..new
Aah, thanks. Then you can just avoid the warning using
git log $(git reflog show new|sed -n 's/ .*//;$ p')..new
> Are you sure? I'm more inclined to believe he'd like to see all the
> commits that have been added to the "new" branch since he created it
> (which may be the same as what you say, but not necessarily). Of
> course, neither my assumption or yours match what he actually asked
> for (though I think what he asked for isn't possible and is merely an
> means to the end he really wants).
No, I'm not sure about what he thought, but I hope he will clarify. :)
[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* Re: How do I show only log messages for commits on a specific branch?
From: Elijah Newren @ 2009-12-17 0:04 UTC (permalink / raw)
To: Santi Béjar; +Cc: Miklos Vajna, bd, git
In-Reply-To: <adf1fd3d0912161558u36d9674eid36e3042d181ed8f@mail.gmail.com>
On Wed, Dec 16, 2009 at 4:58 PM, Santi Béjar <santi@agolina.net> wrote:
> git log new --not $(git for-each-ref --format='%(refname)'
> 'refs/heads/*' | grep -v refs/heads/new)
How did I miss '--not' as a git log option? Thanks for pointing it out!
^ 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