* Re: Git SVN Rebranching Issue
From: Sverre Rabbelier @ 2008-11-04 10:15 UTC (permalink / raw)
To: Dmitry Potapov; +Cc: Eric Wong, Matt Kern, git
In-Reply-To: <20081104094224.GC24100@dpotapov.dyndns.org>
On Tue, Nov 4, 2008 at 10:42, Dmitry Potapov <dpotapov@gmail.com> wrote:
> On Tue, Nov 04, 2008 at 12:41:11AM -0800, Eric Wong wrote:
>> Short answer: you can use grafts to remove parents.
>
> Using grafts requires some cautious, especially when it is used to make
> some commits unreachable, because git gc can remove unreachable commits.
> Also, a repository with grafts cannot be cloned. So using grafts looks
> like more as workaround rather a real solution
I think what was meants is to use grafts and then make them permanent
with 'git filter-branch'.
--
Cheers,
Sverre Rabbelier
^ permalink raw reply
* Re: locate commit by file
From: Jakub Narebski @ 2008-11-04 9:57 UTC (permalink / raw)
To: Ittay Dror; +Cc: Git Mailing List
In-Reply-To: <491003BC.7040206@gmail.com>
Ittay Dror <ittay.dror@gmail.com> writes:
> Given a file, is there an easy way (e.g., not bisecting) to find the
> latest commit where the file content is the same?
>
> Meaning: I have a file /tmp/A and I want to file the latest commit
> where a/b/A is identical (content wise) to /tmp/A.
Do you mean: find the commit which changed file to current version?
I think that
$ git rev-parse -1 -- file
Would work (but better check "git log -- file").
If you want to find which version corresponds to given contents, you
would have to find sha-1 of /tmp/A (using "git hash-object"), and
find it in difftree searching for sha ("git log --raw -- file", or
just "git log --raw" if you are not sure about name).
I think you can fins such script in mailing list archives...
--
Jakub Narebski
Poland
ShadeHawk on #git
^ permalink raw reply
* Re: Git SVN Rebranching Issue
From: Dmitry Potapov @ 2008-11-04 9:42 UTC (permalink / raw)
To: Eric Wong; +Cc: Matt Kern, git
In-Reply-To: <20081104084111.GB14405@untitled>
On Tue, Nov 04, 2008 at 12:41:11AM -0800, Eric Wong wrote:
>
> Short answer: you can use grafts to remove parents.
Using grafts requires some cautious, especially when it is used to make
some commits unreachable, because git gc can remove unreachable commits.
Also, a repository with grafts cannot be cloned. So using grafts looks
like more as workaround rather a real solution.
>
> It was actually an intentional design decision on my part preserve
> parents based on branch name. We would eventually otherwise lose
> history of the now-deleted branches, as reflogs can expire.
Would it not be better to save the old branch using "@SVN-NUMBER" as
suffix? Thus, those do not need the old branch can easily delete it.
Dmitry
^ permalink raw reply
* Re: [PATCH] Documentation: add a planning document for the next CLI revamp
From: Dmitry Potapov @ 2008-11-04 9:18 UTC (permalink / raw)
To: Sam Vilain
Cc: Junio C Hamano, Jeff King, Sam Vilain, git, Johannes Schindelin,
Scott Chacon, Tom Preston-Werner, J.H., Christian Couder,
Kai Blin
In-Reply-To: <1225691960.20883.41.camel@maia.lan>
On Mon, Nov 03, 2008 at 06:59:20PM +1300, Sam Vilain wrote:
>
> I can see that some people want this behaviour by default; but to me
> "push the current branch back to where it came from" seems like far more
> a rational default for at least 90% of users.
I think it depends on one's workflow. If you use a centralized workflow
as with CVS then yes, 90% cases you want to push the current branch. On
the other hand, if people push their changes to the server only for
review, it means that accidentally pushing more than one intended is not
a big deal. The only one who does publishing to the official repository
is the maintainer, and the maintainer is most likely to run some tests
after merging all changes, which takes some time. So, it is rarely push
the current branch, it is usually the branch that has been tested, so
the name of the branch should be specified explicitly anyway.
Dmitry
^ permalink raw reply
* Re: [PATCH] push: fix local refs update if already up-to-date
From: Clemens Buchacher @ 2008-11-04 9:05 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Jeff King, git
In-Reply-To: <7v7i7jsx6a.fsf@gitster.siamese.dyndns.org>
On Tue, Nov 04, 2008 at 12:38:37AM -0800, Junio C Hamano wrote:
> Jeff King <peff@peff.net> writes:
>
> > Though I am not happy that we have to look up the tracking ref for every
> > uptodate ref. I think it shouldn't be a big performance problem with
> > packed refs, though, since they are cached (i.e., we pay only to compare
> > the hashes, not touch the filesystem for each ref).
>
> It is either (1) the user pays the cost of finding what remote tracking
> branch we are mirroring when you push for all up-to-date refs, like you
> did in your "here is an improvement" patch; or (2) the user pays the cost
> of fetching from there, immediately after pushing. I'd imagine that the
> cost to do (1) would be smaller than (2). The question is if seeing stale
> tracking branches is such a big deal, as next "git fetch" from there will
> update them anyway. If it is a big deal, (1) would be a price worth
> paying.
Right. I think it is a big deal. I found out about this bug, because a user
on #git was confused by the fact that push reported "Everything up-to-date",
even though there were changes. A fetch fixed that, of course. But it is
confusing and inconsistent with normal push behavior. So I really think it's
worth a small performance hit.
> Clemens, care to reroll the patch?
I will do so later today.
^ permalink raw reply
* Re: [PATCH] push: fix local refs update if already up-to-date
From: Clemens Buchacher @ 2008-11-04 8:56 UTC (permalink / raw)
To: Jeff King; +Cc: git, Junio C Hamano
In-Reply-To: <20081104042643.GA31276@coredump.intra.peff.net>
On Mon, Nov 03, 2008 at 11:26:44PM -0500, Jeff King wrote:
> > The hashcpy for new_ref is now executed more often than absolutely
> > necessary. But this is not a critical path, right? So I decided to keep
> > things simple.
>
[...]
> Your patch makes ref->new_sha1 "valid" for every status case. Ordinarily
> I would be in favor of that, since it reduces coupling with other parts
> of the code (which have to know _which_ status flags provide a useful
> value in ->new_sha1). But in this case, I think the value we would be
> sticking in is not necessarily useful for every status flag we end up
> setting; so any consumers of the ref structure still need to know which
> flags set it. So even though it has a defined value, it is not really
> "valid" in all cases.
The other status flags are REF_STATUS_REJECT_NODELETE and
REF_STATUS_REJECT_NONFASTFORWARD. So in these cases the "new sha1" is going
to be the "old sha1". The default for new_sha1 is the null sha1. So while
the sha1 we're trying to push may not be more valid than the null sha1, it's
not less valid either, is it? And it even makes sense if you interpret
new_sha1 as the sha1 the client attempts to push.
> Hmm. I was hoping to see more in update_tracking_ref. With your patch,
> we end up calling update_ref for _every_ uptodate ref, which results in
> writing a new unpacked ref file for each one. And that _is_ a
> performance problem for people with large numbers of refs.
>
> So I think we need a check to make sure we aren't just updating with the
> same value. Something like:
I think update_ref already takes care of that. See this check in
write_ref_sha1:
if (!lock->force_write && !hashcmp(lock->old_sha1, sha1)) {
unlock_ref(lock);
return 0;
}
> Though I am not happy that we have to look up the tracking ref for every
> uptodate ref. I think it shouldn't be a big performance problem with
> packed refs, though, since they are cached (i.e., we pay only to compare
> the hashes, not touch the filesystem for each ref).
I don't think we can avoid that, though.
I agree with your other comments.
^ permalink raw reply
* Re: [Q] Abbreviated history graph?
From: Junio C Hamano @ 2008-11-04 8:45 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Brian Foster, Git Mailing List
In-Reply-To: <alpine.LFD.2.00.0811031211180.3419@nehalem.linux-foundation.org>
Linus Torvalds <torvalds@linux-foundation.org> writes:
> On Mon, 3 Nov 2008, Linus Torvalds wrote:
>>
>> I'll post a simple series of four commits in a moment.
> ...
> Side note: it's certainly possible that we could improve on this. Right
> now, "--simplify-namespace" will totally override any path simplification,
> so you can't get a combination of pathnames _and_ naming commits. I don't
> know exactly what the rules should be, but I could imagine that we could
> do something like:
>
> - if no pathnames are given, work the way the current patch-series works.
>
> - if path-names are given, make rev_compare_tree() truen
> REV_TREE_DIFFERENT if a name decoration _or_ a tree difference exists.
>
> Anyway, that's a fairly trivial extension to the idea, and doesn't really
> matter for the basic code. It can easily be left for later.
Thanks.
Including this (and the --source one), the series looks reasonable.
^ permalink raw reply
* git-p4: Importing multiple p4 prods into same git repo
From: dhruva @ 2008-11-04 8:42 UTC (permalink / raw)
To: Git
Hi,
I have the p4 layout as follows:
1. //depot/prod/devel/main
2. //depot/prod/devel/hacks
where #2 is a sort of fork of #1. There are lot of common objects
between them and #2 can trace its history to #1. I would like to
import both the above paths under the same git repository as 2 remote
branches so that they can share objects and reduce overall size. Is
this possible using 'git-p4'. I went through the code and got lost in
the complexities...
I urgently need this to consolidate multiple paths under the same git
folder and be able to serve them soon. Any help is greatly
appreciated.
-dhruva
--
Contents reflect my personal views only!
^ permalink raw reply
* Re: Git SVN Rebranching Issue
From: Eric Wong @ 2008-11-04 8:41 UTC (permalink / raw)
To: Matt Kern; +Cc: git
In-Reply-To: <20081103140746.GA5969@mars.cyantechnology.local>
Matt Kern <matt.kern@undue.org> wrote:
> I have a git-svn issue which keeps biting me.
>
> My company uses svn as its primary version control system. We
> frequently create branches, e.g. /branches/somebranch, by forking the
> trunk to ensure stability over the "somebranch" code. The problem is
> that we also frequently blow away /branches/somebranch and refork it
> from the trunk.
>
> git-svn does a good job for most work, but I notice that if you delete
> the "somebranch" branch in svn and then refork it, also in svn, then
> when you git-svn fetch, the git commit at the head of remotes/somebranch
> will have two parents: the first is the previous head of
> remotes/somebranch, and the second is the head of remotes/trunk. Surely
> only the remotes/trunk parent should be listed? Any connection with the
> previous remotes/somebranch is an accident of naming. The real problem
> then comes when you come to look at the history in gitk. If
> "somebranch" is rebranched many times, the git history starts looking
> pretty complicated, when in fact it should simply be the linear history
> of remotes/trunk up to the branch point followed by a few,
> branch-specific commits. Is there any way to prevent (or modify) the
> git history to remove the errant parent?
Hi Matt,
Short answer: you can use grafts to remove parents.
It was actually an intentional design decision on my part preserve
parents based on branch name. We would eventually otherwise lose
history of the now-deleted branches, as reflogs can expire.
To me, it's easier to drop history connections you don't want with
grafts than to recover it by refetching.
--
Eric Wong
^ permalink raw reply
* Re: [PATCH] push: fix local refs update if already up-to-date
From: Junio C Hamano @ 2008-11-04 8:38 UTC (permalink / raw)
To: Jeff King; +Cc: Clemens Buchacher, git
In-Reply-To: <20081104042643.GA31276@coredump.intra.peff.net>
Jeff King <peff@peff.net> writes:
> Though I am not happy that we have to look up the tracking ref for every
> uptodate ref. I think it shouldn't be a big performance problem with
> packed refs, though, since they are cached (i.e., we pay only to compare
> the hashes, not touch the filesystem for each ref).
It is either (1) the user pays the cost of finding what remote tracking
branch we are mirroring when you push for all up-to-date refs, like you
did in your "here is an improvement" patch; or (2) the user pays the cost
of fetching from there, immediately after pushing. I'd imagine that the
cost to do (1) would be smaller than (2). The question is if seeing stale
tracking branches is such a big deal, as next "git fetch" from there will
update them anyway. If it is a big deal, (1) would be a price worth
paying.
In short, I agree with everything you said in your analysis. Thanks for
being a very good reviewer.
Clemens, care to reroll the patch?
^ permalink raw reply
* Re: libxdiff and patience diff
From: Pierre Habouzit @ 2008-11-04 8:33 UTC (permalink / raw)
To: Davide Libenzi; +Cc: Git ML
In-Reply-To: <Pine.LNX.4.64.0811031904130.9116@alien.or.mcafeemobile.com>
[-- Attachment #1: Type: text/plain, Size: 2593 bytes --]
On Tue, Nov 04, 2008 at 03:17:37AM +0000, Davide Libenzi wrote:
> On Tue, 4 Nov 2008, Pierre Habouzit wrote:
>
> > Hi Davide,
> >
> > I've been working tonight, trying to make libxdiff support the patience
> > diff algorithm, but I've totally failed, because I _thought_ I
> > understood what xdl_split was doing, but it appears I don't.
> >
> >
> > [ For the readers playing at home, the patience diff algorithm is
> > explained after my sig. ]
> >
> >
> > What I did is to:
> > (1) add a flag to the xenv in xdl_split that says that I want a
> > patience "split".
> > (2) Then in xdl_split, if that bit is set, I compute the longest common
> > subsequence from the patience diff.
> > (3) for each split it computes I call xdl_recs_cmp on that interval.
> >
> >
> > What I thought it would achieve is that I force some boundaries at which
> > libxdiff _must_ resync. Though, it seems that for some reason it doesn't
> > work, probably because the "ha" stuff and the boundaries absolutely
> > don't work the way I thought it did.
> >
> > So where is the place I should do that ? I suspect it should be
> > partly in xprepare.c but I'm a bit stuck right now.
> >
> >
> > Any pointer on how the stuff in xprepare.c and xdiffi.c work would help
> > greatly, it's really not self-evident to me :)
>
> What makes you think it'd self-evident to me? :)
> Seriously, I forgot stuff I wrote the last month, this is way beyond my
> memory limits.
> You definitely need to look at xprepare.c, especially at xdl_trim_ends()
> and xdl_cleanup_records(). Lines are re-arranged in indexes, and this
> might screw up your logic if you're not prepared for it.
> What xdl_split() does, is find the start of an LCS and return the
> coordinate. Then xdl_recs_cmp() does the box reducing (first two "for"
> loops) and different-lines marking (first and second "if").
Well it's what I thought it did indeed, that's why before recursing into
that bit, I tried to extract a full LCS from the patience diff algorithm
and recurse into that for each interval it gives, which _should_ work,
but doesn't at all :/
Okay maybe I should re-read my algorithm slowly and check that I've not
made something silly (like chaining the list in the reverse order or god
knows what), but my debug functions let me believe that I did that fine.
I'll look into it tonight.
--
·O· Pierre Habouzit
··O madcoder@debian.org
OOO http://www.madism.org
[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* Re: libxdiff and patience diff
From: Pierre Habouzit @ 2008-11-04 8:30 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: davidel, Git ML
In-Reply-To: <alpine.DEB.1.00.0811040627020.24407@pacific.mpi-cbg.de>
[-- Attachment #1: Type: text/plain, Size: 3639 bytes --]
On Tue, Nov 04, 2008 at 05:39:48AM +0000, Johannes Schindelin wrote:
> Hi,
>
> On Tue, 4 Nov 2008, Pierre Habouzit wrote:
>
> > I've been working tonight, trying to make libxdiff support the patience
> > diff algorithm, but I've totally failed, because I _thought_ I
> > understood what xdl_split was doing, but it appears I don't.
>
> I thought about it, too, at the GitTogether, although I want to finish my
> jGit diff first.
>
> The main idea I had about patience diff is that you can reuse a lot of
> functions in libxdiff.
>
> But the requirement of taking just unique lines/hashes into account, and
> _after_ splitting up, _again_ determine uniqueness _just_ in the
> between-hunk part made me think that it may be wiser to have a separate
> function for the patience diff stuff.
>
> Basically, you would start to have libxdiff split the lines and hash them
> as normal, but then determine the unique hashes (I'd start with the
> smaller text, just to have a better chance to end up with unique hashes).
>
> Once they are determined, you can search for those exact lines (hash
> first) in the post-document.
Actually my current implementation just puts all the hashes into an
array, sorts them by hash (which is O(n log(n)) with the position from
left or right file it's in, ordered by increasing right position. (and
the struct is filled with the left pos to -1 if the right pos is set,
and vice versa).
The I scan the array to find patterns of two consecutive hashes exactly,
and collapse it into the proper {left pos, right pos} tuple if it was
indeed a unique line in both files.
This results into an array I sort again by right pos then, and we can
work on that for the stack sorting, and I do it, and then I have my LCS.
This is the complete brute-force algorithm which requires a temporary
array of the size of the number of lines on the left + the right, and a
temporary array for the stacks which _may_ end up being as large as the
smallest number of lines between the left or right file in the worst
case I'd say (roughly).
Then I just remember a list of split points, and I recurse in all the
sub splits again. It has a fixed point which may or may not need
libxdiff recursion in it.
This code is actually written, naive and unoptimized but it doesn't work
probably because I didn't plug that in the proper place :)
> Once that is done, you'd have to find the longest common subsequence,
> which you could do using the existing infrastructure, but that would
> require more work (as we already know the lines are unique).
Patience diff gives you the algorithm to do that, it's pretty simple,
and is more efficient than the current infrastructure (in time, I don't
know for space though).
> After that, you would have to recurse to the same algorithm _between_
> known chunks. Eventually, that would have to resort to classical libxdiff
> (if there are no, or not enough, unique lines).
Yeah, that's the point, the problem is, I believe more and more that I
should prepare the LCS from patience diff in xprepare.c, but I grok
absolutely nothing at what the chastore_t and similar stuff is. I
understand it's about hashing, but the exact stuff it does eludes me. In
fact when I look at the records I have in xdiffi.c I had the impression
they were already somehow collapsed, which makes it a too late point to
apply the patience diff ...
--
·O· Pierre Habouzit
··O madcoder@debian.org
OOO http://www.madism.org
[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* Re: [RFC PATCH] git-svn: proper detection of bare repositories
From: Eric Wong @ 2008-11-04 8:30 UTC (permalink / raw)
To: Deskin Miller; +Cc: git
In-Reply-To: <20081103000903.GA1135@euler>
Deskin Miller <deskinm@umich.edu> wrote:
> I keep coming across commands like this, which don't work properly in bare
> repositories, and thinking that they need to be patched (see e.g. ddff8563, or
> Duy's comments on the thread starting at
> http://thread.gmane.org/gmane.comp.version-control.git/98849), but now I'm not
> so sure. For one, despite this patch working, it turns out that 'git --bare
> svn <cmd>' also works (and presumably has) for some time.
Interesting. I've never even looked at --bare myself. It always
should've worked if GIT_DIR= was explicitly set and I guess back in the
old days when I wrote git-svn, --bare wasn't even a flag :)
> Is git --bare the correct way to deal with this situation? That is to say, do
> we intend commands to 'just work' regardless of whether the repo is bare or
> not, or should the user be thinking about the difference and including --bare
> in the command invocation when necessary? I'm a vote for the 'just work' camp,
> but it seems a lot of things aren't necessarily that way. On the other hand,
> the majority of commands do just work.
>
> I guess I'm asking for a sanity check before I write any more such patches;
> certainly I find them useful, as the issues come up during my normal use of
> Git, but I don't want to be pursuing things of no use to anyone else, or
> (worse) things that are fundamentally wrong for some reason I don't understand
> yet.
I don't think there's anything fundamentally wrong with things 'just
working' on bare repos. It's just another case of something that not
many people end up using (especially for git-svn) and hence got fewer
testers and bug reports.
> -- 8< --
>
> When in a bare repository (or .git, for that matter), git-svn would fail
> to initialise properly, since git rev-parse --show-cdup would not output
> anything. However, git rev-parse --show-cdup actually returns an error
> code if it's really not in a git directory.
>
> Fix the issue by checking for an explicit error from git rev-parse, and
> setting $git_dir appropriately if instead it just does not output.
>
> Signed-off-by: Deskin Miller <deskinm@umich.edu>
> ---
> git-svn.perl | 14 ++++++++++----
> t/t9100-git-svn-basic.sh | 9 +++++++++
> 2 files changed, 19 insertions(+), 4 deletions(-)
>
> diff --git a/git-svn.perl b/git-svn.perl
> index 56238da..d25e9be 100755
> --- a/git-svn.perl
> +++ b/git-svn.perl
> @@ -42,6 +42,7 @@ use File::Path qw/mkpath/;
> use Getopt::Long qw/:config gnu_getopt no_ignore_case auto_abbrev/;
> use IPC::Open3;
> use Git;
> +use Error qw/:try/;
>
> BEGIN {
> # import functions from Git into our packages, en masse
> @@ -214,11 +215,16 @@ unless ($cmd && $cmd =~ /(?:clone|init|multi-init)$/) {
> "but it is not a directory\n";
> }
> my $git_dir = delete $ENV{GIT_DIR};
> - chomp(my $cdup = command_oneline(qw/rev-parse --show-cdup/));
> - unless (length $cdup) {
> - die "Already at toplevel, but $git_dir ",
> - "not found '$cdup'\n";
> - }
> + my $cdup = undef;
> + try {
> + $cdup = command_oneline(qw/rev-parse --show-cdup/);
> + $git_dir = '.' unless ($cdup);
> + chomp $cdup if ($cdup);
> + $cdup = "." unless ($cdup && length $cdup);
> + }
> + catch Git::Error::Command with {
> + die "Already at toplevel, but $git_dir not found\n";
> + };
How about using git_cmd_try instead?
The Error.pm try/catch stuff makes me a bit uncomfortable. I realize
it's (unfortunately) in Git.pm; but I'd rather keep it confined there so
we can more easily remove it later if someone were inclined.
Otherwise I like the idea of this patch.
Thanks,
--
Eric Wong
^ permalink raw reply
* Re: [PATCH] git send-email: allow any rev-list option as an argument.
From: Pierre Habouzit @ 2008-11-04 8:19 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Jeff King, git
In-Reply-To: <7vej1sti78.fsf@gitster.siamese.dyndns.org>
[-- Attachment #1: Type: text/plain, Size: 2254 bytes --]
On Tue, Nov 04, 2008 at 01:04:27AM +0000, Junio C Hamano wrote:
> Pierre Habouzit <madcoder@debian.org> writes:
>
> > As a summary, I'd say that I like both (1) and (3) because those are
> > handy, short, and either completely or mostly backward compatible. My
> > way would be to go down (1) and add a alias.s-e = !git send-email -F in
> > my .gitconfig.
> >
> > What do you think ?
>
> I wonder if we can do this even without an explicit -F.
>
> What command line arguments does send-email take, and what options would
> we want to give the underlying format-patch? Can't you sift them without
> ambiguity?
>
> The current syntax is:
>
> git send-email <flags>... <file|dir>...
>
> I am wondering if we can just extend it to:
>
> git send-email <flags>... <<file|dir>...|rev>
>
> E.g. we should be able to parse this out:
>
> git send-email --to git@vger.kernel.org -M --suppress-cc=all origin
>
> and notice "--to git@vger.kernel.org" and "--suppress-cc" are for
> send-email, guess "-M" (or anything that is outside the current
> send-email's vocabulary) is meant for format-patch, and if there is no
> file or directory called "origin" then decide that the user wants to run
> format-patch, and act as a front-end as if the user did:
>
> git format-patch -o tmp.$$ -M origin &&
> ... perhaps do your --annotate and --compose here by launching
> ... the editor...
> git send-email --to git@vger.kernel.org --suppress-cc=all tmp.$$ &&
> rm -fr tmp.$$
>
> If you happen to have a file or a directory called origin, it would be
> safer for users if the command errored out asking for disambiguation. The
> user can either say "./origin" or "origin^0" to disambiguate between them.
Oh right you can disambiguate references using ^0 so maybe my proposal
works after all, though it has to check for each file name if it's not a
reference _also_. I like it. I will rework my patch series now then,
since most of the discussed points of them have been addressed in the
thread.
--
·O· Pierre Habouzit
··O madcoder@debian.org
OOO http://www.madism.org
[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* locate commit by file
From: Ittay Dror @ 2008-11-04 8:11 UTC (permalink / raw)
To: Git Mailing List
Hi,
Given a file, is there an easy way (e.g., not bisectig) to find the
latest commit where the file content is the same?
Meaning: I have a file /tmp/A and I want to file the latest commit where
a/b/A is identical (content wise) to /tmp/A.
Thank you,
Ittay
--
--
Ittay Dror <ittay.dror@gmail.com>
^ permalink raw reply
* Re: [RFC PATCH] gitweb: Support filtering projects by .htaccess files.
From: Francis Galiegue @ 2008-11-04 7:42 UTC (permalink / raw)
To: Jakub Narebski; +Cc: Alexander Gavrilov, git
In-Reply-To: <200811040124.36708.jnareb@gmail.com>
Le mardi 04 novembre 2008, Jakub Narebski a écrit :
[...]
> >
> > As to what repository is accessible to whom, does gitweb really have
> > an internal mechanism for this? Wouldn't it be "better" is privately
> > accessible projects were available on another website to start with?
>
> The problem is that Apache has to decide whether to deny or grant access
> based on URL, not on path in filesystem. Perhaps that is possible...
>
It is, with <Location> or <LocationMatch>. You can use mod_access directives
within these (or mod_auth* ones).
--
Francis Galiegue, fg@one2team.com
[ATTENTION - CHANGEMENT D'ADRESSE !]
40 av Raymond Poincaré, 75016 PARIS
+33178945570, +33683877875
^ permalink raw reply
* Re: Repo corrupted somehow?
From: Andrew Arnott @ 2008-11-04 7:34 UTC (permalink / raw)
To: git
In-Reply-To: <216e54900811032309s51c8cb1fr64054ff18c450b1d@mail.gmail.com>
I guess I was still in the middle of a rebase. git rebase --abort
sort of ultimately fixed it.
On Mon, Nov 3, 2008 at 11:09 PM, Andrew Arnott <andrewarnott@gmail.com> wrote:
> I was just git commit'ing, and then I was doing a git rebase to squash
> several commits into one when the rebase failed. I then did a
> git checkout -f master
> git reset --hard
> but no matter what I do, git thinks that several files have changed.
> The diff shows all the lines in these several files removed and then
> added, yet without any changes made to them. git reset --hard doesn't
> revert the change. When I jump around history with git checkout these
> files remain in their "changed" state. I even tried "git clone" to
> create a whole new repo, but one of these several files STILL
> registered as changed before I made any changes.
>
> Any idea what's wrong and how to recover?
>
> Observe the below command buffer: (I can upload my repo so you can
> clone it and perhaps repro it if you want).
>
> Andrew@LACKY /c/git/dotnetoauth
> $ git status
> # On branch master
> # Changed but not updated:
> # (use "git add <file>..." to update what will be committed)
> #
> # modified: tools/Documentation.targets
> # modified: tools/DotNetOpenAuth.Common.Settings.targets
> # modified: tools/DotNetOpenAuth.Versioning.targets
> # modified:
> tools/Sandcastle/Presentation/vs2005/Content/reference_content.xml
> # modified: tools/libcheck.ps1
> # modified: tools/sandcastle.targets
> #
> no changes added to commit (use "git add" and/or "git commit -a")
>
> Andrew@LACKY /c/git/dotnetoauth
> $ git reset --hard
> HEAD is now at 13d37b8 Patching up the bad merges in the phases.
>
> Andrew@LACKY /c/git/dotnetoauth
> $ git status
> # On branch master
> # Changed but not updated:
> # (use "git add <file>..." to update what will be committed)
> #
> # modified: tools/Documentation.targets
> # modified: tools/DotNetOpenAuth.Common.Settings.targets
> # modified: tools/DotNetOpenAuth.Versioning.targets
> # modified:
> tools/Sandcastle/Presentation/vs2005/Content/reference_content.xml
> # modified: tools/libcheck.ps1
> # modified: tools/sandcastle.targets
> #
> no changes added to commit (use "git add" and/or "git commit -a")
>
^ permalink raw reply
* [PATCH v2 1/2] contrib/hooks/post-receive-email: Put rev display in separate function
From: Pete Harlan @ 2008-11-04 7:19 UTC (permalink / raw)
To: Andy Parkins, git; +Cc: Pete Harlan
In-Reply-To: <7v7i7kthkc.fsf@gitster.siamese.dyndns.org>
The display of a revision in an email-appropriate format is done in
two places with similar code. In preparation for making that display
more complex, move it into a separate function that handles both cases.
Signed-off-by: Pete Harlan <pgit@pcharlan.com>
---
contrib/hooks/post-receive-email | 41 +++++++++++++++++++++++++++++--------
1 files changed, 32 insertions(+), 9 deletions(-)
diff --git a/contrib/hooks/post-receive-email b/contrib/hooks/post-receive-email
index 4136895..2cd373d 100644
--- a/contrib/hooks/post-receive-email
+++ b/contrib/hooks/post-receive-email
@@ -224,13 +224,7 @@ generate_create_branch_email()
echo ""
echo $LOGBEGIN
- # This shows all log entries that are not already covered by
- # another ref - i.e. commits that are now accessible from this
- # ref that were previously not accessible
- # (see generate_update_branch_email for the explanation of this
- # command)
- git rev-parse --not --branches | grep -v $(git rev-parse $refname) |
- git rev-list --pretty --stdin $newrev
+ show_new_revisions
echo $LOGEND
}
@@ -390,8 +384,7 @@ generate_update_branch_email()
echo ""
echo $LOGBEGIN
- git rev-parse --not --branches | grep -v $(git rev-parse $refname) |
- git rev-list --pretty --stdin $oldrev..$newrev
+ show_new_revisions
# XXX: Need a way of detecting whether git rev-list actually
# outputted anything, so that we can issue a "no new
@@ -591,6 +584,36 @@ generate_delete_general_email()
echo $LOGEND
}
+
+# --------------- Miscellaneous utilities
+
+#
+# Show new revisions as the user would like to see them in the email.
+#
+show_new_revisions()
+{
+ # This shows all log entries that are not already covered by
+ # another ref - i.e. commits that are now accessible from this
+ # ref that were previously not accessible
+ # (see generate_update_branch_email for the explanation of this
+ # command)
+
+ # Revision range passed to rev-list differs for new vs. updated
+ # branches.
+ if [ "$change_type" = create ]
+ then
+ # Show all revisions exclusive to this (new) branch.
+ revspec=$newrev
+ else
+ # Branch update; show revisions not part of $oldrev.
+ revspec=$oldrev..$newrev
+ fi
+
+ git rev-parse --not --branches | grep -v $(git rev-parse $refname) |
+ git rev-list --pretty --stdin $revspec
+}
+
+
send_mail()
{
if [ -n "$envelopesender" ]; then
--
1.6.0.3.533.ge0502
^ permalink raw reply related
* [PATCH v2 2/2] contrib/hooks/post-receive-email: Make revision display configurable
From: Pete Harlan @ 2008-11-04 7:19 UTC (permalink / raw)
To: Andy Parkins, git; +Cc: Pete Harlan
In-Reply-To: <7v7i7kthkc.fsf@gitster.siamese.dyndns.org>
Add configuration option hooks.showrev, letting the user override how
revisions will be shown in the commit email.
Signed-off-by: Pete Harlan <pgit@pcharlan.com>
---
contrib/hooks/post-receive-email | 18 +++++++++++++++++-
1 files changed, 17 insertions(+), 1 deletions(-)
diff --git a/contrib/hooks/post-receive-email b/contrib/hooks/post-receive-email
index 2cd373d..28a3c0e 100644
--- a/contrib/hooks/post-receive-email
+++ b/contrib/hooks/post-receive-email
@@ -38,6 +38,12 @@
# hooks.emailprefix
# All emails have their subjects prefixed with this prefix, or "[SCM]"
# if emailprefix is unset, to aid filtering
+# hooks.showrev
+# The shell command used to format each revision in the email, with
+# "%s" replaced with the commit id. Defaults to "git rev-list -1
+# --pretty %s", displaying the commit id, author, date and log
+# message. To list full patches separated by a blank line, you
+# could set this to "git show -C %s; echo".
#
# Notes
# -----
@@ -610,7 +616,16 @@ show_new_revisions()
fi
git rev-parse --not --branches | grep -v $(git rev-parse $refname) |
- git rev-list --pretty --stdin $revspec
+ if [ -z "$custom_showrev" ]
+ then
+ git rev-list --pretty --stdin $revspec
+ else
+ git rev-list --stdin $revspec |
+ while read onerev
+ do
+ eval $(printf "$custom_showrev" $onerev)
+ done
+ fi
}
@@ -650,6 +665,7 @@ recipients=$(git config hooks.mailinglist)
announcerecipients=$(git config hooks.announcelist)
envelopesender=$(git config hooks.envelopesender)
emailprefix=$(git config hooks.emailprefix || echo '[SCM] ')
+custom_showrev=$(git config hooks.showrev)
# --- Main loop
# Allow dual mode: run from the command line just like the update hook, or
--
1.6.0.3.533.ge0502
^ permalink raw reply related
* [PATCH v2 0/2] post-receive-email configurable rev display
From: Pete Harlan @ 2008-11-04 7:19 UTC (permalink / raw)
To: Andy Parkins, git; +Cc: Pete Harlan
In-Reply-To: <7v7i7kthkc.fsf@gitster.siamese.dyndns.org>
This is the second version of the user-configurable revision display
patch. The first version decreased the efficiency of the default
case, while this avoids it thanks to a suggestion by Junio.
The first version of this patch also failed to customize the display
of revisions included in newly-created branches; this version displays
those revisions in the same manner as for updated branches.
The two places (new vs. updated branches) where the original code
displayed revisions used similar code. The first patch in this series
factors that out to a separate routine that handles both cases, in
order to avoid duplicating the code introduced in the second patch.
Pete Harlan (2):
contrib/hooks/post-receive-email: Put rev display in separate
function
contrib/hooks/post-receive-email: Make revision display configurable
contrib/hooks/post-receive-email | 57 ++++++++++++++++++++++++++++++++------
1 files changed, 48 insertions(+), 9 deletions(-)
^ permalink raw reply
* Repo corrupted somehow?
From: Andrew Arnott @ 2008-11-04 7:09 UTC (permalink / raw)
To: git
I was just git commit'ing, and then I was doing a git rebase to squash
several commits into one when the rebase failed. I then did a
git checkout -f master
git reset --hard
but no matter what I do, git thinks that several files have changed.
The diff shows all the lines in these several files removed and then
added, yet without any changes made to them. git reset --hard doesn't
revert the change. When I jump around history with git checkout these
files remain in their "changed" state. I even tried "git clone" to
create a whole new repo, but one of these several files STILL
registered as changed before I made any changes.
Any idea what's wrong and how to recover?
Observe the below command buffer: (I can upload my repo so you can
clone it and perhaps repro it if you want).
Andrew@LACKY /c/git/dotnetoauth
$ git status
# On branch master
# Changed but not updated:
# (use "git add <file>..." to update what will be committed)
#
# modified: tools/Documentation.targets
# modified: tools/DotNetOpenAuth.Common.Settings.targets
# modified: tools/DotNetOpenAuth.Versioning.targets
# modified:
tools/Sandcastle/Presentation/vs2005/Content/reference_content.xml
# modified: tools/libcheck.ps1
# modified: tools/sandcastle.targets
#
no changes added to commit (use "git add" and/or "git commit -a")
Andrew@LACKY /c/git/dotnetoauth
$ git reset --hard
HEAD is now at 13d37b8 Patching up the bad merges in the phases.
Andrew@LACKY /c/git/dotnetoauth
$ git status
# On branch master
# Changed but not updated:
# (use "git add <file>..." to update what will be committed)
#
# modified: tools/Documentation.targets
# modified: tools/DotNetOpenAuth.Common.Settings.targets
# modified: tools/DotNetOpenAuth.Versioning.targets
# modified:
tools/Sandcastle/Presentation/vs2005/Content/reference_content.xml
# modified: tools/libcheck.ps1
# modified: tools/sandcastle.targets
#
no changes added to commit (use "git add" and/or "git commit -a")
^ permalink raw reply
* RE: why not TortoiseGit
From: Li Frank @ 2008-11-04 6:36 UTC (permalink / raw)
To: Nigel Magnay; +Cc: Scott Chacon, Andreas Ericsson, Ian Hilt, git
In-Reply-To: <320075ff0811030200q606b76a8i16496cf7b8b1b7d2@mail.gmail.com>
I also think it is best choose base on Tortoise SVN. TortoriseGIt
should be in windows platform only because it is extension of explore.
Best regards
Frank Li
-----Original Message-----
From: Nigel Magnay [mailto:nigel.magnay@gmail.com]
Sent: Monday, November 03, 2008 6:00 PM
To: Li Frank-B20596
Cc: Scott Chacon; Andreas Ericsson; Ian Hilt; git@vger.kernel.org
Subject: Re: why not TortoiseGit
> I read some code of TortoiseSVN and TortoiseHg Code.
> At beginning, TortoiseGit can git command to get information like
Qgit.
> After linkable library ready, replace "git command".
>
> I think TortoiseGit can start base on below way.
>
> 1. Base on TortoiseHg, It is python Script. Replace below hg
> operator with Git.
> 2. Base on TortoiseSVN, It is developed with C++. Need VS2008.
> ToritoiseSVN provide some built in diff and merge tools.
> 3. Base on Qgit, which provide some basic UI, such comment dialogbox,
> history view and file annotate.
>
>
TortoiseSVN is a good place to start because it separates out the
windows icon decorators into a separate DLL (shared with TortoiseCVS).
This is significant, as these are a finite resource in the windows
shell, and so having a TortoiseSVN + TortoiseGIT on one machine and you
might run out, and I'd imagine lots of people wanting both.
On the minus side, building (Tortoise)SVN requires a lot of environment
setup just to get it to build - most of which can be immediately thrown
away as it's specific to SVN.
But it doesn't look like a hard project to me, just requires stripping
out a lot of junk and re-patching callouts to a git executable (which
could be the standard git tools) and a minimal git library that knows if
files are dirty.
^ permalink raw reply
* Re: Intensive rename detection
From: Andrew Arnott @ 2008-11-04 6:36 UTC (permalink / raw)
To: Jeff King; +Cc: Junio C Hamano, Linus Torvalds, git
In-Reply-To: <20081104061647.GA18297@coredump.intra.peff.net>
Yes, on git status. I'm afraid I don't know how to look up the
reference you gave.
On Mon, Nov 3, 2008 at 10:16 PM, Jeff King <peff@peff.net> wrote:
> On Mon, Nov 03, 2008 at 10:02:37PM -0800, Andrew Arnott wrote:
>
>> Hmmm.... actually on second run I am still getting the too many files
>> warning. I put the [diff] section in a ~/.gitconfig file, a
>> .gitconfig file in the root of my repo, and in the .git/config file,
>> but none of them seem to get rid of the message.
>
> Where are you getting the warning? On "git status"?
>
> If so, then this is an instance of the problem I mentioned here:
>
> [PATCH v3 7/8] wt-status: load diff ui config
> 20081026044935.GG21047@coredump.intra.peff.net
>
> (sorry, I would link to gmane, but it seems to be down at the moment).
> Junio, maybe it is worth applying after all (we could also do just the
> diff "basic" config instead).
>
> -Peff
>
^ permalink raw reply
* Re: Intensive rename detection
From: Jeff King @ 2008-11-04 6:16 UTC (permalink / raw)
To: Andrew Arnott; +Cc: Junio C Hamano, Linus Torvalds, git
In-Reply-To: <216e54900811032202h5c82e3a9j30100e5b82f6a16a@mail.gmail.com>
On Mon, Nov 03, 2008 at 10:02:37PM -0800, Andrew Arnott wrote:
> Hmmm.... actually on second run I am still getting the too many files
> warning. I put the [diff] section in a ~/.gitconfig file, a
> .gitconfig file in the root of my repo, and in the .git/config file,
> but none of them seem to get rid of the message.
Where are you getting the warning? On "git status"?
If so, then this is an instance of the problem I mentioned here:
[PATCH v3 7/8] wt-status: load diff ui config
20081026044935.GG21047@coredump.intra.peff.net
(sorry, I would link to gmane, but it seems to be down at the moment).
Junio, maybe it is worth applying after all (we could also do just the
diff "basic" config instead).
-Peff
^ permalink raw reply
* Re: Intensive rename detection
From: Andrew Arnott @ 2008-11-04 6:02 UTC (permalink / raw)
To: Linus Torvalds; +Cc: git
In-Reply-To: <216e54900811032119h4cb51327v2d85712acc444185@mail.gmail.com>
Hmmm.... actually on second run I am still getting the too many files
warning. I put the [diff] section in a ~/.gitconfig file, a
.gitconfig file in the root of my repo, and in the .git/config file,
but none of them seem to get rid of the message.
I'm running git version 1.5.5.1015.g9d258
Is that too old for this removal of a file rename limit?
On Mon, Nov 3, 2008 at 9:19 PM, Andrew Arnott <andrewarnott@gmail.com> wrote:
> Awesome. Per Linus' tip, I just noticed at the top of a long list of
> messages git said:
> warning: too many files, skipping inexact rename detection
>
> So I added the config file change, and that did the trick. Thanks, everyone!
>
> Here's a related but slightly different question: I've been stashing
> and unstashing in the midst of all these renames and refactoring, and
> now I'm left with some files listed in git status 3 times. I
> understand why this is, but I don't know the best way to proceed. Git
> is telling me:
>
> $ git status | grep MessageBase
> src/DotNetOAuth/Messages/MessageBase.cs: needs merge
> src/DotNetOAuth/OAuth/Messages/MessageBase.cs: needs merge
> src/DotNetOpenAuth/Messages/MessageBase.cs: needs merge
> # unmerged: src/DotNetOAuth/Messages/MessageBase.cs
> # unmerged: src/DotNetOAuth/OAuth/Messages/MessageBase.cs
> # unmerged: src/DotNetOpenAuth/Messages/MessageBase.cs
>
> I want to end up with MessageBase.cs in
> src/DotNetOpenAuth/OAuth/Messages/MessageBase.cs, which ironically is
> none of these three. And the couple of lines that changed in the file
> need to be merged. Only two of these listed files exist on disk. How
> can I best leverage git to merge the two files on disk while moving it
> to a new location?
>
>> On Mon, Nov 3, 2008 at 8:22 PM, Linus Torvalds <torvalds@linux-foundation.org> wrote:
>>>
>>>
>>> On Mon, 3 Nov 2008, Andrew Arnott wrote:
>>> >
>>> > I'm refactoring a library including renaming both files and
>>> > directories. A few lines of each file are also changed, but they are
>>> > substantially unchanged in content. I've done a git add to put all my
>>> > changes into the index, but a git status shows that git only detected
>>> > a few of the renames... most of them are delete-add operations. Is
>>> > there anything I can do to help git recognize the rename so that
>>> > history is preserved across this commit?
>>>
>>> How many renames do you have? Modern versions of git will do any number of
>>> exact renames, but the (rather expensive) inexact rename detection has a
>>> default limit of something fairly small.
>>>
>>> You could try adding
>>>
>>> [diff]
>>> renamelimit=0
>>>
>>> to your ~/.gitconfig file. It can be quite expensive though.
>>>
>>> Linus
>>
>
^ 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