* Re: theirs/ours was Re: [PATCH 6/6] Add a new test for using a custom merge strategy
From: Jeff King @ 2008-07-29 12:36 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: sverre, Git Mailinglist, Miklos Vajna
In-Reply-To: <alpine.DEB.1.00.0807291301060.4631@eeepc-johanness>
On Tue, Jul 29, 2008 at 01:05:11PM +0200, Johannes Schindelin wrote:
> > Perhaps. But I see this as an operation on the production branch: "pull
> > in master's changes, forgetting ours".
>
> First of all, I cannot say how wrong it is to forget any changes in a
> production branch without proper explanation. I.e. without a commit
> message explaining _why_ the change was wrong to begin with.
Of course; I even mentioned the same in another part of the thread. But
that isn't a difference between "ours" and "theirs"; any time you are
discarding some changes, you should mention why.
> > In your workflow (git checkout master && git merge -s ours production &&
> > git push origin master:production) we perform an operation on master,
> > which doesn't seem as intuitive to me.
>
> But why? Isn't the _content_ of "master" what we want?
Sure, which means we must _read_ from master. But you are _changing_
master. Whereas I view this as an operation on the production branch.
Please don't misunderstand me. I am not saying your way of thinking
about it is wrong (or even less right than mine). What I have been
trying to say this whole thread is that it is reasonable for a user to
model the goal as I have described, and that git can easily support the
direct implementation of achieving that goal (which is what Sverre asked
originally -- is this useful to people?).
> > Not to mention that we might not _control_ master.
>
> This is Git. We control all local branches.
Sort of. Consider the kernel example I gave. A "linus" branch represents
"this is where Linus is." But that _isn't_ where Linus is if you have
added an extra merge commit to it. So either we throw away the change
made to the "linus" branch, or we forever have extra merges that Linus
does not have.
So yes, obviously you can do whatever you like with your local branches.
But you complained in my example that the "production" branch was
unnecessarily being treated as "dominant". My example was meant to
indicate that the "thrown away" branch is dominant for a reason (in this
case, it is my work branch, while the other is a tracking branch).
> No, this workflow almost _dictates_ a plain "pull" into your local branch.
> The fact that a few commits were applied to upstream usually only means
> that your merge succeeds trivially, since the merged branches contain the
> _same_ changes.
I don't see the point in talking about "usually". In the scenario in
which I used it, the merge _didn't_ succeed trivially. Of course,
usually you would not use "-s theirs". But the question was "is this
ever useful?" and my answer was "rarely, but here is an example of when
I wanted it."
If you are using "-s theirs" frequently, you are probably doing
something wrong. But that doesn't mean it is wrong for it to exist.
-Peff
^ permalink raw reply
* RE: [PATCH] git-gui: Look for gitk in $PATH, not $LIBEXEC/git-core
From: Murphy, John @ 2008-07-29 12:40 UTC (permalink / raw)
To: spearce, Abhijit Menon-Sen; +Cc: git
In-Reply-To: <20080725220544.GD23202@spearce.org>
I have rebuilt git-gui with version 0.10.2.18.gc629 it is still not finding gitk.
I have done some debugging in proc _which
I have found the issue is with the following line:
set p [file join $p $what$_search_exe]
The variable $p = gitk.exe
And there is no such animal
When I copy gitk to gitk.exe in /usr/local/git/bin, it works fine.
So, not sure if this is a git issue or a git-gui issue.
-John
-----Original Message-----
From: spearce@spearce.org [mailto:spearce@spearce.org]
Sent: Friday, July 25, 2008 6:06 PM
To: Abhijit Menon-Sen
Cc: Murphy, John; git@vger.kernel.org
Subject: Re: [PATCH] git-gui: Look for gitk in $PATH, not $LIBEXEC/git-core
Abhijit Menon-Sen <ams@toroid.org> wrote:
> At 2008-07-24 09:01:48 -0400, john.murphy@bankofamerica.com wrote:
> >
> > I presume this was just an oversight when git- commands were removed
> > from the bin directory.
>
> Looks like it. The following patch fixes it for me. Does it work for
> you on Windows?
Thanks.
This patch is obviously correct on any platform except Mac OS X.
On Mac OS X it gets confusing because [info nameofexecutable] is
a wrapper .app which loads its own main script. That main script
needs to use the gitk location it receives from git-gui, and not
the location it computes from gitexecdir. So I'm following up
your patch with this:
diff --git a/macosx/AppMain.tcl b/macosx/AppMain.tcl
index 41ca08e..ddbe633 100644
--- a/macosx/AppMain.tcl
+++ b/macosx/AppMain.tcl
@@ -7,7 +7,7 @@ if {[string first -psn [lindex $argv 0]] == 0} {
}
if {[file tail [lindex $argv 0]] eq {gitk}} {
- set argv0 [file join $gitexecdir gitk]
+ set argv0 [lindex $argv 0]
set AppMain_source $argv0
} else {
set argv0 [file join $gitexecdir [file tail [lindex $argv 0]]]
--
Shawn.
^ permalink raw reply related
* Re: theirs/ours was Re: [PATCH 6/6] Add a new test for using a custom merge strategy
From: Sverre Rabbelier @ 2008-07-29 12:42 UTC (permalink / raw)
To: Jeff King; +Cc: Johannes Schindelin, Git Mailinglist, Miklos Vajna
In-Reply-To: <20080729123629.GA12069@sigill.intra.peff.net>
On Tue, Jul 29, 2008 at 14:36, Jeff King <peff@peff.net> wrote:
<good explanation of what I meant snipped>
> If you are using "-s theirs" frequently, you are probably doing
> something wrong. But that doesn't mean it is wrong for it to exist.
Exactly, thank you for that :). I hope it is clear to everybody what I
meant now, although it seems that especially Junio and Dscho feel
'git-merge-theirs' should not be part of git in the suggested form.
--
Cheers,
Sverre Rabbelier
^ permalink raw reply
* Re: theirs/ours was Re: [PATCH 6/6] Add a new test for using a custom merge strategy
From: Jeff King @ 2008-07-29 12:42 UTC (permalink / raw)
To: Mike Ralphson
Cc: Junio C Hamano, Johannes Schindelin, sverre, Git Mailinglist,
Miklos Vajna
In-Reply-To: <e2b179460807290236k214b41f2wee25c213d7c95ae3@mail.gmail.com>
On Tue, Jul 29, 2008 at 10:36:32AM +0100, Mike Ralphson wrote:
> > I just didn't want history thrown away for two reasons:
> >
> > - historical interest; some of the commits had counterparts in devel
> > that were done differently (because the two branches had diverged),
> > but it might later be interesting to see how and why the stable
> > changes were done (e.g., if a similar situation arose)
> >
> > - this project did not rebase, favoring the simplicity of "git pull"
> > over clean history.
> >
> > Bear in mind that this project was not very big. I think devel had ~20
> > commits, and stable had about ~5. So it was easy to get such confidence.
>
> Is there any reason you couldn't have reverted the stable commits in
> preparation for the merge from devel?
No, there is no technical reason. I think that is a perfectly valid way
of accomplishing the same goal (as is switching to the "kept" branch and
using "-s ours"). It's just that we had a particular mental model, and
the simplest way of translating that model into a git history graph was
as I described.
Again, I don't think this is a common problem, and I have certainly not
been aching for "-s theirs". The question was whether such a thing might
be useful, and I think it is, if only because it most directly matches
how a user might be thinking of the problem; for other users, or other
similar situations, one of the other methods might make more sense.
To me, seeing a commit that joins two histories with a comment saying
"these two branches are now becoming the same, but we don't care about
what happened down this ancestry chain because of X" most directly
models what happened (in my case).
-Peff
^ permalink raw reply
* Re: Bizarre missing changes (git bug?)
From: Olivier Galibert @ 2008-07-29 12:48 UTC (permalink / raw)
To: Roman Zippel; +Cc: Jeff King, Linus Torvalds, Tim Harper, git
In-Reply-To: <Pine.LNX.4.64.0807291339580.6791@localhost.localdomain>
On Tue, Jul 29, 2008 at 02:32:14PM +0200, Roman Zippel wrote:
> Most frequently this involves changes where the same change is merged
> twice. [...]
You're not answering the question. You cite cases when you consider
both the default and the full-history output incorrect from a
usefulness point of view. The question is, what would the correct
output be, from your point of view? What should be shown, and what
shouldn't?
OG.
^ permalink raw reply
* Re: Bizarre missing changes (git bug?)
From: Jeff King @ 2008-07-29 12:52 UTC (permalink / raw)
To: Roman Zippel; +Cc: Linus Torvalds, Tim Harper, git
In-Reply-To: <Pine.LNX.4.64.0807291339580.6791@localhost.localdomain>
On Tue, Jul 29, 2008 at 02:32:14PM +0200, Roman Zippel wrote:
> > Perhaps I am just slow, but I haven't been able to figure out what that
> > history is, or what the "correct" output should be. Can you try to state
> > more clearly what it is you are looking for?
>
> Most frequently this involves changes where the same change is merged
> twice. Another interesting example is kernel/printk.c where a change is
> added and later removed again before it's merged.
I glanced briefly over "gitk kernel/printk.c" and it looks pretty sane.
I was really hoping for you to make your case as something like:
1. here is an ascii diagram of an actual history graph (or a recipe of
git commands for making one)
2. here is what git-log (or gitk) produces for this history by
default; and here is why it is not optimal (presumably some
information it fails to convey)
3. here is what git-log (or gitk) with --full-history produces; and
here is why it is not optimal (presumably because it is too messy)
4. here is what output I would like to see. Bonus points for "and here
is an algorithm that accomplishes it."
> The point is now that I think the problem is solvable even within Linus'
> constraints, so that git-log produces the right output by default and a
> workaround like --full-history isn't needed anymore.
I think this is a separate issue. Even if you came up with some great
new history simplification, it likely wouldn't become the _default_
right away anyway. So you need to:
1. produce a new simplification algorithm that is at least useful in
_some_ contexts. Then this can be used when desired for those
contexts. It almost doesn't matter how efficient it is, if it is
providing results that are otherwise unavailable. A user can choose
to take the performance hit to get those results.
2. If that algorithm doesn't provide worse output in any other
contexts _and_ it has similar performance to the current default,
then it can be considered for the default.
But I haven't seen convincing evidence leading to step '1', so arguing
about step '2' seems pointless.
-Peff
^ permalink raw reply
* Re: git-svn and svn:externals, was Re: Hackontest ideas?
From: Johannes Schindelin @ 2008-07-29 13:04 UTC (permalink / raw)
To: Jakub Narebski; +Cc: Petr Baudis, Eric Wong, git
In-Reply-To: <200807291428.32072.jnareb@gmail.com>
Hi,
On Tue, 29 Jul 2008, Jakub Narebski wrote:
> Johannes Schindelin wrote:
>
> > On Tue, 29 Jul 2008, Jakub Narebski wrote:
> >
> > > * handling of svn:externals using submodules
> >
> > The main concern I have is to get the semantics right: AFAICT
> > svn:externals has _no notion_ of "what is current". It just _always_
> > fetches the HEAD. Even if you check out an ancient revision in the
> > "superproject".
>
> If I understand correctly with version 1.5 svn:externals can be
> specified using "peg revisions", so they could refer to some specific
> revision of 'external', like git submodules.
... which only means that if they had done that from the beginning, it
the git-svn enhancement would be easy.
But as they did not have it from the beginning, anybody tackling git-svn
and svn:externals will have to come up with sensible semantics for the
hard case.
Ciao,
Dscho
^ permalink raw reply
* Re: git submodules
From: Pierre Habouzit @ 2008-07-29 13:07 UTC (permalink / raw)
To: Johannes Schindelin
Cc: Petr Baudis, Benjamin Collins, Avery Pennarun, Nigel Magnay,
Git ML
In-Reply-To: <alpine.DEB.1.00.0807291413460.4631@eeepc-johanness>
[-- Attachment #1: Type: text/plain, Size: 983 bytes --]
On Tue, Jul 29, 2008 at 12:15:05PM +0000, Johannes Schindelin wrote:
> On Tue, 29 Jul 2008, Petr Baudis wrote:
> > On Tue, Jul 29, 2008 at 10:37:55AM +0200, Pierre Habouzit wrote:
> >
> > > path = "$path"
> > > url = git://somewhere/
> > > tracks = master
[...]
> But then, how does the relation to the currently _committed_ state get
> displayed?
Hmm _that's_ why you need a name for it. Or you need the submodule to be
aware he's one, and then one would have some kind of "magic" word to
name this sha1. And tools would find out in the supermodule what it
translates into. I don't have any briliant idea for a proposal
(COMMITED_HEAD is clearly too long ;p, BASE is not very explicit, ...)
but someone will have one.
Ideally gitk would show some litle tag for this state too.
--
·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: git submodules
From: Johannes Schindelin @ 2008-07-29 13:15 UTC (permalink / raw)
To: Pierre Habouzit
Cc: Petr Baudis, Benjamin Collins, Avery Pennarun, Nigel Magnay,
Git ML
In-Reply-To: <20080729130713.GF32312@artemis.madism.org>
Hi,
On Tue, 29 Jul 2008, Pierre Habouzit wrote:
> On Tue, Jul 29, 2008 at 12:15:05PM +0000, Johannes Schindelin wrote:
> > On Tue, 29 Jul 2008, Petr Baudis wrote:
> > > On Tue, Jul 29, 2008 at 10:37:55AM +0200, Pierre Habouzit wrote:
> > >
> > > > path = "$path"
> > > > url = git://somewhere/
> > > > tracks = master
> [...]
> > But then, how does the relation to the currently _committed_ state get
> > displayed?
>
> Hmm _that's_ why you need a name for it.
I do not understand. We are talking about three different things here:
1) the committed state of the submodule
2) the local state of the submodule
3) the state of the "tracks" branch
We always have 1) and we have 2) _iff_ the submodule was checked out. We
only will have 3) if "tracks" is set in .git/config (for consistency's
sake, we should not read that information directly from the .gitmodules
file, but let the user override it in .git/config after "submodule init".
> Or you need the submodule to be aware he's one, and then one would have
> some kind of "magic" word to name this sha1. And tools would find out in
> the supermodule what it translates into.
You lost me there.
Ciao,
Dscho
^ permalink raw reply
* Re: git-svn and svn:externals, was Re: Hackontest ideas?
From: Luciano Rocha @ 2008-07-29 13:08 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Jakub Narebski, Petr Baudis, Eric Wong, git
In-Reply-To: <alpine.DEB.1.00.0807291354130.4631@eeepc-johanness>
[-- Attachment #1: Type: text/plain, Size: 925 bytes --]
On Tue, Jul 29, 2008 at 01:56:37PM +0200, Johannes Schindelin wrote:
> Hi,
>
> On Tue, 29 Jul 2008, Jakub Narebski wrote:
>
> > * handling of svn:externals using submodules
>
> I doubt that this is easy. Otherwise, Eric would have done it a long time
> ago.
>
> The main concern I have is to get the semantics right: AFAICT
> svn:externals has _no notion_ of "what is current". It just _always_
> fetches the HEAD. Even if you check out an ancient revision in the
> "superproject".
Usually, yes. But you could specify a specific revision with -r <rev>.
Or, for branches/tags, as they're paths, a correct url would suffice.
With the new 1.5, it is also possible to specify pegged revisions. Much
better, because otherwise subversion would require that the path existed
in the server in HEAD.
--
Luciano Rocha <luciano@eurotux.com>
Eurotux Informática, S.A. <http://www.eurotux.com/>
[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* Re: gitk crashes when quitting gitk while it is is reading commits (was Re: gitk crashing on Windows.)
From: Dmitry Potapov @ 2008-07-29 13:15 UTC (permalink / raw)
To: Steffen Prohaska; +Cc: Eric Raible, git
In-Reply-To: <E7C7B8BA-6050-40DE-917C-200EAE9CA6E8@zib.de>
On Mon, Jul 28, 2008 at 09:18:35PM +0200, Steffen Prohaska wrote:
>
> I don't think the problem is Windows-specific. At least on Mac I am
> seeing similar problems. When I hit CTRL-q while gitk is still reading
> the commits, it crashes with as segfault.
On Linux, when I hit CTRL-q (after a few attempts), I got this:
invalid command name ".tf.histframe.pwclist.canv"
while executing
"$canv yview"
(procedure "drawvisible" line 5)
invoked from within
"drawvisible"
(procedure "layoutmore" line 14)
invoked from within
"layoutmore"
(procedure "chewcommits" line 5)
invoked from within
"chewcommits"
("eval" body line 1)
invoked from within
"eval $script"
(procedure "dorunq" line 9)
invoked from within
"dorunq"
("after" script)
X Error of failed request: BadWindow (invalid Window parameter)
Major opcode of failed request: 8 (X_MapWindow)
Resource id in failed request: 0x0
Serial number of failed request: 2453
Current serial number in output stream: 2456
Dmitry
^ permalink raw reply
* Re: git-svn and svn:externals, was Re: Hackontest ideas?
From: Johannes Schindelin @ 2008-07-29 13:17 UTC (permalink / raw)
To: Luciano Rocha; +Cc: Jakub Narebski, Petr Baudis, Eric Wong, git
In-Reply-To: <20080729130823.GB30334@bit.office.eurotux.com>
Hi,
On Tue, 29 Jul 2008, Luciano Rocha wrote:
> On Tue, Jul 29, 2008 at 01:56:37PM +0200, Johannes Schindelin wrote:
>
> > On Tue, 29 Jul 2008, Jakub Narebski wrote:
> >
> > > * handling of svn:externals using submodules
> >
> > The main concern I have is to get the semantics right: AFAICT
> > svn:externals has _no notion_ of "what is current". It just _always_
> > fetches the HEAD. Even if you check out an ancient revision in the
> > "superproject".
>
> Usually, yes. But you could specify a specific revision with -r <rev>.
I do not see how that helps defining the semantics for git-svn at all.
> With the new 1.5, it is also possible to specify pegged revisions. Much
> better, because otherwise subversion would require that the path existed
> in the server in HEAD.
As I already commented, the possibility (and for most svn repositories,
the likelihood) that nothing is pegged makes this less helpful, either.
Ciao,
Dscho
^ permalink raw reply
* Re: git submodules
From: Pierre Habouzit @ 2008-07-29 13:19 UTC (permalink / raw)
To: Johannes Schindelin
Cc: Petr Baudis, Benjamin Collins, Avery Pennarun, Nigel Magnay,
Git ML
In-Reply-To: <alpine.DEB.1.00.0807291511400.4631@eeepc-johanness>
[-- Attachment #1: Type: text/plain, Size: 990 bytes --]
On Tue, Jul 29, 2008 at 01:15:10PM +0000, Johannes Schindelin wrote:
> Hi,
>
> On Tue, 29 Jul 2008, Pierre Habouzit wrote:
>
> > On Tue, Jul 29, 2008 at 12:15:05PM +0000, Johannes Schindelin wrote:
> > > On Tue, 29 Jul 2008, Petr Baudis wrote:
> > > > On Tue, Jul 29, 2008 at 10:37:55AM +0200, Pierre Habouzit wrote:
> > > >
> > > > > path = "$path"
> > > > > url = git://somewhere/
> > > > > tracks = master
> > [...]
> > > But then, how does the relation to the currently _committed_ state get
> > > displayed?
> > Or you need the submodule to be aware he's one, and then one would have
> > some kind of "magic" word to name this sha1. And tools would find out in
> > the supermodule what it translates into.
>
> You lost me there.
Then I didn't understand your question.
--
·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: git submodules
From: Nigel Magnay @ 2008-07-29 13:31 UTC (permalink / raw)
To: Johannes Schindelin
Cc: Pierre Habouzit, Petr Baudis, Benjamin Collins, Avery Pennarun,
Git ML
In-Reply-To: <alpine.DEB.1.00.0807291511400.4631@eeepc-johanness>
> I do not understand. We are talking about three different things here:
>
> 1) the committed state of the submodule
> 2) the local state of the submodule
> 3) the state of the "tracks" branch
>
> We always have 1) and we have 2) _iff_ the submodule was checked out. We
> only will have 3) if "tracks" is set in .git/config (for consistency's
> sake, we should not read that information directly from the .gitmodules
> file, but let the user override it in .git/config after "submodule init".
>
I think the implication is that .gitconfig states "I'm expecting that
submodule X will always be tracking branch name 'Y'" and that you
wouldn't ever override it in .git/config. If you then switched
submodule X to branch Z, then committed the superproject, that commit
would contain a change to .gitconfig also (to say I'm expecting to
track Z rather than X') ?
>> Or you need the submodule to be aware he's one, and then one would have
>> some kind of "magic" word to name this sha1. And tools would find out in
>> the supermodule what it translates into.
>
> You lost me there.
>
This sounds like it relates to the problem that what I call X and Z,
you might call Bibble and Bobble; you could use some kind of SHA1 in
lieu of a textual name to make sure everyone was talking about the
same thing ?
> Ciao,
> Dscho
>
>
^ permalink raw reply
* Re: [PATCH] Respect crlf attribute even if core.autocrlf has not been set
From: Dmitry Potapov @ 2008-07-29 13:46 UTC (permalink / raw)
To: Eyvind Bernhardsen
Cc: Johannes Schindelin, Avery Pennarun, Joshua Jensen,
Junio C Hamano, git
In-Reply-To: <42C252B2-85B9-4D05-B3A2-2A0250D7F5D6@orakel.ntnu.no>
On Fri, Jul 25, 2008 at 11:05:33PM +0200, Eyvind Bernhardsen wrote:
>
> The reason I want versioning is to fix the problem of enforcing
> normalised line endings in repositories with checked-in CRLFs; I'm not
> sure how to solve it any other way, but I'm open to suggestions.
You clearly want *enforcing* and versioning for you is just means to do
that. Regardless, what is the best way to achieve that, the *main*
question is whether we want this enforcing and if yet then in what form
and to what degree...
>
> >If we had core.autocrlf=input as default then clueless users will not
> >checkin files with the incorrect ending. But there is an objection to
> >that -- you penalize those who always have good endings. And even the
> >fact that is merely default value that you can easily change to false
> >does not convince everyone.
>
> That is an excellent argument for why setting "autocrlf=true" by
> default on Windows was a bad idea. Thanks! :)
I am sorry, but I don't see connection here.
>
> >The same can be said about your
> >* eol=auto
> >It forces conversion on everyone, even on those who do not need it.
> >Of course, you can say those projects that do not have the problem
> >with
> >clueless users putting text files with incorrect end-of-lines will not
> >have lines like that in their .gitattribute. Yet, if I participate in
> >that project, why do I have to pay the price for this conversion just
> >because someone stupid can mess up line-endings?
>
> It's about correctness: if the repository isn't supposed to have CRs
> in any text files, that needs to be enforced. You might not be
> stupid, but that doesn't mean you won't ever take a file that was
> created on Windows and commit it to the repository on Linux. If the
> tool used to create the file was CR-damaged, there goes the
> repository's LF-only policy.
Again, why should people who do not use Windows and other CR-damaged
tools be penalized? No one can prevent me from putting in *my* own
repository whatever I want anyway. Thus, if we agreed having this
conversion/check is useful, remaining questions are:
1. whether this check should be possible to turn off
2. whether this check should be turned off by default for people
who use Git on other system than Windows?
The current status is:
1. Yes, it is possible to turn of this conversion
2. It is turned off by default for anyone but MSYS/GIT users.
And the main argument for having that in this way is that people with LF
text files should be unnecessary penalized for Windows being different.
>
> As you say, the reason I want the setting to be per-repository is that
> I don't think the cost is worthwhile for every repository.
Side note: Personally, I am not very concerned about this cost, but some
people are...
> The case
> where it _is_ worthwhile is when the repository will be shared between
> Windows users and Linux users, and the Windows users want CRLFs in
> their working directories. I think it's worthwhile to actually make
> Git work right in that case.
Windows users who want CRLF should set autocrlf=true
Windows users who prefer LF should set autocrlf=input
Non-Windows users who copy file directly from Windows should also
set autocrlf=input
All other users who do not touch Windows may have autocrlf=false.
Files that do not need conversion (such as *.bat) should be marked as
"-crlf" in .gitattributes.
Of course, those who are very careful and have good editors can set
autocrlf=false even on Windows...
>
> As a side note, there's a lot of complaining about the cost of
> enforcing LF-only input, but I can't remember seeing any actual
> numbers. Is it really that bad?
No, it is not bad. In most practical cases, you will not notice any
difference. I've posted some numbers in this thread. You can find
them here:
http://article.gmane.org/gmane.comp.version-control.git/89908
>
> >>There's also no way of saying "this file should
> >>have LF line endings, even with autocrlf=true".
> >
> >Actually, there is
> >
> >*.sh crlf=input
> >
> >i.e. I want my shell files to have LF even I normally use CRLF for
> >all other files (on Windows).
>
> Won't they still be converted to CRLF on checkout when autocrlf=true
> on Windows?
autocrlf=true works in the same way on Linux and Windows, and I have
tested it right now, and it works as I said above.
> >but there are people who do not want to pay any price for conversion.
> >Currently, "core.autocrlf=false" means to do nothing about end-of-
> >lines,
> >and even to ignore setting in .gitattributes. Should it be possible to
> >disable *any* conversion on checkin and checkout? Should this be that
> >value be the default, which most users use?
>
> Well, there's no reason why Git repositories used only on Windows
> machines shouldn't store CRLFs, so why should all msysgit users pay
> the cost on every checkin _and_ checkout?
1. You may want to use on other platforms later. In any case, it makes
much sense to have the default that compatible with other systems.
2. Conversion cost is not significant (I suppose much less than gzip
compression used for all objects) and it also saves some space.
3. Internally, Git considers only LF as true end of line. CR is just
like an extra space before end-of-line. Is any good reason to have
it inside of your repo anyway?
4. This is what other VCSes do on Windows. CVS converts all text files
on checkin. SVN does the same for files having svn:eol-style=native.
In fact, if you read the discussion we had here some time ago, you may
find some other arguments too.
>
> This is the reason the setting needs to be a per-repository policy and
> not a user configuration;
What exactly?
> users should not be able to configure away
> correctness,
Why not? *Every* user has him/her own repository, so he/she can do
*anything* with it, in principle.
> but they shouldn't be penalised unnecessarily for it,
> either.
The problem is how to determine when it is necessary and when it is
not. If I never commit with wrong EOLs, I don't think it is necessary
for me to have this conversion... On the other hand, I don't mind having
this check as default. It does not really bother me much, and if I can
turn it off, it is fine with me. But I suppose other people may feel
differently about this issue.
Dmitry
^ permalink raw reply
* Thunderbird: issues with applying saved patches
From: Bruce Stephens @ 2008-07-29 14:16 UTC (permalink / raw)
To: git
I can see comments and advice on how to *send* patches using
Thunderbird, but for the most part we're not attempting that (we're
using "git send-email").
However, we're (by "we" I mean those of my colleagues who use
Thunderbird, obviously) finding occasional issues with saving patches
from Thunderbird: "git am" complains that they're corrupt.
I'm not sure that they are, but they're Quoted-printable encoded, and
so perhaps not decoded quite correctly by git. Or perhaps they're
invalidly encoded.
I'm not sure that I care exactly what's at fault, though I think
Thunderbird ought to be able to save an article exactly as it is
(it appears to be encoding it using Quoted-printable).
Anyway, I'm surprised I don't see anyone else mentioning this. Have I
just missed it, or are we doing something silly (maybe there's some
slightly non-obvious way of saving an article in Thunderbird)?
Could be that other people just go to the message file or something.
Someone tells me that he has no problems if he moves the article from
the IMAP folder to a local folder and uses that. So maybe most people
just don't notice (because they're not using IMAP)?
^ permalink raw reply
* Re: git submodules
From: Pierre Habouzit @ 2008-07-29 14:49 UTC (permalink / raw)
To: Nigel Magnay
Cc: Johannes Schindelin, Petr Baudis, Benjamin Collins,
Avery Pennarun, Git ML
In-Reply-To: <320075ff0807290631l1f9a1e70jcb73bde7e2c86000@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 1112 bytes --]
On Tue, Jul 29, 2008 at 01:31:23PM +0000, Nigel Magnay wrote:
> > I do not understand. We are talking about three different things here:
> >
> > 1) the committed state of the submodule
> > 2) the local state of the submodule
> > 3) the state of the "tracks" branch
> >
> > We always have 1) and we have 2) _iff_ the submodule was checked out. We
> > only will have 3) if "tracks" is set in .git/config (for consistency's
> > sake, we should not read that information directly from the .gitmodules
> > file, but let the user override it in .git/config after "submodule init".
> >
>
> I think the implication is that .gitconfig states "I'm expecting that
> submodule X will always be tracking branch name 'Y'" and that you
> wouldn't ever override it in .git/config. If you then switched
> submodule X to branch Z, then committed the superproject, that commit
> would contain a change to .gitconfig also (to say I'm expecting to
> track Z rather than X') ?
Yes, tracks branch in .git/config doesn't fly. Or you need a
branch.$supermodule_branch.$submodule_name.tracks setting (oh god!)
[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* Re: git submodules
From: Junio C Hamano @ 2008-07-29 14:53 UTC (permalink / raw)
To: Nigel Magnay
Cc: Johannes Schindelin, Pierre Habouzit, Petr Baudis,
Benjamin Collins, Avery Pennarun, Git ML
In-Reply-To: <320075ff0807290631l1f9a1e70jcb73bde7e2c86000@mail.gmail.com>
"Nigel Magnay" <nigel.magnay@gmail.com> writes:
>> I do not understand. We are talking about three different things here:
>>
>> 1) the committed state of the submodule
>> 2) the local state of the submodule
>> 3) the state of the "tracks" branch
>>
>> We always have 1) and we have 2) _iff_ the submodule was checked out. We
>> only will have 3) if "tracks" is set in .git/config (for consistency's
>> sake, we should not read that information directly from the .gitmodules
>> file, but let the user override it in .git/config after "submodule init".
>
> I think the implication is that .gitconfig states "I'm expecting that
> submodule X will always be tracking branch name 'Y'" and that you
> wouldn't ever override it in .git/config. If you then switched
> submodule X to branch Z, then committed the superproject, that commit
> would contain a change to .gitconfig also (to say I'm expecting to
> track Z rather than X') ?
You are right. I think letting the user override with .git/config is a
good idea, but it shouldn't be ".gitmodules may say X or whatever, but I
want to use Y".
Instead, it should be more like "On branches where .gitmodules says X, I
want to use Y."
This comment actually applies to the existing override of .gitmodules item
with .git/config (I think I've been saying it since the design phase).
^ permalink raw reply
* [PATCH 0/5] Allow custom merge strategies, take 3
From: Miklos Vajna @ 2008-07-29 15:24 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <cover.1217207602.git.vmiklos@frugalware.org>
Hi,
Changes from 'take 2':
- the testcase now makes sure the trees are the same for 'theirs' as
well.
- patch 4 and 5 are squashed so there is no compile error after applying
only some of the patches. (or when bisecting)
- using FLEX_ARRAY in help.h
- the first two patches are unchanged
Miklos Vajna (5):
builtin-help: make is_git_command() usable outside builtin-help
builtin-help: make list_commands() a bit more generic
builtin-help: make it possible to exclude some commands in
list_commands()
builtin-merge: allow using a custom strategy
Add a new test for using a custom merge strategy
Makefile | 1 +
builtin-merge.c | 32 ++++++++++++++++++++-----
help.c | 57 ++++++++++++++++++++++++-----------------------
help.h | 19 +++++++++++++++
t/t7606-merge-custom.sh | 46 +++++++++++++++++++++++++++++++++++++
5 files changed, 120 insertions(+), 35 deletions(-)
create mode 100644 help.h
create mode 100755 t/t7606-merge-custom.sh
^ permalink raw reply
* [PATCH 3/5] builtin-help: make it possible to exclude some commands in list_commands()
From: Miklos Vajna @ 2008-07-29 15:25 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <cover.1217344802.git.vmiklos@frugalware.org>
The supposed method is to build a list of commands to be excluded using
add_cmdname(), then pass the list as the new exclude parameter. If no
exclude is needed, NULL should be used.
Signed-off-by: Miklos Vajna <vmiklos@frugalware.org>
---
help.c | 26 +++++++++++---------------
help.h | 14 +++++++++++++-
2 files changed, 24 insertions(+), 16 deletions(-)
diff --git a/help.c b/help.c
index 7a42517..858f76a 100644
--- a/help.c
+++ b/help.c
@@ -9,6 +9,7 @@
#include "common-cmds.h"
#include "parse-options.h"
#include "run-command.h"
+#include "help.h"
static struct man_viewer_list {
struct man_viewer_list *next;
@@ -300,18 +301,11 @@ static inline void mput_char(char c, unsigned int num)
putchar(c);
}
-static struct cmdnames {
- int alloc;
- int cnt;
- struct cmdname {
- size_t len;
- char name[1];
- } **names;
-} main_cmds, other_cmds;
+struct cmdnames main_cmds, other_cmds;
-static void add_cmdname(struct cmdnames *cmds, const char *name, int len)
+void add_cmdname(struct cmdnames *cmds, const char *name, int len)
{
- struct cmdname *ent = xmalloc(sizeof(*ent) + len);
+ struct cmdname *ent = xmalloc(sizeof(*ent) + len + 1);
ent->len = len;
memcpy(ent->name, name, len);
@@ -463,7 +457,7 @@ static unsigned int list_commands_in_dir(struct cmdnames *cmds,
return longest;
}
-static unsigned int load_command_list(const char *prefix)
+static unsigned int load_command_list(const char *prefix, struct cmdnames *exclude)
{
unsigned int longest = 0;
unsigned int len;
@@ -502,13 +496,15 @@ static unsigned int load_command_list(const char *prefix)
sizeof(*other_cmds.names), cmdname_compare);
uniq(&other_cmds);
exclude_cmds(&other_cmds, &main_cmds);
+ if (exclude)
+ exclude_cmds(&main_cmds, exclude);
return longest;
}
-void list_commands(const char *prefix, const char *title)
+void list_commands(const char *prefix, const char *title, struct cmdnames *exclude)
{
- unsigned int longest = load_command_list(prefix);
+ unsigned int longest = load_command_list(prefix, exclude);
const char *exec_path = git_exec_path();
if (main_cmds.cnt) {
@@ -558,7 +554,7 @@ static int is_in_cmdlist(struct cmdnames *c, const char *s)
int is_git_command(const char *s, const char *prefix)
{
- load_command_list(prefix);
+ load_command_list(prefix, NULL);
return is_in_cmdlist(&main_cmds, s) ||
is_in_cmdlist(&other_cmds, s);
}
@@ -704,7 +700,7 @@ int cmd_help(int argc, const char **argv, const char *prefix)
if (show_all) {
printf("usage: %s\n\n", git_usage_string);
- list_commands("git-", "git commands");
+ list_commands("git-", "git commands", NULL);
printf("%s\n", git_more_info_string);
return 0;
}
diff --git a/help.h b/help.h
index 0741662..3eb8cfb 100644
--- a/help.h
+++ b/help.h
@@ -1,7 +1,19 @@
#ifndef HELP_H
#define HELP_H
+struct cmdnames {
+ int alloc;
+ int cnt;
+ struct cmdname {
+ size_t len;
+ char name[FLEX_ARRAY];
+ } **names;
+};
+
int is_git_command(const char *s, const char *prefix);
-void list_commands(const char *prefix, const char *title);
+void list_commands(const char *prefix, const char *title, struct cmdnames *exclude);
+void add_cmdname(struct cmdnames *cmds, const char *name, int len);
+
+extern struct cmdnames main_cmds, other_cmds;
#endif /* HELP_H */
--
1.6.0.rc0.14.g95f8.dirty
^ permalink raw reply related
* [PATCH 4/5] builtin-merge: allow using a custom strategy
From: Miklos Vajna @ 2008-07-29 15:25 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <cover.1217344802.git.vmiklos@frugalware.org>
Allow using a custom strategy, as long as it's named git-merge-foo. The
error handling is now done using is_git_command(). The list of available
strategies is now shown by list_commands().
If an invalid strategy is supplied, like -s foobar, then git-merge would
list all git-merge-* commands. This is not perfect, since for example
git-merge-index is not a valid strategy.
These are removed from the output by scanning the list of main commands;
if the git-merge-foo command is listed in the all_strategy list, then
it's shown, otherwise excluded. This does not exclude commands somewhere
else in the PATH, where custom strategies are expected.
Signed-off-by: Miklos Vajna <vmiklos@frugalware.org>
---
builtin-merge.c | 32 +++++++++++++++++++++++++-------
1 files changed, 25 insertions(+), 7 deletions(-)
diff --git a/builtin-merge.c b/builtin-merge.c
index e78fa18..29826b1 100644
--- a/builtin-merge.c
+++ b/builtin-merge.c
@@ -22,6 +22,7 @@
#include "log-tree.h"
#include "color.h"
#include "rerere.h"
+#include "help.h"
#define DEFAULT_TWOHEAD (1<<0)
#define DEFAULT_OCTOPUS (1<<1)
@@ -77,7 +78,7 @@ static int option_parse_message(const struct option *opt,
static struct strategy *get_strategy(const char *name)
{
int i;
- struct strbuf err;
+ struct strategy *ret;
if (!name)
return NULL;
@@ -86,12 +87,29 @@ static struct strategy *get_strategy(const char *name)
if (!strcmp(name, all_strategy[i].name))
return &all_strategy[i];
- strbuf_init(&err, 0);
- for (i = 0; i < ARRAY_SIZE(all_strategy); i++)
- strbuf_addf(&err, " %s", all_strategy[i].name);
- fprintf(stderr, "Could not find merge strategy '%s'.\n", name);
- fprintf(stderr, "Available strategies are:%s.\n", err.buf);
- exit(1);
+ if (!is_git_command(name, "git-merge-")) {
+ struct cmdnames not_strategies;
+
+ memset(¬_strategies, 0, sizeof(struct cmdnames));
+ for (i = 0; i < main_cmds.cnt; i++) {
+ int j, found = 0;
+ struct cmdname *ent = main_cmds.names[i];
+ for (j = 0; j < ARRAY_SIZE(all_strategy); j++)
+ if (!strncmp(ent->name, all_strategy[j].name, ent->len)
+ && !all_strategy[j].name[ent->len])
+ found = 1;
+ if (!found)
+ add_cmdname(¬_strategies, ent->name, ent->len);
+ }
+ fprintf(stderr, "Could not find merge strategy '%s'.\n\n", name);
+ list_commands("git-merge-", "strategies", ¬_strategies);
+ exit(1);
+ }
+
+ ret = xmalloc(sizeof(struct strategy));
+ memset(ret, 0, sizeof(struct strategy));
+ ret->name = xstrdup(name);
+ return ret;
}
static void append_strategy(struct strategy *s)
--
1.6.0.rc0.14.g95f8.dirty
^ permalink raw reply related
* [PATCH 1/5] builtin-help: make is_git_command() usable outside builtin-help
From: Miklos Vajna @ 2008-07-29 15:24 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <cover.1217344802.git.vmiklos@frugalware.org>
Other builtins may want to check if a given command is a valid git
command or not as well. Additionally add a new parameter that specifies
a custom prefix, so that the "git-" prefix is no longer hardwired.
Useful for example to limit the search for "git-merge-*".
Signed-off-by: Miklos Vajna <vmiklos@frugalware.org>
---
Makefile | 1 +
help.c | 25 ++++++++++++++-----------
help.h | 6 ++++++
3 files changed, 21 insertions(+), 11 deletions(-)
create mode 100644 help.h
diff --git a/Makefile b/Makefile
index 798a2f2..351afd7 100644
--- a/Makefile
+++ b/Makefile
@@ -355,6 +355,7 @@ LIB_H += git-compat-util.h
LIB_H += graph.h
LIB_H += grep.h
LIB_H += hash.h
+LIB_H += help.h
LIB_H += list-objects.h
LIB_H += ll-merge.h
LIB_H += log-tree.h
diff --git a/help.c b/help.c
index 3cb1962..08188f5 100644
--- a/help.c
+++ b/help.c
@@ -418,11 +418,11 @@ static int is_executable(const char *name)
}
static unsigned int list_commands_in_dir(struct cmdnames *cmds,
- const char *path)
+ const char *path,
+ const char *prefix)
{
unsigned int longest = 0;
- const char *prefix = "git-";
- int prefix_len = strlen(prefix);
+ int prefix_len;
DIR *dir = opendir(path);
struct dirent *de;
struct strbuf buf = STRBUF_INIT;
@@ -430,6 +430,9 @@ static unsigned int list_commands_in_dir(struct cmdnames *cmds,
if (!dir)
return 0;
+ if (!prefix)
+ prefix = "git-";
+ prefix_len = strlen(prefix);
strbuf_addf(&buf, "%s/", path);
len = buf.len;
@@ -460,7 +463,7 @@ static unsigned int list_commands_in_dir(struct cmdnames *cmds,
return longest;
}
-static unsigned int load_command_list(void)
+static unsigned int load_command_list(const char *prefix)
{
unsigned int longest = 0;
unsigned int len;
@@ -469,7 +472,7 @@ static unsigned int load_command_list(void)
const char *exec_path = git_exec_path();
if (exec_path)
- longest = list_commands_in_dir(&main_cmds, exec_path);
+ longest = list_commands_in_dir(&main_cmds, exec_path, prefix);
if (!env_path) {
fprintf(stderr, "PATH not set\n");
@@ -481,7 +484,7 @@ static unsigned int load_command_list(void)
if ((colon = strchr(path, PATH_SEP)))
*colon = 0;
- len = list_commands_in_dir(&other_cmds, path);
+ len = list_commands_in_dir(&other_cmds, path, prefix);
if (len > longest)
longest = len;
@@ -505,7 +508,7 @@ static unsigned int load_command_list(void)
static void list_commands(void)
{
- unsigned int longest = load_command_list();
+ unsigned int longest = load_command_list(NULL);
const char *exec_path = git_exec_path();
if (main_cmds.cnt) {
@@ -551,9 +554,9 @@ static int is_in_cmdlist(struct cmdnames *c, const char *s)
return 0;
}
-static int is_git_command(const char *s)
+int is_git_command(const char *s, const char *prefix)
{
- load_command_list();
+ load_command_list(prefix);
return is_in_cmdlist(&main_cmds, s) ||
is_in_cmdlist(&other_cmds, s);
}
@@ -574,7 +577,7 @@ static const char *cmd_to_page(const char *git_cmd)
return "git";
else if (!prefixcmp(git_cmd, "git"))
return git_cmd;
- else if (is_git_command(git_cmd))
+ else if (is_git_command(git_cmd, NULL))
return prepend("git-", git_cmd);
else
return prepend("git", git_cmd);
@@ -712,7 +715,7 @@ int cmd_help(int argc, const char **argv, const char *prefix)
}
alias = alias_lookup(argv[0]);
- if (alias && !is_git_command(argv[0])) {
+ if (alias && !is_git_command(argv[0], NULL)) {
printf("`git %s' is aliased to `%s'\n", argv[0], alias);
return 0;
}
diff --git a/help.h b/help.h
new file mode 100644
index 0000000..73da8d6
--- /dev/null
+++ b/help.h
@@ -0,0 +1,6 @@
+#ifndef HELP_H
+#define HELP_H
+
+int is_git_command(const char *s, const char *prefix);
+
+#endif /* HELP_H */
--
1.6.0.rc0.14.g95f8.dirty
^ permalink raw reply related
* [PATCH 2/5] builtin-help: make list_commands() a bit more generic
From: Miklos Vajna @ 2008-07-29 15:25 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <cover.1217344802.git.vmiklos@frugalware.org>
That function now takes two paramters to control the prefix of the
listed commands, and a second parameter to specify the title of the
table. This can be useful for listing not only all git commands, but
specific ones, like merge strategies.
Signed-off-by: Miklos Vajna <vmiklos@frugalware.org>
---
help.c | 18 ++++++++++--------
help.h | 1 +
2 files changed, 11 insertions(+), 8 deletions(-)
diff --git a/help.c b/help.c
index 08188f5..7a42517 100644
--- a/help.c
+++ b/help.c
@@ -506,23 +506,25 @@ static unsigned int load_command_list(const char *prefix)
return longest;
}
-static void list_commands(void)
+void list_commands(const char *prefix, const char *title)
{
- unsigned int longest = load_command_list(NULL);
+ unsigned int longest = load_command_list(prefix);
const char *exec_path = git_exec_path();
if (main_cmds.cnt) {
- printf("available git commands in '%s'\n", exec_path);
- printf("----------------------------");
- mput_char('-', strlen(exec_path));
+ printf("available %s in '%s'\n", title, exec_path);
+ printf("----------------");
+ mput_char('-', strlen(title) + strlen(exec_path));
putchar('\n');
pretty_print_string_list(&main_cmds, longest);
putchar('\n');
}
if (other_cmds.cnt) {
- printf("git commands available from elsewhere on your $PATH\n");
- printf("---------------------------------------------------\n");
+ printf("%s available from elsewhere on your $PATH\n", title);
+ printf("---------------------------------------");
+ mput_char('-', strlen(title));
+ putchar('\n');
pretty_print_string_list(&other_cmds, longest);
putchar('\n');
}
@@ -702,7 +704,7 @@ int cmd_help(int argc, const char **argv, const char *prefix)
if (show_all) {
printf("usage: %s\n\n", git_usage_string);
- list_commands();
+ list_commands("git-", "git commands");
printf("%s\n", git_more_info_string);
return 0;
}
diff --git a/help.h b/help.h
index 73da8d6..0741662 100644
--- a/help.h
+++ b/help.h
@@ -2,5 +2,6 @@
#define HELP_H
int is_git_command(const char *s, const char *prefix);
+void list_commands(const char *prefix, const char *title);
#endif /* HELP_H */
--
1.6.0.rc0.14.g95f8.dirty
^ permalink raw reply related
* [PATCH 5/5] Add a new test for using a custom merge strategy
From: Miklos Vajna @ 2008-07-29 15:25 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <cover.1217344802.git.vmiklos@frugalware.org>
Testing is done by creating a simple git-merge-theirs strategy which is
the opposite of ours. Using this in real merges is not recommended but
it's perfect for our testing needs.
Signed-off-by: Miklos Vajna <vmiklos@frugalware.org>
---
t/t7606-merge-custom.sh | 46 ++++++++++++++++++++++++++++++++++++++++++++++
1 files changed, 46 insertions(+), 0 deletions(-)
create mode 100755 t/t7606-merge-custom.sh
diff --git a/t/t7606-merge-custom.sh b/t/t7606-merge-custom.sh
new file mode 100755
index 0000000..13e8ff5
--- /dev/null
+++ b/t/t7606-merge-custom.sh
@@ -0,0 +1,46 @@
+#!/bin/sh
+
+test_description='git-merge
+
+Testing a custom strategy.'
+
+. ./test-lib.sh
+
+cat > git-merge-theirs << EOF
+#!/bin/sh
+eval git read-tree --reset -u \\\$\$#
+EOF
+chmod +x git-merge-theirs
+PATH=.:$PATH
+export PATH
+
+test_expect_success 'setup' '
+ echo c0 > c0.c &&
+ git add c0.c &&
+ git commit -m c0 &&
+ git tag c0 &&
+ echo c1 > c1.c &&
+ git add c1.c &&
+ git commit -m c1 &&
+ git tag c1 &&
+ git reset --hard c0 &&
+ echo c2 > c2.c &&
+ git add c2.c &&
+ git commit -m c2 &&
+ git tag c2
+'
+
+test_expect_success 'merge c2 with a custom strategy' '
+ git reset --hard c1 &&
+ git merge -s theirs c2 &&
+ test "$(git rev-parse c1)" != "$(git rev-parse HEAD)" &&
+ test "$(git rev-parse c1)" = "$(git rev-parse HEAD^1)" &&
+ test "$(git rev-parse c2)" = "$(git rev-parse HEAD^2)" &&
+ test "$(git rev-parse c2^{tree})" = "$(git rev-parse HEAD^{tree})" &&
+ git diff --exit-code &&
+ test -f c0.c &&
+ test ! -f c1.c &&
+ test -f c2.c
+'
+
+test_done
--
1.6.0.rc0.14.g95f8.dirty
^ permalink raw reply related
* Re: Bizarre missing changes (git bug?)
From: Linus Torvalds @ 2008-07-29 15:50 UTC (permalink / raw)
To: Roman Zippel; +Cc: Tim Harper, git
In-Reply-To: <Pine.LNX.4.64.0807291235350.6791@localhost.localdomain>
On Tue, 29 Jul 2008, Roman Zippel wrote:
>
> I'm not dismissing it, but your focus is on how to get this result.
No, you misunderstand.
My focus is really on one single thing:
- performance
with a smaller focus on the fact that I simply don't see how it's
_possible_ to do better than our current all-or-nothing approach of
simplification (eg either extreme simplification or none at all: nothing
or --full-history).
So here's my challenge again, which you seem to have TOTALLY MISSED.
Make this be fast:
time sh -c "git log <filename> | head"
nothing else matters. If you can make that one be fast, I'm happy.
And that "| head" is really very fundamentally important. The important
thing from a performance standpoint is not how long the _whole_ "log"
takes. The important thing is how fast it _feels_, and that is directly
tied to how fast it starts outputting the data.
Put another way: I _know_ how to simplify things. Trust me, Roman. That's
not the problem. But doing it incrementally is really really hard, to the
point that I actually believe that it is impossible to do.
And doing it after-the-fact is simply not interesting. We could trivially
(well, _fairly_ trivially) do it when we do the topology sort. But I have
long long tried to teach people _not_ to do the topo sort inside the core
git machinery, exactly because it is a horrid thing from an interactivity
standpoint.
In fact, you can see what I'm talking about by trying --topo-order in the
above timing test.
Really. Just _try_ it. And if you still don't understand what I'm talking
about, I don't know what to say.
> > And quite frankly, I've seen that behaviour from you before, when it comes
> > to other things.
>
> What exact behaviour is that? That I dare to disagree with you?
No. The fact that you like arguing _pointlessly_, and just being abrasive,
without actually helping or understanding the big picture. I'm thinking
back on the whole scheduler thing. You weren't arguing with _me_, but you
had the same modus operandi.
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