* Re: [PATCH] fast-export: Allow pruned-references in mark file
From: Junio C Hamano @ 2012-11-26 17:41 UTC (permalink / raw)
To: Antoine Pelisse; +Cc: Felipe Contreras, git
In-Reply-To: <CALWbr2yZpAT=eSahGcGKw5weoz1MjTzbb16pdQndKDFcn_3VJg@mail.gmail.com>
Antoine Pelisse <apelisse@gmail.com> writes:
> On Mon, Nov 26, 2012 at 12:37 PM, Felipe Contreras
> <felipe.contreras@gmail.com> wrote:
>> On Mon, Nov 26, 2012 at 5:03 AM, Junio C Hamano <gitster@pobox.com> wrote:
>>> Is this a safe and sane thing to do, and if so why? Could you
>>> describe that in the log message here?
>> Why would fast-export try to export something that was pruned? Doesn't
>> that mean it wasn't reachable?
>
> Hello Junio,
> Hello Felipe,
>
> Actually the issue happened while using Felipe's branch with his
> git-remote-hg. Everything was going fine until I (or did it run
> automatically, I dont remember) ran git gc that pruned unreachable
> objects. Of course some of the branch I had pushed to the hg remote
> had been changed (most likely rebased). References no longer exists
> in the repository (cleaned by gc), but the reference still exists in
> mark file, as it was exported earlier. Thus the failure when git
> fast-export reads the mark file.
You described that part very well in your proposed log message and I
got it just fine.
> Then, is it safe ?
> Updating the last_idnum as I do in the patch doesn't work because
> if the reference is the last, the number is going to be overwriten
> in the next run.
> From git point of view, I guess it is fine. The file is fully read at
> the beginning of fast-export and fully written at the end.
I am not sure I follow the above, but anyway, I think the patch does
is safe because (1) future "fast-export" will not refer to these
pruned objects in its output (we have decided that these pruned
objects are not used anywhere in the history so nobody will refer to
them) and (2) we still need to increment the id number so that later
objects in the marks file get assigned the same id number as they
were assigned originally (otherwise we will not name these objects
consistently when we later talk about them).
And I wanted to see that kind of reasoning behind the patch in the
proposed log message, because other people will need to refer to it
when they read "git log" output to understand the change.
Thanks.
^ permalink raw reply
* Re: [PATCH 5/5] git-send-email: allow edit invalid email address
From: Krzysztof Mazur @ 2012-11-26 17:33 UTC (permalink / raw)
To: Junio C Hamano
Cc: git, Felipe Contreras, Andreas Schwab, Felipe Balbi,
Tomi Valkeinen
In-Reply-To: <7vobikthpp.fsf@alter.siamese.dyndns.org>
On Mon, Nov 26, 2012 at 09:08:34AM -0800, Junio C Hamano wrote:
> Krzysztof Mazur <krzysiek@podlesie.net> writes:
>
> > In some cases the user may want to send email with "Cc:" line with
> > email address we cannot extract. Now we allow user to extract
> > such email address for us.
> >
> > Signed-off-by: Krzysztof Mazur <krzysiek@podlesie.net>
> > ---
> > git-send-email.perl | 9 ++++++---
> > 1 file changed, 6 insertions(+), 3 deletions(-)
> >
> > diff --git a/git-send-email.perl b/git-send-email.perl
> > index d42dca2..9996735 100755
> > --- a/git-send-email.perl
> > +++ b/git-send-email.perl
> > @@ -851,10 +851,10 @@ sub extract_valid_address_or_die {
> >
> > sub validate_address {
> > my $address = shift;
> > - if (!extract_valid_address($address)) {
> > + while (!extract_valid_address($address)) {
> > print STDERR "error: unable to extract a valid address from: $address\n";
> > - $_ = ask("What to do with this address? ([q]uit|[d]rop): ",
> > - valid_re => qr/^(?:quit|q|drop|d)/i,
> > + $_ = ask("What to do with this address? ([q]uit|[d]rop|[e]dit): ",
> > + valid_re => qr/^(?:quit|q|drop|d|edit|e)/i,
> > default => 'q');
> > if (/^d/i) {
> > return undef;
> > @@ -862,6 +862,9 @@ sub validate_address {
> > cleanup_compose_files();
> > exit(0);
> > }
> > + $address = ask("Who should the email be sent to (if any)? ",
> > + default => "",
> > + valid_re => qr/\@.*\./, confirm_only => 1);
>
> Not having this new code inside "elsif (/^e/) { }" feels somewhat
> sloppy, even though it is not *too* bad. Also do we know this
ok, I will fix that.
> function will never be used for addresses other than recipients' (I
> gave a cursory look to see what is done to the $sender and it does
> not seem to go through this function, tho)?
Yes, this function is called only from validate_address_just()
to filter @initial_to, @initial_cc, @bcc_list as early as possible,
and filter @to and @cc added in each email.
Krzysiek
^ permalink raw reply
* Re: [PATCH v5 15/15] fast-export: don't handle uninteresting refs
From: Johannes Schindelin @ 2012-11-26 16:28 UTC (permalink / raw)
To: Junio C Hamano
Cc: Felipe Contreras, Jeff King, Jonathan Nieder, git, Max Horn,
Sverre Rabbelier, Brandon Casey, Brandon Casey, Ilari Liusvaara,
Pete Wyckoff, Ben Walton, Matthieu Moy, Julian Phillips
In-Reply-To: <7v7gp9udsl.fsf@alter.siamese.dyndns.org>
Hi Junio,
On Sun, 25 Nov 2012, Junio C Hamano wrote:
> From: Johannes Schindelin <Johannes.Schindelin@gmx.de>
> Subject: Re: [PATCH v3 4/4] fast-export: make sure refs are updated properly
> Date: Fri, 2 Nov 2012 16:17:14 +0100 (CET)
> Message-ID: <alpine.DEB.1.00.1211021612320.7256@s15462909.onlinehome-server.info>
>
> (which is $gmane/208946) that says:
>
> Note that
>
> $ git branch foo master~1
> $ git fast-export foo master~1..master
>
> still does not update the "foo" ref, but a partial fix is better
> than no fix.
If you changed your stance on the patch Sverre and I sent to fix this, we
could get a non-partial fix for this. You wanted a fix for a bigger
problem, though, which I am unwilling to fix because it is not my itch to
scratch and I have to balance my time.
Ciao,
Johannes
^ permalink raw reply
* Re: git-fetch does not work from .git subdirectory
From: Timur Tabi @ 2012-11-26 16:09 UTC (permalink / raw)
To: Patrik Gornicz; +Cc: git
In-Reply-To: <50AD77F3.3080702@mail.pgornicz.com>
Patrik Gornicz wrote:
> Just a hunch but your remote's location uses a relative path
> '../linux-2.6.git', perhaps git is messing up what the path is relative
> to.
That makes sense. Git is looking at the URL and not realizing that it's
relative to the home directory.
[remote "upstream"]
url = ../linux-2.6.git/
fetch = +refs/heads/*:refs/remotes/upstream/*
> Note sure what the fix will be though as it'll likely break existing
> repositories that use relative paths either way. Can you try an
> absolute path to see if that fixes thing?
If I change that to
[remote "upstream"]
url = /home/b04825/git/linux-2.6.git/
fetch = +refs/heads/*:refs/remotes/upstream/*
then everything works.
IMHO, this is a bug in git.
--
Timur Tabi
Linux kernel developer at Freescale
^ permalink raw reply
* Re: commit gone after merge - how to debug?
From: Matthieu Moy @ 2012-11-26 14:50 UTC (permalink / raw)
To: Igor Lautar; +Cc: Tomas Carnecky, git
In-Reply-To: <CAO1Khk8=nrKknfqY-k6XaGPDbLrHyrK-8fxfB7XXUWeB7L4EUA@mail.gmail.com>
[ Jumping back in time ]
Igor Lautar <igor.lautar@gmail.com> writes:
>> Try this:
>>
>> commit=<sha1 of your merge commit>
>> # Show diff with first parent:
>> git diff "$commit" "$commit"^1
>> # Show diff with second parent:
>> git diff "$commit" "$commit"^2
>
> Yes, change is shown in commit^2, but actual file after merge does not have it.
My commands had the wrong order. It should have been git diff
"$commit"^2 "$commit". So, it showed the reverse of the modification
introduced by the commit. If you see your change here, it means the
change was reverted by the merge.
My understanding of the situation up to now is:
M
|\
A C
|/
B
($commit = M, $commit^1 = A and $commit^2 = B)
Your file had a content (say, "old") at revision B. It changed content
(say, to "new") at revision C, and at some point. A did not change it so
it had the content "old". Then you merged, expected the merge commit M
to get content "new", and actually got "old".
So, your history looks like:
M (old)
| \
| `---.
| \
A (old) C (new)
| /
| .---'
| /
|/
B (old)
and "git diff C M" shows the diff between new and old.
Something went wrong during the merge, I guess it used an ancestor (B
above) that had "new" as content. I don't see how this happened (rather
clearly, your history is more complex than my example above), but
"GIT_MERGE_VERBOSITY=5 git merge" will show you which common ancestor
was used, it may help.
What's possible is that someone had already merged the branch containing
"new", got conflicts, and resolved it in favor of "old" somewhere in the
history of your master branch.
--
Matthieu Moy
http://www-verimag.imag.fr/~moy/
^ permalink raw reply
* Re: commit gone after merge - how to debug?
From: Igor Lautar @ 2012-11-26 14:23 UTC (permalink / raw)
To: Matthieu Moy; +Cc: Tomas Carnecky, git
In-Reply-To: <vpqboekqwei.fsf@grenoble-inp.fr>
On Mon, Nov 26, 2012 at 3:19 PM, Matthieu Moy
<Matthieu.Moy@grenoble-inp.fr> wrote:
> What about "git annotate <file> <merge-commit>^1"?
No change, line version goes back to when file was added.
> Was the merge completely automatic, or were there any conflict?
No conflicts at all. In fact, that particular file was not touched by
one side of merge, only by another. It seems like git ignored the
change, but still recorded history (shown only with --full-history).
^ permalink raw reply
* Re: commit gone after merge - how to debug?
From: Matthieu Moy @ 2012-11-26 14:19 UTC (permalink / raw)
To: Igor Lautar; +Cc: Tomas Carnecky, git
In-Reply-To: <CAO1Khk9Y_SC8q4iHnv848Z+dXMaeUOWxzW76yPSj_as317_u5g@mail.gmail.com>
Igor Lautar <igor.lautar@gmail.com> writes:
> git annotate <file> <merge commit>^2
> - shows line as being modified by a commit done after file was added
> - ie., state I would expect after a merge
What about "git annotate <file> <merge-commit>^1"?
Was the merge completely automatic, or were there any conflict?
--
Matthieu Moy
http://www-verimag.imag.fr/~moy/
^ permalink raw reply
* Re: commit gone after merge - how to debug?
From: Igor Lautar @ 2012-11-26 14:15 UTC (permalink / raw)
To: Matthieu Moy; +Cc: Tomas Carnecky, git
In-Reply-To: <vpqhaocqx4k.fsf@grenoble-inp.fr>
On Mon, Nov 26, 2012 at 3:03 PM, Matthieu Moy
<Matthieu.Moy@grenoble-inp.fr> wrote:
> Your initial message was about the output of "git log". Do you mean that
> the file, on the filesystem, does not have the line introduced by the
> commit?
Yes, sorry if I was not clear enough.
> If so, check the content registered in the repository too:
>
> git show <merge-commit>:<file-name>
Content shown is identical to the one in working copy, ie., it is
missing one line change.
git annotate <file> <merge commit>
- shows that particular line as if it has originated from when the
file was originally added to repo.
git annotate <file> <merge commit>^2
- shows line as being modified by a commit done after file was added
- ie., state I would expect after a merge
^ permalink raw reply
* Re: [PATCH] fast-export: Allow pruned-references in mark file
From: Antoine Pelisse @ 2012-11-26 14:14 UTC (permalink / raw)
To: Felipe Contreras; +Cc: Junio C Hamano, git
In-Reply-To: <CAMP44s3Xo2ko6X1-SO3hLiTYHA3+i912jTGOQCUihixxcbEuRQ@mail.gmail.com>
> If that's the case, I don't think it should throw a warning even just skip them.
Removing the warning seems fine to me.
> Then, in the actual export if some of these objects are referenced the
> export would fail anyway (but they won't).
Of course it will fail to export anything that requires the missing object.
As they are unreachable, it will be hard to provide a ref that needs
it anyway.
On the other hand, I'm afraid that your file
'.git/hg/<remote>/marks-hg' needs consistent references to mark.
If a mark is removed, and then replaced by another object, can it
break somehow git-remote-hg ? If not, I can provide a simpler patch.
If it does, it will be more complicated.
Cheers,
Antoine
^ permalink raw reply
* Re: [PATCH] fast-export: Allow pruned-references in mark file
From: Felipe Contreras @ 2012-11-26 14:04 UTC (permalink / raw)
To: Antoine Pelisse; +Cc: Junio C Hamano, git
In-Reply-To: <CALWbr2yZpAT=eSahGcGKw5weoz1MjTzbb16pdQndKDFcn_3VJg@mail.gmail.com>
On Mon, Nov 26, 2012 at 2:23 PM, Antoine Pelisse <apelisse@gmail.com> wrote:
> On Mon, Nov 26, 2012 at 12:37 PM, Felipe Contreras
> <felipe.contreras@gmail.com> wrote:
>> On Mon, Nov 26, 2012 at 5:03 AM, Junio C Hamano <gitster@pobox.com> wrote:
>>> Is this a safe and sane thing to do, and if so why? Could you
>>> describe that in the log message here?
>> Why would fast-export try to export something that was pruned? Doesn't
>> that mean it wasn't reachable?
>
> Hello Junio,
> Hello Felipe,
>
> Actually the issue happened while using Felipe's branch with his
> git-remote-hg. Everything was going fine until I (or did it run
> automatically, I dont remember) ran git gc that pruned unreachable
> objects. Of course some of the branch I had pushed to the hg remote
> had been changed (most likely rebased). References no longer exists
> in the repository (cleaned by gc), but the reference still exists in
> mark file, as it was exported earlier. Thus the failure when git
> fast-export reads the mark file.
Ah, I see, so these objects are _before_ fast-export tries to do
anything, it's just importing the marks without any knowledge if these
objects are going to be used in the export or not.
If that's the case, I don't think it should throw a warning even just skip them.
Then, in the actual export if some of these objects are referenced the
export would fail anyway (but they won't).
Cheers.
--
Felipe Contreras
^ permalink raw reply
* Re: commit gone after merge - how to debug?
From: Matthieu Moy @ 2012-11-26 14:03 UTC (permalink / raw)
To: Igor Lautar; +Cc: Tomas Carnecky, git
In-Reply-To: <CAO1Khk8=nrKknfqY-k6XaGPDbLrHyrK-8fxfB7XXUWeB7L4EUA@mail.gmail.com>
Igor Lautar <igor.lautar@gmail.com> writes:
> Yes, change is shown in commit^2, but actual file after merge does not have it.
Your initial message was about the output of "git log". Do you mean that
the file, on the filesystem, does not have the line introduced by the
commit?
If so, check the content registered in the repository too:
git show <merge-commit>:<file-name>
--
Matthieu Moy
http://www-verimag.imag.fr/~moy/
^ permalink raw reply
* Re: commit gone after merge - how to debug?
From: Igor Lautar @ 2012-11-26 13:58 UTC (permalink / raw)
To: Matthieu Moy; +Cc: Tomas Carnecky, git
In-Reply-To: <vpqehjgscv3.fsf@grenoble-inp.fr>
On Mon, Nov 26, 2012 at 2:38 PM, Matthieu Moy
<Matthieu.Moy@grenoble-inp.fr> wrote:
> Igor Lautar <igor.lautar@gmail.com> writes:
>> Somewhat, but it does not explain why the file no longer has that
>> change.
>
> It still has, but it's not shown by "git log <file>", probably because
> one of the parent of the merge commit introduces no change for this
> file, so one side of the merge is not needed to explain you how you went
> from the origin of time to the last commit.
No, the change is not there. See below.
> Try this:
>
> commit=<sha1 of your merge commit>
> # Show diff with first parent:
> git diff "$commit" "$commit"^1
> # Show diff with second parent:
> git diff "$commit" "$commit"^2
Yes, change is shown in commit^2, but actual file after merge does not have it.
I've double and triple checked, it is just not there. In the end, I've
cherry-picked the same commit after the merge and change is applied.
If change would be there after the merge, cherry-pick would not have
anything to do (whole commit is a one line change in single file).
So its not that the history is hidden, the change *is* missing after the merge.
Is there anything else I can try to figure out why its missing (other
than actually debugging git code/scripts)? Like debug output for each
change being considered/merged in?
Regards,
Igor
^ permalink raw reply
* Re: commit gone after merge - how to debug?
From: Matthieu Moy @ 2012-11-26 13:38 UTC (permalink / raw)
To: Igor Lautar; +Cc: Tomas Carnecky, git
In-Reply-To: <CAO1Khk9mzJjnysnc1iDFeMgqnRq0z35t0kgC-8nrsjJ-oOvdOg@mail.gmail.com>
Igor Lautar <igor.lautar@gmail.com> writes:
> On Mon, Nov 26, 2012 at 2:23 PM, Matthieu Moy
> <Matthieu.Moy@grenoble-inp.fr> wrote:
>> The other related question being: does reading the section "History
>> Simplification" in "man git-log" help? ;-)
>
> Somewhat, but it does not explain why the file no longer has that
> change.
It still has, but it's not shown by "git log <file>", probably because
one of the parent of the merge commit introduces no change for this
file, so one side of the merge is not needed to explain you how you went
from the origin of time to the last commit.
Try this:
commit=<sha1 of your merge commit>
# Show diff with first parent:
git diff "$commit" "$commit"^1
# Show diff with second parent:
git diff "$commit" "$commit"^2
> I can understand omitting history if end result is the same, but here
> it shouldn't be - I cannot find a commit that reversed that change, so
> the change should still be in after the merge?
revert is not the only situation that can lead to history
simplification. I'm no expert in the domain, but I think if you did the
same change in two branches, the merge will be candidate for history
simplification.
--
Matthieu Moy
http://www-verimag.imag.fr/~moy/
^ permalink raw reply
* Re: commit gone after merge - how to debug?
From: Igor Lautar @ 2012-11-26 13:29 UTC (permalink / raw)
To: Matthieu Moy; +Cc: Tomas Carnecky, git
In-Reply-To: <vpqr4ngsdjl.fsf@grenoble-inp.fr>
On Mon, Nov 26, 2012 at 2:23 PM, Matthieu Moy
<Matthieu.Moy@grenoble-inp.fr> wrote:
> The other related question being: does reading the section "History
> Simplification" in "man git-log" help? ;-)
Somewhat, but it does not explain why the file no longer has that
change. I can understand omitting history if end result is the same,
but here it shouldn't be - I cannot find a commit that reversed that
change, so the change should still be in after the merge?
The file in question was not modified on mirror, nor was modified on
origin after that change.
^ permalink raw reply
* Re: commit gone after merge - how to debug?
From: Igor Lautar @ 2012-11-26 13:24 UTC (permalink / raw)
To: Tomas Carnecky; +Cc: git
In-Reply-To: <1353935441-ner-9639@calvin>
On Mon, Nov 26, 2012 at 2:10 PM, Tomas Carnecky
<tomas.carnecky@gmail.com> wrote:
> On Mon, 26 Nov 2012 14:06:09 +0100, Igor Lautar <igor.lautar@gmail.com> wrote:
>> git log <file modified by commit>
>> - commit NOT shown in file history any more and file does not have this change
>
> does `git log --full-history <file modified by commit>` show the commit?
Indeed it does.
Did the merge with verbosity set to 5. It says the commit I'm merging
in is virtual (probably as it is a merge commit in itself?).
Why would commit be left behind after merge? What kind of history
triggers this scenario?
Just trying to understand reasoning as its counter-intuitive to what I
know now. This may affect our workflow (ie., change it so we avoid it
happening).
^ permalink raw reply
* Re: commit gone after merge - how to debug?
From: Matthieu Moy @ 2012-11-26 13:23 UTC (permalink / raw)
To: Tomas Carnecky; +Cc: Igor Lautar, git
In-Reply-To: <1353935441-ner-9639@calvin>
Tomas Carnecky <tomas.carnecky@gmail.com> writes:
> On Mon, 26 Nov 2012 14:06:09 +0100, Igor Lautar <igor.lautar@gmail.com> wrote:
>> git log <file modified by commit>
>> - commit NOT shown in file history any more and file does not have this change
>
> does `git log --full-history <file modified by commit>` show the commit?
The other related question being: does reading the section "History
Simplification" in "man git-log" help? ;-)
--
Matthieu Moy
http://www-verimag.imag.fr/~moy/
^ permalink raw reply
* Re: [PATCH] fast-export: Allow pruned-references in mark file
From: Antoine Pelisse @ 2012-11-26 13:23 UTC (permalink / raw)
To: Felipe Contreras, Junio C Hamano; +Cc: git
In-Reply-To: <CAMP44s0iSkqcOW0YsD=Jm_=x1tuoRbFQ+EbVvkROa_yY2-WFcA@mail.gmail.com>
On Mon, Nov 26, 2012 at 12:37 PM, Felipe Contreras
<felipe.contreras@gmail.com> wrote:
> On Mon, Nov 26, 2012 at 5:03 AM, Junio C Hamano <gitster@pobox.com> wrote:
>> Is this a safe and sane thing to do, and if so why? Could you
>> describe that in the log message here?
> Why would fast-export try to export something that was pruned? Doesn't
> that mean it wasn't reachable?
Hello Junio,
Hello Felipe,
Actually the issue happened while using Felipe's branch with his
git-remote-hg. Everything was going fine until I (or did it run
automatically, I dont remember) ran git gc that pruned unreachable
objects. Of course some of the branch I had pushed to the hg remote
had been changed (most likely rebased). References no longer exists
in the repository (cleaned by gc), but the reference still exists in
mark file, as it was exported earlier. Thus the failure when git
fast-export reads the mark file.
Then, is it safe ?
Updating the last_idnum as I do in the patch doesn't work because
if the reference is the last, the number is going to be overwriten
in the next run.
From git point of view, I guess it is fine. The file is fully read at
the beginning of fast-export and fully written at the end.
The issue is more for git-remote-hg that keeps track of
matches between git marks and hg commits. The marks are going to
change and be overriden. It will most likely need to read the mark
file to see if a ref has changed, and update it's dictionary.
One of the solution I'm thinking of, is to update the mark file
with marks of newly exported objects instead of recreating it,
and let obsolete references in the file. But of course that is
not acceptable.
Cheers,
Antoine
^ permalink raw reply
* Re: Python extension commands in git - request for policy change
From: Felipe Contreras @ 2012-11-26 13:17 UTC (permalink / raw)
To: esr; +Cc: Michael Haggerty, git
In-Reply-To: <20121125221126.GB6937@thyrsus.com>
On Sun, Nov 25, 2012 at 11:11 PM, Eric S. Raymond <esr@thyrsus.com> wrote:
> Felipe Contreras <felipe.contreras@gmail.com>:
>> And are you going to be around to spot them? It seems my patches for
>> git-remote-hg slipped by your watch, because it seems they use stuff
>> specific to python 2.7.
>
> The dev group hasn't decided (in whatever way it decides these
> things) to require 2.6 yet. When and if it does, I will volunteer my
> services as a Python expert to audit the in-tree Python code for 2.6
> conformance and assist the developers in backporting if required.
> I will also make myself available to audit future submissions.
What dev group?
> I think you know who I am. Junio and the other senior devs certainly
> know where to find me. I've been making promises like this, and
> *keeping* them, for decades. Please stop wasting our time with
> petulant display.
All right, you don't wand feedback, fine.
If you need me I'll be rewriting python code to ruby.
Cheers.
--
Felipe Contreras
^ permalink raw reply
* Re: Python extension commands in git - request for policy change
From: Felipe Contreras @ 2012-11-26 13:11 UTC (permalink / raw)
To: esr; +Cc: Nguyen Thai Ngoc Duy, git, msysGit
In-Reply-To: <20121125215635.GA6937@thyrsus.com>
On Sun, Nov 25, 2012 at 10:56 PM, Eric S. Raymond <esr@thyrsus.com> wrote:
> Felipe Contreras <felipe.contreras@gmail.com>:
>> And gitk is an integral part of git. But if you have different
>> numbers, what are they?
>
> I looked at the Makefile. I saw that there are shell variables that collect
> C commands, shell command, Perl commands, and Python commands. There are no
> collections of other commands.
I suppose you are talking about BUILT_INS, and SCRIPT_FOO, but tcl
scripts don't need no SCRIPT_FOO stuff, because they don't need to be
regenerated, in fact, I don't think the shell scripts need to be
regenerated, but that's not important, what is important is this:
all::
ifndef NO_TCLTK
$(QUIET_SUBDIR0)git-gui $(QUIET_SUBDIR1) gitexecdir='$(gitexec_instdir_SQ)' all
$(QUIET_SUBDIR0)gitk-git $(QUIET_SUBDIR1) all
endif
Why are you ignoring that?
> That makes them the top languages in the universe we are concerned about
According to whom?
I find it very curious how you are arguing for a change in the status
quo to move more towards python, and the basis you are using for
choosing python, and not ruby, or other scripting language is
precisely the status quo. However, the only scripts using python are
these:
SCRIPT_PYTHON += git-remote-testgit.py
SCRIPT_PYTHON += git-p4.py
I already re-wrote git-remote-testgit in bash, and it's dubious
whether or not git-remote-testpy (the new name for this old test) will
fulfill any service. Than means 43% of the current python code is
gone.
And what happens if I rewrite git-p4 in ruby? Would you then argue
that ruby is the way to go because 1% of the *current* code-base uses
it?
Interestingly, according to Wikipedia git is written in: C, Bourne
Shell, Tcl, Perl. That seems to be the case.
> Please don't waste further time on quibbling. We all know that gitk is
> an uncomfortable special case and that the project would be far better
> off, maintainability-wise, if it were successfully ported to one if these
> other languages.
As I said, gitk is integral to the git experience. Of course you are
free to disagree, but according to the last user survey 57% of the
responders used some kind of graphical tool (e.g. gitk, tig). How many
use gitk, and how many use something else, we don't really know, but
what we know is that gitk is distributed *by default*.
Nobody is arguing that gitk should not be distributed by default, just
like nobody is arguing that git-p4 shouldn't, but we *know* very few
people use git-p4 (1% according to the survey), and we can reasonably
assume that many more use gitk.
You cannot have your cake and eat it at the same time. If you use the
amount of code as a measure, then you have to agree that Tcl/Tk is a
way bigger language than python in the mainline git world. If not,
then by all means, show us the numbers. But you can't say "the
important languages are A, B, and D, C doesn't count because I don't
like it, and E doesn't count either because we should draw the line at
three", that seems awfully convenient to push your agenda.
And I don't agree that the project would be better off with something
else, if it was, somebody would have proposed an alternative by now,
but there aren't any. I have tried gitg, and giggle, and I have even
contributed to them, but they are just not as good and useful as plain
old gitk, I always keep coming back.
gitk:
* is blazing fast to start
* doesn't have a lot of dependencies: just tcl/tk
* works on Windows without a major fuzz
* is actively maintained
* shows a proper graph (unlike gitg or giggle)
Now, show me an alternative that fulfills all these points. And I'm
pretty sure you won't find one, because if you did, it would have been
already proposed for mainline git... there isn't any. And if you did,
we would start with oh, but it's GTK+, or it's Qt, and how do you make
it work on Windows. No, gitk is just fine, and works great.
Tcl/Tk might not be your cup of tea, and indeed it's rather unmodern,
but that only tells you how an awful job the modern toolkits have done
with regards to portability and flexibility.
You were arguing for portability, well, Tcl/Tk works on all platforms,
here, have a look, there's no other tool that fulfills this:
http://www.mediawiki.org/wiki/Git/Graphical_User_Interfaces
> Trying to catch me out by triumphantly pointing at gitk is...juvenile.
Isn't that what you are doing by triumphantly pointing at git-p4?
Sorry, if you want to cut the line for the languages that git should
use right now at three, then python is out. Maybe in a couple of
years. Maybe. But I doubt it.
Cheers.
--
Felipe Contreras
^ permalink raw reply
* Re: commit gone after merge - how to debug?
From: Tomas Carnecky @ 2012-11-26 13:10 UTC (permalink / raw)
To: Igor Lautar, git
In-Reply-To: <CAO1Khk_eugH--wp3s-gr4HTvuRyL=SaWHWtEXCRZ_Ak7+s5U=w@mail.gmail.com>
On Mon, 26 Nov 2012 14:06:09 +0100, Igor Lautar <igor.lautar@gmail.com> wrote:
> git log <file modified by commit>
> - commit NOT shown in file history any more and file does not have this change
does `git log --full-history <file modified by commit>` show the commit?
^ permalink raw reply
* commit gone after merge - how to debug?
From: Igor Lautar @ 2012-11-26 13:06 UTC (permalink / raw)
To: git
Hi,
This looks really weird and I cannot explain why it occurs.
Setup is as follows:
- origin
- mirror
- local clone
Reference repository is origin from where builds are done etc.
Parallel to that, we keep a mirror that is synced manually
(fetch/merge/push).
I do this from my local clone (which is mostly just tracking origin
and mirror, no local branches).
What happened is that after a merge of mirror/master into local
master, a commit (that also exists on origin/master) is lost.
Lost as in:
pre-merge:
git log <file modified by commit>
- commit shown in history
git merge mirror/master
- no conflicts
git log <file modified by commit>
- commit NOT shown in file history any more and file does not have this change
Doing git log shows commit as being present in repository history. One
interesting point is that one of the parents is previous merge commit
of same branches.
Unfortunately, I cannot open up repository for public access, but
would appreciate any pointers how to debug this.
git fsck finds some dangling blobs/commits, but no other
warnings/errors, I can clone repo just fine, everything seams in
order.
How can I debug what the merge is doing?
git version 1.7.12.1 on mac:
Darwin 12.2.0 Darwin Kernel Version 12.2.0: Sat Aug 25 00:48:52 PDT
2012; root:xnu-2050.18.24~1/RELEASE_X86_64 x86_64
Regards,
Igor
PS. please keep me in CC, I'm not on list
^ permalink raw reply
* Re: Can I zip a git repo without losing anything?
From: Konstantin Khomoutov @ 2012-11-26 13:04 UTC (permalink / raw)
To: Carl Smith; +Cc: git
In-Reply-To: <CAP-uhDcQg0BuEdHDTa6qVqLCeB-LE1GZtEqHgY_j1--XodsDKw@mail.gmail.com>
On Mon, 26 Nov 2012 04:55:10 +0000
Carl Smith <carl.input@gmail.com> wrote:
> After suggesting using zip files to move our projects around, I was
> told that you can not zip a git repo without loosing all the history.
> This didn't make sense to me, but two people told me the same thing,
> so I wasn't sure. I think they may have been confusing the zipped file
> you can download from GitHub with a zipped git repo.
>
> If someone could put me straight on this, I'd really appreciate it.
To amend the already provided answer -- if you need to move repos
around using the sneakernet, the tool you should probably use is
`git bundle`.
^ permalink raw reply
* Re: [RFC/PATCH] Option to revert order of parents in merge commit
From: Kacper Kornet @ 2012-11-26 12:42 UTC (permalink / raw)
To: Junio C Hamano, git
In-Reply-To: <7vfw3zzoye.fsf@alter.siamese.dyndns.org>
On Fri, Nov 23, 2012 at 06:58:49PM -0800, Junio C Hamano wrote:
> Kacper Kornet <draenog@pld-linux.org> writes:
> > The following patch is an attempt to implement this idea.
> I think "revert" is a wrong word (implying you have already done
> something and you are trying to defeat the effect of that old
> something), and you meant to say "reverse" (i.e. the opposite of
> normal) or something.
You are right. Probably transpose is the best description what the patch
really does.
> I am unsure about the usefulness of this, though.
> After completing a topic on branch A, you would merge it to your own
> copy of the integration branch (e.g. 'master') and try to push,
> which may be rejected due to non-fast-forwardness:
> $ git checkout master
> $ git merge A
> $ git push
> At that point, if you _care_ about the merge parent order, you could
> do this (still on 'master'):
> $ git fetch origin
> $ git reset --hard origin/master
> $ git merge A
> $ test test test
> $ git push
> With --reverse-parents, it would become:
> $ git pull --reverse-parents
> $ test test test
> $ git push
> which certainly is shorter and looks simpler. The workflow however
> would encourage people to work directly on the master branch, which
> is a bit of downside.
Our developers work mainly on master branches. The project consists of
many thousands independent git repositories, and at the given time a
developer usually wants to make only one commit in the given repository
and push his changes upstream. So he usually doesn't care to make a
branch. Then after failed pushed, one needs to add creation and removal
of temporary branch (see the commit message of the suggested patch).
The possibility to do git pull --reverse-parent would make the life
easier in this case.
> Is there any interaction between this "pull --reverse-parents"
> change and possible conflict resolution when the command stops and
> asks the user for help? For example, whom should "--ours" and "-X
> ours" refer to? Us, or the upstream?
The change of order of parents happens at the very last moment, so
"ours" in merge options is local version and "theirs" upstream.
--
Kacper Kornet
^ permalink raw reply
* Re: [RFC] pack-objects: compression level for non-blobs
From: David Michael Barr @ 2012-11-26 12:35 UTC (permalink / raw)
To: Git Mailing List; +Cc: David Michael Barr
In-Reply-To: <1353911154-23495-1-git-send-email-b@rr-dav.id.au>
> Add config pack.graphcompression similar to pack.compression.
> Applies to non-blob objects and if unspecified falls back to pack.compression.
>
> We may identify objects compressed with level 0 by their leading bytes.
> Use this to force recompression when the source and target levels mismatch.
> Limit its application to when the config pack.graphcompression is set.
>
> Signed-off-by: David Michael Barr <b@rr-dav.id.au (mailto:b@rr-dav.id.au)>
> ---
> builtin/pack-objects.c | 49 +++++++++++++++++++++++++++++++++++++++++++++----
> 1 file changed, 45 insertions(+), 4 deletions(-)
>
> I started working on this just before taking a vacation,
> so it's been a little while coming.
>
> The intent is to allow selective recompression of pack data.
> For small objects/deltas the overhead of deflate is significant.
> This may improve read performance for the object graph.
>
> I ran some unscientific experiments with the chromium repository.
> With pack.graphcompression = 0, there was a 2.7% increase in pack size.
> I saw a 35% improvement with cold caches and 43% otherwise on git log --raw.
I neglected to mention that this is a WIP. I get failures with certain repositories:
fatal: delta size changed
--
David Michael Barr
^ permalink raw reply
* Re: [PATCH v5 15/15] fast-export: don't handle uninteresting refs
From: Felipe Contreras @ 2012-11-26 12:16 UTC (permalink / raw)
To: Junio C Hamano
Cc: Jeff King, Jonathan Nieder, git, Johannes Schindelin, Max Horn,
Sverre Rabbelier, Brandon Casey, Brandon Casey, Ilari Liusvaara,
Pete Wyckoff, Ben Walton, Matthieu Moy, Julian Phillips
In-Reply-To: <7v7gp9udsl.fsf@alter.siamese.dyndns.org>
On Mon, Nov 26, 2012 at 6:35 AM, Junio C Hamano <gitster@pobox.com> wrote:
> Felipe Contreras <felipe.contreras@gmail.com> writes:
>
>> On Wed, Nov 21, 2012 at 8:48 PM, Jeff King <peff@peff.net> wrote:
>> ...
>> I would like to understand that that even means. What behavior is
>> currently broken?
>
> I do not know if this is the same as what Peff was referring to, but
> I found this message in the discussion thread during my absense.
>
> From: Johannes Schindelin <Johannes.Schindelin@gmx.de>
> Subject: Re: [PATCH v3 4/4] fast-export: make sure refs are updated properly
> Date: Fri, 2 Nov 2012 16:17:14 +0100 (CET)
> Message-ID: <alpine.DEB.1.00.1211021612320.7256@s15462909.onlinehome-server.info>
>
> (which is $gmane/208946) that says:
>
> Note that
>
> $ git branch foo master~1
> $ git fast-export foo master~1..master
>
> still does not update the "foo" ref, but a partial fix is better
> than no fix.
First of all, do we agree that this patch does not change the
situation for this command? If so, I don't see why that would be
relevant while discussing this patch series.
Second, this is what I get:
% git log --decorate --oneline foo master~1..master
8c7a786 (tag: v1.8.0, master) Git 1.8.0
Notice that 'foo' is not there? It's not there because we explicitly
stated that we didn't want it there.
And what do you expect that command to do with 'foo'? To throw a
'reset refs/heads/foo'? To what commit? There is no mark for that
commit. 'reset :0'? That doesn't help anybody. No, that command is not
broken, it works as expected.
Notice the situation would be different with 'git fast-export
--import-marks=marks foo master~1..master', because if there's a mark
for foo, *now* we can do something about it. This particular patch
series doesn't, but the next one does.
Cheers.
--
Felipe Contreras
^ 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