* Re: Finding all commits which modify a file
From: Santi Béjar @ 2012-01-24 1:15 UTC (permalink / raw)
To: Neal Groothuis; +Cc: Neal Kreitzinger, git, Linus Torvalds, Junio C Hamano
In-Reply-To: <CA+gHt1DxY42W9g+gJQTFrXuXBN-Jny+Jg60gKssdftZ5wxu91A@mail.gmail.com>
On Tue, Jan 24, 2012 at 1:58 AM, Santi Béjar <santi@agolina.net> wrote:
> [Note: CC main authors of the code surrounding the patch]
>
> On Mon, Jan 23, 2012 at 5:14 PM, Neal Groothuis <ngroot@lo-cal.org> wrote:
>>> On 1/20/2012 3:35 PM, Neal Groothuis wrote:
>>>> I'm trying to find /all/ commits that change a file in the
>>>> repository...and its proving to be trickier than I thought. :-)
>>
>> On 1/21/2012 6:16 PM, Neal Kreitzinger wrote:
>>> Does git-log --all help?
>>
>> I don't see how it would. The commits are all reachable from HEAD, which
>> would seem to be the problem that --all would correct.
>>
>> What I'm trying to do is find the commits in which a file differs from
>> that same file in any of its parents.
>
> If you add parent rewriting (--parent, --graph or see it in gitk, with
> --full-history) you'll get your B2 commit as it adds commits to have a
> meaningful history. But I don't think this is what you are asking for.
Note that even if it get listed, you won't get a diff for foo.txt
because it is an evil merge as the result is not the expected (using
the three way merge) one but is equal to one of the branches.
HTH,
Santi
^ permalink raw reply
* Re: Finding all commits which modify a file
From: Linus Torvalds @ 2012-01-24 1:15 UTC (permalink / raw)
To: Santi Béjar; +Cc: Neal Groothuis, Neal Kreitzinger, git, Junio C Hamano
In-Reply-To: <CA+gHt1DxY42W9g+gJQTFrXuXBN-Jny+Jg60gKssdftZ5wxu91A@mail.gmail.com>
On Mon, Jan 23, 2012 at 4:58 PM, Santi Béjar <santi@agolina.net> wrote:
>
> If you add parent rewriting (--parent, --graph or see it in gitk, with
> --full-history) you'll get your B2 commit as it adds commits to have a
> meaningful history. But I don't think this is what you are asking for.
>
> You could try the following patch (sorry for the whitespace damage,
> also attatched):
>
> Subject: [PATCH/RFC] revision: merging branches with different content
> is interesting in --full-history
The concept seems sane.
But please check the interaction with "--simplify-merges" too, just in
case. The merge simplification looks at TREESAME too, so I suspect
your change may break merge simplification.
Linus
^ permalink raw reply
* Re: Finding all commits which modify a file
From: Santi Béjar @ 2012-01-24 1:36 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Neal Groothuis, Neal Kreitzinger, git, Junio C Hamano
In-Reply-To: <CA+55aFynLN7kBYh7i-kh+Xd1Qn-wKBePcokmJRNfe8RYA0cCZA@mail.gmail.com>
On Tue, Jan 24, 2012 at 2:15 AM, Linus Torvalds
<torvalds@linux-foundation.org> wrote:
> On Mon, Jan 23, 2012 at 4:58 PM, Santi Béjar <santi@agolina.net> wrote:
>>
>> If you add parent rewriting (--parent, --graph or see it in gitk, with
>> --full-history) you'll get your B2 commit as it adds commits to have a
>> meaningful history. But I don't think this is what you are asking for.
>>
>> You could try the following patch (sorry for the whitespace damage,
>> also attatched):
>>
>> Subject: [PATCH/RFC] revision: merging branches with different content
>> is interesting in --full-history
>
> The concept seems sane.
>
> But please check the interaction with "--simplify-merges" too, just in
> case. The merge simplification looks at TREESAME too, so I suspect
> your change may break merge simplification.
Indeed, there is a bad interaction with --simplify-merges. If you add
--simplify-merges it not only increase the number of commit but
changes them :-(
$ ./git rev-list --full-history --simplify-merges HEAD Makefile >
rev-list.simp-merges
$ ./git rev-list --full-history HEAD Makefile > rev-list.new
$ diff rev-list.new rev-list.simp-merges -u | diffstat
rev-list.simp-merges | 1841 ++++++++++++++++++++++++++-------------------------
1 file changed, 944 insertions(+), 897 deletions(-)
Santi
^ permalink raw reply
* Re: Finding all commits which modify a file
From: Junio C Hamano @ 2012-01-24 1:40 UTC (permalink / raw)
To: Santi Béjar; +Cc: Neal Groothuis, Neal Kreitzinger, git, Linus Torvalds
In-Reply-To: <CA+gHt1DxY42W9g+gJQTFrXuXBN-Jny+Jg60gKssdftZ5wxu91A@mail.gmail.com>
Santi Béjar <santi@agolina.net> writes:
> diff --git a/revision.c b/revision.c
> index 064e351..db97250 100644
> --- a/revision.c
> +++ b/revision.c
> @@ -492,7 +492,7 @@ static void try_to_simplify_commit(struct rev_info
> *revs, struct commit *commit)
> }
> die("bad tree compare for commit %s",
> sha1_to_hex(commit->object.sha1));
> }
> - if (tree_changed && !tree_same)
> + if ((tree_changed && !tree_same) || (!revs->simplify_history
> && tree_changed))
Is that the same as saying this?
if (!(tree_same && revs->simplify_history) && tree_changed)
return;
Which reads: unless we find a parent that matches the result and we are
simplifying the history, a child different from at least one parent is
worth showing.
Which makes sort of sense at the conceptual level, but I am not sure if it
is practically useful (the same issue with --full-history that makes
complex history almost unreadable).
^ permalink raw reply
* HEAD file location
From: mfine @ 2012-01-24 3:42 UTC (permalink / raw)
To: git
I'm working on a Git project and had a question about HEAD.
In our remote Git repository, I see the file
git_repo_home/HEAD
and another file
git_repo_home/refs/heads/HEAD
The content of the former file is refs/heads/master which looks ok because
we want HEAD pointing at master.
However, should the latter file exist? I had thought only branches
should exist in /refs/heads and HEAD isn't a branch right? I'm wondering
if we erroneously created a HEAD branch.
Thanks for any help!
^ permalink raw reply
* Re: HEAD file location
From: Sitaram Chamarty @ 2012-01-24 3:52 UTC (permalink / raw)
To: mfine; +Cc: git
In-Reply-To: <loom.20120124T043119-263@post.gmane.org>
On Tue, Jan 24, 2012 at 9:12 AM, mfine <eboats@gmail.com> wrote:
> I'm working on a Git project and had a question about HEAD.
>
> In our remote Git repository, I see the file
>
> git_repo_home/HEAD
>
> and another file
>
> git_repo_home/refs/heads/HEAD
>
> The content of the former file is refs/heads/master which looks ok because
> we want HEAD pointing at master.
>
> However, should the latter file exist? I had thought only branches
> should exist in /refs/heads and HEAD isn't a branch right? I'm wondering
> if we erroneously created a HEAD branch.
Yes. Someone did something like 'git push origin HEAD:HEAD'
^ permalink raw reply
* Re: Cannot push a commit
From: Matthias Fechner @ 2012-01-24 6:53 UTC (permalink / raw)
To: Jeff King; +Cc: git
In-Reply-To: <20120119020913.GA20219@sigill.intra.peff.net>
Am 19.01.2012 03:09, schrieb Jeff King:
> Thanks for following up on this. It does seem like openssh is dropping
> your connection in a half-duplex way, though we don't know why. A bug in
> openssh sounds like a reasonable candidate...
I was now able to track the problem down to the command which is causing
the problem.
If you install git and you have tortoise-svn installed the installer
select as ssh client tortoiseplink.exe and this is the program which has
the bug.
I changed the system back to the ssh.exe which comes with the git
installer and it is working fine.
I downloaded the plink.exe (dev version) for the putty homepage and it
works fine.
If i use the tortoiseplink.exe again it fails.
Hopefully this will help some ppl to solve there problem too.
I'll start to do some tests if the same problem will raise with svn too
and I ask the tortoise-svn devs to replace the tortoiseplink.exe by a
newer version.
Thanks a lot for your help.
Bye
Matthias
--
"Programming today is a race between software engineers striving to
build bigger and better idiot-proof programs, and the universe trying to
produce bigger and better idiots. So far, the universe is winning." --
Rich Cook
^ permalink raw reply
* Re: [PATCH] Don't search files with an unset "grep" attribute
From: Junio C Hamano @ 2012-01-24 6:59 UTC (permalink / raw)
To: Conrad Irwin; +Cc: git, Nguyen Thai Ngoc Duy, Dov Grobgeld
In-Reply-To: <1327359555-29457-1-git-send-email-conrad.irwin@gmail.com>
Conrad Irwin <conrad.irwin@gmail.com> writes:
>> in order to avoid uselessly spewing garbage at you while reminding you
>> that the command is not showing the whole truth and you _might_ want to
>> look into the elided file if you wanted to with "grep -a world hello.o".
>> Compared to this, it feels that the result your patch goes too far and
>> hides the truth a bit too much to my taste. Maybe it is just me.
>
> I used to use this approach, hooking into the "diff" attribute directly to mark
> a file as binary, however that was clearly a hack.
After thinking about this a bit more, I have to say I disagree that it is
a hack.
I agree that the issue you are trying to address is real, but I think the
approach taken by the patch is flawed on three counts:
- You cannot do "grep -a" equivalent once you set your "-grep" attribute;
- The user has flexibility to set "diff" and "grep" independently, which
is an unnecessary complication [*1*]; and
- The user does not get any hint that potential hits are elided, like
normal "grep" would do.
I also think we can fix the above problems, while simplifying the external
interface visible to the end users.
So let's step back a bit and take a look at the handling of files for
which you do not want to see patch output and/or you do not want to see
grep hits, in a fictional but realisitic use scenario.
I am building a small embedded applicance that links with a binary blob
firmware, xyzzy.so, supplied by an upstream vendor, and this blob is
updated from time to time. In order to keep track of what binary blob went
into which product release, this binary blob is stored in the repository
together with the source files. Because it is useless to view binary
changes in "git log -p" output, I would naturally mark this as "binary".
Now, is it realistic to expect that I might want to see "grep" hits from
this binary blob? I do not think so [*2*].
When I say "xyzzy.so is a binary" in my .gitattributes file, according to
the current documentation, I am saying that "do not run diff, and also do
not run EOL conversion on this file" [*3*], but from the end user's point
of view, it is natural that I am entitled to expect much more than that.
Without having to know how many different kinds of textual operations the
SCM I happen to be using supports, I am telling it that I do not want to
see _any_ textual operations done on it. If a new version of "git grep"
learns to honor the attributes system, I want my "this is binary" to be
considered by the improved "git grep".
If you think about it this way from the very high level description of the
problem, aka, end user's point of view, it is fairly clear that tying the
"binary" attribute to "git grep" to allow us to override the built-in
buffer_is_binary() call you see in grep.c gives the most intuitive result,
without forcing the user to do anything more than they are already doing.
Because "binary" decomposes to "-diff" and "-text", we have two choices.
We _could_ say "-text" should be the one that overrides buffer_is_binary()
autodetection, but using "-diff" instead for that purpose opens the door
for us to give our users even more intuitive and consistent experience.
Suppose that this binary blob firmware came with an API manual formatted
in PDF, xyzzy.pdf, also supplied by the vendor. It is also kept in the
repository, but again, running textual diff between updated versions of
the PDF documentation would not be very useful. I however may have a
textconv filter defined for it to grab the text by running pdf2ascii.
Now if my "git show --textconv xyzzy.pdf" has an output line that says a
string "XYZZY API 2.0" was added to the current version, wouldn't it be
natural for me to expect that "git grep --textconv 'XYZZY API' xyzzy.pdf"
to find it [*4*]?
As an added bonus, if you truly want to omit _any_ hit from "git grep" for
your minified.js files, you can easily do so. Just define a textconv
filter that yields an empty string for them, and "grep --textconv" won't
produce any matches, not even "Binary file ... matches".
So I am inclined to think that reusing the infrastructure we already have
for the `diff` attribute as much as possible would be a better design for
this new feature you are proposing.
The name of the attribute `diff` is somewhat unfortunate, but the end user
interface to the feature at the highest level is already called "binary"
attribute (macro), and our low-level documentation can give precise
meaning of the attribute while alluding to the origin of the name so that
intelligent readers would understand it pretty easily (see attached
patch).
Besides, we already tell the users in "Marking files as binary" section to
mark them with "-diff" in the attributes file if they want their contents
treated as binary.
[Footnotes]
*1* An unused flexibility like this does nothing useful, other than
forcing the user to flip two attributes always as a pair, when one should
suffice.
*2* The essence of my previous message was "why it is insufficient to mark
them binary, i.e. uninteresting for the purpose of all textual operations
not just grep but also for diff." which was unanswered.
*3* This is because "binary" is defined as an attribute macro that expands
to "-diff -text".
*4* This also suggests that the infrastructure we already have for driving
"git diff" is a good match for "git grep". The "funcname" patterns, which
"git grep -p" already can borrow and use from "diff" infrastructure, is
another indication that using `diff` is a good match for "git grep".
Documentation/gitattributes.txt | 15 ++++++++++++---
1 files changed, 12 insertions(+), 3 deletions(-)
diff --git a/Documentation/gitattributes.txt b/Documentation/gitattributes.txt
index a85b187..63844c4 100644
--- a/Documentation/gitattributes.txt
+++ b/Documentation/gitattributes.txt
@@ -388,9 +388,18 @@ Generating diff text
`diff`
^^^^^^
-The attribute `diff` affects how 'git' generates diffs for particular
-files. It can tell git whether to generate a textual patch for the path
-or to treat the path as a binary file. It can also affect what line is
+The attribute `diff` affects if `git` treats the contents of file as text
+or binary. Historically, `git diff` and its friends were the first to use
+this attribute, hence its name, but the attribute governs textual
+operations in general, including `git grep`.
+
+For `git diff` and its friends, differences in contents marked as text
+produces a textual patch, while differences in non-text are reported only
+as "Binary files differ". For `git grep`, matches in contents marked as
+text are reported by showing lines that contain them, while matches in
+non-text are reported only as "Binary file ... matches".
+
+This attribute can also affect what line is
shown on the hunk header `@@ -k,l +n,m @@` line, tell git to use an
external command to generate the diff, or ask git to convert binary
files to a text format before generating the diff.
^ permalink raw reply related
* Re: [PATCH v3 06/10] clone: delay cloning until after remote HEAD checking
From: Nguyen Thai Ngoc Duy @ 2012-01-24 7:01 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Jeff King
In-Reply-To: <7vvco253xx.fsf@alter.siamese.dyndns.org>
2012/1/24 Junio C Hamano <gitster@pobox.com>:
> Recently, 6f48d39 (clone: delay cloning until after remote HEAD checking,
> 2012-01-16) tried to record if a remote helper needs to be called after
> parsing the remote when transport_get() is called, by overwriting the
> field meant to store the configured remote helper name in the remote
> structure.
>
> This is OK when a remote represents a single remote repository, but fails
> miserably when pushing to locations with multiple URLs, like this:
>
> $ cat .git/config
> [remote "origin"]
> url = https://code.google.com/p/git-htmldocs/
> url = github.com:gitster/git-htmldocs.git
> push = refs/heads/master:refs/heads/master
My bad. remote.*.vcs (or remote->foreign_vcs) is designed to override
remote helper detection based on url. Once you have pushed over https,
the following urls will be over https too. Luckily no other places
perform an operation over multiple urls like push so we're safe with
your bandage.
We should have another way to detect whether remote helper being used
(comparing some function pointers like transport->connect or
transport->disconnect may help). But I need to think a bit about
delaying cloning for http(s) too even though remote helper is used.
--
Duy
^ permalink raw reply
* Re: [Q] Determing if a commit is reachable from the HEAD ?
From: Brian Foster @ 2012-01-24 8:16 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git mailing list, Sitaram Chamarty
In-Reply-To: <7vk44i9z99.fsf@alter.siamese.dyndns.org>
On Monday 23 January 2012 17:09:38 Junio C Hamano wrote:
> Brian Foster <brian.foster@maxim-ic.com> writes:
> > I am probably misunderstanding ‘--quiet’, which the
> > man page cryptically describes as “... allow the
> > caller to test the exit status to see if a range
> > of objects is fully connected (or not).” What is
> > meant here by “fully connected” ?
>
> If the real history looks like this:
>
> ---Y---x---HEAD
>
> i.e. the commit at HEAD says "parent x" in it, and your lacks "x"
> for whatever reason, Y..HEAD is not fully connected.
Junio, and my _what_ lacks "x"? Sorry, it looks like
you typo'ed, but I cannot decipher what you meant.
cheers!
-blf-
--
Brian Foster
Principal MTS, Software | La Ciotat, France
Maxim Integrated Products | Web: http://www.maxim-ic.com/
^ permalink raw reply
* Re: What's cooking in git.git (Jan 2012, #05; Mon, 23)
From: Michael Haggerty @ 2012-01-24 8:35 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vmx9d6hpw.fsf@alter.siamese.dyndns.org>
On 01/24/2012 01:56 AM, Junio C Hamano wrote:
> Here are the topics that have been cooking. [...]
> * mh/ref-api-rest (2011-12-12) 35 commits
> . [...]
>
> I had to remove this temporarily out of 'pu' as I didn't want to deal with
> merge conflicts with the mh/ref-clone-without-extra-refs topic that
> removes yet another caller of add_extra_ref() that this series touches.
Yes, I agree; the branch can be put on ice. After I find the time to
remove the last user of extra_refs, I plan to rework the branch with no
support for extra_refs at all.
Michael
--
Michael Haggerty
mhagger@alum.mit.edu
http://softwareswirl.blogspot.com/
^ permalink raw reply
* Re: [Q] Determing if a commit is reachable from the HEAD ?
From: Brian Foster @ 2012-01-24 8:56 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git mailing list, Sitaram Chamarty
In-Reply-To: <7vk44i9z99.fsf@alter.siamese.dyndns.org>
On Monday 23 January 2012 17:09:38 Junio C Hamano wrote:
> Brian Foster <brian.foster@maxim-ic.com> writes:
> > I am probably misunderstanding ‘--quiet’, which the
> > man page cryptically describes as “... allow the
> > caller to test the exit status to see if a range
> > of objects is fully connected (or not).” What is
> > meant here by “fully connected” ?
>
> If the real history looks like this:
>
> ---Y---x---HEAD
>
> i.e. the commit at HEAD says "parent x" in it, and your [repository]
> lacks "x" for whatever reason, Y..HEAD is not fully connected.
Ah, Ok. Thanks! Then YES, I misunderstood ‘--quiet’.
The man page caused me to think it was functionally
equivalent to ‘git rev-list STUFF >/dev/null’.
cheers!
-blf-
--
Brian Foster
Principal MTS, Software | La Ciotat, France
Maxim Integrated Products | Web: http://www.maxim-ic.com/
^ permalink raw reply
* [PATCH] clone: fix up delay cloning conditions
From: Nguyễn Thái Ngọc Duy @ 2012-01-24 11:10 UTC (permalink / raw)
To: git; +Cc: Junio C Hamano, Jeff King, Nguyễn Thái Ngọc Duy
6f48d39 (clone: delay cloning until after remote HEAD checking -
2012-01-16) allows us to perform some checks on remote refs before the
actual cloning happens. But not all transport types support
this. Remote helper with "import" capability will not return complete
ref information until fetch is performed and therefore the clone cannot
be delayed.
foreign_vcs field in struct remote was used to detect this kind of transport
and save the result. This is a mistake because foreign_vcs is designed
to override url-based transport detection. As a result, if the same
"struct transport *" object is used on many different urls and one of
them attached remote transport, the following urls will be mistakenly
attached to the same transport. This fault is worked around by dad0b3d
(push: do not let configured foreign-vcs permanently clobbered -
2012-01-23)
To fix this, detect incomplete refs from transport_get_remote_refs()
by SHA-1. Incomplete ones must have null SHA-1 (*). Then revert
changes related to foreign_cvs field in 6f48d39 and dad0b3d.
A good thing from this change is that cloning smart http transport can
also be delayed. Earlier it falls into the same category "remote
transport, no delay".
(*) Theoretically if one of the remote refs happens to have null SHA-1,
it will trigger false alarm and the clone will not be delayed. But
that chance may be too small for us to pay attention to.
Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com>
---
builtin/clone.c | 20 ++++++++++++++------
builtin/push.c | 2 --
transport.c | 5 +----
3 files changed, 15 insertions(+), 12 deletions(-)
diff --git a/builtin/clone.c b/builtin/clone.c
index 72eebca..379cafa 100644
--- a/builtin/clone.c
+++ b/builtin/clone.c
@@ -631,12 +631,13 @@ int cmd_clone(int argc, const char **argv, const char *prefix)
const struct ref *remote_head_points_at;
const struct ref *our_head_points_at;
struct ref *mapped_refs;
+ const struct ref *ref;
struct strbuf key = STRBUF_INIT, value = STRBUF_INIT;
struct strbuf branch_top = STRBUF_INIT, reflog_msg = STRBUF_INIT;
struct transport *transport = NULL;
const char *src_ref_prefix = "refs/heads/";
struct remote *remote;
- int err = 0;
+ int err = 0, complete_refs_before_fetch = 1;
struct refspec *refspec;
const char *fetch_pattern;
@@ -816,15 +817,22 @@ int cmd_clone(int argc, const char **argv, const char *prefix)
mapped_refs = refs ? wanted_peer_refs(refs, refspec) : NULL;
/*
- * mapped_refs may be updated if transport-helper is used so
- * we need fetch it early because remote_head code below
- * relies on it.
+ * transport_get_remote_refs() may return refs with null sha-1
+ * in mapped_refs (see struct transport->get_refs_list
+ * comment). In that case we need fetch it early because
+ * remote_head code below relies on it.
*
* for normal clones, transport_get_remote_refs() should
* return reliable ref set, we can delay cloning until after
* remote HEAD check.
*/
- if (!is_local && remote->foreign_vcs && refs)
+ for (ref = refs; ref; ref = ref->next)
+ if (is_null_sha1(ref->old_sha1)) {
+ complete_refs_before_fetch = 0;
+ break;
+ }
+
+ if (!is_local && !complete_refs_before_fetch && refs)
transport_fetch_refs(transport, mapped_refs);
if (refs) {
@@ -856,7 +864,7 @@ int cmd_clone(int argc, const char **argv, const char *prefix)
if (is_local)
clone_local(path, git_dir);
- else if (refs && !remote->foreign_vcs)
+ else if (refs && complete_refs_before_fetch)
transport_fetch_refs(transport, mapped_refs);
update_remote_refs(refs, mapped_refs, remote_head_points_at,
diff --git a/builtin/push.c b/builtin/push.c
index 5fb98a0..35cce53 100644
--- a/builtin/push.c
+++ b/builtin/push.c
@@ -204,13 +204,11 @@ static int do_push(const char *repo, int flags)
url_nr = remote->url_nr;
}
if (url_nr) {
- const char *configured_foreign_vcs = remote->foreign_vcs;
for (i = 0; i < url_nr; i++) {
struct transport *transport =
transport_get(remote, url[i]);
if (push_with_options(transport, flags))
errs++;
- remote->foreign_vcs = configured_foreign_vcs;
}
} else {
struct transport *transport =
diff --git a/transport.c b/transport.c
index 4366639..a99b7c9 100644
--- a/transport.c
+++ b/transport.c
@@ -895,10 +895,8 @@ struct transport *transport_get(struct remote *remote, const char *url)
while (is_urlschemechar(p == url, *p))
p++;
- if (!prefixcmp(p, "::")) {
+ if (!prefixcmp(p, "::"))
helper = xstrndup(url, p - url);
- remote->foreign_vcs = helper;
- }
}
if (helper) {
@@ -940,7 +938,6 @@ struct transport *transport_get(struct remote *remote, const char *url)
char *handler = xmalloc(len + 1);
handler[len] = 0;
strncpy(handler, url, len);
- remote->foreign_vcs = handler;
transport_helper_init(ret, handler);
}
--
1.7.8.36.g69ee2
^ permalink raw reply related
* Re: rsync a *bunch* of git repos
From: Jason @ 2012-01-24 14:11 UTC (permalink / raw)
To: Seth Robertson; +Cc: git
In-Reply-To: <201201102124.q0ALOowL026941@no.baka.org>
Hi Seth,
On Tue, Jan 10, 2012 at 04:24:50PM -0500, Seth Robertson wrote:
>
> In message <20120110211548.GD10255@titan.lakedaemon.net>, Jason writes:
>
> The nuts and bolts of this aren't difficult, the problem is I don't have
> a complete understanding of how git stores data. I've heard in the
> past that it uses a lot of hardlinks and softlinks. I need to make
> sure, that once I transfer the data, and reboot the machine with the new
> partition mounted under /home, that all my git repos will be okay.
>
> Under most circumstances, git will do the right thing. Only if you
> use specific flags on clone (like --shared or --reference) might
> something go wrong, and as the manual page explains, you can use
> git-repack to undo these.
>
> The real solution is, after you rsync, to:
>
> for f in */.git; do (cd $f; git fsck >&/dev/null || echo "$f is BAD!!"); done
Okay, I've been using the new system for a week or so now, and
everything looks good. Thanks!
Before the transfer, I went ahead and did the above to make sure the
repos were good to begin with. All 279 of them were fine, both before
and after.
thx,
Jason.
^ permalink raw reply
* Most reliable method to detect a merge commit in pre-commit hook
From: Sebastian Schuberth @ 2012-01-24 14:16 UTC (permalink / raw)
To: git
Hi,
I'd like our pre-commit hook to skip some checks if the commit that's
about to be made is a merge commit. What's the most reliable way to
detect a merge commit from within a pre-commit hook script? Currently,
the only way I see is to check whether .git/MERGE_MSG exists, but I'd
feel safer to check whether the commit is going to have more than one
parent or so. Is that possible / a better detection?
--
Sebastian Schuberth
^ permalink raw reply
* Re: Most reliable method to detect a merge commit in pre-commit hook
From: Stefan Haller @ 2012-01-24 15:10 UTC (permalink / raw)
To: Sebastian Schuberth, git
In-Reply-To: <jfmegi$scg$1@dough.gmane.org>
Sebastian Schuberth <sschuberth@gmail.com> wrote:
> I'd like our pre-commit hook to skip some checks if the commit that's
> about to be made is a merge commit. What's the most reliable way to
> detect a merge commit from within a pre-commit hook script? Currently,
> the only way I see is to check whether .git/MERGE_MSG exists, but I'd
> feel safer to check whether the commit is going to have more than one
> parent or so. Is that possible / a better detection?
I haven't found a better way either, so this is the method we use too.
The problem is that it fails when you are amending a merge commit; so
the output of our pre-commit hook advises the user to manually do a "git
commit --no-verify" in that case.
--
Stefan Haller
Berlin, Germany
http://www.haller-berlin.de/
^ permalink raw reply
* Re: [ANNOUNCE] Git 1.7.9.rc2
From: fREW Schmidt @ 2012-01-24 16:16 UTC (permalink / raw)
To: git, Linux Kernel
In-Reply-To: <7vpqegjxu3.fsf@alter.siamese.dyndns.org>
On Wed, Jan 18, 2012 at 7:16 PM, Junio C Hamano <gitster@pobox.com> wrote:
> * gitk updates accumulated since early 2011.
Where might one go to find more detail on this one?
--
fREW Schmidt
http://blog.afoolishmanifesto.com
^ permalink raw reply
* Re: Finding all commits which modify a file
From: Neal Groothuis @ 2012-01-24 16:34 UTC (permalink / raw)
To: Santi Béjar; +Cc: git
In-Reply-To: <CA+gHt1DxY42W9g+gJQTFrXuXBN-Jny+Jg60gKssdftZ5wxu91A@mail.gmail.com>
> On Mon, Jan 23, 2012 at 5:14 PM, Neal Groothuis <ngroot@lo-cal.org> wrote:
>>> On 1/20/2012 3:35 PM, Neal Groothuis wrote:
>>>> I'm trying to find /all/ commits that change a file in the
>>>> repository...and its proving to be trickier than I thought. :-)
>>
>> On 1/21/2012 6:16 PM, Neal Kreitzinger wrote:
>>> Does git-log --all help?
>>
>> I don't see how it would. The commits are all reachable from HEAD,
>> which
>> would seem to be the problem that --all would correct.
>>
>> What I'm trying to do is find the commits in which a file differs from
>> that same file in any of its parents.
>
> If you add parent rewriting (--parent, --graph or see it in gitk, with
> --full-history) you'll get your B2 commit as it adds commits to have a
> meaningful history. But I don't think this is what you are asking for.
Correct. If I add parent rewriting, I get all merges, even those in which
the file is not changed from either parent.
Based on what's in the man page for git log about the history
simplification algorithm, it seems that B2 should be included in the
output when I do a git log --full-history --simplify-history foo.txt, as
per the steps I noted in the original post. Is my understanding of the
algorithm faulty?
^ permalink raw reply
* Correct way to pull using subtree merge without guesswork?
From: Manuel Reimer @ 2012-01-24 17:49 UTC (permalink / raw)
To: git
Hello,
can someone please tell me, if this is the correct syntax for using "git pull"
to pull in "subtree merging strategy", if I don't want to allow git to guess
where to do the changes:
git pull -s subtree -X subtree=path/to/subtree externalproject master
Returns with success, but is "-X subtree=" the right way to force a subtree path
and disallow git to autodetect the subtree?
$ git --version
git version 1.7.4.4
Thank you very much in advance
Yours
Manuel
^ permalink raw reply
* Re: Finding all commits which modify a file
From: Santi Béjar @ 2012-01-24 18:10 UTC (permalink / raw)
To: Neal Groothuis, Junio C Hamano, Linus Torvalds; +Cc: git
In-Reply-To: <52932.38.96.167.131.1327422884.squirrel@mail.lo-cal.org>
[ Do not cut the CC]
On Tue, Jan 24, 2012 at 5:34 PM, Neal Groothuis <ngroot@lo-cal.org> wrote:
>> On Mon, Jan 23, 2012 at 5:14 PM, Neal Groothuis <ngroot@lo-cal.org> wrote:
>>>> On 1/20/2012 3:35 PM, Neal Groothuis wrote:
>>>>> I'm trying to find /all/ commits that change a file in the
>>>>> repository...and its proving to be trickier than I thought. :-)
>>>
>>> On 1/21/2012 6:16 PM, Neal Kreitzinger wrote:
>>>> Does git-log --all help?
>>>
>>> I don't see how it would. The commits are all reachable from HEAD,
>>> which
>>> would seem to be the problem that --all would correct.
>>>
>>> What I'm trying to do is find the commits in which a file differs from
>>> that same file in any of its parents.
>>
>> If you add parent rewriting (--parent, --graph or see it in gitk, with
>> --full-history) you'll get your B2 commit as it adds commits to have a
>> meaningful history. But I don't think this is what you are asking for.
>
> Correct. If I add parent rewriting, I get all merges, even those in which
> the file is not changed from either parent.
>
> Based on what's in the man page for git log about the history
> simplification algorithm, it seems that B2 should be included in the
> output when I do a git log --full-history --simplify-history foo.txt, as
> per the steps I noted in the original post. Is my understanding of the
> algorithm faulty?
>
Following your steps in the first post, B2 is excluded in the
--simplify-merge phase because it is (originally) TREESAME, even if it
is not in the rewritten history...
HTH,
Santi
^ permalink raw reply
* Re: [ANNOUNCE] Git 1.7.9.rc2
From: Junio C Hamano @ 2012-01-24 18:11 UTC (permalink / raw)
To: fREW Schmidt; +Cc: git
In-Reply-To: <CADVrmKT2RAOC-n_-h4pGJw91imj28h0-HqwGH-NOu-m3XtqiJg@mail.gmail.com>
fREW Schmidt <frioux@gmail.com> writes:
> On Wed, Jan 18, 2012 at 7:16 PM, Junio C Hamano <gitster@pobox.com> wrote:
>> * gitk updates accumulated since early 2011.
>
> Where might one go to find more detail on this one?
Hmm, http://git.kernel.org/?p=git/git.git;a=shortlog, perhaps?
^ permalink raw reply
* Re: Correct way to pull using subtree merge without guesswork?
From: Junio C Hamano @ 2012-01-24 18:27 UTC (permalink / raw)
To: Manuel Reimer; +Cc: git
In-Reply-To: <jfmr88$1p8$1@dough.gmane.org>
Manuel Reimer <Manuel.Spam@nurfuerspam.de> writes:
> git pull -s subtree -X subtree=path/to/subtree externalproject master
>
> Returns with success, but is "-X subtree=" the right way to force a
> subtree path and disallow git to autodetect the subtree?
More or less. Note that with the syntax, you cannot still express the
distinction between mapping the root of external to path/to/subtree of
your current tree and mapping the other way around, but that is not an
issue in practice.
By the way, I had an impression that "-X subtree" makes "-s subtree"
redundant and unnecessary.
^ permalink raw reply
* Re: Finding all commits which modify a file
From: Santi Béjar @ 2012-01-24 18:35 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Neal Groothuis, Neal Kreitzinger, git, Junio C Hamano
In-Reply-To: <CA+gHt1AYrCv_9MJwBntt_+-GRb4N81PxxO8HXP-XU0pCiFWAVw@mail.gmail.com>
On Tue, Jan 24, 2012 at 2:36 AM, Santi Béjar <santi@agolina.net> wrote:
> On Tue, Jan 24, 2012 at 2:15 AM, Linus Torvalds
> <torvalds@linux-foundation.org> wrote:
>> On Mon, Jan 23, 2012 at 4:58 PM, Santi Béjar <santi@agolina.net> wrote:
>>>
>>> If you add parent rewriting (--parent, --graph or see it in gitk, with
>>> --full-history) you'll get your B2 commit as it adds commits to have a
>>> meaningful history. But I don't think this is what you are asking for.
>>>
>>> You could try the following patch (sorry for the whitespace damage,
>>> also attatched):
>>>
>>> Subject: [PATCH/RFC] revision: merging branches with different content
>>> is interesting in --full-history
>>
>> The concept seems sane.
>>
>> But please check the interaction with "--simplify-merges" too, just in
>> case. The merge simplification looks at TREESAME too, so I suspect
>> your change may break merge simplification.
>
> Indeed, there is a bad interaction with --simplify-merges. If you add
> --simplify-merges it not only increase the number of commit but
> changes them :-(
>
> $ ./git rev-list --full-history --simplify-merges HEAD Makefile >
> rev-list.simp-merges
> $ ./git rev-list --full-history HEAD Makefile > rev-list.new
> $ diff rev-list.new rev-list.simp-merges -u | diffstat
> rev-list.simp-merges | 1841 ++++++++++++++++++++++++++-------------------------
> 1 file changed, 944 insertions(+), 897 deletions(-)
Ops, it even happens without my patch...
I think it is OK, it just redefines what is TREESAME, and use the new
meaning in:
* If after this parent rewriting, `C'` is a root or merge commit (has
zero or >1 parents), a boundary commit, or !TREESAME, it remains.
Otherwise, it is replaced with its only parent.
We could keep the old meaning if --simplify-merges or we could have a
flag to just change the meaning of TREESAME for merges
(--with-all-interesting-merges? I'm not good at naming flags...)
Santi
^ permalink raw reply
* Re: What does "modified" in git status mean?
From: Jeff King @ 2012-01-24 18:57 UTC (permalink / raw)
To: Mikolas; +Cc: git
In-Reply-To: <loom.20120122T174204-274@post.gmane.org>
On Sun, Jan 22, 2012 at 04:57:52PM +0000, Mikolas wrote:
> So it looks something like this:
> $ git status
> # On branch master
> nothing to commit (working directory clean)
>
> $ cd foo
> $ git status
> # On branch master
> # Changes not staged for commit:
> # (use "git add <file>..." to update what will be committed)
> # (use "git checkout -- <file>..." to discard changes in working directory)
> #
> # modified: ../foo/bar
Modified files appearing only in some calls to status is definitely odd,
and may be a bug. How close is this to your actual invocation?
In particular, if "foo/bar" is modified, and you do "cd foo && git
status", then the relative path shown by "git status" should be simply
"bar", not "../foo/bar". If you did "cd other && git status", then I
would expect it to say "../foo/bar".
So was the directory you entered the same as the one that contains the
(supposedly) modified file, yielding the output above?
If that is the case, then I might suspect it has to do with path
normalization and case sensitivity. It might be worth seeing if you can
reproduce the problem with a more recent version of git. In particular,
v1.7.8 and later shipped with my 2548183 (fix phantom untracked files
when core.ignorecase is set, 2011-10-06), which fixes some weird bugs
surrounding case-insensitive file lookup.
(Actually, even if that is not the case, it would be worth upgrading and
seeing if the bug is reproducible).
> So my questions are
> 1) Is there some way how to tell status to tell me *why* the files are marked
> as modified?
Typically you would ask "diff" for more details. But since "diff" is not
reporting anything, that isn't helpful (and is probably indicative of a
bug).
> 2) Is it normal that git status behaves differently in different directories?
No.
-Peff
^ permalink raw reply
* {Spam?} push pull not working
From: Rick Bragg @ 2012-01-24 19:00 UTC (permalink / raw)
To: GIT Mailing-list
Hi,
I cloned a repo from /home/me/repo1 to /home/me/repo2. Then made
changes and a new commit on repo1, then from repo1 did "git
push /home/me/repo2 and it says Everything is up-to-date. How could
this be?
Thanks
Rick
^ 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