* Re: [PATCH] Fix update-index --refresh for submodules if stat(2) returns st_size 0
From: Johannes Schindelin @ 2008-07-21 23:26 UTC (permalink / raw)
To: Alex Riesen; +Cc: git, Junio C Hamano
In-Reply-To: <20080721194322.GA4013@blimp.local>
Hi,
On Mon, 21 Jul 2008, Alex Riesen wrote:
> Johannes Schindelin, Mon, Jul 21, 2008 20:20:43 +0200:
>
> > Alex wrote:
> >
> > > Can MSys folks please try it? I noticed it when the test
> > > t2103-update-index-ignore-missing.sh (the 5th case) started failing.
> >
> > Since M$' documentation says "This member does not have a meaning for
> > directories." about the member nFileSizeLow of
> > WIN32_FILE_ATTRIBUTE_DATA which we use to implement a sane "lstat()",
> > I think this bug hits MinGW (not MSys) as well.
>
> Could you, just for completeness, try?
No, I cannot. I have no Windows machine.
Ciao,
Dscho
^ permalink raw reply
* Re: Bizarre missing changes (git bug?)
From: Linus Torvalds @ 2008-07-21 22:57 UTC (permalink / raw)
To: Tim Harper; +Cc: Git Mailing List
In-Reply-To: <8C23FB54-A28E-4294-ABEA-A5766200768B@gmail.com>
[ git channel added back to cc, because this is an interesting question in
itself ]
On Mon, 21 Jul 2008, Tim Harper wrote:
>
> Another false impression I had is a merge conflict resolution would always be
> displayed in a merge commit. However, after running over the merges again, if
> you pick the right or left, discarding the one or the other, nothing is shown
> in "git log -p" for the merge commit. Is there a way to see what was chosen
> for a conflict resolution? Seeing that in the merge commit would have made
> things a little more clear.
The default behavior for showing merges is "--cc", which is the condensed
version that only shows _actual_ conflicts that got resolved differently
from either of the sources.
But note how this is an "after-the-fact" determination: it doesn't look
whether the merge _did_ conflict (because doing that would require
re-running the whole merge!), but it looks whether the end _result_ is
different from either side.
So you can easily have a merge that conflicts - but then you resolve that
merge by picking just one side of the merge as the result. And in that
case the "--cc" diff will not show anything at all - because the end
result did not conflict with the sources of the merge!
So "--cc" only shows output if: the merge itself actually changed
something from _all_ parents. This can happen if:
- there was a non-trivial conflict, and the end result really was a
"mixture" of the two. The result wasn't just a select of either side,
it was a combination of the two.
This is obviously one "common" case for a merge resolution.
But it's equally common that when you merge something you just say "Ok,
that other side did it better, I'll just pick that version". And in
that case, "--cc" won't show anything at all, because it's not really a
conflict any more once you've done that choice.
- There can also be an "evil merge" that actually adds/changes/deletes
code that didn't exist AT ALL in either side. And --cc is very much
designed to show that.
This is actually not always a bad thing (despite the name "evil
merge"), because it happens regularly that one branch had changed some
infrastructure setup or other, and the other branch had added a totally
new use of that infrastructure - and as a result the _merge_ needs to
add that setup code that didn't exist in either of the branches (in one
because the use wasn't there, in the other because the setup wasn't
needed).
Anyway, this all means that yes, "--cc" _often_ shows conflicts, but not
always - exactly because it doesn't show the ones that the merge had
committed as a non-conflict.
If you actually want to see the _real_ conflicts that happened as the
merge was done, you do have to re-do it.
Linus
^ permalink raw reply
* Re: Bizarre missing changes (git bug?)
From: Tim Harper @ 2008-07-21 22:55 UTC (permalink / raw)
To: git
In-Reply-To: <E301C92A-8794-4E90-9C85-D73B94A2648C@gmail.com>
On Jul 21, 2008, at 4:53 PM, Tim Harper wrote:
>
> On Jul 21, 2008, at 2:37 PM, Linus Torvalds wrote:
>
>>
>>
>> On Mon, 21 Jul 2008, Tim Harper wrote:
>>>
>>> Anyone run into this before? Any idea what might have caused it?
>>> We're a bit
>>> concerned about this because if we don't know how to avoid this,
>>> we no longer
>>> can feel certain that when something is committed, it will make it
>>> out in our
>>> release.
>>
>> Read up on '--full-history'.
>>
>> By default, git simplifies the history for logs that have path
>> simplification: only walking down the side of a merge that all the
>> data
>> came from (ie the unchanged side). So it only leaves merges around if
>> there was changes from _all_ parents.
>>
>> So without --full-history, if any parent matches the state, it just
>> removes the merge and picks that parent that contained all the state.
>> Obviously, any changes to that file can be sufficiently explained by
>> walking just that limited history, because they must have changed in
>> _that_ history too!
>>
>> That default behaviour leads to a *much* simpler history, and is
>> usually
>> what you want - it avoids unnecessary duplication when something was
>> changed trivially the same way in both branches - 'git log' will
>> just pick
>> the first branch.
>>
>
> Agreed - this was an insightful decision.
>
>> So, if you had two (or more) commits that both fixed the same bug in
>> different branches, and thus both branches actually ended up with
>> the same
>> contents, it does mean that "git log <filename>" will only show
>> _one_ of
>> the fixes.
>>
>> In this case, it apparently showed another version than the one you
>> were
>> looking for.
>>
>> Linus
>
> Git has made me feel stupid on various occasions. This is no
> exception as the problem turned out being in the chair, not in git.
>
> After running through git bisect, and ran the command Alex Riesen
> suggested, it made it pretty crystal clear where things went wrong.
> It turned out to be a bad merge that was from a conflict related to
> white-space issues, and the wrong resolution was chosen (a
> resolution that also consequently turned out to be no change).
>
> Another false impression I had is a merge conflict resolution would
> always be displayed in a merge commit. However, after running over
> the merges again, if you pick the right or left, discarding the one
> or the other, nothing is shown in "git log -p" for the merge
> commit. Is there a way to see what was chosen for a conflict
> resolution? Seeing that in the merge commit would have made things
> a little more clear.
>
Actually, I found it:
http://www.kernel.org/pub/software/scm/git/docs/git-log.html
"git log -p -c" gives me what I was looking for
Tim
> Thank you for articulating git branch's behavior - all is clear as
> mud now :)
>
> Tim
^ permalink raw reply
* Re: Bizarre missing changes (git bug?)
From: Tim Harper @ 2008-07-21 22:53 UTC (permalink / raw)
To: git
In-Reply-To: <alpine.LFD.1.10.0807211331390.31863@woody.linux-foundation.org>
On Jul 21, 2008, at 2:37 PM, Linus Torvalds wrote:
>
>
> On Mon, 21 Jul 2008, Tim Harper wrote:
>>
>> Anyone run into this before? Any idea what might have caused it?
>> We're a bit
>> concerned about this because if we don't know how to avoid this, we
>> no longer
>> can feel certain that when something is committed, it will make it
>> out in our
>> release.
>
> Read up on '--full-history'.
>
> By default, git simplifies the history for logs that have path
> simplification: only walking down the side of a merge that all the
> data
> came from (ie the unchanged side). So it only leaves merges around if
> there was changes from _all_ parents.
>
> So without --full-history, if any parent matches the state, it just
> removes the merge and picks that parent that contained all the state.
> Obviously, any changes to that file can be sufficiently explained by
> walking just that limited history, because they must have changed in
> _that_ history too!
>
> That default behaviour leads to a *much* simpler history, and is
> usually
> what you want - it avoids unnecessary duplication when something was
> changed trivially the same way in both branches - 'git log' will
> just pick
> the first branch.
>
Agreed - this was an insightful decision.
> So, if you had two (or more) commits that both fixed the same bug in
> different branches, and thus both branches actually ended up with
> the same
> contents, it does mean that "git log <filename>" will only show
> _one_ of
> the fixes.
>
> In this case, it apparently showed another version than the one you
> were
> looking for.
>
> Linus
Git has made me feel stupid on various occasions. This is no
exception as the problem turned out being in the chair, not in git.
After running through git bisect, and ran the command Alex Riesen
suggested, it made it pretty crystal clear where things went wrong.
It turned out to be a bad merge that was from a conflict related to
white-space issues, and the wrong resolution was chosen (a resolution
that also consequently turned out to be no change).
Another false impression I had is a merge conflict resolution would
always be displayed in a merge commit. However, after running over
the merges again, if you pick the right or left, discarding the one or
the other, nothing is shown in "git log -p" for the merge commit. Is
there a way to see what was chosen for a conflict resolution? Seeing
that in the merge commit would have made things a little more clear.
Thank you for articulating git branch's behavior - all is clear as mud
now :)
Tim
^ permalink raw reply
* Re: [StGit PATCH] Test that we can add a new file to a non-topmost patch with refresh -p
From: Catalin Marinas @ 2008-07-21 22:01 UTC (permalink / raw)
To: Karl Hasselström; +Cc: git, Jon Smirl
In-Reply-To: <20080718180109.GA14825@diana.vm.bytemark.co.uk>
2008/7/18 Karl Hasselström <kha@treskal.com>:
> On 2008-07-18 19:03:06 +0200, Karl Hasselström wrote:
>
>> We currently can't -- this is bug 12038, found by Jon Smirl. See
>>
>> https://gna.org/bugs/index.php?12038
>
> OK, the problem is that to pop the patches on top of the one we are to
> refresh, we call pop_patch(keep = True). This in turn calls
> git.switch(keep = True), which resets the index (but is careful to not
> touch the worktree).
Yes.
> I'm not quite sure how to fix this in a simple way -- the code simply
> assumes that the index contains nothing of interest. And since I
> already have a rewrite of refresh that handles this and a handful of
> other cases that the old code does not, I'm kind of disinclined to
> undertake a larger restructuring of the code.
>
> Catalin, what do you think?
I don't think we should spend time on fixing the current code as you
already have a new implementation. Maybe we could add a simple test
and refuse refreshing other than the topmost patch in case of files
added to the index.
--
Catalin
^ permalink raw reply
* Re: [PATCH] builtin-merge: missing structure bzero.
From: Pierre Habouzit @ 2008-07-21 21:49 UTC (permalink / raw)
To: Miklos Vajna, git, gitster
In-Reply-To: <20080721181850.GA2718@artemis.madism.org>
[-- Attachment #1: Type: text/plain, Size: 4378 bytes --]
On Mon, Jul 21, 2008 at 06:18:50PM +0000, Pierre Habouzit wrote:
> On Mon, Jul 21, 2008 at 05:21:19PM +0000, Miklos Vajna wrote:
> > On Mon, Jul 21, 2008 at 07:03:50PM +0200, Pierre Habouzit <madcoder@debian.org> wrote:
> > > This cause segfaults when replacing a directory with a submodule in a
> > > fast-forward.
> >
> > Thanks.
> >
> > > +test_expect_failure 'Replace a directory with a submodule, with a file conflict' '
> > > + mkdir test &&
> > > + cd test &&
> > > + : create our repository with a sub/a file &&
> > > + git init &&
> > > + mkdir sub && echo a > sub/a &&
> > > + git add sub && git commit -asm"initial repository" &&
> > > + : save this state in a new branch &&
> > > + git branch temp &&
> > > + : then replace sub with it &&
> > > + git rm -rf sub &&
> > > + git submodule add -- "$(pwd)/../submodule/.git/" sub &&
> > > + git commit -asm "replace sub/ with a submodule" &&
> > > + : then try to update the "temp" branch &&
> > > + git checkout temp &&
> >
> > It seems this one fails. I guess this will be a problem in the low-level
> > merge code (read-tree -m) and not in builtin-merge.
>
> Yeah, I saw that afterwards, the error was misleading (as it tells
> about some "merge" issue), but when I tried to debug it, it was indeed
> in git checkout. The easiest way to reproduce, is to have a submodule
> that replace a file that was previously versionned (which is something
> that will happen in real life when you take out a subdirectory of a
> project to make it live into a submodule) and that you then git checkout
> HEAD~1.
Actually, the issue is quite obvious when thinking. At git-checkout
time, git doesn't recurse (yet) into submodules, hence when we checkout
'temp' that is basically master~1 that basically does that:
"sub/" is a submodule, and gets replaced by sub/ a tree with "a" in it,
and the submodule _also_ has "a". As submodules are ignored silently, it
just:
(1) forgets about the submodule at once, leaving all the submodules
files into the wild, and sub/a (that was in the submodule) is now
an untracked file.
(2) tries to checkout sub/a and sees a file currently untracked and
barfs.
So it boils down to the fact that git-checkout does nothing with
submodules. I really think we should address that, it's a major issue
wrt submodules and usability.
I believe we should for now require that all submodules are clean for
checkout to be able to work, and then we have those cases:
* submodule -> directory: ignore any file that is either versionned or
ignored in the submodule wrt checkout issues. If no issue arises
with untracked non ignored files in the submodule, then basically:
(1) in the submodule: git ls-files | xargs rm -f ; rm -rf .git
(2) proceed with the checkout.
* submodule -> blob: refuse to proceed if there is any untracked non
ignored file in the submodule, else just rm -rf it, and proceed.
* submodule h1 -> h2: if "git checkout h2" will work in the submodule,
then we have no problem with the checkout, and do proceed. Though,
if the checkout isn't possible because "h2" is unknown, then instead
of a "cannot read h2" error, one should suggest the user to update
its submodules (he probably lacks some objects and needs to fetch).
Special case: if the submodule isn't initialized, proceed and warn
about the submodule being uninitialized.
* {blob,directory} -> submodule already work properly, though
suggesting the user to run "git submodule update -i" when we *know*
we have uninitialized submodules because of a checkout is a good
idea.
Note that uninitialized submodules are not special cases for the two
first cases, because uninitialized submodules are not different from a
directory with possibly untracked files in it. An uninitialized
submodule probably need to be dealt with as if it's clean from many
places actually.
The issue is that I tried to grok upack-trees.c, but the code is quite
dense, and how to hack this efficiently still eludes me, because I don't
really get the big picture enough yet.
--
·O· Pierre Habouzit
··O madcoder@debian.org
OOO http://www.madism.org
[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* [PATCH 1/2] git-svn: teach dcommit about svn auto-props
From: Brad King @ 2008-07-21 21:40 UTC (permalink / raw)
To: git; +Cc: Eric Wong
[-- Attachment #1: Type: text/plain, Size: 1041 bytes --]
Subversion repositories often require files to have properties such as
svn:mime-type and svn:eol-style set when they are added. Users
typically set these properties automatically using the SVN auto-props
feature with 'svn add'. This commit teaches dcommit to look at the user
SVN configuration and apply matching auto-props entries for files added
by a diff as it is applied to the SVN remote. A later commit will make
this feature optional.
Signed-off-by: Brad King <brad.king@kitware.com>
---
This change honors the user's enable-auto-props svn config setting.
The next patch will configure this at the git level and add the
corresponding documentation.
I've tested this by hand on an real SVN repo that checks for mime type.
Unfortunately I'm unable to run the git-svn test suite because I get
the error reported here:
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=486527
(even without my changes).
git-svn.perl | 47 +++++++++++++++++++++++++++++++++++++++++++++++
1 files changed, 47 insertions(+), 0 deletions(-)
[-- Attachment #2: 31da8bfbf702861ed89b7c6fd307c99ebbd01165.diff --]
[-- Type: text/x-patch, Size: 2201 bytes --]
diff --git a/git-svn.perl b/git-svn.perl
index 2e0e552..1975b62 100755
--- a/git-svn.perl
+++ b/git-svn.perl
@@ -3340,6 +3340,7 @@ sub new {
$self->{rm} = { };
$self->{path_prefix} = length $self->{svn_path} ?
"$self->{svn_path}/" : '';
+ $self->{config} = $opts->{config};
return $self;
}
@@ -3528,6 +3529,51 @@ sub ensure_path {
return $bat->{$c};
}
+# Subroutine to convert a globbing pattern to a regular expression.
+# From perl cookbook.
+sub glob2pat {
+ my $globstr = shift;
+ my %patmap = ('*' => '.*', '?' => '.', '[' => '[', ']' => ']');
+ $globstr =~ s{(.)} { $patmap{$1} || "\Q$1" }ge;
+ return '^' . $globstr . '$';
+}
+
+sub check_autoprop {
+ my ($self, $pattern, $properties, $file, $fbat) = @_;
+ # Convert the globbing pattern to a regular expression.
+ my $regex = glob2pat($pattern);
+ # Check if the pattern matches the file name.
+ if($file =~ m/($regex)/) {
+ # Parse the list of properties to set.
+ my @props = split(/;/, $properties);
+ foreach my $prop (@props) {
+ # Parse 'name=value' syntax and set the property.
+ if ($prop =~ /([^=]+)=(.*)/) {
+ $self->change_file_prop($fbat, $1, $2);
+ }
+ }
+ }
+}
+
+sub apply_autoprops {
+ my ($self, $file, $fbat) = @_;
+ my $conf_t = ${$self->{config}}{'config'};
+ no warnings 'once';
+ # Check [miscellany]/enable-auto-props in svn configuration.
+ if (SVN::_Core::svn_config_get_bool($conf_t,
+ $SVN::_Core::SVN_CONFIG_SECTION_MISCELLANY,
+ $SVN::_Core::SVN_CONFIG_OPTION_ENABLE_AUTO_PROPS,
+ 0)) {
+ # Auto-props are enabled. Enumerate them to look for matches.
+ my $callback = sub {
+ $self->check_autoprop($_[0], $_[1], $file, $fbat);
+ };
+ SVN::_Core::svn_config_enumerate($conf_t,
+ $SVN::_Core::SVN_CONFIG_SECTION_AUTO_PROPS,
+ $callback);
+ }
+}
+
sub A {
my ($self, $m) = @_;
my ($dir, $file) = split_path($m->{file_b});
@@ -3535,6 +3581,7 @@ sub A {
my $fbat = $self->add_file($self->repo_path($m->{file_b}), $pbat,
undef, -1);
print "\tA\t$m->{file_b}\n" unless $::_q;
+ $self->apply_autoprops($file, $fbat);
$self->chg_file($fbat, $m);
$self->close_file($fbat,undef,$self->{pool});
}
^ permalink raw reply related
* [PATCH 2/2] git-svn: make use of svn auto-props optional
From: Brad King @ 2008-07-21 21:40 UTC (permalink / raw)
To: git; +Cc: Eric Wong
[-- Attachment #1: Type: text/plain, Size: 775 bytes --]
In order to preserve existing default behavior, dcommit should use svn
auto-props only if instructed to do so. This commit creates a config
option 'svn.autoprops' to enable the behavior.
Signed-off-by: Brad King <brad.king@kitware.com>
---
Topics for discussion:
Should we instead call this option 'useAutoProps' or some other name?
Does a 'svn-remote.<name>.autoprops' version make sense?
(I'll need help with this one because I'm learning perl just for this).
Should we still honor/require the svn config option 'enable-auto-props',
or treat that as an option specific to 'svn add' and let this git-specific
one take over here?
Documentation/git-svn.txt | 7 +++++++
git-svn.perl | 7 +++++--
2 files changed, 12 insertions(+), 2 deletions(-)
[-- Attachment #2: 4c068ff135558651ac51de5771815b40e63a2c07.diff --]
[-- Type: text/x-patch, Size: 1985 bytes --]
diff --git a/Documentation/git-svn.txt b/Documentation/git-svn.txt
index e7c0f1c..300a9e0 100644
--- a/Documentation/git-svn.txt
+++ b/Documentation/git-svn.txt
@@ -448,6 +448,13 @@ svn-remote.<name>.rewriteRoot::
the repository with a public http:// or svn:// URL in the
metadata so users of it will see the public URL.
+svn.autoprops::
+
+ Tells 'dcommit' to use '[auto-props]' entries from the user
+ SVN configuration to set properties on added files. The
+ 'enable-auto-props' option in the user SVN configuration must
+ also be enabled.
+
--
Since the noMetadata, rewriteRoot, useSvnsyncProps and useSvmProps
diff --git a/git-svn.perl b/git-svn.perl
index 1975b62..9e8799d 100755
--- a/git-svn.perl
+++ b/git-svn.perl
@@ -73,6 +73,7 @@ my %remote_opts = ( 'username=s' => \$Git::SVN::Prompt::_username,
'no-auth-cache' => \$Git::SVN::Prompt::_no_auth_cache );
my %fc_opts = ( 'follow-parent|follow!' => \$Git::SVN::_follow_parent,
'authors-file|A=s' => \$_authors,
+ 'autoprops' => \$Git::SVN::_auto_props,
'repack:i' => \$Git::SVN::_repack,
'noMetadata' => \$Git::SVN::_no_metadata,
'useSvmProps' => \$Git::SVN::_use_svm_props,
@@ -1273,7 +1274,7 @@ use constant rev_map_fmt => 'NH40';
use vars qw/$default_repo_id $default_ref_id $_no_metadata $_follow_parent
$_repack $_repack_flags $_use_svm_props $_head
$_use_svnsync_props $no_reuse_existing $_minimize_url
- $_use_log_author $_add_author_from/;
+ $_use_log_author $_add_author_from $_auto_props/;
use Carp qw/croak/;
use File::Path qw/mkpath/;
use File::Copy qw/copy/;
@@ -3581,7 +3582,9 @@ sub A {
my $fbat = $self->add_file($self->repo_path($m->{file_b}), $pbat,
undef, -1);
print "\tA\t$m->{file_b}\n" unless $::_q;
- $self->apply_autoprops($file, $fbat);
+ if ($Git::SVN::_auto_props) {
+ $self->apply_autoprops($file, $fbat);
+ }
$self->chg_file($fbat, $m);
$self->close_file($fbat,undef,$self->{pool});
}
^ permalink raw reply related
* Re: [PATCH] checkout without arguments does not make sense
From: Miklos Vajna @ 2008-07-21 21:44 UTC (permalink / raw)
To: Avery Pennarun; +Cc: Johannes Sixt, Junio C Hamano, git
In-Reply-To: <32541b130807211436h77bf5985xa61ed7b4941c47dc@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 787 bytes --]
On Mon, Jul 21, 2008 at 05:36:59PM -0400, Avery Pennarun <apenwarr@gmail.com> wrote:
> Eek, are we using "checkout" to get status information now? If that
> goes wrong, you could be blowing away your locally modified data by
> accident.
Hm, let's say I have uncommitted changes to Makefile, then I'll get:
$ git checkout
M Makefile
Your branch is ahead of the tracked remote branch 'junio/next' by 1 commit.
But it will not drop my local changes.
> I think "git status" reports this information in recent versions, doesn't it?
Right. But that shows other infos as well, for example the untracked
files, etc. So there are cases when git checkout is just better.
However, you are right about it may not be the best habit from my side
to use git checkout to get that info. ;-)
[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* Re: [PATCH] checkout without arguments does not make sense
From: Avery Pennarun @ 2008-07-21 21:36 UTC (permalink / raw)
To: Miklos Vajna; +Cc: Johannes Sixt, Junio C Hamano, git
In-Reply-To: <20080721204955.GI32057@genesis.frugalware.org>
On 7/21/08, Miklos Vajna <vmiklos@frugalware.org> wrote:
> Actually I think it _is_ useful, like this:
>
> $ git checkout
> Your branch is ahead of the tracked remote branch 'junio/next' by 1 commit.
>
> How will it be possible to get that info easily after your patch?
Eek, are we using "checkout" to get status information now? If that
goes wrong, you could be blowing away your locally modified data by
accident.
I think "git status" reports this information in recent versions, doesn't it?
Thanks,
Avery
^ permalink raw reply
* [PATCH] Allow pager of diff command be enabled/disabled
From: Alex Riesen @ 2008-07-21 21:28 UTC (permalink / raw)
To: git; +Cc: Junio C Hamano
See for example, status and show commands. Besides,
Documentation/RelNotes-1.6.0.txt mentions that pager.<cmd>
can be used to enable/disable paging behavior per command.
Signed-off-by: Alex Riesen <raa.lkml@gmail.com>
---
Also, really export check_pager_config, which just got another call
site.
builtin-diff.c | 3 ++-
builtin.h | 1 +
2 files changed, 3 insertions(+), 1 deletions(-)
diff --git a/builtin-diff.c b/builtin-diff.c
index faaa85a..7ffea97 100644
--- a/builtin-diff.c
+++ b/builtin-diff.c
@@ -296,7 +296,8 @@ int cmd_diff(int argc, const char **argv, const char *prefix)
* If the user asked for our exit code then don't start a
* pager or we would end up reporting its exit code instead.
*/
- if (!DIFF_OPT_TST(&rev.diffopt, EXIT_WITH_STATUS))
+ if (!DIFF_OPT_TST(&rev.diffopt, EXIT_WITH_STATUS) &&
+ check_pager_config("diff") != 0)
setup_pager();
/*
diff --git a/builtin.h b/builtin.h
index 0e605d4..f3502d3 100644
--- a/builtin.h
+++ b/builtin.h
@@ -18,6 +18,7 @@ extern int fmt_merge_msg(int merge_summary, struct strbuf *in,
struct strbuf *out);
extern int commit_tree(const char *msg, unsigned char *tree,
struct commit_list *parents, unsigned char *ret);
+extern int check_pager_config(const char *cmd);
extern int cmd_add(int argc, const char **argv, const char *prefix);
extern int cmd_annotate(int argc, const char **argv, const char *prefix);
--
1.6.0.rc0.24.g1329.dirty
^ permalink raw reply related
* Re: [PATCH] checkout without arguments does not make sense
From: Johannes Sixt @ 2008-07-21 21:11 UTC (permalink / raw)
To: Miklos Vajna; +Cc: git, Junio C Hamano
In-Reply-To: <20080721204955.GI32057@genesis.frugalware.org>
On Montag, 21. Juli 2008, Miklos Vajna wrote:
> Actually I think it _is_ useful, like this:
>
> $ git checkout
> Your branch is ahead of the tracked remote branch 'junio/next' by 1 commit.
Ah, yes, indeed; that makes sense. Scrap the patch.
-- Hannes
^ permalink raw reply
* Re: [PATCH] Documentation/git-ls-tree.txt: Add a caveat about prefixing pathspec
From: Petr Baudis @ 2008-07-21 21:04 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7v1w1nvf7q.fsf@gitster.siamese.dyndns.org>
On Mon, Jul 21, 2008 at 01:00:57AM -0700, Junio C Hamano wrote:
> Petr Baudis <pasky@suse.cz> writes:
>
> > +Note that within a subdirectory of the working copy, 'git ls-tree'
> > +will automatically prepend the subdirectory prefix to the specified
> > +paths and assume just the prefix was specified in case no paths were
> > +given --- no matter what the tree object is!
>
> Don't be negative upfront. Explain why this is a good thing first.
>
> ... were given. This is useful when you are deep in a
> subdirectory and want to inspect the list of files in an arbitrary
> commit. E.g.
>
> $ cd some/deep/path
> $ git ls-tree --name-only -r HEAD~20
>
> will list the files in some/deep/path (i.e. where you are) 20
> commits ago, just like running "/bin/ls" there will give you the
> list of files you have right now.
Frankly, I think this is overdoing it. I'm all for being positive, but
it is obvious why this is good thing when you inspect a root tree and
there's no need to be too wordy about it - it should be enough to
acknowledge this later by the "as expected" as I note below.
The documentation should be detailed and complete, but not too chatty,
or it gets too hard to read again.
> > +Thus, within a subdirectory, 'git ls-tree' behaves as expected
> > +only when run on a root tree object (e.g. with a 'HEAD' tree-ish,
> > +but not anymore when passed 'HEAD:Documentation' instead).
> > +
> > +
> > OPTIONS
> > -------
> > <tree-ish>::
--
Petr "Pasky" Baudis
As in certain cults it is possible to kill a process if you know
its true name. -- Ken Thompson and Dennis M. Ritchie
^ permalink raw reply
* Re: [PATCH] checkout without arguments does not make sense
From: Miklos Vajna @ 2008-07-21 20:49 UTC (permalink / raw)
To: Johannes Sixt; +Cc: Junio C Hamano, git
In-Reply-To: <200807212206.32818.johannes.sixt@telecom.at>
[-- Attachment #1: Type: text/plain, Size: 665 bytes --]
On Mon, Jul 21, 2008 at 10:06:32PM +0200, Johannes Sixt <johannes.sixt@telecom.at> wrote:
> @@ -487,7 +487,8 @@ int cmd_checkout(int argc, const char **argv, const char *prefix)
> }
>
> return checkout_paths(source_tree, pathspec);
> - }
> + } else if (!new.name && !opts.new_branch)
> + usage_with_options(checkout_usage, options);
>
> if (new.name && !new.commit) {
> die("Cannot switch branch to a non-commit.");
Actually I think it _is_ useful, like this:
$ git checkout
Your branch is ahead of the tracked remote branch 'junio/next' by 1 commit.
How will it be possible to get that info easily after your patch?
Thanks.
[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* Re: Bizarre missing changes (git bug?)
From: Alex Riesen @ 2008-07-21 20:42 UTC (permalink / raw)
To: Tim Harper; +Cc: git
In-Reply-To: <8502DF7C-5303-49E8-8C67-F837343E2F0C@gmail.com>
Tim Harper, Mon, Jul 21, 2008 22:26:06 +0200:
> I ran into a strange issue that has left me scratching my head.
>
> I have a commit in my history, that does indeed show up in my branch,
> named "sprint"
>
...
>
> Any help or clues VERY much apperciated. Thanks!
>
Try looking at the history graph in gitk
$ gitk --all -- app/controllers/events_controller.rb spec/fixtures/factors.yml
It usually shows the history in a very understandable way and
it can help to detect when the histories have diverged.
^ permalink raw reply
* Re: Bizarre missing changes (git bug?)
From: Linus Torvalds @ 2008-07-21 20:37 UTC (permalink / raw)
To: Tim Harper; +Cc: git
In-Reply-To: <8502DF7C-5303-49E8-8C67-F837343E2F0C@gmail.com>
On Mon, 21 Jul 2008, Tim Harper wrote:
>
> Anyone run into this before? Any idea what might have caused it? We're a bit
> concerned about this because if we don't know how to avoid this, we no longer
> can feel certain that when something is committed, it will make it out in our
> release.
Read up on '--full-history'.
By default, git simplifies the history for logs that have path
simplification: only walking down the side of a merge that all the data
came from (ie the unchanged side). So it only leaves merges around if
there was changes from _all_ parents.
So without --full-history, if any parent matches the state, it just
removes the merge and picks that parent that contained all the state.
Obviously, any changes to that file can be sufficiently explained by
walking just that limited history, because they must have changed in
_that_ history too!
That default behaviour leads to a *much* simpler history, and is usually
what you want - it avoids unnecessary duplication when something was
changed trivially the same way in both branches - 'git log' will just pick
the first branch.
So, if you had two (or more) commits that both fixed the same bug in
different branches, and thus both branches actually ended up with the same
contents, it does mean that "git log <filename>" will only show _one_ of
the fixes.
In this case, it apparently showed another version than the one you were
looking for.
Linus
^ permalink raw reply
* Bizarre missing changes (git bug?)
From: Tim Harper @ 2008-07-21 20:26 UTC (permalink / raw)
To: git
I ran into a strange issue that has left me scratching my head.
I have a commit in my history, that does indeed show up in my branch,
named "sprint"
The following commands yield as follows (I've modified the output
slightly to conceal any potentially proprietary information):
#########################
git log HEAD -p
commit 8f9effffb0dcdacd514085608e8923fbbe00ff29
Author: Name Concealed <email@email.com>
Date: Mon Jul 14 16:19:18 2008 -0600
commit message....
diff --git a/app/controllers/events_controller.rb b/app/controllers/
events_controller.rb
index 6905ba4..a0b7dfc 100644
--- a/app/controllers/events_controller.rb
+++ b/app/controllers/events_controller.rb
@@ -238,36 +238,37 @@ class EventsController < ApplicationController
}.freeze
RUBY_STUFF = {
- changes...
- changes...
- changes...
+ changes...
+ changes...
+ changes...
diff --git a/spec/fixtures/factors.yml b/spec/fixtures/factors.yml
index 186ed73..3c76e86 100755
--- a/spec/fixtures/factors.yml
+++ b/spec/fixtures/factors.yml
@@ -2483,4 +2483,54 @@ some_branch:
file:
contents:
- reliable_on:
\ No newline at end of file
+ data:
+fixture_name:
+ id: 115
+ file: Event
+ contents: behavior
#########################
git log spec/fixtures/factors.yml
... commit 8f9effff is not listed anywhere
#########################
git log app/controllers/events_controller.rb
... commit 8f9effff shows up
#########################
git branch --contains 8f9effff
some-task-branch
* sprint
The changes in 8f9effff for app/controllers/events_controller.rb show
up in the working copy, however the changes for spec/fixtures/
factors.yml are nowhere to be seen. It's as if the history of that
particular file diverged somehow, but I know that can't be true since
git doesn't track files.
Anyone run into this before? Any idea what might have caused it?
We're a bit concerned about this because if we don't know how to avoid
this, we no longer can feel certain that when something is committed,
it will make it out in our release.
Any help or clues VERY much apperciated. Thanks!
Tim
^ permalink raw reply related
* [GSoC] Git popularity on GSoC
From: Sverre Rabbelier @ 2008-07-21 20:07 UTC (permalink / raw)
To: Git Mailinglist
Heya,
There was a poll on the GSoC students mailing list: "What is your
favorite revision control system?". From the 100 responses so far, my
vote topled the balance in favor of Git ;). As a statistics junkie I
think it's fun to see that the only real competition among GSoC
students is Subversion, which has about as much market share as Git.
(Surely the 1 vote for TFS/SourceSafe must have been a misclick.) At
least nobody can claim we're the underdog RCS anymore!
Git 40% (40)
Subversion 39% (39)
Mercurial 7% (7)
CVS 6% (6)
Bazaar 5% (5)
Perforce 1% (1)
Monotone 1% (1)
Microsoft TFS/SourceSafe 1% (1)
Other 0% (0)
BitKeeper 0% (0)
--
Cheers,
Sverre Rabbelier
^ permalink raw reply
* [PATCH] checkout without arguments does not make sense
From: Johannes Sixt @ 2008-07-21 20:06 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
Signed-off-by: Johannes Sixt <johannes.sixt@telecom.at>
---
builtin-checkout.c | 3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/builtin-checkout.c b/builtin-checkout.c
index fbd5105..669be0e 100644
--- a/builtin-checkout.c
+++ b/builtin-checkout.c
@@ -487,7 +487,8 @@ int cmd_checkout(int argc, const char **argv, const char *prefix)
}
return checkout_paths(source_tree, pathspec);
- }
+ } else if (!new.name && !opts.new_branch)
+ usage_with_options(checkout_usage, options);
if (new.name && !new.commit) {
die("Cannot switch branch to a non-commit.");
--
1.6.0.rc0.18.g6aef2
^ permalink raw reply related
* Re: Git Branding Overview, Re: Git.or.cz Experimental Design
From: Matt Graham @ 2008-07-21 20:03 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Michael J Gruber, git
In-Reply-To: <alpine.DEB.1.00.0807211218470.8986@racer>
On Mon, Jul 21, 2008 at 7:20 AM, Johannes Schindelin
<Johannes.Schindelin@gmx.de> wrote:
> Hi,
>
> On Mon, 21 Jul 2008, Michael J Gruber wrote:
>
>> Martin Langhoff venit, vidit, dixit 20.07.2008 23:50:
>> > On Fri, Jul 18, 2008 at 10:39 PM, Petr Baudis <pasky@suse.cz> wrote:
>> > > On Wed, Jul 02, 2008 at 11:11:02PM -0400, David Baldwin wrote:
>> > > > http://baldwindev.com/git.or.cz/
>> > > I'm not sure if this is really an improvement on the current state,
>> > > but then again, the current state pretty much matches my idea and maybe
>> > > others will agree that your proposal is better. Thus, it's better to
>> > > show this to the Git community at large. :-)
>> >
>> > FWIW, I like it. I like both the better font and whitespace layout and
>> > the 3-color-spot-merge-to-white. As Petr says, we have had the
>> > (apologies, but to me) ugly logo for a while, so it is widely used,
>> > and perhaps it has even grown on people.
>> >
>> > BazaarNG managed to grab the best concept logo of the lot, IMHO, with
>> > the 'merge' roadsign.
>> >
>> > > If you think you have a cooler logo, that's fine too, but then it's
>> > > again better to present it explicitly, I believe.
>> >
>> > Can we separate the 2 things? The better fonts and layout look like a win to
>> > me.
>> >
>> > WRT the logo, the current one is not a particularly strong image, and
>> > we haven't spent millions in plastering it over magazines or anything.
>> > So a good new logo would be something to take on.
>>
>> I like that new logo (plusminus G), too, it's very descriptive. I just want to
>> raise one question which I can't answer myself:
>>
>> Are there any potential issues with the Helvetica license?
>>
>> In any case it may be safer do redo it with a GPL sans serif font. If one
>> wants to keep the association of the shape of "G" with a circular arrow then
>> FreeSans and Nimbus Sans L seem to be the only options.
>>
>> Alternatively, it may be easier to redo it in plain PS. I'll attach 2 KISS
>> variants. 1.5k for the eps, 3 colors only.
>
> You could have spared yourself the trouble:
>
> http://repo.or.cz/w/msysgit.git?a=blob_plain;f=share/resources/gitlogo.svg;h=c0d67e70ab31394f0635c141998e512437a138b4;hb=HEAD
The sideways Git is sweet, but as a favicon, it's awfully small. I
think it would be easier to see with just the sideways G or just the
+- as a favicon and the whole thing for larger images.
^ permalink raw reply
* Re: [PATCH] Fix update-index --refresh for submodules if stat(2) returns st_size 0
From: Alex Riesen @ 2008-07-21 19:43 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git, Junio C Hamano
In-Reply-To: <alpine.DEB.1.00.0807211917440.8986@racer>
Johannes Schindelin, Mon, Jul 21, 2008 20:20:43 +0200:
> Hi,
>
> On Mon, 21 Jul 2008, Alex Riesen wrote:
>
> > For example - Cygwin.
>
> Please enhance: your oneline is too long, and your commit message body too
> short.
Well, I'm really not sure. I just found this difference between linux
and cygwin (st_stat is 0 for dirs on cygwin). Than I noticed that the
routine where I made the change explicitely checks for st_size not
being 0. I must admit I can't make much out of comment, and hope this
discussion will help to clear the check up.
> > Can MSys folks please try it? I noticed it when the test
> > t2103-update-index-ignore-missing.sh (the 5th case) started failing.
>
> Since M$' documentation says "This member does not have a meaning for
> directories." about the member nFileSizeLow of WIN32_FILE_ATTRIBUTE_DATA
> which we use to implement a sane "lstat()", I think this bug hits MinGW
> (not MSys) as well.
Could you, just for completeness, try? I don't have mingw at hand
and SUSv3 (http://www.opengroup.org/onlinepubs/009695399/toc.htm)
does not tells much too. No UNIX system I know about has it 0 for
directories.
^ permalink raw reply
* [PATCH 10/9] git-gui: git.git now uses $(gitexec_instdir) to point to the exec-path
From: Johannes Sixt @ 2008-07-21 19:26 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: git, Junio C Hamano
In-Reply-To: <1216667998-8879-10-git-send-email-johannes.sixt@telecom.at>
In git.git the Makefile variable $(gitexecdir) can be relative. It now
exports the actual install location in $(gitexec_instdir).
Signed-off-by: Johannes Sixt <johannes.sixt@telecom.at>
---
Makefile | 4 ++++
1 files changed, 4 insertions(+), 0 deletions(-)
diff --git a/Makefile b/Makefile
index b19fb2d..c8660fb 100644
--- a/Makefile
+++ b/Makefile
@@ -30,8 +30,12 @@ ifndef SHELL_PATH
endif
ifndef gitexecdir
+ifdef gitexec_instdir
+ gitexecdir := $(gitexec_instdir)
+else
gitexecdir := $(shell git --exec-path)
endif
+endif
ifndef sharedir
sharedir := $(dir $(gitexecdir))share
--
1.6.0.rc0.18.g6aef2
^ permalink raw reply related
* [PATCH 8/9] Windows: Make sure argv[0] has a path
From: Johannes Sixt @ 2008-07-21 19:19 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Johannes Sixt
In-Reply-To: <1216667998-8879-8-git-send-email-johannes.sixt@telecom.at>
Since the exec-path on Windows is derived from the program invocation path,
we must ensure that argv[0] always has a path. Unfortunately, if a program
is invoked from CMD, argv[0] has no path. But on the other hand, the
C runtime offers a global variable, _pgmptr, that always has the full path
to the program. We hook into main() with a preprocessor macro, where we
replace argv[0].
Signed-off-by: Johannes Sixt <johannes.sixt@telecom.at>
---
compat/mingw.h | 12 ++++++++++++
1 files changed, 12 insertions(+), 0 deletions(-)
diff --git a/compat/mingw.h b/compat/mingw.h
index 8ffec51..290a9e6 100644
--- a/compat/mingw.h
+++ b/compat/mingw.h
@@ -223,3 +223,15 @@ void mingw_open_html(const char *path);
char **copy_environ(void);
void free_environ(char **env);
char **env_setenv(char **env, const char *name);
+
+/*
+ * A replacement of main() that ensures that argv[0] has a path
+ */
+
+#define main(c,v) main(int argc, const char **argv) \
+{ \
+ static int mingw_main(); \
+ argv[0] = xstrdup(_pgmptr); \
+ return mingw_main(argc, argv); \
+} \
+static int mingw_main(c,v)
--
1.6.0.rc0.18.g6aef2
^ permalink raw reply related
* [PATCH 7/9] Windows: Make $(gitexecdir) relative
From: Johannes Sixt @ 2008-07-21 19:19 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Johannes Sixt
In-Reply-To: <1216667998-8879-7-git-send-email-johannes.sixt@telecom.at>
Signed-off-by: Johannes Sixt <johannes.sixt@telecom.at>
---
Makefile | 1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/Makefile b/Makefile
index 908c1cb..1bfffff 100644
--- a/Makefile
+++ b/Makefile
@@ -745,6 +745,7 @@ ifneq (,$(findstring MINGW,$(uname_S)))
COMPAT_OBJS += compat/mingw.o compat/fnmatch.o compat/regex.o compat/winansi.o
EXTLIBS += -lws2_32
X = .exe
+ gitexecdir = ../libexec/git-core
template_dir = ../share/git-core/templates/
ETC_GITCONFIG = ../etc/gitconfig
endif
--
1.6.0.rc0.18.g6aef2
^ permalink raw reply related
* [PATCH 9/9] Windows: Do not compile git-shell
From: Johannes Sixt @ 2008-07-21 19:19 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Johannes Sixt
In-Reply-To: <1216667998-8879-9-git-send-email-johannes.sixt@telecom.at>
Signed-off-by: Johannes Sixt <johannes.sixt@telecom.at>
---
Makefile | 4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/Makefile b/Makefile
index 1bfffff..f8dd7e6 100644
--- a/Makefile
+++ b/Makefile
@@ -283,7 +283,6 @@ PROGRAMS += git-pack-redundant$X
PROGRAMS += git-patch-id$X
PROGRAMS += git-receive-pack$X
PROGRAMS += git-send-pack$X
-PROGRAMS += git-shell$X
PROGRAMS += git-show-index$X
PROGRAMS += git-unpack-file$X
PROGRAMS += git-update-server-info$X
@@ -812,6 +811,7 @@ EXTLIBS += -lz
ifndef NO_POSIX_ONLY_PROGRAMS
PROGRAMS += git-daemon$X
PROGRAMS += git-imap-send$X
+ PROGRAMS += git-shell$X
endif
ifndef NO_OPENSSL
OPENSSL_LIBSSL = -lssl
@@ -1348,7 +1348,7 @@ endif
fi && \
{ $(foreach p,$(BUILT_INS), $(RM) "$$execdir/$p" && ln "$$execdir/git$X" "$$execdir/$p" ;) } && \
$(RM) "$$execdir/git$X" && \
- ./check_bindir "z$$bindir" "z$$execdir" "$$bindir/git-shell$X"
+ ./check_bindir "z$$bindir" "z$$execdir" "$$bindir/git-add$X"
install-doc:
$(MAKE) -C Documentation install
--
1.6.0.rc0.18.g6aef2
^ 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