* 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: [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
* 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: 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-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: 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: 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: 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 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-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: 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: 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: 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: 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: [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: 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: Bizarre missing changes (git bug?)
From: Roman Zippel @ 2008-07-29 12:32 UTC (permalink / raw)
To: Jeff King; +Cc: Linus Torvalds, Tim Harper, git
In-Reply-To: <20080729053108.GH26997@sigill.intra.peff.net>
Hi,
On Tue, 29 Jul 2008, Jeff King wrote:
> > Can we please get past this and look at what is required to produce the
> > correct history?
>
> You seem to be indicating here (and elsewhere in the thread) that there
> exists some history graph for which neither "git log" nor "git log
> --full-history" produces the output you want, but that there is some
> better output (even if it might take more time to compute).
>
> 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.
With "git-log --full-history" you see these changes, but it lacks the
necessary merges to produce a full graph. As consequence none of the
graphical front ends produce a useful history graph.
This problem now hits me now more seriously in a repository conversion,
where it frequently happened, that changes were applied both locally and
upstream, so that I have relatively many of these empty merges and the
default git-log output is useless. --full-history is more of a workaround
than a real solution and again the history graph in _all_ graphical front
ends is useless.
More generally this means in any kind of situation where you maintain your
own repository and it takes a while until upstream accepts your changes,
so that you frequently have duplicated changes (because upstream doesn't
use git or doesn't pull directly), you have to be careful to get the right
history out of git.
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.
bye, Roman
^ permalink raw reply
* Re: git-svn and svn:externals, was Re: Hackontest ideas?
From: Jakub Narebski @ 2008-07-29 12:28 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Petr Baudis, Eric Wong, git
In-Reply-To: <alpine.DEB.1.00.0807291354130.4631@eeepc-johanness>
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.
Yeah, I guess is too large a project for Hackontest.
> 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.
--
Jakub Narebski
Poland
^ permalink raw reply
* Re: git submodules
From: Johannes Schindelin @ 2008-07-29 12:15 UTC (permalink / raw)
To: Petr Baudis
Cc: Pierre Habouzit, Benjamin Collins, Avery Pennarun, Nigel Magnay,
Git ML
In-Reply-To: <20080729085125.GJ32184@machine.or.cz>
Hi,
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
>
> I do like this (well, I'd just name it "branch" instead of "tracks"). I
> use submodules very "traditionally" just to bind external projects of
> certain version to my project, but I have been already thinking about
> implementing this merely as a hint for others to know what branch should
> the other developers follow when updating the submodule to a newer
> version.
As long as you only use it in "submodule status" to say what the relation
of the current revision is with respect to the "tracks" branch...
But then, how does the relation to the currently _committed_ state get
displayed?
Ciao,
Dscho
^ permalink raw reply
* Re: [trivial fast-export PATCH] Fix typo in documentation
From: Johannes Schindelin @ 2008-07-29 12:06 UTC (permalink / raw)
To: Nick Andrew; +Cc: git
In-Reply-To: <20080729045026.27648.54610.stgit@marcab.local.tull.net>
Hi,
On Tue, 29 Jul 2008, Nick Andrew wrote:
> hg-fast-export.txt | 10 +++++-----
I do not see this in git.git. Maybe you meant to Cc: Simon Hausmann,
Rocco Rutte or Han-Wen?
Or Chris Lee, who seems to be the owner of fast-export.git.
Ciao,
Dscho
^ permalink raw reply
* Re: Bizarre missing changes (git bug?)
From: David Kastrup @ 2008-07-29 12:00 UTC (permalink / raw)
To: git
In-Reply-To: <Pine.LNX.4.64.0807291235350.6791@localhost.localdomain>
Roman Zippel <zippel@linux-m68k.org> writes:
> On Mon, 28 Jul 2008, Linus Torvalds wrote:
>
>> So go away. Write the code. Come back with patches.
>
> If you knew me that well, you also knew that such threats don't work
> with me.
I'd like to add to Linus' suggested course of action the task "look up
threat in a dictionary".
> In this case you know perfectly well, that I don't know the code as
> well as you, so without any help it would require a huge waste of time
> with the risk of rejection.
If _you_ need the functionality, you can easily keep it around in _your_
copy. That's what I do with a few patches that were not accepted here.
So the "risk of rejection" has no real cost for you (apart from an
occasional rebase on origin, which is cheap). Just for others. And of
no-one else argues your case, then they probably don't mind.
--
David Kastrup
^ permalink raw reply
* git-attic
From: Paul Gideon Dann @ 2008-07-29 11:57 UTC (permalink / raw)
To: git
Hello all,
I looked around everywhere for a script that could make it easy for me
to store stale branches in refs/attic for possible later retrieval. I
don't like such branches lying around in refs/heads and used to tag them
to clear them out of the way, but then that makes "git push origin
--tags" unusable, since I don't want to push my stale branches out...
Anyway, I wrote my own little script in the end and thought it might be
useful to others.
Please Cc pdgiddie@gmail.com in replies,
Paul Gideon Dann
Usage: git-attic
git-attic store <ref> [<commit>]
git-attic remove <ref>
#!/bin/bash
###
# Original Author: Paul Gideon Dann <pdgiddie@gmail.com>
###
showUsage() {
echo "Usage: git-attic"
echo " git-attic store <ref> [<commit>]"
echo " git-attic remove <ref>"
}
case $1 in
"store")
if [[ ! $2 ]]; then
showUsage
exit 1
fi
if [[ $3 ]]; then
OBJECT_SHA1=`git-rev-parse --revs-only $3`
if [[ ! $OBJECT_SHA1 ]]; then
echo "$3 is not a recognisable commit object."
exit 1
fi
else
OBJECT_SHA1=`git show-ref -h HEAD | awk '{print $1}'`
fi
git update-ref refs/attic/$2 $OBJECT_SHA1
echo "$2 stored in attic."
;;
"remove")
if [[ ! $2 ]]; then
showUsage
exit 1
fi
OBJECT_SHA1=`git show-ref attic/$2 | awk '{print $1}'`
if [[ ! $OBJECT_SHA1 ]]; then
echo "$2 does not exist in the attic!"
exit 1
fi
git update-ref -d refs/attic/$2 $OBJECT_SHA1
echo "$2 removed from attic."
;;
*)
if [[ $1 ]]; then
showUsage
else
# display contents of attic
git for-each-ref --format="%(refname)" refs/attic | awk -F /
'{print $3}'
fi
;;
esac
^ permalink raw reply
* git-svn and svn:externals, was Re: Hackontest ideas?
From: Johannes Schindelin @ 2008-07-29 11:56 UTC (permalink / raw)
To: Jakub Narebski; +Cc: Petr Baudis, Eric Wong, git
In-Reply-To: <m3myk1t54c.fsf@localhost.localdomain>
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".
Ciao,
Dscho
^ permalink raw reply
* SSL + mod_dav + Git
From: Chris Hart @ 2008-07-29 11:53 UTC (permalink / raw)
To: git
Hi guys, I've been up all night on this one and after exhaustive
Googling and checking the sleepy #git, decided to check with the
mailing list! Here's the current problem:
Git is working perfectly over SSH. The server is Ubuntu, and doing
cadaver https://serveraddress/.git successfully authenticates using
the passwd file I provided to Apache. Basically I've done everything
from Rutger's guide
(http://www.kernel.org/pub/software/scm/git/docs/v1.4.4.4/howto/setup-git-server-over-http.txt)
except for the ~/.netrc stuff.
However, once authenticated to the .git folder (cadaver through
https), basic commands give strange errors or 404s. Ls throws "Listing
collection `/.git/': failed:
Could not read status line: Secure connection truncated" and cd
/to/some/legitimate/directory throws "Could not access /.git/dir/ (not
WebDAV-enabled?):
404 Not Found." Oddly tab-completion for cd suggests the contents of
the directory (although I'm cadaver-ing from localhost). Same results
remotely in a browser: authenticates successfully and gives 404s.
Trying git clone https://server/.git throws:
"warning: remote HEAD refers to nonexistent ref, unable to checkout"
...despite the working certificate and authorization. Any ideas?
Thanks infinity and one to anybody with attention for this!
Chris
Note: Apache owns all the files here so I really hope it's not a
permissions thing.
------------------ Git version info --------------------
server> git version 1.5.4.3
remote-laptop> git version 1.5.6.4
------------------------------------------------------------
^ permalink raw reply
* Re: Bizarre missing changes (git bug?)
From: Roman Zippel @ 2008-07-29 11:39 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Tim Harper, git
In-Reply-To: <alpine.LFD.1.10.0807282023290.3334@nehalem.linux-foundation.org>
Hi,
On Mon, 28 Jul 2008, Linus Torvalds wrote:
> You dismiss all my issues, and then you continue to talk about "correct",
> even though it isn't a correctness thing - it's a difference of opinion.
> Me, I *much* prefer the simplified history. That _is_ the correct one for
> me.
I'm not dismissing it, but your focus is on how to get this result. If the
results were always the same, I wouldn't have a problem at all.
That's why I'm trying to give you an example where the end result differs,
how are we supposed to get to an agreement on _how_ to get the result, if
we don't even agree on _what_ the result should be?
> 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?
> So go away. Write the code. Come back with patches.
If you knew me that well, you also knew that such threats don't work with
me.
In this case you know perfectly well, that I don't know the code as well
as you, so without any help it would require a huge waste of time with the
risk of rejection.
bye, Roman
^ 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