* Re: [PATCH] Document diff.external and mergetool.<tool>.path
From: Johannes Schindelin @ 2007-12-18 1:00 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Schuberth, Sebastian, git
In-Reply-To: <7vy7bs3jv2.fsf@gitster.siamese.dyndns.org>
Hi,
On Mon, 17 Dec 2007, Junio C Hamano wrote:
> Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
>
> > On Mon, 17 Dec 2007, Junio C Hamano wrote:
> >
> >> Thanks. Applied.
> >
> > Dumb question: with, or without, the diff.external patch?
>
> Swapped the order to first make diff.external work and then document.
Thank you very much!
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH] Document diff.external and mergetool.<tool>.path
From: Junio C Hamano @ 2007-12-18 0:52 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Schuberth, Sebastian, git
In-Reply-To: <Pine.LNX.4.64.0712180047300.9446@racer.site>
Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> On Mon, 17 Dec 2007, Junio C Hamano wrote:
>
>> Thanks. Applied.
>
> Dumb question: with, or without, the diff.external patch?
Swapped the order to first make diff.external work and then document.
^ permalink raw reply
* Re: [PATCH 5/6] whitespace: more accurate initial-indent highlighting
From: Junio C Hamano @ 2007-12-18 0:51 UTC (permalink / raw)
To: Jakub Narebski; +Cc: Wincent Colaiuta, J. Bruce Fields, Git Mailing List
In-Reply-To: <m3y7bsq1vo.fsf@roke.D-201>
Jakub Narebski <jnareb@gmail.com> writes:
> By the way, does "trailing empty lines at the end of file" whitespace
> error get detected and hightlighted with refactored whitespace checking?
Did you read the whole thread yet?
^ permalink raw reply
* Re: [PATCH] gitweb: Make config_to_multi return [] instead of [undef]
From: Junio C Hamano @ 2007-12-18 0:49 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git, Petr Baudis
In-Reply-To: <200712180112.52094.jnareb@gmail.com>
Please send updates if something is not right. Thanks.
^ permalink raw reply
* Re: [PATCH] Document diff.external and mergetool.<tool>.path
From: Johannes Schindelin @ 2007-12-18 0:47 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Schuberth, Sebastian, git
In-Reply-To: <7vtzmg5072.fsf@gitster.siamese.dyndns.org>
Hi,
On Mon, 17 Dec 2007, Junio C Hamano wrote:
> Thanks. Applied.
Dumb question: with, or without, the diff.external patch?
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH] provide advance warning of some future pack default changes
From: Junio C Hamano @ 2007-12-18 0:41 UTC (permalink / raw)
To: Nicolas Pitre; +Cc: Joel Becker, Jakub Narebski, git
In-Reply-To: <alpine.LFD.0.999999.0712171641460.8467@xanadu.home>
Nicolas Pitre <nico@cam.org> writes:
> On Mon, 17 Dec 2007, Junio C Hamano wrote:
> ...
>> Instead we unconditionally said "if you are downloading with the new
>> client, we assume you would never be using older client to access that
>> repository locally, if you did so, you are screwed."
>>
>> IOW, I think e4fe4b8ef7cdde842a9e5e2594d0fba1367d9dd3 (let the GIT
>> native protocol use offsets to delta base when possible) could have been
>> a bit more careful in this respect.
>
> Probably. But this can hardly be called a "corruption" since nothing
> was actually lost, rather an incompatibility problem.
It is not a corruption, but the distinction doesn't matter much to the
end user who wants to get the job done with the data right now. The
data that was made inaccessible is inaccessible. The only difference is
that it is recoverable once the user upgrades, but that may be painful,
even though it may be rewarding afterwards and worth doing so, and the
user may not be able to afford doing so right at that moment.
^ permalink raw reply
* Re: [PATCH 5/6] whitespace: more accurate initial-indent highlighting
From: Jakub Narebski @ 2007-12-18 0:32 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Wincent Colaiuta, J. Bruce Fields, Git Mailing List
In-Reply-To: <7vwsrdd9wa.fsf@gitster.siamese.dyndns.org>
Junio C Hamano <gitster@pobox.com> writes:
> Wincent Colaiuta <win@wincent.com> writes:
>
> > Basically I would have proposed extracting out each type of whitespace
> > error into an inline function in ws.c, where it could be used by both
> > check_and_emit_line() in ws.c and apply_one_fragment() in builtin-
> > apply.c.
> >
> > Unfortunately, mixing checking and emission phases makes this proposed
> > refactoring a little bit ugly.
>
> The right refactoring would be what JBF hinted in his message, to record
> and return a list of suspicious ranges from the checker function and
> have the highlighter and the fixer make use of that list.
>
> Such a refactoring is still possible but I think it is beyond the scope
> of pre 1.5.4 clean-up.
By the way, does "trailing empty lines at the end of file" whitespace
error get detected and hightlighted with refactored whitespace checking?
--
Jakub Narebski
Poland
ShadeHawk on #git
^ permalink raw reply
* Re: git-stash: RFC: Adopt the default behavior to other commands
From: Junio C Hamano @ 2007-12-18 0:31 UTC (permalink / raw)
To: Benoit Sigoure; +Cc: Sebastian Harl, git
In-Reply-To: <57F403E7-AF5B-40F1-AE9D-8EA036675A67@lrde.epita.fr>
Benoit Sigoure <tsuna@lrde.epita.fr> writes:
> On Dec 18, 2007, at 12:00 AM, Junio C Hamano wrote:
>
>> Benoit Sigoure <tsuna@lrde.epita.fr> writes:
>>
>>> ... The current behavior of git stash is very
>>> dangerous ...
> ...
>> This is a plain FUD, isn't it? The first Oops should not happen these
>> days.
>
> *git pull in git*
> *reads Documentation/RelNotes-1.5.4.txt*
>
> Blah. I didn't know follow the development over the past 3 weeks well
> enough, sorry for the noise. I'm glad that this was improved.
But the original point by Sebastian hasn't been answered. He wanted to
make the command list the stash without arguments.
This was discussed already in the early days of stash and there indeed
was a suggestion to do so (I think I sided with that), but the users did
not want it. IIRC, the argument went like: "when I say 'stash', that is
because I want a quick and immediate way to stash, and I do not want a
list. If I do not have to have a quick way, I would create a temporary
commit on the current branch, or switch to a temporary branch and commit
there."
^ permalink raw reply
* Re: [PATCH] the use of 'tr' in the test suite isn't really portable
From: Junio C Hamano @ 2007-12-18 0:20 UTC (permalink / raw)
To: H.Merijn Brand; +Cc: git
In-Reply-To: <20071217232846.476940ec@pc09.procura.nl>
Thanks. Applied.
^ permalink raw reply
* Re: [PATCH] Document diff.external and mergetool.<tool>.path
From: Junio C Hamano @ 2007-12-18 0:13 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Schuberth, Sebastian, git, gitster
In-Reply-To: <Pine.LNX.4.64.0712171220540.9446@racer.site>
Thanks. Applied.
^ permalink raw reply
* Re: [PATCH] gitweb: Make config_to_multi return [] instead of [undef]
From: Jakub Narebski @ 2007-12-18 0:12 UTC (permalink / raw)
To: git; +Cc: Junio Hamano, Petr Baudis
In-Reply-To: <200712151536.33296.jnareb@gmail.com>
On Sat, 15 Dec 2007, Jakub Narebski wrote:
> This is important for the list of clone urls, where if there are
> no per-repository clone URL configured, the default base URLs
> are never used for URL construction without this patch.
>
> Add tests for different ways of setting project URLs, just in case.
> Note that those tests in current form wouldn't detect breakage fixed
> by this patch, as it only checks for errors and not for expected
> output.
The patch applied to master bc8b95ae4a4b21753e84bbfd28cbcbf1b3f6e0a8
does have above paragraph in commit message, but DOES NOT have the
tests itself.
> I have added tests _then_ I have realized that in current form they
> cannot detect regression corrected by this patch. So if you want, you
> can not apply changes to test (and remove paragraph about test from
> commit message).
See above...
> diff --git a/gitweb/gitweb.perl b/gitweb/gitweb.perl
> index 24b3158..a746a85 100755
> --- a/gitweb/gitweb.perl
> +++ b/gitweb/gitweb.perl
> @@ -1511,7 +1511,7 @@ sub config_to_int {
> sub config_to_multi {
> my $val = shift;
>
> - return ref($val) ? $val : [ $val ];
> + return ref($val) ? $val : (defined($val) ? [ $val ] : []);
> }
And somehow (I don't know how[*1*]) patch got whitespace corrupted,
and now the line is indented with spaces, instead of with tab.
[*1*] Other patches are fine.
--
Jakub Narebski
Poland
^ permalink raw reply
* Re: [PATCH] Clean up documentation that references deprecated 'git peek-remote'.
From: Junio C Hamano @ 2007-12-18 0:11 UTC (permalink / raw)
To: Johannes Sixt; +Cc: git
In-Reply-To: <1197882503-4296-1-git-send-email-johannes.sixt@telecom.at>
Johannes Sixt <johannes.sixt@telecom.at> writes:
> Now that 'git peek-remote' is deprecated and only an alias for
> 'git ls-remote', it should not be referenced from other manual pages.
>
> This also removes the description of the --exec option, which is no
> longer present.
It seems to be supported as a backward compatibility option but not
shown in the short help. Removal of it from the documentation is
alright nevertheless.
Thanks.
^ permalink raw reply
* Re: git annotate runs out of memory
From: Linus Torvalds @ 2007-12-18 0:05 UTC (permalink / raw)
To: Jan Hudec; +Cc: Jeff King, Daniel Berlin, Git Mailing List
In-Reply-To: <20071217232450.GA13012@efreet.light.src>
On Tue, 18 Dec 2007, Jan Hudec wrote:
> On Tue, Dec 11, 2007 at 11:50:08AM -0800, Linus Torvalds wrote:
> > And, btw: the diff is totally different from the xdelta we have, so even
> > if we have an already prepared nice xdelta between the two versions, we'll
> > end up re-generating the files in full, and then do a diff on the end
> > result.
>
> The problem is whether git does not end-up re-generating the same file
> multiple times. When it needs to construct the diff between two versions of
> a file and one is delta-base (even indirect) of the other, does it know to
> create the first, remember it, continue to the other and calculate the diff?
Yes.
Actually, it doesn't "know" anything at all - what happens is that git
internally has a simple "delta-cache", which just caches the latest
objects we've generated from deltas, and which automatically handles this
common case (and others).
So when we tend to work with multiple versions of the same file (which is
obviously very common with diff, and even more so with something like
"annotate"), those multiple versions will obviously also tend to be deltas
against each other and/or against some shared base object, and when we see
a delta, we'll look the base object up in the delta cache, and if it has
been generated earlier we'll be able to short-circuit the whole delta
chain and just use the whole object we already cached.
So if you compare two objects that each have a very deep delta chain, you
will obviously have to walk the whole delta chain _once_ (to generate
whichever version of the file you happen to look up first), but you won't
need to do it twice, because the second time you'll end up hitting in the
delta cache.
Linus
^ permalink raw reply
* Re: [PATCH] provide advance warning of some future pack default changes
From: J. Bruce Fields @ 2007-12-18 0:04 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Nicolas Pitre, Joel Becker, Jakub Narebski, git
In-Reply-To: <7vprx553u4.fsf@gitster.siamese.dyndns.org>
On Mon, Dec 17, 2007 at 02:55:15PM -0800, Junio C Hamano wrote:
> "J. Bruce Fields" <bfields@fieldses.org> writes:
>
> > Hm. We tell people to set up public repo's by doing something like:
> >
> > git clone --bare ~/proj proj.git
> > touch proj.git/git-daemon-export-ok
> > scp -r proj.git example.com:
> >
> > Is that going to hit the same problem if the public server has an older
> > git version?
>
> It will, but I think you should teach people --mirror pushing these
> days, which was specifically invented for priming the public
> repository.
>
> That way, the administrator at example.com, as long as he initializes an
> empty repository with suitable daemon-export-ok and necessary hooks
> (which can be automated via templates), does not even have to allow you
> a full ssh access.
So the basic instructions would be something like this?:
ssh example.com "git init --bare myproj.git"
# (or ask your admin to do the previous step)
git add remote example example.com:myproj.git
git push --mirror example
OK, that's neat, thanks.
On the backwards-compatibility issue, though: this won't help the large
number of people who learned to just clone a bare repo and copy it
around, since they aren't of their own initiative going to seek out new
ways of doing things that they think they already know how to do.
--b.
^ permalink raw reply
* Re: how to properly update dumb-hosted repo (using rsync..?)
From: Junio C Hamano @ 2007-12-17 23:46 UTC (permalink / raw)
To: Stephen Sinclair; +Cc: git
In-Reply-To: <9b3e2dc20712171511r41e6bd4p64d243747ad4d2af@mail.gmail.com>
"Stephen Sinclair" <radarsat1@gmail.com> writes:
> $ git-pull
> Warning: No merge candidate found because value of config option
> "branch.master.merge" does not match any remote branch fetched.
> No changes.
> -------------------
>
> However I haven't done any branching in this cloned repo, it is
> immediately after a git-clone from the web server.
>
> My .git/config basically looks like this, minus the "core" section:
>
> -------------------
> [remote "origin"]
> url = http://my.server.com/git/project.git
> fetch = +refs/heads/*:refs/remotes/origin/*
> [branch "master"]
> remote = origin
> merge = refs/heads/master
> -------------------
>
> Which seems fine to me...
> Any ideas?
A dumb question. does "git ls-remote origin" show what you expect to be
there? Specifically, does refs/heads/master exist?
^ permalink raw reply
* Re: git-stash: RFC: Adopt the default behavior to other commands
From: Benoit Sigoure @ 2007-12-17 23:32 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Sebastian Harl, git
In-Reply-To: <7vk5nd53lp.fsf@gitster.siamese.dyndns.org>
On Dec 18, 2007, at 12:00 AM, Junio C Hamano wrote:
> Benoit Sigoure <tsuna@lrde.epita.fr> writes:
>
>> ... The current behavior of git stash is very
>> dangerous as the following frequently happens to new comers:
>> $ git stash
>> $ <hack on something else>
>> $ git commit
>> $ git stash apply
>> $ git stash clean # Oops, typo, I just stashed my changes again
>> $ git stash clear # Oops, I just lost my changed
>
> This is a plain FUD, isn't it? The first Oops should not happen these
> days.
*git pull in git*
*reads Documentation/RelNotes-1.5.4.txt*
Blah. I didn't know follow the development over the past 3 weeks
well enough, sorry for the noise. I'm glad that this was improved.
--
Benoit Sigoure aka Tsuna
EPITA Research and Development Laboratory
^ permalink raw reply
* Re: [PATCH] include/asm-arm/: Spelling fixes
From: Junio C Hamano @ 2007-12-17 23:28 UTC (permalink / raw)
To: Jeff King; +Cc: Joe Perches, J. Bruce Fields, git
In-Reply-To: <20071217230558.GD2105@coredump.intra.peff.net>
Jeff King <peff@peff.net> writes:
>> I wonder if stripping existing "Message-Id:" away just like we strip
>> away "Date:" from @xh would be a much saner fix.
>
> That is definitely wrong if we expect to re-use the in-reply-to and
> references headers that already exist (though obviously we could strip
> out all three of those headers and re-add our own).
Ah, you are right.
And undef $message_id you squashed in definitely belongs there --
"prepare for the next round" section.
^ permalink raw reply
* Re: git with custom diff for commits
From: Junio C Hamano @ 2007-12-17 23:26 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Matthieu Moy, Gerald Gutierrez, git
In-Reply-To: <Pine.LNX.4.64.0712172310090.9446@racer.site>
Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
>> It will show an empty output for "git diff", but I doubt thit will
>> change anything at commit time. Probably the "filter" thing on the same
>> file (also "man gitattributes") can help though.
>
> Ah, right. I completely missed that you were talking about git-commit,
> not git-log on git commits.
>
> Yes, setting up a "clean" filter that removes the timestamps is probably
> the reasonable thing to do here.
I wouldn't do filters for something like that. Can you guarantee that
the output from corresopnding smudge filter will load cleanly back to
the mysql database?
Just do not make the commit if you made only meaningless changes and
nothing else. pre-commit hook would probably be a good place to do so.
^ permalink raw reply
* RE: git with custom diff for commits
From: Gerald Gutierrez @ 2007-12-17 23:27 UTC (permalink / raw)
To: 'Johannes Schindelin', 'Matthieu Moy'; +Cc: git
In-Reply-To: <Pine.LNX.4.64.0712172310090.9446@racer.site>
> Ah, right. I completely missed that you were talking about
> git-commit, not git-log on git commits.
>
> Yes, setting up a "clean" filter that removes the timestamps
> is probably the reasonable thing to do here.
I read about the filter too, but have no idea how to implement it. Any
examples that I could follow?
Thanks,
Gerald.
^ permalink raw reply
* Re: git annotate runs out of memory
From: Jan Hudec @ 2007-12-17 23:24 UTC (permalink / raw)
To: Jeff King; +Cc: Linus Torvalds, Daniel Berlin, Git Mailing List
In-Reply-To: <20071212075725.GA7676@coredump.intra.peff.net>
On Wed, Dec 12, 2007 at 02:57:25 -0500, Jeff King wrote:
> On Tue, Dec 11, 2007 at 11:50:08AM -0800, Linus Torvalds wrote:
> > And, btw: the diff is totally different from the xdelta we have, so even
> > if we have an already prepared nice xdelta between the two versions, we'll
> > end up re-generating the files in full, and then do a diff on the end
> > result.
The problem is whether git does not end-up re-generating the same file
multiple times. When it needs to construct the diff between two versions of
a file and one is delta-base (even indirect) of the other, does it know to
create the first, remember it, continue to the other and calculate the diff?
> > Of course, part of that is that git logically *never* works with deltas,
> > except in the actual code-paths that generate objects (or generate packs,
> > of course). So even if we had used a delta algorithm that would be
> > amenable to be turned into a diff directly, it would have been a layering
> > violation to actually do that.
>
> That doesn't mean we can't opportunistically jump layers when available,
> and fall back on the regular behavior otherwise. The nice thing about
> clean and simple layers is that you can always add optimizations later
> by poking sane holes.
>
> Let's assume for the sake of argument that we can convert an xdelta into
> a diff fairly cheaply. Using the patch below, we can count the places
> where we are diffing two blobs, and one blob is a delta base of the
> other (assuming our magical conversion function can also reverse diffs.
> ;) ).
>
> For a "git log -p" on git.git, I get:
>
> 9951 diffs could be optimized
> 10958 diffs could not be optimized
>
> or about 48%. It would be nice if we could drop the cost by almost 50%
> (if our magical function is free to call, too!).
This is actually a gross underestimation. The idea would be to know all the
diffs we need to calculate and than remember all useful results. Ie. if we
know we'll want objects A and C, A's delta base is B and B's delta base is C,
start calculating A and when it turns out to need C at some point, just
remember it for purpose of doing the final diff. On the other hand B can be
thrown away early (because we don't need it) to save memory.
Now git can know the list of deltas it will need in advance. First generate
the list of revisions -- nothing helps there, but their delta bases are
likely to be randomish anyway -- and than with the knowledge of full list of
trees, start doing the diffs to see which touched the subtree in question.
Repeat for each level.
Since the list of deltas that will be needed is known, the objects from
which all deltas were already generated can be expired from cache (but not
thrown away immediately, as they may help building other objects).
> Of course, I haven't even looked at whether converting xdeltas to
> unified diffs is possible. I suspect in some cases it is (e.g., pure
> addition of text) and in some cases it isn't (I assume xdelta doesn't
> have any context lines, which might hurt). And it's possible that a
> specialized diff user like git-blame can just learn to use the xdeltas
> by itself (I didn't get a "could optimize" count for git-blame since
> it seems to follow a different codepath for its diffs).
Well, it's about as hard as applying them, because you can remember the
necessary stuff when applying. The imporant bit would be to avoid applying
the same delta more than once during the whole annotate.
--
Jan 'Bulb' Hudec <bulb@ucw.cz>
^ permalink raw reply
* Re: [PATCH] builtin-tag: fix fallouts from recent parsopt restriction.
From: Pierre Habouzit @ 2007-12-17 23:14 UTC (permalink / raw)
To: Jeff King; +Cc: Junio C Hamano, git
In-Reply-To: <20071217230729.GE2105@coredump.intra.peff.net>
[-- Attachment #1: Type: text/plain, Size: 872 bytes --]
On Mon, Dec 17, 2007 at 11:07:29PM +0000, Jeff King wrote:
> On Mon, Dec 17, 2007 at 10:01:16PM +0100, Pierre Habouzit wrote:
>
> > Err I misread your point, _yes_ we do, see builtin-show-ref.c, or see
> > --start-number in builtin-log.c. There is a precedent.
>
> Ugh. Well, in that case, it seems we are stuck with it, and I think
> the behavior Junio laid out is the right course of action.
Well I agree, I was mostly trying to show what the code could look like
if we tried to be more clever. I'm fine for enforcing the sticked usage
for optional flags, I was the one advocating it in the first place
anyways. I just wanted to be sure we didn't missed something obvious.
--
·O· Pierre Habouzit
··O madcoder@debian.org
OOO http://www.madism.org
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: [PATCH] provide advance warning of some future pack default changes
From: Nicolas Pitre @ 2007-12-17 23:13 UTC (permalink / raw)
To: Junio C Hamano; +Cc: J. Bruce Fields, Joel Becker, Jakub Narebski, git
In-Reply-To: <7vtzmh55lu.fsf@gitster.siamese.dyndns.org>
On Mon, 17 Dec 2007, Junio C Hamano wrote:
> Pack-idx format v2 is by design much safer in the face of bitflip (do we
> have a test case to make sure this is indeed true?).
t5302 provides a good demonstration of that.
Nicolas
^ permalink raw reply
* Re: [PATCH] include/asm-arm/: Spelling fixes
From: Jeff King @ 2007-12-17 23:12 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Joe Perches, J. Bruce Fields, git
In-Reply-To: <20071217230558.GD2105@coredump.intra.peff.net>
On Mon, Dec 17, 2007 at 06:05:58PM -0500, Jeff King wrote:
> > I wonder if stripping existing "Message-Id:" away just like we strip
> > away "Date:" from @xh would be a much saner fix.
>
> That is definitely wrong if we expect to re-use the in-reply-to and
> references headers that already exist (though obviously we could strip
> out all three of those headers and re-add our own).
>
> I don't have a strong opinion. I never use git-send-email myself, but
> was just trying to fix a reported bug.
Actually, I don't think stripping the message-id is ever the right
thing. The user put it in there for some purpose, and "ours not to
reason why" (ours but to do and die). IOW, it is not possible for us to
know what we are breaking by changing the message-id. It could simply be
the reply-to header in the following messages, or it could be the
reply-to in some message we have not and will not ever see.
Even if we assume git-send-email only ever gets the unmunged output of
git-format-patch, we do not necessarily know it has been fed all of the
patches during a single run.
-Peff
^ permalink raw reply
* Re: git with custom diff for commits
From: Johannes Schindelin @ 2007-12-17 23:11 UTC (permalink / raw)
To: Matthieu Moy; +Cc: Gerald Gutierrez, git
In-Reply-To: <vpq1w9kaphg.fsf@bauges.imag.fr>
Hi,
On Tue, 18 Dec 2007, Matthieu Moy wrote:
> Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
>
> > On Mon, 17 Dec 2007, Gerald Gutierrez wrote:
> >
> >> I've tried to set up an external diff script that runs diff -I "<<sql
> >> timestamp comment>>" that effectively ignores the timestamp. While
> >> this works with "git diff", it seems when git commits, it still sees
> >> the differences.
> >>
> >> How do I properly teach git to ignore these types of differences?
> >
> > You might be interested in reading Documentation/gitattributes.txt,
> > look for "diff driver".
>
> It will show an empty output for "git diff", but I doubt thit will
> change anything at commit time. Probably the "filter" thing on the same
> file (also "man gitattributes") can help though.
Ah, right. I completely missed that you were talking about git-commit,
not git-log on git commits.
Yes, setting up a "clean" filter that removes the timestamps is probably
the reasonable thing to do here.
Sorry for the noise,
Dscho
^ permalink raw reply
* how to properly update dumb-hosted repo (using rsync..?)
From: Stephen Sinclair @ 2007-12-17 23:11 UTC (permalink / raw)
To: git
Hello!
I have a question related to dumb transports (i.e., http hosting without git).
I have a shell-accessible server which on which I have installed git,
but it is not a web server. So to make my git repo public I have put
the repo on a web server which I cannot install git on. I have made a
post-update hook on my server repo which runs git-update-server-info
and then uses rsync to copy the repo over to the public web server.
So far so good. I am able to clone the http-hosted repo and push
changes to my private server which then get copied over to the http
repo.
However, after a git-push/rsync operation, I typed git-pull to try and
pull the changes I'd just made, and got the following:
-------------------
$ git-pull
Warning: No merge candidate found because value of config option
"branch.master.merge" does not match any remote branch fetched.
No changes.
-------------------
However I haven't done any branching in this cloned repo, it is
immediately after a git-clone from the web server.
My .git/config basically looks like this, minus the "core" section:
-------------------
[remote "origin"]
url = http://my.server.com/git/project.git
fetch = +refs/heads/*:refs/remotes/origin/*
[branch "master"]
remote = origin
merge = refs/heads/master
-------------------
Which seems fine to me...
Any ideas?
This is of course only for people who want to clone my web-hosted repo
and then be able to subsequently git-pull my updates.
thanks,
Steve
^ 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