* Re: [RFC/PATCHv10 01/11] fast-import: Proper notes tree manipulation
From: Junio C Hamano @ 2009-12-11 3:00 UTC (permalink / raw)
To: Johan Herland; +Cc: git, Shawn O. Pearce
In-Reply-To: <200912101540.43521.johan@herland.net>
Johan Herland <johan@herland.net> writes:
> On Thursday 10 December 2009, Shawn O. Pearce wrote:
>> Johan Herland <johan@herland.net> wrote:
>> > Do you have more comments/suggestions on this patch? Or is it ok to
>> > include in fast-import as-is?
>>
>> Oops, sorry.
>>
>> No, no additional comments. I am happy with this patch.
>>
>> Acked-by: Shawn O. Pearce <spearce@spearce.org>
>
> Thanks.
>
> Junio: With the above Ack, I believe patches #1 - #4 (and possibly #5)
> from this series are ready for 'next'.
>
> You may want to hold off on the remainder of the series until I get
> around to writing some functionality that actually _uses_ the new API.
Thanks for a notice, but we are already deep in pre-release freeze. I'll
hold onto the message I am replying to, but I won't be adding anything to
'next' until 1.6.6 final, unless it is somehow really urgent and deserves
to be in 'maint' and/or 'master'.
^ permalink raw reply
* Re: [PATCH 1/6] GITWEB - Load Checking
From: J.H. @ 2009-12-11 3:07 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Jakub Narebski, git
In-Reply-To: <4B21B550.1060806@kernel.org>
J.H. wrote:
> Junio C Hamano wrote:
>> "J.H." <warthog9@kernel.org> writes:
>>
>>> It was intended to be the most minimal possible, mainly get in, get
>>> out. Also not sure the die_error existed in gitweb when this was
>>> originally written. Probably worth switching to it now since it's
>>> there either way, and I don't think using it would add enough overhead
>>> to matter.
>>
>> Thanks; all sounded a reasonable response to the review. Are you
>> re-rolling the series anytime soon (I am asking because then I'd rather
>> not to queue this round especially because I didn't see 5/6).
>
> I'll probably have some changes up and about tomorrow, and it's a little
> troubling that 5/6 didn't come through for you
>
> 6 at least made it to marc.info:
> http://marc.info/?l=git&m=126048884825985&w=2
>
> and 5 seems to have been eaten by a grue somewhere. It was a *big*
> patch mainly because all the caching flips over in a single go. If you
> want I can privately bounce 5 & 6 to you so you have a complete tree
> right now?
Not to reply to myself but this might also be helpful:
http://git.kernel.org/?p=git/warthog9/gitweb.git;a=shortlog;h=refs/heads/gitweb-ml-v2
- John 'Warthog9' Hawley
^ permalink raw reply
* Re: [PATCH 1/6] GITWEB - Load Checking
From: Junio C Hamano @ 2009-12-11 3:09 UTC (permalink / raw)
To: J.H.; +Cc: Jakub Narebski, git
In-Reply-To: <4B21B550.1060806@kernel.org>
"J.H." <warthog9@kernel.org> writes:
>> Thanks; all sounded a reasonable response to the review. Are you
>> re-rolling the series anytime soon (I am asking because then I'd rather
>> not to queue this round especially because I didn't see 5/6).
>
> I'll probably have some changes up and about tomorrow, and it's a
> little troubling that 5/6 didn't come through for you
>
> 6 at least made it to marc.info:
> http://marc.info/?l=git&m=126048884825985&w=2
Sorry; I meant to say "[PATCH 5/6]", not "5 and 6 didn't come".
> and 5 seems to have been eaten by a grue somewhere. It was a *big*
> patch mainly because all the caching flips over in a single go. If
> you want I can privately bounce 5 & 6 to you so you have a complete
> tree right now?
Thanks, but not interested, in the sense that it wouldn't make much sense
to me to have a version tonight that is known to go stale within a few
days. I only pick up and queue patches to 'pu' to save me from later
trouble of finding them from the mailing list backlog, and not to actively
review and engage in the discussion to polish them right now. We are
already deep in pre-release freeze and my attention is not currently on
anything that won't go in to the upcoming release.
I want to have a solid 1.6.6 before the holidays as a present to all ;-).
^ permalink raw reply
* [ANNOUNCE] Git 1.6.5.6
From: Junio C Hamano @ 2009-12-11 6:09 UTC (permalink / raw)
To: git
The latest maintenance release Git 1.6.5.6 is available at the
usual places:
http://www.kernel.org/pub/software/scm/git/
git-1.6.5.6.tar.{gz,bz2} (source tarball)
git-htmldocs-1.6.5.6.tar.{gz,bz2} (preformatted docs)
git-manpages-1.6.5.6.tar.{gz,bz2} (preformatted docs)
The RPM binary packages for a few architectures are found in:
RPMS/$arch/git-*-1.6.5.6-1.fc11.$arch.rpm (RPM)
Hopefully this will be the last update to the 1.6.5.X series before the
upcoming feature release (1.6.6). It fixes a security issue, and users of
older 1.6.5.X series are strongly recommended to update to this version.
Git v1.6.5.6 Release Notes
==========================
Fixes since v1.6.5.5
--------------------
* "git add -p" had a regression since v1.6.5.3 that broke deletion of
non-empty files.
* "git archive -o o.zip -- Makefile" produced an archive in o.zip
but in POSIX tar format.
* Error message given to "git pull --rebase" when the user didn't give
enough clue as to what branch to integrate with still talked about
"merging with" the branch.
* Error messages given by "git merge" when the merge resulted in a
fast-forward still were in plumbing lingo, even though in v1.6.5
we reworded messages in other cases.
* The post-upload-hook run by upload-pack in response to "git fetch" has
been removed, due to security concerns (the hook first appeared in
1.6.5).
----------------------------------------------------------------
Changes since v1.6.5.5 are as follows:
Jan Krüger (1):
pull: clarify advice for the unconfigured error case
Jeff King (1):
add-interactive: fix deletion of non-empty files
Junio C Hamano (3):
Remove post-upload-hook
Fix archive format with -- on the command line
Git 1.6.5.6
Matthieu Moy (2):
merge-recursive: make the error-message generation an extern function
builtin-merge: show user-friendly error messages for fast-forward too.
^ permalink raw reply
* Re: Ambiguous ref names
From: Jeenu V @ 2009-12-11 8:03 UTC (permalink / raw)
To: git
In-Reply-To: <5195c8760911200355x1aff9781l848f974c9f09f416@mail.gmail.com>
On Fri, Nov 20, 2009 at 5:25 PM, Jeenu V <jeenuv@gmail.com> wrote:
>
> On Fri, Nov 20, 2009 at 4:29 PM, Junio C Hamano <gitster@pobox.com> wrote:
> > Jeenu V <jeenuv@gmail.com> writes:
> >
> >> On Fri, Nov 20, 2009 at 3:56 PM, Junio C Hamano <gitster@pobox.com> wrote:
> >>> [...]
> >>> It could be that you have a tag and a branch that are both named a.b.c,
> >>> though.
> >>
> >> Hm, right. But I'm getting this from an existing local repo of mine. I
> >> can't see any tags; 'git tag -l' is empty. Is there any more info that
> >> I can provide?
> >
> > man git-for-each-ref?
>
> It does list all refs that I know of, but I don't see any duplicate entries.
Ah, I think I get what happened here: I had used git update-ref, which
turned out to be used wrongly. My intention was to update a.b.c to a
new ref, but I used it 'git update-ref XXXXXX', rather than 'git
update-ref refs/heads/a.b.c XXXXXX'. The wrong usage created
.git/a.b.c and I guess this was causing the warning.
--
:J
^ permalink raw reply
* Re: git svn fetch loses data
From: Victor Engmark @ 2009-12-11 8:32 UTC (permalink / raw)
To: Thomas Rast; +Cc: Johan 't Hart, Sverre Rabbelier, git
In-Reply-To: <200911152152.01513.trast@student.ethz.ch>
On Sun, Nov 15, 2009 at 9:52 PM, Thomas Rast <trast@student.ethz.ch> wrote:
> Johan 't Hart wrote:
>> I didn't even know you could also do
>> $ git rebase git-svn
>> Unless git-svn is a ref...
>
> You can't, but in git-svn's default configuration (without
> --stdlayout) the cloned SVN history is called refs/remotes/git-svn.
Thanks all; now it all works a lot more smoothly.
--
Victor Engmark
^ permalink raw reply
* Re: [PATCH 1/6] GITWEB - Load Checking
From: Jakub Narebski @ 2009-12-11 10:09 UTC (permalink / raw)
To: J.H.; +Cc: git, John 'Warthog9' Hawley
In-Reply-To: <4B21AC4D.2020407@kernel.org>
On Fri, 11 Dec 2009, J.H. wrote:
> <snip>
>>> adds $maxload configuration variable. Default is a load of 300,
>>> which for most cases should never be hit.
>>
>> Your patch doesn't allow for *turning off* this feature. Reasonable
>> solution would be to use 'undef' or negative number to turn off this
>> check (this feature).
>
> Well there's the opposite argument that setting the number arbitrarily
> high, 4096 for instance would also in essence negate this (though I'll
> admit I've reached and exceeded those numbers before)
>
> That said I agree, being able to turn this off needs to be added and
> will be shortly.
Simplest solution would be to used 'undef' (undefined value) for
"turned off", i.e.:
if (defined $maxload && get_loadavg() > $maxload) {
>>> Please note this makes the assumption that /proc/loadavg exists
>>> as there is no good way to read load averages on a great number of
>>> platforms [READ: Windows], or that it's reasonably accurate.
>>
>> What about MacOS X, or FreeBSD, or OpenSolaris?
>
> Will comment on this further down
I think it would be better to write in commit message that because finding
load average is OS dependent, there is provided (sample) solution which
uses /proc/loadavg and works (at least) on Linux. And that for platforms
which do not have /proc/loadavg the feature is simply turned off (by the
way of using load=0 if load cannot be determined).
>> You should mention that it is intended that if gitweb cannot read load
>> average (for example /proc/loadavg does not exist), then the feature
>> is turned off, i.e. the check always succeeds. Which is reasonable.
>
> That's fine.
See above proposal. This information should be present in commit message,
and perhaps maybe even as one-line comment above opening /proc/loadavg.
>>> +# loadavg throttle
>>> +sub get_loadavg() {
>>> + my $load;
>>> + my @loads;
>>> +
>>> + open($load, '<', '/proc/loadavg') or return 0;
>>
>> Why not use one of existing CPAN modules: Sys::Info::Device::CPU,
>> BSD::getloadavg, Sys::CpuLoad?
>
> Here's the fundamental problem:
>
> Sys:Info:Device:CPU
> Windows:
> Using this method under Windows is not recommended
> since, the WMI interface will possibly take at least 2
> seconds to complete the request.
>
> BSD::getloadavg
> While this more or less supports anything with a libc getloadavg
> (and thus might be the best one I've seen, I'll admit I didn't
> notice this one when I looked years ago) getting it to work on
> windows looks, exciting.
>
> Sys::CpuLoad:
> http://cpansearch.perl.org/src/CLINTDW/Sys-CpuLoad-0.03/README
> Specifically:
> - Currently FreeBSD and OpenBSD are supported.
> - Wanted: HPUX 11.11 ...
> - Todo: Win32 support
>
> So this doesn't really buy me anything but, maybe, BSD support.
>
> So at the end of the day, none of those really gets me a "useful" cross
> platform load checker (though like I said BSD::getloadavg looks to be
> the best of the ones you mentioned) and more or less Windows is going to
> lose this as a usable feature no matter what.
>
> I think I'd almost rather set this up so that if it can't get something
> useful (I.E. /proc/loadavg is missing) it just skips past it as if the
> load was 0.
>
> I might try out the BSD::getloadavg but I want to take a look and see if
> that's easily installed or not, if it's not it might be difficult to
> justify that as a dependency.
After thinking about this a bit, now I don't think that it is terribly
important. You *might* describe alternate approaches (roads not taken)
in commit message, but requiring /proc/loadavg for the feature to work
is fine for first patch (it makes patch simpler).
>>> +if (get_loadavg()> $maxload) {
>>> + print "Content-Type: text/plain\n";
>>> + print "Status: 503 Excessive load on server\n";
>>> + print "\n";
>>> + print "The load average on the server is too high\n";
>>> + exit 0;
>>
>> Why not use die_error subroutine? Is it to have generate absolutely
>> minimal load, and that is why you do not use die_error(), or even
>> $cgi->header()?
>>
>> Wouldn't a better solution be to use here-doc syntax?
>>
>> + print <<'EOF';
>> +Content-Type: text/plain; charset=utf-8
>> +Status: 503 Excessive load on server
>> +
>> +The load average on the server is too high
>> +EOF
>> + exit 0;
>
> It was intended to be the most minimal possible, mainly get in, get out.
>
> Also not sure the die_error existed in gitweb when this was originally
> written. Probably worth switching to it now since it's there either
> way, and I don't think using it would add enough overhead to matter.
Well, if you are not worring excessively about overhead, then I think
using die_error would be the best solution, as it would preserve look
of gitweb. It would require extending die_error by 503 response, or
rather %http_responses hash and comment above die_error.
Also I think that Status: should be before Content-Type: header (but
probably it is not required by the standard).
--
Jakub Narebski
Poland
^ permalink raw reply
* Re: How to selectively recreate merge state?
From: Michael J Gruber @ 2009-12-11 10:44 UTC (permalink / raw)
To: Jakub Narebski; +Cc: Junio C Hamano, Jay Soffian, git
In-Reply-To: <200912110233.18756.jnareb@gmail.com>
Jakub Narebski venit, vidit, dixit 11.12.2009 02:33:
> Dnia piątek 11. grudnia 2009 02:11, Junio C Hamano napisał:
>> Jakub Narebski <jnareb@gmail.com> writes:
>>
>>> --unresolve::
>>> Restores the 'unmerged' or 'needs updating' state of a
>>> file during a merge if it was cleared by accident.
>>>
>>> Unless "git add foo" not only adds current contents of foo at stage 0,
>>> but also removes higher stages from index...
>>
>> By definition, adding anything at stage #0 is to remove higher stages.
>
> Hmmm... let's test it:
>
> $ git merge side-branch
> Auto-merging foo
> CONFLICT (content): Merge conflict in foo
> Automatic merge failed; fix conflicts and then commit the result.
> $ git ls-files --stage
> 100644 257cc5642cb1a054f08cc83f2d943e56fd3ebe99 1 foo
> 100644 3bd1f0e29744a1f32b08d5650e62e2e62afb177c 2 foo
> 100644 469a41eda5c8b45503a3bfc32ad6b5decc658132 3 foo
> $ <edit foo>
> $ git add foo
> $ git ls-files --stage
> 100644 a1b58d38ffa61e8e99b7cb95cdf540aedf2a96b3 0 foo
>
> Now let's test '--unresolve' option of git-update-index:
>
> $ git update-index --unresolve foo
> $ git ls-files --stage foo
> 100644 3bd1f0e29744a1f32b08d5650e62e2e62afb177c 2 foo
> 100644 469a41eda5c8b45503a3bfc32ad6b5decc658132 3 foo
>
> WTF? What happened to stage 1 (ancestor)?
2 and 3 are easy (cheap) to recreate from HEAD and MERGE_HEAD, 1 is not.
I guess that's why --unresolve doesn't even attempt to do anything with 1.
>
> $ git checkout --conflict=merge foo
> error: path 'foo' does not have all three versions
>
> Let's recover it by hand:
>
> $ echo -e "100644 257cc5642cb1a054f08cc83f2d943e56fd3ebe99 1\tfoo" |
> git update-index --index-info
> $ git ls-files --stage foo
> 100644 257cc5642cb1a054f08cc83f2d943e56fd3ebe99 1 foo
> 100644 3bd1f0e29744a1f32b08d5650e62e2e62afb177c 2 foo
> 100644 469a41eda5c8b45503a3bfc32ad6b5decc658132 3 foo
> $ git checkout --conflict=merge foo
Yeah, if we knew that sha1...
^ permalink raw reply
* Re: [PATCH 2/6] GITWEB - Missmatching git w/ gitweb
From: Jakub Narebski @ 2009-12-11 10:52 UTC (permalink / raw)
To: John 'Warthog9' Hawley; +Cc: git, John 'Warthog9' Hawley
In-Reply-To: <1260488743-25855-3-git-send-email-warthog9@kernel.org>
"John 'Warthog9' Hawley" <warthog9@kernel.org> writes:
> This adds $missmatch_git so that gitweb can run with a miss-matched
> git install. Gitweb, generally, runs fine on a very broad range of
> git versions, but it's not always practicle or useful to upgrade it
> every time you upgrade git.
>
> This allows the administrator to realize they are miss-matched, and
> should they be so inclined, disable the check entirely and run in
> a miss-matched fasion.
>
> This is more here to give an obvious warning as to whats going on
> vs. silently failing.
First, why one would want to require that gitweb version (version at
the time of build) and runtime git version (version of git used to run
commands) match?
Second, it is mismatch, not missmatch (one 's', not double 's').
Third, in my opinion it would be better to name variable in question
e.g. $versions_must_match and also flip its meaning (true means check
that versions match, and show an error otherwise).
>
> Signed-off-by: John 'Warthog9' Hawley <warthog9@eaglescrag.net>
signoff mismatch
> ---
> gitweb/gitweb.perl | 22 ++++++++++++++++++++++
> 1 files changed, 22 insertions(+), 0 deletions(-)
>
>
> diff --git a/gitweb/gitweb.perl b/gitweb/gitweb.perl
> index 813e48f..d84f4c0 100755
> --- a/gitweb/gitweb.perl
> +++ b/gitweb/gitweb.perl
> @@ -221,6 +221,9 @@ our %avatar_size = (
> 'double' => 32
> );
>
> +# This is here to allow for missmatch git & gitweb versions
> +our $missmatch_git = '';
> +
First, 'undef' is false, so it could have been written as
+our $missmatch_git;
Or if you prefer explicit false-ish value as default, 0 would be I
think better than empty string '':
+our $missmatch_git = 0;
Second, there is question whether default should be to allow
mismatched versions (current behaviour, more lenient...) or deny (or
warn about) mismatched version, i.e. should it be $versions_must_match
false by default, or $allow_versions_mismatch false by default.
> # Used to set the maximum load that we will still respond to gitweb queries.
> # if we exceed this than we do the processing to figure out if there's a mirror
> # and redirect to it, or to just return 503 server busy
> @@ -579,6 +582,25 @@ if (get_loadavg() > $maxload) {
> our $git_version = qx("$GIT" --version) =~ m/git version (.*)$/ ? $1 : "unknown";
> $number_of_git_cmds++;
>
> +# There's a pretty serious flaw that we silently fail if git doesn't find something it needs
> +# a quick and simple check is to have gitweb do a simple check - are we running on the same
> +# version of git that we shipped with - if not, throw up an error so that people doing
> +# first installs don't have to debug perl to figure out whats going on
Could you please clean up language in above comment? It is very
convoluted. Please also limit line width of above comment to 76 / 80
columns.
> +if (
> + $git_version ne $version
> + &&
> + $missmatch_git eq ''
> +){
Style
+if (!$allow_versions_mismatch &&
+ $git_version ne $version) {
Do not compare $missmatch_git / $allow_versions_mismatch against '':
it is a boolean value!
> + git_header_html();
Shouldn't this be "500 Internal Server Error" or something (using the
optional parameter to git_header_html())?
> + print "<p><b>*** Warning ***</b></p>\n";
> + print "<p>\n";
> + print "This version of gitweb was compiled for <b>$version</b> however git version <b>$git_version</b> was found<br/>\n";
> + print "If you are sure this version of git works with this version of gitweb - please define <b>\$missmatch_git</b> to a non empty string in your git config file.\n";
Too long lines. Here-doc could be better here.
> + print "</p>\n";
> + git_footer_html();
> + exit;
> +}
> +
> $projects_list ||= $projectroot;
>
> # ======================================================================
--
Jakub Narebski
Poland
ShadeHawk on #git
^ permalink raw reply
* Re: [PATCH RFC] rebase: add --revisions flag
From: Björn Steinbrink @ 2009-12-11 11:07 UTC (permalink / raw)
To: Junio C Hamano
Cc: Michael S. Tsirkin, Andreas Schwab, Peter Krefting,
Git Mailing List
In-Reply-To: <7vpr6mkaoz.fsf@alter.siamese.dyndns.org>
On 2009.12.10 09:20:28 -0800, Junio C Hamano wrote:
> Björn Steinbrink <B.Steinbrink@gmx.de> writes:
>
> >> But at the conceptual level, "merge --squash" is a short-hand for this
> >> command sequence:
> >>
> >> git rebase -i HEAD that-branch
> >> ... make everything except the first one into "squash"
> >> git checkout - ;# come back to the original branch
> >> git merge that-branch ;# fast forward to it
> >>
> >> So after all, it is "merge it after squashing them".
> >
> > To me, that approach looks backwards,...
>
> Yes, of course, but what you are missing (and I am at blame for forgetting
> to mention the history behind this in the message you are responding to)
> is that "merge --squash" to support a particular need/use case was done
> way before "rebase -i" came into existence.
Hm? You started explaining that "merge --squash" would be right because
you can do it via some command sequence that involves rebase -i and then
merge. I said that using that rebase+merge sequence as an argument for
the choice of the name is wrong. It would even have made more sense to
me if you said:
git merge that-branch
git reset --soft HEAD^
git commit -C ORIG_HEAD
Which is "merge, but then drop the extra parents", which pretty close to
what "merge --squash" does (and that sequence even gets it right not to
rewrite that-branch).
I'm not arguing that you shouldn't have chosen "merge --squash" to do
that. You couldn't possibly foresee the future and that git might get
rebase -i or maybe at some day cherry-pick -i <range>. I'm just saying
that in retrospective, it's sad that merge doesn't always mean "merge
histories", but that --squash makes it degenerate to "merge changes".
I don't see why you're trying to defend the choice of "merge --squash"
using a IMHO rather weird command sequence that happens to involve
"merge", using commands that weren't present when "merge --squash" was
added, but at the same ignore the "cherry-pick -i <range>" command git
might learn in the near future, which allows for a much saner
explanation:
git cherry-pick -i ..that-branch
... make everything except the first one into "squash"
And given that, one could add a --squash flag to cherry-pick that makes
it do the "squash everything" itself, allowing it to be a bit smarter
about the whole thing, because it could use a three-way merge
internally, instead of cherry-picking all the individual commits. Making
"git cherry-pick --squash ..that-branch" the same as "git merge --squash
that-branch".
> A nicer workflow may be to use "rebase -i" to clean up the history before
> even contemplating to integrate the topic to the mainline, instead of the
> above "abandoning or forking off again", if you know today's git.
Well, I'm not saying that git should completely lose the abilitiy to do
something like "merge --squash", just that if it learns "git cherry-pick
<range>", it might as well get the --squash thing for cherry-pick, maybe
allowing for "merge --squash" to be phased out. And heck, having it as
an option to cherry-pick instead of merge would probably already help a
lot to make people realise that it won't remember that the changes got
"integrated". We've had people on #git that wondered why repeated "git
merge --squash" commands would try to merge the same stuff over and over
again, leading to the same conflicts every time. Because they didn't
realise that with --squash, "git merge" is no longer about merging
histories.
> But interactive was not available back then. It was introduced at 1b1dce4
> (Teach rebase an interactive mode, 2007-06-25), which is 1 year after
> 7d0c688 (git-merge --squash, 2006-06-23).
Again, I'm not blaming you for having chosen that command back then.
Just saying that it might be better to have the same functionality in an
extended cherry-pick now.
Björn
^ permalink raw reply
* Re: How to selectively recreate merge state?
From: Björn Steinbrink @ 2009-12-11 11:09 UTC (permalink / raw)
To: Michael J Gruber; +Cc: Jakub Narebski, Junio C Hamano, Jay Soffian, git
In-Reply-To: <4B222289.6000004@drmicha.warpmail.net>
On 2009.12.11 11:44:25 +0100, Michael J Gruber wrote:
> Jakub Narebski venit, vidit, dixit 11.12.2009 02:33:
> > $ git checkout --conflict=merge foo
> > error: path 'foo' does not have all three versions
> >
> > Let's recover it by hand:
> >
> > $ echo -e "100644 257cc5642cb1a054f08cc83f2d943e56fd3ebe99 1\tfoo" |
> > git update-index --index-info
> > $ git ls-files --stage foo
> > 100644 257cc5642cb1a054f08cc83f2d943e56fd3ebe99 1 foo
> > 100644 3bd1f0e29744a1f32b08d5650e62e2e62afb177c 2 foo
> > 100644 469a41eda5c8b45503a3bfc32ad6b5decc658132 3 foo
> > $ git checkout --conflict=merge foo
>
> Yeah, if we knew that sha1...
Hm, isn't that "$(git merge-base HEAD MERGE_HEAD):foo"?
Björn
^ permalink raw reply
* Re: How to selectively recreate merge state?
From: Jakub Narebski @ 2009-12-11 11:20 UTC (permalink / raw)
To: Michael J Gruber; +Cc: Junio C Hamano, Jay Soffian, git
In-Reply-To: <4B222289.6000004@drmicha.warpmail.net>
Dnia piątek 11. grudnia 2009 11:44, Michael J Gruber napisał:
> Jakub Narebski venit, vidit, dixit 11.12.2009 02:33:
>> Dnia piątek 11. grudnia 2009 02:11, Junio C Hamano napisał:
>>> Jakub Narebski <jnareb@gmail.com> writes:
>>>
>>>> --unresolve::
>>>> Restores the 'unmerged' or 'needs updating' state of a
>>>> file during a merge if it was cleared by accident.
>>>>
>>>> Unless "git add foo" not only adds current contents of foo at stage 0,
>>>> but also removes higher stages from index...
>>>
>>> By definition, adding anything at stage #0 is to remove higher stages.
>>
>> Hmmm... let's test it:
>>
>> $ git merge side-branch
>> Auto-merging foo
>> CONFLICT (content): Merge conflict in foo
>> Automatic merge failed; fix conflicts and then commit the result.
>> $ git ls-files --stage
>> 100644 257cc5642cb1a054f08cc83f2d943e56fd3ebe99 1 foo
>> 100644 3bd1f0e29744a1f32b08d5650e62e2e62afb177c 2 foo
>> 100644 469a41eda5c8b45503a3bfc32ad6b5decc658132 3 foo
>> $ <edit foo>
>> $ git add foo
>> $ git ls-files --stage
>> 100644 a1b58d38ffa61e8e99b7cb95cdf540aedf2a96b3 0 foo
I thought that "git add foo" only adds current contents of foo in stage 0,
and does not delete other stages.
Unless "git add foo" does more than "git update-index foo" does here.
>> Now let's test '--unresolve' option of git-update-index:
>>
>> $ git update-index --unresolve foo
>> $ git ls-files --stage foo
>> 100644 3bd1f0e29744a1f32b08d5650e62e2e62afb177c 2 foo
>> 100644 469a41eda5c8b45503a3bfc32ad6b5decc658132 3 foo
>>
>> WTF? What happened to stage 1 (ancestor)?
>
> 2 and 3 are easy (cheap) to recreate from HEAD and MERGE_HEAD, 1 is not.
> I guess that's why --unresolve doesn't even attempt to do anything with 1.
But then "git update-index --unresolve <file>" is next to useless.
>>
>> $ git checkout --conflict=merge foo
>> error: path 'foo' does not have all three versions
>>
>> Let's recover it by hand:
>>
>> $ echo -e "100644 257cc5642cb1a054f08cc83f2d943e56fd3ebe99 1\tfoo" |
>> git update-index --index-info
>> $ git ls-files --stage foo
>> 100644 257cc5642cb1a054f08cc83f2d943e56fd3ebe99 1 foo
>> 100644 3bd1f0e29744a1f32b08d5650e62e2e62afb177c 2 foo
>> 100644 469a41eda5c8b45503a3bfc32ad6b5decc658132 3 foo
>> $ git checkout --conflict=merge foo
>
> Yeah, if we knew that sha1...
Isn't it:
$ git ls-tree $(git merge-base HEAD MERGE_HEAD) -- foo
or
$ git rev-parse "$(git merge-base HEAD MERGE_HEAD):foo"
--
Jakub Narebski
Poland
^ permalink raw reply
* git fetch with GIT_SSH fails with "The remote end hung up unexpectedly"
From: Gert Palok @ 2009-12-11 11:57 UTC (permalink / raw)
To: git
At my work I have to use an intermediate gateway to ssh to the outer
world. I have set up private-public keys to allow easy connection:
ssh gateway ssh user@outside
Now, I want to fetch from outside repo, so I created a GIT_SSH wrapper:
#! /bin/bash
LOG="/path/to/git-ssh-wrapper.
log"
HOST="$1"
COMMAND="$2"
echo host: $HOST >>"$LOG"
echo command: $COMMAND >>"$LOG"
echo exec: ssh gateway ssh "$HOST" $COMMAND >>"$LOG"
ssh gateway ssh "$HOST" $COMMAND
And ran:
$ GIT_SSH="/path/to/git-ssh-wrapper" git clone ssh://user@outside/path/to/repo
Initialized empty Git repository in /path/to/local-repo/.git/
warning: You appear to have cloned an empty repository.
$ fatal: The remote end hung up unexpectedly
And again just to be sure:
$ GIT_SSH="/path/to/git-ssh-wrapper" git fetch origin
$ fatal: The remote end hung up unexpectedly
fatal: The remote end hung up unexpectedly
Now, the log says:
host: user@outside
command: git-upload-pack '/path/to/repo'
exec: ssh gateway ssh user@outside git-upload-pack '/path/to/repo'
When I ran the command from shell I got:
$ "$GIT_SSH" user@outside "git-upload-pack '/path/to/repo'"
0000
And the connection was kept open (waiting for input, got protocol
error after entering something)
Local environment: Windows Vista 32-bit, cygwin 1.7
Local git version (installed by cygwin): 1.6.4.2
Remote git version: 1.6.4.4
What might be the cause(s)? Have there been compatibility breaking
protocol changes between those version?
--
Gert Palok
^ permalink raw reply
* Re: How to selectively recreate merge state?
From: Michael J Gruber @ 2009-12-11 12:33 UTC (permalink / raw)
To: Jakub Narebski; +Cc: Junio C Hamano, Jay Soffian, git
In-Reply-To: <200912111220.40844.jnareb@gmail.com>
Jakub Narebski venit, vidit, dixit 11.12.2009 12:20:
> Dnia piątek 11. grudnia 2009 11:44, Michael J Gruber napisał:
>> Jakub Narebski venit, vidit, dixit 11.12.2009 02:33:
>>> Dnia piątek 11. grudnia 2009 02:11, Junio C Hamano napisał:
>>>> Jakub Narebski <jnareb@gmail.com> writes:
>>>>
>>>>> --unresolve::
>>>>> Restores the 'unmerged' or 'needs updating' state of a
>>>>> file during a merge if it was cleared by accident.
>>>>>
>>>>> Unless "git add foo" not only adds current contents of foo at stage 0,
>>>>> but also removes higher stages from index...
>>>>
>>>> By definition, adding anything at stage #0 is to remove higher stages.
>>>
>>> Hmmm... let's test it:
>>>
>>> $ git merge side-branch
>>> Auto-merging foo
>>> CONFLICT (content): Merge conflict in foo
>>> Automatic merge failed; fix conflicts and then commit the result.
>>> $ git ls-files --stage
>>> 100644 257cc5642cb1a054f08cc83f2d943e56fd3ebe99 1 foo
>>> 100644 3bd1f0e29744a1f32b08d5650e62e2e62afb177c 2 foo
>>> 100644 469a41eda5c8b45503a3bfc32ad6b5decc658132 3 foo
>>> $ <edit foo>
>>> $ git add foo
>>> $ git ls-files --stage
>>> 100644 a1b58d38ffa61e8e99b7cb95cdf540aedf2a96b3 0 foo
>
> I thought that "git add foo" only adds current contents of foo in stage 0,
> and does not delete other stages.
>
> Unless "git add foo" does more than "git update-index foo" does here.
Quoting Junio:
By definition, adding anything at stage #0 is to remove higher stages.
Could one leave 1 alone but still mark the conflict resolved?
>>> Now let's test '--unresolve' option of git-update-index:
>>>
>>> $ git update-index --unresolve foo
>>> $ git ls-files --stage foo
>>> 100644 3bd1f0e29744a1f32b08d5650e62e2e62afb177c 2 foo
>>> 100644 469a41eda5c8b45503a3bfc32ad6b5decc658132 3 foo
>>>
>>> WTF? What happened to stage 1 (ancestor)?
>>
>> 2 and 3 are easy (cheap) to recreate from HEAD and MERGE_HEAD, 1 is not.
>> I guess that's why --unresolve doesn't even attempt to do anything with 1.
>
> But then "git update-index --unresolve <file>" is next to useless.
Well, I'm not defending current behaviour, just describing its
implementation.
>
>>>
>>> $ git checkout --conflict=merge foo
>>> error: path 'foo' does not have all three versions
>>>
>>> Let's recover it by hand:
>>>
>>> $ echo -e "100644 257cc5642cb1a054f08cc83f2d943e56fd3ebe99 1\tfoo" |
>>> git update-index --index-info
>>> $ git ls-files --stage foo
>>> 100644 257cc5642cb1a054f08cc83f2d943e56fd3ebe99 1 foo
>>> 100644 3bd1f0e29744a1f32b08d5650e62e2e62afb177c 2 foo
>>> 100644 469a41eda5c8b45503a3bfc32ad6b5decc658132 3 foo
>>> $ git checkout --conflict=merge foo
>>
>> Yeah, if we knew that sha1...
>
> Isn't it:
>
> $ git ls-tree $(git merge-base HEAD MERGE_HEAD) -- foo
>
> or
>
> $ git rev-parse "$(git merge-base HEAD MERGE_HEAD):foo"
Yes, sure. That's why I wrote "cheap": --unresolve simply reads HEAD and
MERGE_HEAD. Resetting 1 requires (re)calculation of the merge base.
Michael
^ permalink raw reply
* Re: [PATCH 2/6] GITWEB - Missmatching git w/ gitweb
From: Johannes Schindelin @ 2009-12-11 12:49 UTC (permalink / raw)
To: John 'Warthog9' Hawley; +Cc: git, John 'Warthog9' Hawley
In-Reply-To: <1260488743-25855-3-git-send-email-warthog9@kernel.org>
Hi,
On Thu, 10 Dec 2009, John 'Warthog9' Hawley wrote:
> This adds $missmatch_git so that gitweb can run with a miss-matched
> git install.
I'm not a native English speaker and all, but I thought it was spelt
'mismatch', i.e. with only one 's'. Maybe even name it
'allow_different_git_version' or 'no_strict_git_version'.
A few comments on the patch: the style of the if() statement disagrees
with the other ones; please use the same style.
Also, as with 1/6, turning off the feature might be better done by setting
it to undef.
Finally, would it not be nicer if the warning really was only a warning,
i.e. that the script would try to continue after giving the users a pretty
warning header?
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH 3/6] GITWEB - Add git:// link to summary pages
From: Johannes Schindelin @ 2009-12-11 12:52 UTC (permalink / raw)
To: John 'Warthog9' Hawley; +Cc: git, John 'Warthog9' Hawley
In-Reply-To: <1260488743-25855-4-git-send-email-warthog9@kernel.org>
Hi,
On Thu, 10 Dec 2009, John 'Warthog9' Hawley wrote:
> This adds a git:// link to the summary pages should a common $gitlinkurl
> be defined (default is nothing defined, thus nothing shown)
Nice.
I forgot to mention in my comments to 2/6 that you seem to wrap after more
than 80 characters. However, I have no idea what the suggested line width
is for gitweb.
Again, this could be done by having the variable defined as undef.
Maybe it would be even nicer if the administrator could specify the
protocol, e.g. when they do not want/cannot allow git:// but only http://
access to the repositories?
Ciao,
Dscho
^ permalink raw reply
* Re: How to selectively recreate merge state?
From: Thomas Rast @ 2009-12-11 12:51 UTC (permalink / raw)
To: Björn Steinbrink
Cc: Michael J Gruber, Jakub Narebski, Junio C Hamano, Jay Soffian,
git
In-Reply-To: <20091211110944.GB19232@atjola.homenet>
Björn Steinbrink wrote:
> On 2009.12.11 11:44:25 +0100, Michael J Gruber wrote:
> > Jakub Narebski venit, vidit, dixit 11.12.2009 02:33:
> > > $ echo -e "100644 257cc5642cb1a054f08cc83f2d943e56fd3ebe99 1\tfoo" |
> > > git update-index --index-info
> >
> > Yeah, if we knew that sha1...
>
> Hm, isn't that "$(git merge-base HEAD MERGE_HEAD):foo"?
Not if the merge-base isn't unique and you're using the recursive
strategy, IIUC.
--
Thomas Rast
trast@{inf,student}.ethz.ch
^ permalink raw reply
* Re: [PATCH 3/6] GITWEB - Add git:// link to summary pages
From: Jakub Narebski @ 2009-12-11 13:44 UTC (permalink / raw)
To: John 'Warthog9' Hawley; +Cc: git, John 'Warthog9' Hawley
In-Reply-To: <1260488743-25855-4-git-send-email-warthog9@kernel.org>
"John 'Warthog9' Hawley" <warthog9@kernel.org> writes:
> This adds a git:// link to the summary pages should a common
> $gitlinkurl be defined (default is nothing defined, thus nothing
> shown)
>
> This does make the assumption that the git trees share a common
> path, and nothing to date is known to actually make use of the link
The problem I had and have with this patch is the duplication of data:
$gitlinkurl contains subset of information in @git_base_url_list,
which in turn is filled from GITWEB_BASE_URL build config variable.
I can understand that for performance reason you don't want to check
$projectroot/$project/cloneurl nor gitweb.url config variable for
each and every displayed project; if the link to repository (for git)
cannot be derived from project path (repository path), then simply
do not dosplay it.
>
> Signed-off-by: John 'Warthog9' Hawley <warthog9@eaglescrag.net>
> ---
> gitweb/gitweb.perl | 8 ++++++++
> 1 files changed, 8 insertions(+), 0 deletions(-)
>
>
> diff --git a/gitweb/gitweb.perl b/gitweb/gitweb.perl
> index d84f4c0..7ad096c 100755
> --- a/gitweb/gitweb.perl
> +++ b/gitweb/gitweb.perl
> @@ -224,6 +224,10 @@ our %avatar_size = (
> # This is here to allow for missmatch git & gitweb versions
> our $missmatch_git = '';
>
> +#This is here to deal with an extra link on the summary pages - if it's left blank
> +# this link will not be shwon. If it's set, this will be prepended to the repo and used
s/shwon/shown/
I'd say that 'Full URL is "$gitlinkurl/$project"' instead of last
sentence in above comment.
Please watch for excessive line lengths.
> +our $gitlinkurl = '';
Why not
our $gitlinkurl_base = "++GITWEB_BASE_URL++";
of course changing the name everywhere.
> +
> # Used to set the maximum load that we will still respond to gitweb queries.
> # if we exceed this than we do the processing to figure out if there's a mirror
> # and redirect to it, or to just return 503 server busy
> @@ -4454,6 +4458,10 @@ sub git_project_list_body {
> $cgi->a({-href => href(project=>$pr->{'path'}, action=>"log")}, "log") . " | " .
> $cgi->a({-href => href(project=>$pr->{'path'}, action=>"tree")}, "tree") .
> ($pr->{'forks'} ? " | " . $cgi->a({-href => href(project=>$pr->{'path'}, action=>"forks")}, "forks") : '') .
> + if( $gitlinkurl ne '' ){
> + print " | ". $cgi->a({-href => "git://$gitlinkurl/".esc_html($pr->{'path'})}, "git");
> + }
> + print "".
Does it even pass tests?
$cgi->a({-href => href(project=>$pr->{'path'}, action=>"log")}, "log") . " | " .
$cgi->a({-href => href(project=>$pr->{'path'}, action=>"tree")}, "tree") .
($pr->{'forks'} ? " | " . $cgi->a({-href => href(project=>$pr->{'path'}, action=>"forks")}, "forks") : '') .
+ ($gitlinkurl_base ?
+ " | " . $cgi->a({-href=>"$gitlinkurl_base/$pr->{'path'}", "git") : '') .
"</td>\n" .
"</tr>\n";
}
Changes made:
* Instead of using separate if conditional statement and print
statement (note that you forgot to change '.' to ';' to end
statement) use ternary conditional operator "?:"
* Make $gitlinkurl_base include "git://" protocol specifier
* Do not create "git" link if $gitlinkurl_base is false, which means
undef, empty string '' and 0 (but 0 is not very likely to be base
for "git" link).
* Do not use esc_html on fragment of URL. The CGI.pm should escape
attributes itself. If it was HTTP link, one should perhaps esc_url
on whole link, but esc_html is for escaping HTML.
--
Jakub Narebski
Poland
ShadeHawk on #git
^ permalink raw reply
* Re: How to selectively recreate merge state?
From: Jakub Narebski @ 2009-12-11 14:00 UTC (permalink / raw)
To: Michael J Gruber; +Cc: Junio C Hamano, Jay Soffian, git
In-Reply-To: <4B223C1E.6010403@drmicha.warpmail.net>
Dnia piątek 11. grudnia 2009 13:33, Michael J Gruber napisał:
> Jakub Narebski venit, vidit, dixit 11.12.2009 12:20:
>> Dnia piątek 11. grudnia 2009 11:44, Michael J Gruber napisał:
>>> Jakub Narebski venit, vidit, dixit 11.12.2009 02:33:
>>>> Dnia piątek 11. grudnia 2009 02:11, Junio C Hamano napisał:
>>>>> Jakub Narebski <jnareb@gmail.com> writes:
>>>>>
>>>>>> --unresolve::
>>>>>> Restores the 'unmerged' or 'needs updating' state of a
>>>>>> file during a merge if it was cleared by accident.
>>>>>>
>>>>>> Unless "git add foo" not only adds current contents of foo at stage 0,
>>>>>> but also removes higher stages from index...
>>>>>
>>>>> By definition, adding anything at stage #0 is to remove higher stages.
>>>>
>>>> Hmmm... let's test it:
>>>>
>>>> $ git merge side-branch
>>>> Auto-merging foo
>>>> CONFLICT (content): Merge conflict in foo
>>>> Automatic merge failed; fix conflicts and then commit the result.
>>>> $ git ls-files --stage
>>>> 100644 257cc5642cb1a054f08cc83f2d943e56fd3ebe99 1 foo
>>>> 100644 3bd1f0e29744a1f32b08d5650e62e2e62afb177c 2 foo
>>>> 100644 469a41eda5c8b45503a3bfc32ad6b5decc658132 3 foo
>>>> $ <edit foo>
>>>> $ git add foo
>>>> $ git ls-files --stage
>>>> 100644 a1b58d38ffa61e8e99b7cb95cdf540aedf2a96b3 0 foo
>>
>> I thought that "git add foo" only adds current contents of foo in stage 0,
>> and does not delete other stages.
>>
>> Unless "git add foo" does more than "git update-index foo" does here.
>
> Quoting Junio:
>
> By definition, adding anything at stage #0 is to remove higher stages.
>
> Could one leave 1 alone but still mark the conflict resolved?
I have thought that if there exist stage #0 in index, git simply _ignores_
higher stages, so git-add simply adds stage #0 and does not delete higher
stages.
But I see that "git update-index --unresolve" (and its predecessor
"git-unresolve") simply recreate stages #2 and #3.
The documentation of "git update-index --unresolve" lacks this info,
and it doesn't tell one what it is for (see commit message for commit
ec16779 (Add git-unresolve <paths>..., 2006-04-19)).
--
Jakub Narebski
Poland
^ permalink raw reply
* Re: [PATCH 1/6] GITWEB - Load Checking
From: Mihamina Rakotomandimby @ 2009-12-11 13:53 UTC (permalink / raw)
To: git; +Cc: John 'Warthog9' Hawley
In-Reply-To: <1260488743-25855-2-git-send-email-warthog9@kernel.org>
> "John 'Warthog9' Hawley" <warthog9@kernel.org> :
> + open($load, '<', '/proc/loadavg') or return 0;
What about systems not having /proc/loadavg
--
Architecte Informatique chez Blueline/Gulfsat:
Administration Systeme, Recherche & Developpement
+261 34 29 155 34 / +261 33 11 207 36
^ permalink raw reply
* Re: [PATCH 4/6] GITWEB - Makefile changes
From: Jakub Narebski @ 2009-12-11 14:28 UTC (permalink / raw)
To: John 'Warthog9' Hawley; +Cc: git, John 'Warthog9' Hawley
In-Reply-To: <1260488743-25855-5-git-send-email-warthog9@kernel.org>
"John 'Warthog9' Hawley" <warthog9@kernel.org> writes:
Below are _proposed_ changes to make commit message easier to read, in
my opinion. But they are not _necessary_ changes.
> This adjust the makefiles so that you can do such things as
Add "gitweb" target to main Makefile so you would be able to simply
use
>
> make gitweb
>
> from the top level make tree,
instead of requiring to spell it in full
make gitweb/gitweb.cgi
> or if your in the gitweb directory
> itself typing
Add Makefile in gitweb subdirectory so one can simply run
>
> make
when in gitweb subdirectory,
>
> will call back up to the main Makefile and build gitweb
>
> Signed-off-by: John 'Warthog9' Hawley <warthog9@eaglescrag.net>
Signoff mismatch.
> ---
> Makefile | 4 +++-
> gitweb/Makefile | 14 ++++++++++++++
> 2 files changed, 17 insertions(+), 1 deletions(-)
> create mode 100644 gitweb/Makefile
IMPORTANT!
A note about this change: I think it would be better to move creating
gitweb.cgi (and optionally gitweb.min.js) to gitweb/Makefile, and make
main Makefile call gitweb/Makefile, and not vice versa like in your
solution.
If it is possible.
> diff --git a/Makefile b/Makefile
> index 4a1e5bc..8db9d01 100644
> --- a/Makefile
> +++ b/Makefile
> @@ -1509,6 +1509,8 @@ $(patsubst %.perl,%,$(SCRIPT_PERL)): % : %.perl
> chmod +x $@+ && \
> mv $@+ $@
>
> +.PHONY: gitweb
Why it is here, and not with the .PHONY block at line 1924 of
Makefile? It would be nice to have comment supporting this choice in
email with this patch (or in commit message).
> +gitweb: gitweb/gitweb.cgi
> ifdef JSMIN
> OTHER_PROGRAMS += gitweb/gitweb.cgi gitweb/gitweb.min.js
> gitweb/gitweb.cgi: gitweb/gitweb.perl gitweb/gitweb.min.js
> @@ -1537,7 +1539,7 @@ endif
> -e 's|++GITWEB_JS++|$(GITWEB_JS)|g' \
> -e 's|++GITWEB_SITE_HEADER++|$(GITWEB_SITE_HEADER)|g' \
> -e 's|++GITWEB_SITE_FOOTER++|$(GITWEB_SITE_FOOTER)|g' \
> - $< >$@+ && \
> + $(patsubst %.cgi,%.perl,$@) >$@+ && \
Why this change?
> chmod +x $@+ && \
> mv $@+ $@
>
> diff --git a/gitweb/Makefile b/gitweb/Makefile
> new file mode 100644
> index 0000000..8d318b3
> --- /dev/null
> +++ b/gitweb/Makefile
> @@ -0,0 +1,14 @@
> +SHELL = /bin/bash
Why is this needed?
> +
> +FILES = gitweb.cgi
> +
> +.PHONY: $(FILES)
Why .PHONY? $(FILES) are created.
> +
> +all: $(FILES)
> +
> +$(FILES):
> + $(MAKE) $(MFLAGS) -C ../ -f Makefile gitweb/$@
> +
> +clean:
> + rm -rf $(FILES)
> +
--
Jakub Narebski
Poland
ShadeHawk on #git
^ permalink raw reply
* Re: How to selectively recreate merge state?
From: Michael J Gruber @ 2009-12-11 14:57 UTC (permalink / raw)
To: Jakub Narebski; +Cc: Junio C Hamano, Jay Soffian, git
In-Reply-To: <200912111500.51982.jnareb@gmail.com>
Jakub Narebski venit, vidit, dixit 11.12.2009 15:00:
> Dnia piątek 11. grudnia 2009 13:33, Michael J Gruber napisał:
>> Jakub Narebski venit, vidit, dixit 11.12.2009 12:20:
>>> Dnia piątek 11. grudnia 2009 11:44, Michael J Gruber napisał:
>>>> Jakub Narebski venit, vidit, dixit 11.12.2009 02:33:
>>>>> Dnia piątek 11. grudnia 2009 02:11, Junio C Hamano napisał:
>>>>>> Jakub Narebski <jnareb@gmail.com> writes:
>>>>>>
>>>>>>> --unresolve::
>>>>>>> Restores the 'unmerged' or 'needs updating' state of a
>>>>>>> file during a merge if it was cleared by accident.
>>>>>>>
>>>>>>> Unless "git add foo" not only adds current contents of foo at stage 0,
>>>>>>> but also removes higher stages from index...
>>>>>>
>>>>>> By definition, adding anything at stage #0 is to remove higher stages.
>>>>>
>>>>> Hmmm... let's test it:
>>>>>
>>>>> $ git merge side-branch
>>>>> Auto-merging foo
>>>>> CONFLICT (content): Merge conflict in foo
>>>>> Automatic merge failed; fix conflicts and then commit the result.
>>>>> $ git ls-files --stage
>>>>> 100644 257cc5642cb1a054f08cc83f2d943e56fd3ebe99 1 foo
>>>>> 100644 3bd1f0e29744a1f32b08d5650e62e2e62afb177c 2 foo
>>>>> 100644 469a41eda5c8b45503a3bfc32ad6b5decc658132 3 foo
>>>>> $ <edit foo>
>>>>> $ git add foo
>>>>> $ git ls-files --stage
>>>>> 100644 a1b58d38ffa61e8e99b7cb95cdf540aedf2a96b3 0 foo
>>>
>>> I thought that "git add foo" only adds current contents of foo in stage 0,
>>> and does not delete other stages.
>>>
>>> Unless "git add foo" does more than "git update-index foo" does here.
>>
>> Quoting Junio:
>>
>> By definition, adding anything at stage #0 is to remove higher stages.
>>
>> Could one leave 1 alone but still mark the conflict resolved?
>
> I have thought that if there exist stage #0 in index, git simply _ignores_
> higher stages, so git-add simply adds stage #0 and does not delete higher
> stages.
>
> But I see that "git update-index --unresolve" (and its predecessor
> "git-unresolve") simply recreate stages #2 and #3.
>
>
> The documentation of "git update-index --unresolve" lacks this info,
> and it doesn't tell one what it is for (see commit message for commit
> ec16779 (Add git-unresolve <paths>..., 2006-04-19)).
>
Oh yes, one should always read the classics ;) [Really nice commit
message, that is.]
Michael
^ permalink raw reply
* Re: How to selectively recreate merge state?
From: Junio C Hamano @ 2009-12-11 15:35 UTC (permalink / raw)
To: Michael J Gruber; +Cc: Jakub Narebski, Jay Soffian, git
In-Reply-To: <4B225DC0.4020603@drmicha.warpmail.net>
Michael J Gruber <git@drmicha.warpmail.net> writes:
>> The documentation of "git update-index --unresolve" lacks this info,
>> and it doesn't tell one what it is for (see commit message for commit
>> ec16779 (Add git-unresolve <paths>..., 2006-04-19)).
>
> Oh yes, one should always read the classics ;) [Really nice commit
> message, that is.]
Thanks.
This is exactly why I often give _explanation_ of the current behaviour
based on history, without defending it is good nor claiming it is bad.
Knowing how things came about gives us better perspective to decide where
to go next.
^ permalink raw reply
* Re: [PATCH 6/6] GITWEB - Separate defaults from main file
From: Jakub Narebski @ 2009-12-11 15:46 UTC (permalink / raw)
To: John 'Warthog9' Hawley; +Cc: git, John 'Warthog9' Hawley
In-Reply-To: <1260488743-25855-7-git-send-email-warthog9@kernel.org>
"John 'Warthog9' Hawley" <warthog9@kernel.org> writes:
> This is an attempt to break out the default values & associated
> documentation from the main gitweb file so that it's easier to
> browse / read and understand without the associated code involved.
>
> This helps by making defaults self contained with their documentation
> making it easier for someone to read through things and find what
> they want
>
> This is also a not-so-subtle start of trying to break up gitweb into
> separate files for easier maintainability, having everything in a
> single file is just a mess and makes the whole thing more complicated
> than it needs to be. This is a bit of a baby step towards breaking it
> up for easier maintenance.
The question is if easier maintenance and development by spliting
gitweb for developers offsets ease of install for users.
> Signed-off-by: John 'Warthog9' Hawley <warthog9@eaglescrag.net>
Signoff mismatch.
> ---
> .gitignore | 1 +
> Makefile | 15 +-
> gitweb/Makefile | 2 +-
> gitweb/gitweb.perl | 515 +++++--------------------------------------
> gitweb/gitweb_defaults.perl | 468 +++++++++++++++++++++++++++++++++++++++
> 5 files changed, 537 insertions(+), 464 deletions(-)
> create mode 100644 gitweb/gitweb_defaults.perl
>
>
> diff --git a/.gitignore b/.gitignore
> index ac02a58..5e48102 100644
> --- a/.gitignore
> +++ b/.gitignore
> @@ -151,6 +151,7 @@
> /git-core-*/?*
> /gitk-git/gitk-wish
> /gitweb/gitweb.cgi
> +/gitweb/gitweb_defaults.pl
Hmmm... gitweb/gitweb_defaults.perl as source file, and
gitweb/gitweb_defaults.pl as generated file? Wouldn't it be better to
go with the convention used elsewhere in gitweb and use
gitweb/gitweb_defaults.perl.in or gitweb/gitweb_defaults.pl.in as
source file?
> /test-chmtime
> /test-ctype
> /test-date
> diff --git a/Makefile b/Makefile
> index 8db9d01..2c5f139 100644
> --- a/Makefile
> +++ b/Makefile
> @@ -1510,14 +1510,16 @@ $(patsubst %.perl,%,$(SCRIPT_PERL)): % : %.perl
> mv $@+ $@
>
> .PHONY: gitweb
> -gitweb: gitweb/gitweb.cgi
> +gitweb: gitweb/gitweb.cgi gitweb/gitweb_defaults.pl
> ifdef JSMIN
> -OTHER_PROGRAMS += gitweb/gitweb.cgi gitweb/gitweb.min.js
> -gitweb/gitweb.cgi: gitweb/gitweb.perl gitweb/gitweb.min.js
> +OTHER_PROGRAMS += gitweb/gitweb.cgi gitweb/gitweb.min.js gitweb/gitweb_defaults.pl
> +gitweb/gitweb.cgi gitweb/gitweb_defaults.pl: gitweb/gitweb.perl gitweb/gitweb.min.js gitweb/gitweb_defaults.perl
> else
> -OTHER_PROGRAMS += gitweb/gitweb.cgi
> -gitweb/gitweb.cgi: gitweb/gitweb.perl
> +OTHER_PROGRAMS += gitweb/gitweb.cgi gitweb/gitweb_defaults.pl
> +gitweb/gitweb.cgi: gitweb/gitweb_defaults.pl
> +gitweb/gitweb.cgi gitweb/gitweb_defaults.pl: gitweb/gitweb.perl gitweb/gitweb_defaults.perl
> endif
> + #$(QUIET_GEN)$(RM) $@ $@+ &&
What this line is about?
> $(QUIET_GEN)$(RM) $@ $@+ && \
> sed -e '1s|#!.*perl|#!$(PERL_PATH_SQ)|' \
> -e 's|++GIT_VERSION++|$(GIT_VERSION)|g' \
> @@ -1539,7 +1541,7 @@ endif
> -e 's|++GITWEB_JS++|$(GITWEB_JS)|g' \
> -e 's|++GITWEB_SITE_HEADER++|$(GITWEB_SITE_HEADER)|g' \
> -e 's|++GITWEB_SITE_FOOTER++|$(GITWEB_SITE_FOOTER)|g' \
> - $(patsubst %.cgi,%.perl,$@) >$@+ && \
> + $(patsubst %.cgi,%.perl,$(patsubst %.pl, %.perl, $@)) >$@+ && \
Why the slightly inconsistent style ("%.cgi,%perl" vs "%.pl, %perl")?
Also wouldn't all replacements be in the new gitweb_defaults file, so
there would be no need then to do replacements for gitweb.cgi?
Oh, I see there is at least one that stayed in gitweb.perl: $version
> chmod +x $@+ && \
> mv $@+ $@
>
> @@ -1913,6 +1915,7 @@ clean:
> $(MAKE) -C Documentation/ clean
> ifndef NO_PERL
> $(RM) gitweb/gitweb.cgi
> + $(RM) gitweb/gitweb_defaults.pl
> $(MAKE) -C perl clean
> endif
> $(MAKE) -C templates/ clean
> diff --git a/gitweb/Makefile b/gitweb/Makefile
> index 8d318b3..2bd421a 100644
> --- a/gitweb/Makefile
> +++ b/gitweb/Makefile
> @@ -1,6 +1,6 @@
> SHELL = /bin/bash
>
> -FILES = gitweb.cgi
> +FILES = gitweb.cgi gitweb_defaults.pl
>
> .PHONY: $(FILES)
>
> diff --git a/gitweb/gitweb.perl b/gitweb/gitweb.perl
> index 3b44371..fd41539 100755
> --- a/gitweb/gitweb.perl
> +++ b/gitweb/gitweb.perl
> @@ -36,466 +36,67 @@ our $version = "++GIT_VERSION++";
> our $my_url = $cgi->url();
> our $my_uri = $cgi->url(-absolute => 1);
>
[cut deletion]
> +# Define and than setup our configuration
> +#
> +our(
> + $VERSION,
> + $path_info,
> + $GIT,
> + $projectroot,
> + $project_maxdepth,
> + $home_link,
> + $home_link_str,
> + $site_name,
> + $site_header,
> + $home_text,
> + $site_footer,
> + @stylesheets,
> + $stylesheet,
> + $logo,
> + $favicon,
> + $javascript,
> + $logo_url,
> + $logo_label,
> + $projects_list,
> + $projects_list_description_width,
> + $default_projects_order,
> + $export_ok,
> + $export_auth_hook,
> + $strict_export,
> + @git_base_url_list,
> + $default_blob_plain_mimetype,
> + $default_text_plain_charset,
> + $mimetypes_file,
> + $missmatch_git,
> + $gitlinkurl,
> + $maxload,
> + $cache_enable,
> + $minCacheTime,
> + $maxCacheTime,
> + $cachedir,
> + $backgroundCache,
> + $nocachedata,
> + $nocachedatabin,
> + $fullhashpath,
> + $fullhashbinpath,
> + $export_auth_hook,
> + %known_snapshot_format_aliases,
> + %known_snapshot_formats,
> + $path_info,
> + $fallback_encoding,
> + %avatar_size,
> + $project_maxdepth,
> + $headerRefresh,
> + $base_url,
> + $projects_list_description_width,
> + $default_projects_order,
> + $prevent_xss,
> + @diff_opts,
> + %feature
> );
Why this block is required? Why not have variables defined (using
"our") in gitweb_defaults file?
[cut deletion]
> +do 'gitweb_defaults.pl';
>
> sub gitweb_get_feature {
> my ($name) = @_;
> diff --git a/gitweb/gitweb_defaults.perl b/gitweb/gitweb_defaults.perl
> new file mode 100644
> index 0000000..ede0daf
> --- /dev/null
> +++ b/gitweb/gitweb_defaults.perl
> @@ -0,0 +1,468 @@
> +# gitweb - simple web interface to track changes in git repositories
> +#
> +# (C) 2005-2006, Kay Sievers <kay.sievers@vrfy.org>
> +# (C) 2005, Christian Gierke
> +#
> +# This program is licensed under the GPLv2
> +
> +# Base URL for relative URLs in gitweb ($logo, $favicon, ...),
> +# needed and used only for URLs with nonempty PATH_INFO
> +$base_url = $my_url;
Why not "our $base_url = $my_url;"?
[cut]
> +1;
--
Jakub Narebski
Poland
ShadeHawk on #git
^ permalink raw reply
* Re: [PATCH 0/6] Gitweb caching changes v2
From: Jakub Narebski @ 2009-12-11 15:51 UTC (permalink / raw)
To: John 'Warthog9' Hawley; +Cc: git, John 'Warthog9' Hawley
In-Reply-To: <1260488743-25855-1-git-send-email-warthog9@kernel.org>
"John 'Warthog9' Hawley" <warthog9@kernel.org> writes:
> Evening everyone,
>
> This is the latest incarnation of gitweb w/ caching. This is
> finally at the point where it should probably start either being
> considered for inclusion or mainline, or I need to accept that this
> will never get in and more perminantely fork (as is the case with
> Fedora where this is going in as gitweb-caching as a parrallel rpm
> package).
>
> That said this brings the base up to mainline (again), it updates a
> number of elements in the caching engine, and this is a much cleaner
> break-out of the tree vs. what I am currently developing against.
>
> New things known to work:
> - Better breakout
> - You can actually disable the cache now
>
> - John 'Warthog9' Hawley
>
> John 'Warthog9' Hawley (6):
> GITWEB - Load Checking
> GITWEB - Missmatching git w/ gitweb
> GITWEB - Add git:// link to summary pages
> GITWEB - Makefile changes
> GITWEB - File based caching layer
This patch didn't made it to git mailing list. I suspect that you ran
afoul vger anti-SPAM filter.
Does this "File based caching layer" have anything common with GSoC
2008 project, available at git://repo.or.cz/git/gitweb-caching.git ?
> GITWEB - Separate defaults from main file
--
Jakub Narebski
Poland
ShadeHawk on #git
^ 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