* Re: problem switching branches
From: J.V. @ 2013-03-01 20:52 UTC (permalink / raw)
Cc: git@vger.kernel.org
In-Reply-To: <20130227051740.GB10976@sigill.intra.peff.net>
On 2/26/2013 10:17 PM, Jeff King wrote:
> On Tue, Feb 26, 2013 at 04:08:55PM -0700, J.V. wrote:
>
>> I was on my master branch, I then checked out a branch (
>> origin/somebranch ), made no updates
>> but did a few git pulls on the branch over about a week; then made a
>> small change to only a single file & committed & pushed.
>>
>> Now am trying to go back to my master branch and get:
>>
>> error: The following untracked working tree files would be
>> overwritten by checkout:
>> lib/derbyclient.jar
>> Please move or remove them before you can switch branches.
>> Aborting
>>
>>
>> I did not put that jar file there (I edited a single config file),
>> how do I now get back to my master branch?
> Not knowing anything about your project, it's impossible to say for
> sure, but this often happens with something like:
>
> 1. lib/derbyclient.jar used to be generated by your project's build
> procedure
This jar was put on the master branch last year; It does not exist in
the branch that I am now on where I get the error message (I am on a
branch that was created for a previous release).
>
> 2. You did a build of your project, generating the file in your
> working tree.
This jar is downloaded from the web and put there; we did not generate.
>
> 3. Meanwhile, somebody upstream added and commited lib/derbyclient.jar
> directly in the repository. This might have been intentional (it
> used to be a generated file, but now is included as source), or it
> may have been an accident (mistaken use of `git add`).
It was committed intentionally, last year, but does not exist in the
branch that I am now on, but it is there.
>
> 4. You try to switch to the master branch with the new commits from
> (3). Git sees that the copy of the file in your working tree would
> be overwritten and lost (since it was never committed by you), so
> aborts.
>
> If you are sure that the file in the working tree does not contain
> anything interesting, you can use "git checkout -f master" to force the
> overwrite.
I will try this.
>
>> I do not want to muck up the branch that I am now on by deleting anything.
>> Any ideas how this happened?
> You won't hurt the branch you are on; you will just lose the contents in
> the untracked working tree file. That's probably fine if it is a
> generated file, as in the scenario I described above. We know that the
> file is not included in the branch you are on (otherwise, it would not
> be listed as untracked). And even if it were, you would only impact the
> branch by committing the changes, not by changing the working tree.
>
>> Obviously someone put derbyclient.jar there, not sure, but it is
>> supposed to be there so do not want to remove as advised.
> It won't be removed; it will be overwritten with the version of the file
> that is on "master". Which is probably what you want; you may want to
> look at `git log master -- lib/derbyclient.jar` to see why it was added.
>
> -Peff
^ permalink raw reply
* Re: [PATCH] Make !pattern in .gitattributes non-fatal
From: Thomas Rast @ 2013-03-01 20:42 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Nguyễn Thái Ngọc Duy, git
In-Reply-To: <7vfw0eg90e.fsf@alter.siamese.dyndns.org>
Junio C Hamano <gitster@pobox.com> writes:
> Thomas Rast <trast@student.ethz.ch> writes:
>
>> Before 82dce99 (attr: more matching optimizations from .gitignore,
>> 2012-10-15), .gitattributes did not have any special treatment of a
>> leading '!'. The docs, however, always said
>>
>> The rules how the pattern matches paths are the same as in
>> `.gitignore` files; see linkgit:gitignore[5].
>>
>> By those rules, leading '!' means pattern negation. So 82dce99
>> correctly determined that this kind of line makes no sense and should
>> be disallowed.
>>
>> However, users who actually had a rule for files starting with a '!'
>> are in a bad position: before 82dce99 '!' matched that literal
>> character, so it is conceivable that users have .gitattributes with
>> such lines in them. After 82dce99 the unescaped version was
>> disallowed in such a way that git outright refuses to run(!) most
>> commands in the presence of such a .gitattributes. It therefore
>> becomes very hard to fix, let alone work with, such repositories.
>
> Fixing the working tree is easy, but when we read from a history
> that already records such an entry in an attribute file, it would
> become somewhat cumbersome. I wouldn't use "very hard to fix" to
> describe such a case.
Well, I'm sorry if I hurt any feelings there, but...
~/tmp/badattr(master)$ git show bad:.gitattributes
!bad text
~/tmp/badattr(master)$ ~/g/git-checkout bad # a git without my patch
fatal: Negative patterns are forbidden in git attributes
Use '\!' for literal leading exclamation.
~/tmp/badattr(master)$ git status
# On branch master
nothing to commit (use -u to show untracked files)
Notice how it remains on master. I suppose with enough knowledge of the
internals I could manage, but after seeing how hard it was to *build*
such broken history with a git that dies, I don't really want to try.
--
Thomas Rast
trast@{inf,student}.ethz.ch
^ permalink raw reply
* Re: [PATCH] Make !pattern in .gitattributes non-fatal
From: Junio C Hamano @ 2013-03-01 20:28 UTC (permalink / raw)
To: Thomas Rast; +Cc: Nguyễn Thái Ngọc Duy, git
In-Reply-To: <a1679159dbe67c34675bbe016e131260310db189.1362168366.git.trast@student.ethz.ch>
Thomas Rast <trast@student.ethz.ch> writes:
> Before 82dce99 (attr: more matching optimizations from .gitignore,
> 2012-10-15), .gitattributes did not have any special treatment of a
> leading '!'. The docs, however, always said
>
> The rules how the pattern matches paths are the same as in
> `.gitignore` files; see linkgit:gitignore[5].
>
> By those rules, leading '!' means pattern negation. So 82dce99
> correctly determined that this kind of line makes no sense and should
> be disallowed.
>
> However, users who actually had a rule for files starting with a '!'
> are in a bad position: before 82dce99 '!' matched that literal
> character, so it is conceivable that users have .gitattributes with
> such lines in them. After 82dce99 the unescaped version was
> disallowed in such a way that git outright refuses to run(!) most
> commands in the presence of such a .gitattributes. It therefore
> becomes very hard to fix, let alone work with, such repositories.
Fixing the working tree is easy, but when we read from a history
that already records such an entry in an attribute file, it would
become somewhat cumbersome. I wouldn't use "very hard to fix" to
describe such a case.
But the demotion to warning does make sense; let's do that in
v1.8.1.5.
^ permalink raw reply
* Re: [PATCH] Make !pattern in .gitattributes non-fatal
From: Junio C Hamano @ 2013-03-01 20:24 UTC (permalink / raw)
To: Thomas Rast; +Cc: Nguyễn Thái Ngọc Duy, git
In-Reply-To: <a1679159dbe67c34675bbe016e131260310db189.1362168366.git.trast@student.ethz.ch>
Makes sense. Duy?
^ permalink raw reply
* [PATCH] Make !pattern in .gitattributes non-fatal
From: Thomas Rast @ 2013-03-01 20:06 UTC (permalink / raw)
To: Nguyễn Thái Ngọc Duy; +Cc: Junio C Hamano, git
Before 82dce99 (attr: more matching optimizations from .gitignore,
2012-10-15), .gitattributes did not have any special treatment of a
leading '!'. The docs, however, always said
The rules how the pattern matches paths are the same as in
`.gitignore` files; see linkgit:gitignore[5].
By those rules, leading '!' means pattern negation. So 82dce99
correctly determined that this kind of line makes no sense and should
be disallowed.
However, users who actually had a rule for files starting with a '!'
are in a bad position: before 82dce99 '!' matched that literal
character, so it is conceivable that users have .gitattributes with
such lines in them. After 82dce99 the unescaped version was
disallowed in such a way that git outright refuses to run(!) most
commands in the presence of such a .gitattributes. It therefore
becomes very hard to fix, let alone work with, such repositories.
Let's at least allow the users to fix their repos: change the fatal
error into a warning.
Reported-by: mathstuf@gmail.com
Signed-off-by: Thomas Rast <trast@student.ethz.ch>
---
attr.c | 8 +++++---
t/t0003-attributes.sh | 3 ++-
2 files changed, 7 insertions(+), 4 deletions(-)
diff --git a/attr.c b/attr.c
index 4657cc2..e2f9377 100644
--- a/attr.c
+++ b/attr.c
@@ -255,9 +255,11 @@ static struct match_attr *parse_attr_line(const char *line, const char *src,
&res->u.pat.patternlen,
&res->u.pat.flags,
&res->u.pat.nowildcardlen);
- if (res->u.pat.flags & EXC_FLAG_NEGATIVE)
- die(_("Negative patterns are forbidden in git attributes\n"
- "Use '\\!' for literal leading exclamation."));
+ if (res->u.pat.flags & EXC_FLAG_NEGATIVE) {
+ warning(_("Negative patterns are ignored in git attributes\n"
+ "Use '\\!' for literal leading exclamation."));
+ return NULL;
+ }
}
res->is_macro = is_macro;
res->num_attr = num_attr;
diff --git a/t/t0003-attributes.sh b/t/t0003-attributes.sh
index 43b2513..0b98b6f 100755
--- a/t/t0003-attributes.sh
+++ b/t/t0003-attributes.sh
@@ -198,7 +198,8 @@ test_expect_success 'root subdir attribute test' '
test_expect_success 'negative patterns' '
echo "!f test=bar" >.gitattributes &&
- test_must_fail git check-attr test -- f
+ git check-attr test -- '"'"'!f'"'"' 2>errors &&
+ test_i18ngrep "Negative patterns are ignored" errors
'
test_expect_success 'patterns starting with exclamation' '
--
1.8.2.rc1.392.gf57d6b8.dirty
^ permalink raw reply related
* Re: Adding "--ignore-submodules" switch to git-describe
From: Jens Lehmann @ 2013-03-01 19:40 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Francis Moreau, git
In-Reply-To: <7v621bggi5.fsf@alter.siamese.dyndns.org>
Am 01.03.2013 18:46, schrieb Junio C Hamano:
> I think what is missing from "--dirty" is not "--ignore-submodules",
> but "--do-not-ignore-untracked" option [*1*]. "describe --dirty"
> ignores untracked files in the superproject by default, and we
> should ignore untracked files in submodule working trees, but the
> current code does not. Fixing that is (1) above.
>
> And then when "--do-not-ignore-untracked" is in effect, we should
> report a "dirty" revision when the working tree of the superproject
> or any of the submodule working trees has untracked cruft.
I agree with your analysis. What about teaching describe the
"-u|--untracked-files" option which status already knows? The
two modes could be "no" and "yes" here (as the distinction
between "normal" and "all" doesn't make any sense for describe).
Current default would be "no", using "-u" alone would set mode to
"yes".
> You might want to argue, in the longer term, that the default should
> be "--do-not-ignore-untracked" and people who want the current
> toplevel behaviour should ask it with "--ignore-untracked". I am
> somewhat sympathetic to that position, but I do not think it is
> practical. People are not perfect and they do keep untracked and
> unignored paths in the working tree; ignoring untracked paths does
> have an excuse to be the default from practical point of view.
I think the default mostly depends on the habits of the people
using a repo. Personally I would lean towards making "-uyes" the
default, because in my experience untracked files can make a huge
difference when you later try to reproduce a certain version and
its behavior (and additionally that is just what status already
uses as default). But I won't care that much about the default if
we would just reuse the "status.showUntrackedFiles" config option
to set the default for describe too. This should allow to set the
policy per repo or globally to peoples taste. Does that make sense?
> But when we ignore untracked paths in the superproject, we should
> ignore untracked paths in submodule working trees consistently.
Definitely (we fixed that for status some time ago in 3bfc45047).
^ permalink raw reply
* Re: [PATCH] Documentation/githooks: Fix linkgit
From: Junio C Hamano @ 2013-03-01 18:19 UTC (permalink / raw)
To: Andrew Wong; +Cc: git
In-Reply-To: <1362158637-931-1-git-send-email-andrew.kw.w@gmail.com>
Thanks. "grep linkgit *.html" in the installed documentation area
tells me that this is the only instance that needs to be fixed.
^ permalink raw reply
* Re: Elegant subdirectory checkout of remote-tracking branch?
From: Junio C Hamano @ 2013-03-01 18:05 UTC (permalink / raw)
To: W. Trevor King; +Cc: Git
In-Reply-To: <20130301152253.GA9312@odin.tremily.us>
"W. Trevor King" <wking@tremily.us> writes:
> Any suggestions for an elegant solution would be appreciated :).
My Meta checkout is not a submodule of anything. It is a totally
independent repository and is not linked with git.git in any way.
It started as an independent repository, and it still is.
That it has been pushed to the same repository at k.org was a mere
historical accident (I only had that repository writable there when
I started); it not even a recommended practice to publish unrelated
histories in a single repository. You are seeing 'todo' in some of
my public mirrors only due to historical inertia.
Just treat the git.git primary directory and the Meta directory as
what they are: two checkouts of two totally independent projects,
one of which happens to be designed to be checked out at a fixed
location relative to the other. When running "pull --ff-only", do
so in both independently.
That is what I do in my secondary repositories.
> Once we figure something out, I can write it up and stick it in
> howto/maintain-git.txt.
You are free to write and do whatever suites yourself, but a
description of a workflow that is not what I use does not belong to
the howto/maintain-git.txt document ;-)
^ permalink raw reply
* Re: [PATCH] In inproperly merges, the ranges contains additional character "*"
From: Junio C Hamano @ 2013-03-01 17:54 UTC (permalink / raw)
To: Jan Pešta; +Cc: git, 'Matthieu Moy'
In-Reply-To: <002101ce1681$4f261090$ed7231b0$@certicon.cz>
Jan Pešta <jan.pesta@certicon.cz> writes:
> In inproperly merges, the ranges contains additional character "*".
Thanks, but -ECANNOTPARSE. What are "inproperly merges"?
> See http://www.open.collab.net/community/subversion/articles/merge-info.html
> Extract:
> The range r30430:30435 that was added to 1.5.x in this merge has a '*'
> suffix for 1.5.x\www.
> This '*' is the marker for a non-inheritable mergeinfo range.
> The '*' means that only the path on which the mergeinfo is explicitly set
> has had this range merged into it.
If I am reading the above correctly, blindly removing '*' from the
range will record a wrong merge in the result, because on the SVN
side only the history of part of the tree is merged but we represent
the result as a full merge (and Git only records full merge of
histories), no?
My gut feeling tells me that failing the import, saying "We cannot
represent this history", might be a more honest and safe thing to
do.
> Signed-off-by: Jan Pesta <jan.pesta@certicon.cz>
> ---
> perl/Git/SVN.pm | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/perl/Git/SVN.pm b/perl/Git/SVN.pm
> index 0ebc68a..6bd18e9 100644
> --- a/perl/Git/SVN.pm
> +++ b/perl/Git/SVN.pm
> @@ -1493,6 +1493,7 @@ sub lookup_svn_merge {
> my @merged_commit_ranges;
> # find the tip
> for my $range ( @ranges ) {
> + $range =~ s/[*]$//;
> my ($bottom, $top) = split "-", $range;
> $top ||= $bottom;
> my $bottom_commit = $gs->find_rev_after( $bottom, 1, $top );
^ permalink raw reply
* Re: Adding "--ignore-submodules" switch to git-describe
From: Junio C Hamano @ 2013-03-01 17:46 UTC (permalink / raw)
To: Francis Moreau; +Cc: git, Jens Lehmann
In-Reply-To: <CAC9WiBjHEoX154Y2q1NxEB1my78Gqf__+v-KR5jNVqT-MN9ZaQ@mail.gmail.com>
Francis Moreau <francis.moro@gmail.com> writes:
> Would it make sense to add the option --ignore-submodules (currently
> available in git-status) to git-describe when the later is used with
> --dirty option ?
I think the spirit of "describe --dirty" is to allow people who
gives out binaries this assurance:
The version string I got out of "describe --dirty" does not
say dirty. If the recipient of the binary later reports
issues, I should be able to reproduce the same binary by
starting from a pristine checkout of the version (provided
if I didn't screw up and depended on an untracked file when
I initially created the binary, or used a custom build
option, or lost the toolchain, ..., of course).
With that in mind, does --ignore-submodules make sense?
As we do not take untracked content at the superproject level into
account when deciding "--dirty"-ness, I think it is very sensible to
either do one of the following:
(1) always ignore untracked files in submodule working trees; or
(2) if we were to introduce some form of --ignore-submodules,
ignore untracked files in the superproject working tree when we
use that mechanism to ignore untracked files in submodule
working trees.
Strictly speaking, (1) is a degenerate case of (2).
Using the same semantics of "--ignore-submodules" as "git status"
would not make much sense. "git status --ignore-submodules" does not
show modified submodules at all (e.g. the gitlink recorded in the
HEAD of the superproject being described does not match what is
checked out), so a clean output from the "describe --dirty" at the
superproject level does not give any assurance on the build
artifact. It defeats the whole point of "describe --dirty".
I think what is missing from "--dirty" is not "--ignore-submodules",
but "--do-not-ignore-untracked" option [*1*]. "describe --dirty"
ignores untracked files in the superproject by default, and we
should ignore untracked files in submodule working trees, but the
current code does not. Fixing that is (1) above.
And then when "--do-not-ignore-untracked" is in effect, we should
report a "dirty" revision when the working tree of the superproject
or any of the submodule working trees has untracked cruft.
You might want to argue, in the longer term, that the default should
be "--do-not-ignore-untracked" and people who want the current
toplevel behaviour should ask it with "--ignore-untracked". I am
somewhat sympathetic to that position, but I do not think it is
practical. People are not perfect and they do keep untracked and
unignored paths in the working tree; ignoring untracked paths does
have an excuse to be the default from practical point of view.
But when we ignore untracked paths in the superproject, we should
ignore untracked paths in submodule working trees consistently.
[Footnote]
*1* Ignoring any other kind of change in submodules (i.e. "none",
"dirty" or "all" for "git status --ignore-submodules=<when>") in the
context of "describe --dirty" in the superproject tree does not make
any sense, so
BAD$ git describe --dirty --ignore-submodules=<when>
is not a right thing to do.
^ permalink raw reply
* [PATCH] Documentation/githooks: Fix linkgit
From: Andrew Wong @ 2013-03-01 17:23 UTC (permalink / raw)
To: git; +Cc: Andrew Wong
Signed-off-by: Andrew Wong <andrew.kw.w@gmail.com>
---
Documentation/githooks.txt | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/Documentation/githooks.txt b/Documentation/githooks.txt
index 8181e4e..eab9b35 100644
--- a/Documentation/githooks.txt
+++ b/Documentation/githooks.txt
@@ -365,7 +365,7 @@ preceding SP is also omitted. Currently, no commands pass any
'extra-info'.
The hook always runs after the automatic note copying (see
-"notes.rewrite.<command>" in linkgit:git-config.txt) has happened, and
+"notes.rewrite.<command>" in linkgit:git-config.txt[1]) has happened, and
thus has access to these notes.
The following command-specific comments apply:
--
1.8.2.rc0.22.gb3600c3
^ permalink raw reply related
* Re: two-way merge corner case bug
From: Junio C Hamano @ 2013-03-01 16:57 UTC (permalink / raw)
To: Jeff King; +Cc: git
In-Reply-To: <20130301092201.GA17254@sigill.intra.peff.net>
Jeff King <peff@peff.net> writes:
> PS I wonder if the "initial_checkout" hack can just go away under this
> new rule. Although we don't seem to use "o->reset" for the initial
> checkout. Which seems kind of weird. I would think the initial
> checkout would actually just be a oneway merge. Is the point to try
> to leave any existing working tree contents untouched or something?
An initial checkout is *supposed* to happen in an empty working
tree, so if we code it not to overwrite an existing path in the
working tree, the user cannot lose possibly precious contents with
an mistaken initial checkout (they will instead appear as modified
relative to the index), while in the normal case we will write out
the contents from the HEAD through the index. We could attempt "we
do not have to if the user behaves, but with this we could help
misbehaving users" if we used twoway merge for an initial checkout.
Having said that, I notice that in the normal codepath (e.g. "git
clone" without the "--no-checkout" option) we no longer use twoway
merge for the initial checkout. Back when "git clone" was a
scripted Porcelain, I think we used to do a twoway read-tree. It
may be that we broke it when "clone" was rewritten in C, but the
breakage is to the "we do not have to..." thing, so it may not be a
big deal.
The only case that matters in today's code is "git checkout"
(without any option or argument) immediately after "git clone -n", I
think. The special casing for this initial checkout in twoway merge
is needed because we go from HEAD to HEAD in that case, and we do
not want to keep the artificial local removals from the index; we
start from not even having the $GIT_INDEX_FILE, so without the
special case all paths appear to have been "rm --cached", which is
usually not what the user would want to see ;-)
> ... My worry would be that somebody is
> using "--reset" but expecting the removal to be carried through
> (technically, "--reset" is documented as "-m but discard unmerged
> entries", but we are not really treating it that way here).
I've checked all in-tree uses of "read-tree --reset -u".
Nobody seems to use that combination, either from scripts or from C
(i.e. when opts.update==1 and opts.merge==1, opts.reset is not set)
with a twoway merge, other than "git am --abort/--skip".
^ permalink raw reply
* Debugging a bizarre problem: What can influence 'git fetch'?
From: git-users @ 2013-03-01 14:39 UTC (permalink / raw)
To: git
Hello.
I'm working on a small project that talks to external git and fossil
repositories. I've run into a bizarre "this cannot happen" problem and
am completely mystified as to what's causing it.
Essentially, the problem is that a particular git command, run as part
of the unit tests for the project, fails reliably when executed from
the project's build system but works correctly when run directly from the
command line or when the same unit tests are executed from the IDE).
The unit test executes the following commands (where e5KbuUvD4Ps is a
random string to ensure that each invocation of the test starts from a
blank canvas):
/usr/bin/git clone --mirror --bare http://git.io7m.com/io7m-jaux.git /tmp/test-e5KbuUvD4Ps/io7m-jaux.git
/usr/bin/git --git-dir=/tmp/test-e5KbuUvD4Ps/io7m-jaux.git fetch -v
The 'git fetch' command raises the following error:
error: Unable to find f981a2bb02c38f20c1e3a5a0fc37c2b4ef5b92ea under http://git.io7m.com/io7m-jaux.git
Cannot obtain needed object f981a2bb02c38f20c1e3a5a0fc37c2b4ef5b92ea
error: Fetch failed.
The f981a2bb02c38f20c1e3a5a0fc37c2b4ef5b92ea is the HEAD commit of the master
branch in the above repos.
I can execute the fetch command from the command line (on the same clones created
by any past invocations of the unit test) and it works correctly. I can run the unit
test from the IDE and it works correctly.
In desperation, I've replaced the git binary with a shell script that logs
the current environment and command line arguments to a file before executing
the real git binary and in all cases, they're completely identical.
I'm out of ideas. What bizarre invisible environment pollution could possibly
be influencing 'git fetch' in this manner? Is there some way to get 'git fetch'
to be more verbose?
M
^ permalink raw reply
* Elegant subdirectory checkout of remote-tracking branch?
From: W. Trevor King @ 2013-03-01 15:22 UTC (permalink / raw)
To: Git
[-- Attachment #1: Type: text/plain, Size: 2154 bytes --]
I'm trying to figure out the most efficient way to keep an up to
date `todo` branch checked out in Meta [1]. I've tried a few
things like:
$ git submodule add -b refs/remotes/origin/todo --reference ./ -- ./ Meta
and:
$ git clone --single-branch --branch refs/remotes/origin/todo ./ Meta
These fail because I can't use a remote tracking branch as a
source for the clone. It should be possible to do:
$ git clone --reference . --single-branch --branch todo git://git.kernel.org/pub/scm/git/git.git Meta
but that will require (I think) network access during a fetch.
Since I'm already fetching `origin` from the superproject, I
don't want to have to refetch them for the submodule (or whatever
Meta ends up being). Here's what I think happens with a
submodule fetch:
1. Query the remote URL to dereference its current `todo` branch.
2. Check if we have that object in our local object share (which
we should, due to --reference and a recent superproject
fetch).
3. Fetch any missing objects from the remote URL.
I want to replace step 1 with:
1b. Query the superproject to dereference its current
`origin/todo` branch.
and step 3 with:
3b. Access objects from the superproject directly (as with
--reference / --shared).
Do I need to setup something like:
[remote "origin"]
url = ../.git
fetch = +refs/remotes/origin/todo:refs/remotes/origin/todo
by hand, or is there an easier way?
I can, of course, clone a local `todo` branch if I've set one up in my
superproject. However, then I'd have to update-ref that branch to
sync with origin/todo after every fetch (that updates origin/todo).
This could be handled with a `git fetch` wrapper, but… yuck :p.
Any suggestions for an elegant solution would be appreciated :).
Once we figure something out, I can write it up and stick it in
howto/maintain-git.txt.
Cheers,
Trevor
[1]: http://article.gmane.org/gmane.comp.version-control.git/144748
--
This email may be signed or encrypted with GnuPG (http://www.gnupg.org).
For more information, see http://en.wikipedia.org/wiki/Pretty_Good_Privacy
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply
* Re: Ignore version update changes on git show report?
From: Preben Liland Madsen @ 2013-03-01 15:12 UTC (permalink / raw)
To: Michael J Gruber; +Cc: git
In-Reply-To: <5130AE23.4040303@drmicha.warpmail.net>
Den 1. mars 2013 kl. 14.33 skrev Michael J Gruber:
> First of all, there is
>
> git beat-with-stick
>
> that you should apply to those responsible for that mess ;)
Haha, yeah I should try that one ;-)
I wish they weren't included in their release, but what can you do... I'm sure they have their reason for including the updated version number. Maybe to ensure files have been updated or similar when doing support for their clients, I guess... Although for us it really is more a pain than gain that they update the version number in all their php files when we wish to review changes done in files we may have modified earlier or possibly investigate bugs that may suddenly crop up in newer versions.
> If you have to deal with that sort of situation then a textconv filter
> might get you as close as possible. Use "grep -v '^\* IP.Board v*'" as a
> textconv filter for those files, and those changes will disappear from
> the diff. (I do something like that for tracking my gitk config, which
> stores last window sizes.)
Thanks! I got a similar tips on stackoverflow: http://stackoverflow.com/questions/15097401/git-any-way-to-ignore-files-that-have-gotten-version-number-changed-only/
But unfortunately that doesn't work for --stat it seems, but I've written a small "sketchy" shell-script to just ignore all lines with 2+- in them...
Best regards, Preben
^ permalink raw reply
* Re: [PATCH v8 4/5] Implement line-history search (git log -L)
From: Thomas Rast @ 2013-03-01 14:59 UTC (permalink / raw)
To: Junio C Hamano
Cc: git, Bo Yang, Zbigniew Jędrzejewski-Szmek, Will Palmer
In-Reply-To: <87vc9b1p48.fsf@pctrast.inf.ethz.ch>
Thomas Rast <trast@student.ethz.ch> writes:
> Junio C Hamano <gitster@pobox.com> writes:
>
>> I notice that "careful and slow" is just "too slow
>> to be usable" even on a small tree like ours. Try running
>>
>> $ git log -M -L:get_name:builtin/describe.c
>>
>> and see how long you have to wait until you hit the first line of
>> output.
>
> I'll dig some more. It *should* be essentially the following times
> taken together:
>
> $ time git log --raw -M --topo-order >/dev/null
> real 0m5.448s
[...]
> $ time git log -L:get_name:builtin/describe.c >/dev/null
> real 0m0.832s
[...]
> $ time git log -L:get_name:builtin-describe.c 81b50f3ce40^ >/dev/null
> real 0m0.489s
[...]
> So I'm losing a factor of about 4 somewhere, which I can't explain right
> now.
It seems I still don't understand half of this code.
log -M --raw in the above somehow appears to use and optimize for
-M100%, whereas the log -L code is currently written for general args.
However, I couldn't pin down where this happens; I only know from call
graph profiling[1] that log -M --raw never goes through diffcore_std().
And indeed according to the same sort of profiling, log -M -L spends
most of its time within diffcore_std() unpacking blobs to find renames.
Even more confusingly, try_to_follow_renames() _does_ call into
diffcore_std, so there seems to be some merit to calling it after all.
With the hacky patch below, I get something more reasonable:
$ time ./git-log -M -L:get_name:builtin/describe.c >/dev/null
real 0m3.794s
user 0m3.734s
sys 0m0.045s
That's compared to about 35s on my machine without the patch. It still
calls diffcore_std(), but before that it discards all diff pairs except
those affecting the path(s) we're interested in and any deletions (so
that they can be used as rename sources). After diffcore_std() it
discards all pairs that we're not interested in.
[1] valgrind --tool=callgrind --trace-children=yes
-- >8 --
Subject: [PATCH] WIP: speed up log -L... -M
---
line-log.c | 58 ++++++++++++++++++++++++++++++++++++++++++++++++++++++----
1 file changed, 54 insertions(+), 4 deletions(-)
diff --git a/line-log.c b/line-log.c
index a74bbaf..b03cc0b 100644
--- a/line-log.c
+++ b/line-log.c
@@ -997,7 +997,52 @@ static void move_diff_queue(struct diff_queue_struct *dst,
DIFF_QUEUE_CLEAR(src);
}
-static void queue_diffs(struct diff_options *opt,
+static void filter_diffs_for_paths(struct line_log_data *range, int keep_deletions)
+{
+ int i;
+ struct diff_queue_struct outq;
+ DIFF_QUEUE_CLEAR(&outq);
+
+ /* fprintf(stderr, "-- filtering:\n"); */
+
+ for (i = 0; i < diff_queued_diff.nr; i++) {
+ struct diff_filepair *p = diff_queued_diff.queue[i];
+ struct line_log_data *rg = NULL;
+ /* fprintf(stderr, "%-38s\t%-38s\n", (p->one ? p->one->path : "<none>"), (p->two ? p->two->path : "<none>")); */
+ if (!DIFF_FILE_VALID(p->two)) {
+ if (keep_deletions)
+ diff_q(&outq, p);
+ else
+ diff_free_filepair(p);
+ continue;
+ }
+ for (rg = range; rg; rg = rg->next) {
+ if (!strcmp(rg->spec->path, p->two->path))
+ break;
+ }
+ if (rg)
+ diff_q(&outq, p);
+ else
+ diff_free_filepair(p);
+ }
+ free(diff_queued_diff.queue);
+ diff_queued_diff = outq;
+}
+
+static inline int diff_might_be_rename(void)
+{
+ int i;
+ for (i = 0; i < diff_queued_diff.nr; i++)
+ if (!DIFF_FILE_VALID(diff_queued_diff.queue[i]->one)) {
+ /* fprintf(stderr, "diff_might_be_rename found creation of: %s\n", */
+ /* diff_queued_diff.queue[i]->two->path); */
+ return 1;
+ }
+ return 0;
+}
+
+static void queue_diffs(struct line_log_data *range,
+ struct diff_options *opt,
struct diff_queue_struct *queue,
struct commit *commit, struct commit *parent)
{
@@ -1013,7 +1058,12 @@ static void queue_diffs(struct diff_options *opt,
DIFF_QUEUE_CLEAR(&diff_queued_diff);
diff_tree(&desc1, &desc2, "", opt);
- diffcore_std(opt);
+ if (opt->detect_rename) {
+ filter_diffs_for_paths(range, 1);
+ if (diff_might_be_rename())
+ diffcore_std(opt);
+ filter_diffs_for_paths(range, 0);
+ }
move_diff_queue(queue, &diff_queued_diff);
if (tree1)
@@ -1297,7 +1347,7 @@ static int process_ranges_ordinary_commit(struct rev_info *rev, struct commit *c
if (commit->parents)
parent = commit->parents->item;
- queue_diffs(&rev->diffopt, &queue, commit, parent);
+ queue_diffs(range, &rev->diffopt, &queue, commit, parent);
changed = process_all_files(&parent_range, rev, &queue, range);
if (parent)
add_line_range(rev, parent, parent_range);
@@ -1322,7 +1372,7 @@ static int process_ranges_merge_commit(struct rev_info *rev, struct commit *comm
for (i = 0; i < nparents; i++) {
parents[i] = p->item;
p = p->next;
- queue_diffs(&rev->diffopt, &diffqueues[i], commit, parents[i]);
+ queue_diffs(range, &rev->diffopt, &diffqueues[i], commit, parents[i]);
}
for (i = 0; i < nparents; i++) {
--
1.8.2.rc1.391.g6a988e5.dirty
^ permalink raw reply related
* Re: Ignore version update changes on git show report?
From: Michael J Gruber @ 2013-03-01 13:33 UTC (permalink / raw)
To: Preben Liland Madsen; +Cc: git
In-Reply-To: <DEC76CB0-9E35-40A8-9D73-77617CC605A3@gmail.com>
Preben Liland Madsen venit, vidit, dixit 26.02.2013 20:53:
> Hello,
>
> I'm trying to investigate some what changes have been done between two versions of a software with the name IP.Board.
>
> This proves more troublesome than I thought, since their release builder appearantly updates the version number automatically in all files.
>
> This causes a lot of files to have this as the only change:
>
> - * IP.Board v3.4.2
> + * IP.Board v3.4.3
>
> Which is quite annoying to have to go through and therefor is responsible for more than 800 files being changed.
>
> Is there some sort of git command or command I can combine together with git show that will ignore files with only these changes? Something along the lines of ignoring files where the only change matches this change or ignore files that've only gotten 1 line removed and 1 line added?
>
> Best regards, Preben--
> To unsubscribe from this list: send the line "unsubscribe git" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
First of all, there is
git beat-with-stick
that you should apply to those responsible for that mess ;)
If you have to deal with that sort of situation then a textconv filter
might get you as close as possible. Use "grep -v '^\* IP.Board v*'" as a
textconv filter for those files, and those changes will disappear from
the diff. (I do something like that for tracking my gitk config, which
stores last window sizes.)
Michael
^ permalink raw reply
* [PATCH] In inproperly merges, the ranges contains additional character "*"
From: Jan Pešta @ 2013-03-01 13:33 UTC (permalink / raw)
To: git; +Cc: 'Matthieu Moy'
In inproperly merges, the ranges contains additional character "*".
See http://www.open.collab.net/community/subversion/articles/merge-info.html
Extract:
The range r30430:30435 that was added to 1.5.x in this merge has a '*'
suffix for 1.5.x\www.
This '*' is the marker for a non-inheritable mergeinfo range.
The '*' means that only the path on which the mergeinfo is explicitly set
has had this range merged into it.
Signed-off-by: Jan Pesta <jan.pesta@certicon.cz>
---
perl/Git/SVN.pm | 1 +
1 file changed, 1 insertion(+)
diff --git a/perl/Git/SVN.pm b/perl/Git/SVN.pm
index 0ebc68a..6bd18e9 100644
--- a/perl/Git/SVN.pm
+++ b/perl/Git/SVN.pm
@@ -1493,6 +1493,7 @@ sub lookup_svn_merge {
my @merged_commit_ranges;
# find the tip
for my $range ( @ranges ) {
+ $range =~ s/[*]$//;
my ($bottom, $top) = split "-", $range;
$top ||= $bottom;
my $bottom_commit = $gs->find_rev_after( $bottom, 1, $top );
--
1.8.1.msysgit.1
^ permalink raw reply related
* Re: [PATCH] GIT SVN
From: Matthieu Moy @ 2013-03-01 13:07 UTC (permalink / raw)
To: Jan Pešta; +Cc: git
In-Reply-To: <001001ce167c$0f376f10$2da64d30$@certicon.cz>
Jan Pešta <jan.pesta@certicon.cz> writes:
> Hi again,
>
> Finally I created patch according to document.
This is much better, but you still haven't taken into account some
important parts of Documentation/SubmittingPatches (the part about
attachments Vs inline patch, and the part about sign-off).
Thanks,
--
Matthieu Moy
http://www-verimag.imag.fr/~moy/
^ permalink raw reply
* RE: [PATCH] GIT SVN
From: Jan Pešta @ 2013-03-01 12:55 UTC (permalink / raw)
To: 'Matthieu Moy'; +Cc: git
In-Reply-To: <vpqsj4fmhgu.fsf@grenoble-inp.fr>
[-- Attachment #1: Type: text/plain, Size: 1154 bytes --]
Hi again,
Finally I created patch according to document.
Please have a look on referenced site for more details.
Currently I have a problems in our project, where SVN is main repository and
merge-info contains "*" which causes troubles in SVN.pm.
Regards,
Jan
Kind regards / S pozdravem
Jan Pešta
SW Engineer Sr.
CertiCon a.s., www.certicon.cz
Vaclavska 12
12000 Prague 2
Czech Republic
Office Prague: +420 224 904 406
Mobile: +420 604 794 306
E-mail: jan.pesta@certicon.cz
-----Original Message-----
From: Matthieu Moy [mailto:Matthieu.Moy@grenoble-inp.fr]
Sent: Friday, March 01, 2013 1:29 PM
To: Jan Pešta
Cc: git@vger.kernel.org
Subject: Re: [PATCH] GIT SVN
Jan Pešta <jan.pesta@certicon.cz> writes:
> Sorry,
> My fault :)
>
> Here is a patch atached.
Still, please, read Documentation/SubmittingPatches. Your patch cannot be
included as it is because of lack of sign-off.
Also, please write a commit message describing why this change is needed.
Where is this extra "*" comming from, and why do you need to remove it?
Thanks,
--
Matthieu Moy
http://www-verimag.imag.fr/~moy/
[-- Attachment #2: 0001-In-inproperly-merges-the-ranges-contains-additional-.patch --]
[-- Type: application/octet-stream, Size: 1089 bytes --]
>From 03aefff110cc46a82e87c01fed38ac6bb22b353b Mon Sep 17 00:00:00 2001
From: Jan Pesta <jan.pesta@certicon.cz>
Date: Fri, 1 Mar 2013 10:30:42 +0100
Subject: [PATCH] In inproperly merges, the ranges contains additional
character "*".
See http://www.open.collab.net/community/subversion/articles/merge-info.html
Extract:
The range r30430:30435 that was added to 1.5.x in this merge has a '*' suffix for 1.5.x\www.
This '*' is the marker for a non-inheritable mergeinfo range.
The '*' means that only the path on which the mergeinfo is explicitly set has had this range merged into it.
---
perl/Git/SVN.pm | 1 +
1 file changed, 1 insertion(+)
diff --git a/perl/Git/SVN.pm b/perl/Git/SVN.pm
index 0ebc68a..6bd18e9 100644
--- a/perl/Git/SVN.pm
+++ b/perl/Git/SVN.pm
@@ -1493,6 +1493,7 @@ sub lookup_svn_merge {
my @merged_commit_ranges;
# find the tip
for my $range ( @ranges ) {
+ $range =~ s/[*]$//;
my ($bottom, $top) = split "-", $range;
$top ||= $bottom;
my $bottom_commit = $gs->find_rev_after( $bottom, 1, $top );
--
1.8.1.msysgit.1
^ permalink raw reply related
* Re: [PATCH] GIT SVN
From: Matthieu Moy @ 2013-03-01 12:29 UTC (permalink / raw)
To: Jan Pešta; +Cc: git
In-Reply-To: <000301ce1677$c9eb3f80$5dc1be80$@certicon.cz>
Jan Pešta <jan.pesta@certicon.cz> writes:
> Sorry,
> My fault :)
>
> Here is a patch atached.
Still, please, read Documentation/SubmittingPatches. Your patch cannot
be included as it is because of lack of sign-off.
Also, please write a commit message describing why this change is
needed. Where is this extra "*" comming from, and why do you need to
remove it?
Thanks,
--
Matthieu Moy
http://www-verimag.imag.fr/~moy/
^ permalink raw reply
* [PATCH] GIT SVN
From: Jan Pešta @ 2013-03-01 12:24 UTC (permalink / raw)
To: git
[-- Attachment #1: Type: text/plain, Size: 1167 bytes --]
Sorry,
My fault :)
Here is a patch atached.
Jan
Kind regards / S pozdravem
Jan Pešta
SW Engineer Sr.
CertiCon a.s., www.certicon.cz
Vaclavska 12
12000 Prague 2
Czech Republic
Office Prague: +420 224 904 406
Mobile: +420 604 794 306
E-mail: jan.pesta@certicon.cz
-----Original Message-----
From: git-owner@vger.kernel.org [mailto:git-owner@vger.kernel.org] On Behalf
Of Jan Pešta
Sent: Friday, March 01, 2013 11:29 AM
To: git@vger.kernel.org
Subject: [PATCH]
Hi,
I found a problem when using GIT-SVN.
In inproperly merges in SVN causes that the ranges contains additional
character "*".
Attached patch fix this issue, I have it already tested for several months.
Regards,
Jan
Kind regards / S pozdravem
Jan Pešta
SW Engineer Sr.
CertiCon a.s., www.certicon.cz
Vaclavska 12
12000 Prague 2
Czech Republic
Office Prague: +420 224 904 406
Mobile: +420 604 794 306
E-mail: jan.pesta@certicon.cz
--
To unsubscribe from this list: send the line "unsubscribe git" in the body
of a message to majordomo@vger.kernel.org More majordomo info at
http://vger.kernel.org/majordomo-info.html
[-- Attachment #2: svn.patch --]
[-- Type: application/octet-stream, Size: 404 bytes --]
diff --git a/perl/Git/SVN.pm b/perl/Git/SVN.pm
index 0ebc68a..6bd18e9 100644
--- a/perl/Git/SVN.pm
+++ b/perl/Git/SVN.pm
@@ -1493,6 +1493,7 @@ sub lookup_svn_merge {
my @merged_commit_ranges;
# find the tip
for my $range ( @ranges ) {
+ $range =~ s/[*]$//;
my ($bottom, $top) = split "-", $range;
$top ||= $bottom;
my $bottom_commit = $gs->find_rev_after( $bottom, 1, $top );
^ permalink raw reply related
* Re: [PATCH]
From: Matthieu Moy @ 2013-03-01 11:53 UTC (permalink / raw)
To: Jan Pešta; +Cc: git
In-Reply-To: <004101ce1667$85bea730$913bf590$@certicon.cz>
Jan Pešta <jan.pesta@certicon.cz> writes:
> Attached patch fix this issue,
Nothing attached, it seems ;-).
Please, read Documentation/SubmittingPatches in Git's source code.
--
Matthieu Moy
http://www-verimag.imag.fr/~moy/
^ permalink raw reply
* [PATCH]
From: Jan Pešta @ 2013-03-01 10:28 UTC (permalink / raw)
To: git
In-Reply-To: <002b01ce1661$245ebb70$6d1c3250$@certicon.cz>
Hi,
I found a problem when using GIT-SVN.
In inproperly merges in SVN causes that the ranges contains additional
character "*".
Attached patch fix this issue, I have it already tested for several months.
Regards,
Jan
Kind regards / S pozdravem
Jan Pešta
SW Engineer Sr.
CertiCon a.s., www.certicon.cz
Vaclavska 12
12000 Prague 2
Czech Republic
Office Prague: +420 224 904 406
Mobile: +420 604 794 306
E-mail: jan.pesta@certicon.cz
^ permalink raw reply
* Adding "--ignore-submodules" switch to git-describe
From: Francis Moreau @ 2013-03-01 10:16 UTC (permalink / raw)
To: git
Hello,
Would it make sense to add the option --ignore-submodules (currently
available in git-status) to git-describe when the later is used with
--dirty option ?
Thanks
--
Francis
^ 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