* Re: git-stash: RFC: Adopt the default behavior to other commands
From: Benoit Sigoure @ 2007-12-17 22:32 UTC (permalink / raw)
To: Sebastian Harl; +Cc: git
In-Reply-To: <20071217110322.GH14889@albany.tokkee.org>
On Dec 17, 2007, at 12:03 PM, Sebastian Harl wrote:
> Hi,
>
> By default, git-stash (when called without any other arguments)
> creates a new
> stash. This is quite different to the behavior of most other Git
> commands
> (e.g. git-tag, git-branch, etc. do "list" by default). In order to
> improve
> consistency git-stash should imho adopt this as well.
>
> The creation of a new stash should not do any harm. However, I
> think that
> consistency is more important (iirc this has been mentioned in the
> current
> survey a couple of times) and doing "list" is (in general) the best
> default.
Hi Sebastian,
this topic has been brought up the ML several times already, and
there seems to be some sort of consensus on the misbehavior of git
stash and what the default should be (listing the stashes seems like
a decent default action). 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
Hopefully, Git gives you means to recover from this sort of error,
but most of the time new comers don't know them and just assume they
lost their work.
Whenever I use git stash, it gives me chills, because I know I can
easily screw things up (even though now I know how to recover from
this sort of "user error").
Cheers,
--
Benoit Sigoure aka Tsuna
EPITA Research and Development Laboratory
^ permalink raw reply
* [PATCH] Minor portability patch to git-submodule
From: Andy Dougherty @ 2007-12-17 21:41 UTC (permalink / raw)
To: git
While trying git out on Solaris 8, I needed the following patch.
The 'grep' command on Solaris doesn't understand the -e option, though
egrep does.
More mysterious is the printf patch. Without it, the sed command didn't
match anything.
--- git-1.5.4.rc0/git-submodule.sh Wed Dec 12 21:29:16 2007
+++ git-andy/git-submodule.sh Mon Dec 17 14:30:46 2007
@@ -74,7 +74,7 @@
module_name()
{
# Do we have "submodule.<something>.path = $1" defined in .gitmodules file?
- re=$(printf '%s' "$1" | sed -e 's/[].[^$\\*]/\\&/g')
+ re=$(printf '%s\n' "$1" | sed -e 's/[].[^$\\*]/\\&/g')
name=$( GIT_CONFIG=.gitmodules \
git config --get-regexp '^submodule\..*\.path$' |
sed -n -e 's|^submodule\.\(.*\)\.path '"$re"'$|\1|p' )
@@ -176,7 +176,7 @@
#
modules_init()
{
- git ls-files --stage -- "$@" | grep -e '^160000 ' |
+ git ls-files --stage -- "$@" | egrep -e '^160000 ' |
while read mode sha1 stage path
do
# Skip already registered paths
@@ -209,7 +209,7 @@
#
modules_update()
{
- git ls-files --stage -- "$@" | grep -e '^160000 ' |
+ git ls-files --stage -- "$@" | egrep -e '^160000 ' |
while read mode sha1 stage path
do
name=$(module_name "$path") || exit
@@ -268,7 +268,7 @@
#
modules_list()
{
- git ls-files --stage -- "$@" | grep -e '^160000 ' |
+ git ls-files --stage -- "$@" | egrep -e '^160000 ' |
while read mode sha1 stage path
do
name=$(module_name "$path") || exit
--
Andy Dougherty doughera@lafayette.edu
^ permalink raw reply
* [PATCH] Explain what 'ginstall' is
From: Andy Dougherty @ 2007-12-17 21:46 UTC (permalink / raw)
To: git
While trying git out on Solaris 8, the 'make install' step failed because
I don't have a 'ginstall' command. After puzzling over it for a while,
I finally figured out that
a) it's referring to the 'install' command that is now part of the
GNU coreutils package, and
b) it's probably unnecessary, as using the Solaris install command
gave me the same results. (However, I didn't do anything fancy,
so it may be that in some scenarios using 'ginstall' matters.
I didn't do anything other than a very simple test.)
Anyway, this patch documents it a tiny bit more. Perhaps configure
should just go looking for a suitable install program instead of
assuming everyone has one.
--- git-1.5.4.rc0/Makefile 2007-12-12 21:29:16.000000000 -0500
+++ git-andy/Makefile 2007-12-17 15:15:12.000000000 -0500
@@ -416,6 +416,9 @@
NO_STRLCPY = YesPlease
NO_MEMMEM = YesPlease
endif
+# For SunOS, this assumes you have ginstall from the
+# GNU coreutils package. It's not clear whether that
+# is actually necessary.
ifeq ($(uname_S),SunOS)
NEEDS_SOCKET = YesPlease
NEEDS_NSL = YesPlease
--
Andy Dougherty doughera@lafayette.edu
^ permalink raw reply
* Re: [StGit PATCH 00/17] Series short description
From: Karl Hasselström @ 2007-12-17 22:48 UTC (permalink / raw)
To: Catalin Marinas; +Cc: David Kågedal, git
In-Reply-To: <b0943d9e0712170309n415dc6cs9d1c1f8a9c687bf8@mail.gmail.com>
On 2007-12-17 11:09:06 +0000, Catalin Marinas wrote:
> On 14/12/2007, David Kågedal <davidk@lysator.liu.se> wrote:
>
> > The following series an emacs interface to stgit patch stacks. It
> > shows a buffer with the the output of "stg series" and allows you
> > to do some common operations on it, such as push/pop,
> > commit/uncommit, edit, rename, repair, and coalesce.
>
> That's really cool stuff! Thanks.
Yes, incredibly useful.
I've put this series in kha/safe -- except for the mark and coalesce
patches, which are at the tip of kha/experimental. The latter because
it obviously has to be, the former because the latter is the only
thing using it and it's _extremely annoying_ to be able to mark
patches but not, say, push or pop all marked patches.
My stack is now 53 patches deep, so running the test suite on every
patch is getting time consuming -- I'd guess about two hours on my
poor laptop. And I plan to sleep while that runs, so I won't actually
push this until tomorrow.
> > The coalesce command obviosly requires the kha/experimental
> > branch. The edit command requires the edit fixes in kha/safe.
>
> I'll start this week merging patches from kha/experimental (I'm a
> bit slow because of the Christmas activities).
Be careful about merging past the "goto" patch -- I'm pretty sure it
breaks when called from a subdirectory, and I don't have time to fix
that right now. (It should be a clean fix, though -- just adjust the
cwd for precisely those git subprocesses that need it, which is very
few. I think.)
If you like, I can advance "safe" to include as many patches as I
think you should merge right now.
--
Karl Hasselström, kha@treskal.com
www.treskal.com/kalle
^ permalink raw reply
* Re: [PATCH] Minor portability patch to git-submodule
From: Johannes Schindelin @ 2007-12-17 22:54 UTC (permalink / raw)
To: Andy Dougherty; +Cc: git
In-Reply-To: <Pine.LNX.4.64.0712171639420.24957@fractal.phys.lafayette.edu>
Hi,
On Mon, 17 Dec 2007, Andy Dougherty wrote:
> - git ls-files --stage -- "$@" | grep -e '^160000 ' |
> + git ls-files --stage -- "$@" | egrep -e '^160000 ' |
Nack. egrep is not available on all platforms. But then I have to wonder
why not saying "grep '^160000 '" instead?
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH] provide advance warning of some future pack default changes
From: Junio C Hamano @ 2007-12-17 22:55 UTC (permalink / raw)
To: J. Bruce Fields; +Cc: Nicolas Pitre, Joel Becker, Jakub Narebski, git
In-Reply-To: <20071217223055.GI13515@fieldses.org>
"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.
^ permalink raw reply
* git with custom diff for commits
From: Gerald Gutierrez @ 2007-12-17 22:56 UTC (permalink / raw)
To: git
Hello folks,
I do a nightly mysqldump of a database and check it into a git
repository. mysqldump generates a timestamp as part of that output
which is causing git to think that the file changes every night when
it really doesn't. The timestamp is simply in an SQL comment.
So what I'd like to do is teach git to ignore that particular SQL
timestamp comment. 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?
Gerald.
^ permalink raw reply
* Re: "Argument list too long" in git remote update (Was: Git and GCC)
From: Johannes Schindelin @ 2007-12-17 22:59 UTC (permalink / raw)
To: Geert Bosch; +Cc: Harvey Harrison, Git Mailing List
In-Reply-To: <37BDCA73-4318-4BC8-9CCE-1DA30E4A09FC@adacore.com>
Hi,
On Mon, 17 Dec 2007, Geert Bosch wrote:
> On Dec 13, 2007, at 14:05, Harvey Harrison wrote:
> > After the discussions lately regarding the gcc svn mirror. I'm coming
> > up with a recipe to set up your own git-svn mirror. Suggestions on the
> > following.
> >
> > // Create directory and initialize git
> > mkdir gcc
> > cd gcc
> > git init
> > // add the remote site that currently mirrors gcc
> > // I have chosen the name gcc.gnu.org *1* as my local name to refer to
> > // this choose something else if you like
> > git remote add gcc.gnu.org git://git.infradead.org/gcc.git
> > // fetching someone else's remote branches is not a standard thing to do
> > // so we'll need to edit our .git/config file
> > // you should have a section that looks like:
> > [remote "gcc.gnu.org"]
> > url = git://git.infradead.org/gcc.git
> > fetch = +refs/heads/*:refs/remotes/gcc.gnu.org/*
> > // infradead's mirror puts the gcc svn branches in its own namespace
> > // refs/remotes/gcc.gnu.org/*
> > // change our fetch line accordingly
> > [remote "gcc.gnu.org"]
> > url = git://git.infradead.org/gcc.git
> > fetch = +refs/remotes/gcc.gnu.org/*:refs/remotes/gcc.gnu.org/*
> > // fetch the remote data from the mirror site
> > git remote update
>
> With git version 1.5.3.6 on Mac OS X, this results in:
> potomac%:~/gcc%git remote update
> Updating gcc.gnu.org
> /opt/git/bin/git-fetch: line 220: /opt/git/bin/git: Argument list too long
> warning: no common commits
> [after a long wait and a good amount of network traffic]
> fatal: index-pack died of signal 13
> fetch gcc.gnu.org: command returned error: 126
> potomac%:~/gcc%
>
> Any ideas on what to do to resolve this?
Unfortunately, the builtin remote did not make it into git's master yet,
and it will probably miss 1.5.4.
Chances are that this would make the bug go away, but Junio said that on
one of his machines, the regression tests fail with the builtin remote.
In the meantime, "git fetch gcc.gnu.org" should do what you want,
methinks.
Hth,
Dscho
^ permalink raw reply
* Re: git-stash: RFC: Adopt the default behavior to other commands
From: Junio C Hamano @ 2007-12-17 23:00 UTC (permalink / raw)
To: Benoit Sigoure; +Cc: Sebastian Harl, git
In-Reply-To: <506C6191-655D-46AE-A5C2-1335A9044F44@lrde.epita.fr>
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.
^ permalink raw reply
* Re: git with custom diff for commits
From: Johannes Schindelin @ 2007-12-17 23:01 UTC (permalink / raw)
To: Gerald Gutierrez; +Cc: git
In-Reply-To: <60687a7d0712171456p14328817y5aa229f0df23c02f@mail.gmail.com>
Hi,
On Mon, 17 Dec 2007, Gerald Gutierrez wrote:
> I do a nightly mysqldump of a database and check it into a git
> repository. mysqldump generates a timestamp as part of that output which
> is causing git to think that the file changes every night when it really
> doesn't. The timestamp is simply in an SQL comment.
>
> So what I'd like to do is teach git to ignore that particular SQL
> timestamp comment. 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".
Hth,
Dscho
^ permalink raw reply
* Re: "Argument list too long" in git remote update (Was: Git and GCC)
From: Linus Torvalds @ 2007-12-17 23:01 UTC (permalink / raw)
To: Geert Bosch; +Cc: Harvey Harrison, Git Mailing List
In-Reply-To: <37BDCA73-4318-4BC8-9CCE-1DA30E4A09FC@adacore.com>
On Mon, 17 Dec 2007, Geert Bosch wrote:
>
> With git version 1.5.3.6 on Mac OS X, this results in:
> potomac%:~/gcc%git remote update
> Updating gcc.gnu.org
> /opt/git/bin/git-fetch: line 220: /opt/git/bin/git: Argument list too long
Oops.
> Any ideas on what to do to resolve this?
Can you try the current git tree? "git fetch" is built-in these days, and
that old shell-script that ran "git fetch--tool" on all the refs is no
more, so most likely the problem simply no longer exists.
But maybe there is some way to raise the argument size limit on OS X. One
thing to check is whether maybe you have an excessively big environment
(just run "printenv" to see what it contains) which might be cutting down
on the size allowed for arguments.
Linus
^ permalink raw reply
* Re: [PATCH] include/asm-arm/: Spelling fixes
From: Jeff King @ 2007-12-17 23:05 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Joe Perches, J. Bruce Fields, git
In-Reply-To: <7vy7bt57wn.fsf@gitster.siamese.dyndns.org>
On Mon, Dec 17, 2007 at 01:27:20PM -0800, Junio C Hamano wrote:
> > my $sanitized_sender = sanitize_address($sender);
> > - make_message_id();
> > + make_message_id() unless defined($message_id);
>
> Isn't this called inside a loop? If the outgoing message does not
> originally have "Message-Id:", does the loop correctly reinitialize
> $message_id to undef, or does this change make everybody reuse the same
> $message_id over and over again?
Yes, sorry. I realized it right after I sent the other out, but then a
repairman showed up to fix my non-working furnace. :)
The following needs to be squashed in (alternatively, the message_id
doesn't need to be a loop variable, so it could be cleaned up. But part
of me says that git-send-email is beyond hope for being clean).
diff --git a/git-send-email.perl b/git-send-email.perl
index 083466a..248d035 100755
--- a/git-send-email.perl
+++ b/git-send-email.perl
@@ -808,6 +808,7 @@ foreach my $t (@files) {
$references = "$message_id";
}
}
+ $message_id = undef;
}
if ($compose) {
> I have a feeling that --thread to format-patch is a misfeature. Why is
> it needed if you are feeding the output to send-email?
I think it is a case of --thread being added for people not using
send-email, and then getting it misused. I am just trying to add a
sanity check to send-email in case the user does something silly (though
one could certainly argue that it is already hopelessly tied to
git-format-patch, and fixing git-format-patch is the right way to go).
> 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.
-Peff
^ permalink raw reply related
* Re: [PATCH] builtin-tag: fix fallouts from recent parsopt restriction.
From: Jeff King @ 2007-12-17 23:07 UTC (permalink / raw)
To: Pierre Habouzit, Junio C Hamano, git
In-Reply-To: <20071217210116.GB13004@artemis.madism.org>
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.
-Peff
^ permalink raw reply
* Re: git with custom diff for commits
From: Matthieu Moy @ 2007-12-17 23:08 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Gerald Gutierrez, git
In-Reply-To: <Pine.LNX.4.64.0712172300510.9446@racer.site>
Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> Hi,
>
> On Mon, 17 Dec 2007, Gerald Gutierrez wrote:
>
>> I do a nightly mysqldump of a database and check it into a git
>> repository. mysqldump generates a timestamp as part of that output which
>> is causing git to think that the file changes every night when it really
>> doesn't. The timestamp is simply in an SQL comment.
>>
>> So what I'd like to do is teach git to ignore that particular SQL
>> timestamp comment. 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.
--
Matthieu
^ 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
* 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
* 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: [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] 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: 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: 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 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: [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-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: 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
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