* Re: [PATCH v2 00/11] gitweb: display remote heads
From: Jakub Narebski @ 2008-11-14 14:33 UTC (permalink / raw)
To: Giuseppe Bilotta; +Cc: git, Petr Baudis, Junio C Hamano
In-Reply-To: <1226616555-24503-1-git-send-email-giuseppe.bilotta@gmail.com>
On Thu, 13 Nov 2008, Giuseppe Bilotta wrote:
> This is a patchset I presented about a year ago or so, but after a lively
> discussion it dropped into silence. I'm now presenting it again, with minor
> cleanups and adjustements.
That is very nice of you to resend this series. If you could provide
link to earlier discussion of this series...
> Giuseppe Bilotta (11):
> gitweb: introduce remote_heads feature
> gitweb: git_get_heads_list accepts an optional list of refs.
> gitweb: separate heads and remotes list in summary view
> gitweb: optional custom name for refs in git_heads_body
> gitweb: git_split_heads_body function.
> gitweb: use CSS to style split head lists.
> gitweb: add 'remotes' action
> gitweb: display HEAD in heads list when detached
> gitweb: git_is_head_detached() function
> gitweb: add HEAD to list of shortlog refs if detached
> gitweb: CSS style and refs mark for detached HEAD
I'll try to review individual patches, but I haven't examined them
yet, so perhaps there is a reason why there are so many patches in
this series?
Note that on GMane NNTP (news) interface I can see only two last
patches. Could anyone not CC-ed confirm or deny if this is VGER
anti-SPAM filter at work, or some GMane archive hiccup?
--
Jakub Narebski
Poland
^ permalink raw reply
* Re: hosting git on a nfs
From: Kyle Moffett @ 2008-11-14 14:31 UTC (permalink / raw)
To: Linus Torvalds
Cc: Brandon Casey, James Pickens, Bruce Fields, Junio C Hamano,
Git Mailing List
In-Reply-To: <alpine.LFD.2.00.0811131707090.3468@nehalem.linux-foundation.org>
On Thu, Nov 13, 2008 at 8:15 PM, Linus Torvalds
<torvalds@linux-foundation.org> wrote:
> - It would be really cool to find some way to automatically notice when
> the tree is hot-cached and we might as well just be linear. I don't
> know exactly what it might be, but one of the nice things is that the
> preloading is _entirely_ optimistic, and we could just stop it in the
> middle if we notice that there's no upside.
Perhaps, rather... notice when the tree is *cold*-cached. At that
point you're already in a pseudo-slowpath and starting several threads
won't be noticeable at all compared to the time savings. You could
probably very easily do that by keeping track of the time as you start
with the normal single-threaded scan of directory entries. If the
entries are all equally slow/fast, there most likely won't be any
benefit at all to spawning extra threads. You might use some cutoff
on number of entries to test before you assume everything is hot and
stop worrying about the time. If there's a lot of variability in the
first few thousand then it means some caches are cold and spawning
extra threads will probably help.
Cheers,
Kyle Moffett
^ permalink raw reply
* Re: getting started with git
From: Lars Hoss @ 2008-11-14 14:29 UTC (permalink / raw)
To: Tor Arvid Lund; +Cc: Ivan Senji, git
In-Reply-To: <1a6be5fa0811140456j10fd8703w74e485571e3c70af@mail.gmail.com>
>
> Well, if it were me, I think I would commit that eclipse config file
> under a different name... Say, ".classpath.defaults" instead of
> ".classpath". Then your README file could tell your users to start by
> copying the .classpath.defaults to .classpath, and update its contents
> as necessary. Put .classpath in your .gitignore file, so it won't be
> committed to the repository.
Template files (x.default) is a good idea. But regarding your example
with .classpath: it's safe to add it to git since it's developer
independent and project oriented. Therefore it's useful for every
developer in the project who uses eclipse :-)
Yours,
Lars
^ permalink raw reply
* Re: git integration with monodevelop
From: Andreas Ericsson @ 2008-11-14 13:53 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Evgeniy Ivanov, Shawn Pearce, Git Mailing List
In-Reply-To: <alpine.DEB.1.00.0811141429040.30769@pacific.mpi-cbg.de>
Johannes Schindelin wrote:
> Hi,
>
> On Thu, 13 Nov 2008, Andreas Ericsson wrote:
>
>> Evgeniy Ivanov wrote:
>>
>>> But this is the same things Shawn has suggested to my mentor and me at
>>> the beginning of SoC...
>> Oh? I didn't know libgit2 started as a SoC project.
>
> It did not. It started as a request from GitHub, and following
> discussion, at the GitTogether '08.
>
> There _was_ a SoC project last year, libgit-thin, but the problem as far
> as GitHub is concerned was that it was a tear-down approach: it took
> git.git and tried to make a small library of it, and by this approach was
> bound to the GPL.
>
Oh. I was under the impression that libgit2 would also be able to reuse
code from git.git, since there was that huge license thread a couple of
months ago. Did I misinterpret that thread, and everything in libgit2
has to be implemented from scratch?
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
^ permalink raw reply
* Re: multiple-commit cherry-pick?
From: Johannes Schindelin @ 2008-11-14 14:00 UTC (permalink / raw)
To: Chris Frey; +Cc: Alex Riesen, Linus Torvalds, Junio C Hamano, Miles Bader, git
In-Reply-To: <20081114050822.GA23963@foursquare.net>
Hi,
On Fri, 14 Nov 2008, Chris Frey wrote:
> On Mon, Nov 10, 2008 at 10:31:32PM +0100, Johannes Schindelin wrote:
> > On Mon, 10 Nov 2008, Alex Riesen wrote:
> > > for cs in HEAD^..HEAD HEAD~10; do
> > > case "$cs"; in
> > > *..*)
> > > git format-patch --stdout "$cs"
> > > ;;
> > > *)
> > > git show --pretty=email "$cs"
> > > ;;
> > > esac
> > > done
> > >
> > > At least, this is what I have in mind and how I expect it to work.
> >
> > That is not the way git-show is implemented (it uses setup_revisions() to
> > check for validity and to parse the arguments), and I cannot think of any
> > way to make this work without ugly workarounds.
>
> Would it be possible to add "range" support to a subset of commands by
> using a git-range wrapper?
>
> Hypothetical, pie-in-the-sky idea:
>
> git range HEAD^..HEAD HEAD~10 -- show --pretty=email
> git range HEAD^..HEAD HEAD~10 -- log
> git range HEAD^..HEAD HEAD~10 -- cherry-pick
This is not really well defined is it? What about
git range HEAD -- log makefile
Where should it insert the "HEAD" argument?
Besides, I do not like how this muddies the semantics: if git range as you
proposed it became part of Git, people _would_ get confused why "git range
HEAD^..HEAD HEAD~10" interprets the range _differently_ from "git log
HEAD^..HEAD HEAD~10".
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH 3/3] Add -k/--keep-going option to mergetool
From: Charles Bailey @ 2008-11-14 13:25 UTC (permalink / raw)
To: Jeff King
Cc: Junio C Hamano, git, Andreas Ericsson, Theodore Ts'o,
William Pursell
In-Reply-To: <20081114064756.GB11907@coredump.intra.peff.net>
Jeff King wrote:
>> Documentation/config.txt | 4 +++
>> Documentation/git-mergetool.txt | 12 +++++++++-
>> git-mergetool.sh | 46
++++++++++++++++++++++++++++++--------
>> 3 files changed, 51 insertions(+), 11 deletions(-)
>
> This patch in particular changes some of the innards of mergetool, and
> while the changes look good to me via reading, I would feel even more
> comfortable if there were some tests (it looks like your previous t7610
> gives at least a basic sanity check, but it might be nice to test to
> make sure we detect merge failures, too).
I had a little difficulty thinking of some decently robust tests. git
mergetool is, by its nature, more interactive than many git commands.
With --no-prompt it should be easier to make some tests that don't just
hang when it goes wrong. I'll have a further think on this.
>> [...]
>> - exit 1
>> + cleanup_temp_files
>> + return 1
>
> One of these is not like the others. Is there a reason to add a
> cleanup_temp_files here (and if so, should it be noted in the commit
> message, and/or be in a separate commit?).
Ah yes, it's definitely worthy of at least a comment. This is something
that I changed right at the end of testing and I should really have made
it into a separate commit.
Previously, if you aborted a merge, you were left with the
base/local/remote temporaries for the merge that you aborted.
To be honest, I found this a little irritating. The base, local and
remote temporaries are inputs so are accessible from slots 1,2 and 3 of
the index, and any intermediate output will be in the target file. You
can git clean, but if you have other temporaries you need to keep, you
end up having to manually clean them up in any case.
With --keep-going, the problem is compounded. If you make several passes
through a list of complex merges you end up with fistfuls of these
temporary trios in your working tree. It goes from slightly annoying to
very irritating.
Charles.
^ permalink raw reply
* Re: git integration with monodevelop
From: Johannes Schindelin @ 2008-11-14 13:30 UTC (permalink / raw)
To: Andreas Ericsson; +Cc: Evgeniy Ivanov, Shawn Pearce, Git Mailing List
In-Reply-To: <491BD532.9090200@op5.se>
Hi,
On Thu, 13 Nov 2008, Andreas Ericsson wrote:
> Evgeniy Ivanov wrote:
>
> > But this is the same things Shawn has suggested to my mentor and me at
> > the beginning of SoC...
>
> Oh? I didn't know libgit2 started as a SoC project.
It did not. It started as a request from GitHub, and following
discussion, at the GitTogether '08.
There _was_ a SoC project last year, libgit-thin, but the problem as far
as GitHub is concerned was that it was a tear-down approach: it took
git.git and tried to make a small library of it, and by this approach was
bound to the GPL.
Ciao,
Dscho
^ permalink raw reply
* Re: [MonoDevelop] git integration with monodevelop
From: Johannes Schindelin @ 2008-11-14 13:26 UTC (permalink / raw)
To: Miguel de Icaza
Cc: Jakub Narebski, Andreas Ericsson, Git Mailing List, Shawn Pearce,
monodevelop-list, Michael Hutchinson
In-Reply-To: <1226540535.4483.203.camel@erandi.site>
Hi,
On Wed, 12 Nov 2008, Miguel de Icaza wrote:
> > I assume that results of Mono's Google Summer of Code 2008 projects to
> > create managed git implementation in C# (git#)[1][2] were not very
> > successfull? Taking into account that JGit isn't yet full git
> > implementation, after much longer development...
>
> They were a complete disaster, one student was going to focus on the
> front-end, the other on the back-end.
I kinda followed the last few weeks via your svn repository (which was not
helped by the commits being a complete mix of the individual projects).
I was a bit disappointed that nobody asked things on the Git mailing list;
quite a number of very important lessons were learnt during the first
implementation of jgit, and you guys could have benefitted tremendously by
hearing them.
By the time I got aware of your effort, it was too late; for example, the
code already relied on the fact that every blob's contents were read into
memory at once (IIU the code correctly).
Note: personally, I do not like C# all that much, so I am not that
interested in the port myself. However, we get quite a number of
questions in that direction ("do you support .NET yet?"), so I am quite
interested to know what's available.
May I suggest respectfully, that the next time communication channels
between the Mono-mentor and at least one knowledgable Git guy are
established early in the project? IIRC there was a GSoC project to
reimplement Git in C# last year, too, which failed, too.
Ciao,
Dscho
^ permalink raw reply
* Re: Documentation/user-manual.txt, asciidoc and "--" escapes
From: Piotr Findeisen @ 2008-11-14 13:02 UTC (permalink / raw)
To: Jonas Fonseca; +Cc: git
In-Reply-To: <20081112000445.GB17662@diku.dk>
I've investigated it a little.
It seems that this newet version of asciidoc (I'm running 8.2.2) has
the global asciidoc.conf file (placed in /etc/asciidoc/asciidoc.conf
on my computer) containing the previously cited section:
# -- Spaced and unspaced em dashes (entity reference —)
# But disallow unspaced in man pages because double-dash option
name prefixes
# are pervasive.
ifndef::doctype-manpage[]
(^|[^-\\])--($|[^-])=\1—\2
endif::doctype-manpage[]
ifdef::doctype-manpage[]
(^|\s*[^\S\\])--($|\s+)=\1—\2
endif::doctype-manpage[]
\\--(?!-)=--
Those replacements are run *before* any replacements defined in
user-provided files are taken into consideration. You can disable them
only by disabling all replacements, I think.
So the only thing we can do about automatic conversion "--" to "—" is putting
[replacements]
&8212;=--
in Documentation/asciidoc.conf file or similar. (8212 = x2014,
"\u2014" = "—"). This way the unwanted replacement is reverted.
However, this forbids literal "&8212;" in the source .txt files and
there is no way to enable it. This seems only little probable that
anyone would want to write "&8212;" until someone writes "writing
Documentation guide" where she would state that "&8212;" is
prohibited.
If this is good solution and we want to replace punctuation "--" with
unicode "—", I will do this.
However, this seems a bit messy -- fighting against asciidoc instead
of using it as it's designed to be used. IMHO, it's better to
explicitly escape non-punctuation "--" with "\" and write punctuation
"--" with spaces on both sides. Please note, writing literal "—" isn't
so simple -- there is no such key on the keyboard :)
Best regards,
Piotr
On Wed, Nov 12, 2008 at 01:04, Jonas Fonseca <fonseca@diku.dk> wrote:
> Piotr Findeisen <piotr.findeisen@gmail.com> wrote Mon, Nov 10, 2008:
>> > This would also fix the usage of "--" in the manpages, e.g.
>> >
>> > You've now initialized the working directory--you may notice ...
>> >
>> > in gittutorial(7). On my setup, with "--" replaced with "—", I get the
>> > following nroff code:
>>
>> On my machine, make gittutorial.7 produces manpage that displays "--"
>> in this place :)
>
> At least you don't loose anything compared to the current behavior. ;)
>
>> > You've now initialized the working directory\(emyou may notice
>>
>> Anyway, this may be a good idea to use unambiguous "—" (though people
>> writing docs may be used to using "--" as a punctuation). I can run
>> through the Documentation replacing "\w--\w" with m-dash, if you want.
>
> I would like to see such a patch.
>
> --
> Jonas Fonseca
>
^ permalink raw reply
* Re: hosting git on a nfs
From: Michael J Gruber @ 2008-11-14 13:01 UTC (permalink / raw)
To: Linus Torvalds
Cc: Brandon Casey, James Pickens, Bruce Fields, Junio C Hamano,
Git Mailing List
In-Reply-To: <alpine.LFD.2.00.0811131707090.3468@nehalem.linux-foundation.org>
Linus Torvalds venit, vidit, dixit 14.11.2008 02:15:
>
> On Thu, 13 Nov 2008, Linus Torvalds wrote:
>> I'll clean it up a bit and make a less hacky version. And I'll try to make
>> it work for "git status" and friends too.
>
> Ok, this is a no-longer-totally-hacky thing, which also adds support for
> doing the same for "git status". I haven't actually done any timings, but
> the preload algorithm is all the same. The interface is just a much more
> natural one.
>
> NOTE NOTE NOTE! It may not be totally hacky, but it's still not
> "finished". There's a few more things to look at:
Doing nicely already. Over here, cold cache (i.e. sleep 70) "git status"
goes from 0.8s to around 0.4s. Nice. Hot cache goes from 0.18s to 0.23s.
This is really worthwhile if you hack for more than 60s between
diffs/stats ;)
This is already with the server doing some caching (first status was 8s
or so; hardly reproducible), which I can't control.
Michael
^ permalink raw reply
* Re: getting started with git
From: Tor Arvid Lund @ 2008-11-14 12:56 UTC (permalink / raw)
To: Ivan Senji; +Cc: git
In-Reply-To: <20497802.post@talk.nabble.com>
On Fri, Nov 14, 2008 at 11:16 AM, Ivan Senji <ivan.senji@gmail.com> wrote:
> On each location that i develop some project and configuration files are
> different. But i would like them to be in the repository as a starting point
> when checking out a project (example: opening a project on a dfferent OS in
> eclipse... eclipse will find an error in the path to jdk and ask me to fix
> that error by selecting a different jdk).
>
> How to achieve that these files are in the repository but that any further
> changes to them are not commited (or are commited localy but not pushed to a
> remote repository)?
Hi,
Well, if it were me, I think I would commit that eclipse config file
under a different name... Say, ".classpath.defaults" instead of
".classpath". Then your README file could tell your users to start by
copying the .classpath.defaults to .classpath, and update its contents
as necessary. Put .classpath in your .gitignore file, so it won't be
committed to the repository.
-Tor Arvid-
^ permalink raw reply
* [PATCH 3/3] Documentation: tutorial: add information about "git help" at the beginning
From: Christian Couder @ 2008-11-14 12:27 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
Talking about "git help" is useful because it has a few more
features (like when using it without arguments or with "-a") and
it may work on non unix like platforms.
Also add a few links to git-help(1) in "See also" sections.
Signed-off-by: Christian Couder <chriscool@tuxfamily.org>
---
Documentation/gitcore-tutorial.txt | 1 +
Documentation/gittutorial-2.txt | 1 +
Documentation/gittutorial.txt | 14 ++++++++++++++
3 files changed, 16 insertions(+), 0 deletions(-)
diff --git a/Documentation/gitcore-tutorial.txt b/Documentation/gitcore-tutorial.txt
index 61fc5d7..96bf353 100644
--- a/Documentation/gitcore-tutorial.txt
+++ b/Documentation/gitcore-tutorial.txt
@@ -1693,6 +1693,7 @@ SEE ALSO
linkgit:gittutorial[7],
linkgit:gittutorial-2[7],
linkgit:gitcvs-migration[7],
+linkgit:git-help[1],
link:everyday.html[Everyday git],
link:user-manual.html[The Git User's Manual]
diff --git a/Documentation/gittutorial-2.txt b/Documentation/gittutorial-2.txt
index bab0f34..a057b50 100644
--- a/Documentation/gittutorial-2.txt
+++ b/Documentation/gittutorial-2.txt
@@ -425,6 +425,7 @@ linkgit:gittutorial[7],
linkgit:gitcvs-migration[7],
linkgit:gitcore-tutorial[7],
linkgit:gitglossary[7],
+linkgit:git-help[1],
link:everyday.html[Everyday git],
link:user-manual.html[The Git User's Manual]
diff --git a/Documentation/gittutorial.txt b/Documentation/gittutorial.txt
index 384972c..2859a21 100644
--- a/Documentation/gittutorial.txt
+++ b/Documentation/gittutorial.txt
@@ -23,9 +23,22 @@ First, note that you can get documentation for a command such as
`git log --graph` with:
------------------------------------------------
+$ git help log
+------------------------------------------------
+
+or:
+
+------------------------------------------------
$ man git-log
------------------------------------------------
+linkgit:git-help[1] has a few more features and is self-documenting
+using:
+
+------------------------------------------------
+$ git help help
+------------------------------------------------
+
It is a good idea to introduce yourself to git with your name and
public email address before doing any operation. The easiest
way to do so is:
@@ -653,6 +666,7 @@ linkgit:gittutorial-2[7],
linkgit:gitcvs-migration[7],
linkgit:gitcore-tutorial[7],
linkgit:gitglossary[7],
+linkgit:git-help[1],
link:everyday.html[Everyday git],
link:user-manual.html[The Git User's Manual]
--
1.6.0.4.617.g621cb
^ permalink raw reply related
* [PATCH 2/3] Documentation: user-manual: add information about "git help" at the beginning
From: Christian Couder @ 2008-11-14 12:27 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
Talking about "git help" is useful because it has a few more
features (like when using it without arguments or with "-a") and
it may work on non unix like platforms.
Signed-off-by: Christian Couder <chriscool@tuxfamily.org>
---
Documentation/user-manual.txt | 18 ++++++++++++++++--
1 files changed, 16 insertions(+), 2 deletions(-)
diff --git a/Documentation/user-manual.txt b/Documentation/user-manual.txt
index 645d752..48f7189 100644
--- a/Documentation/user-manual.txt
+++ b/Documentation/user-manual.txt
@@ -17,13 +17,27 @@ People needing to do actual development will also want to read
Further chapters cover more specialized topics.
-Comprehensive reference documentation is available through the man
-pages. For a command such as "git clone <repo>", just use
+Comprehensive reference documentation is available through either the
+linkgit:git-help[1] command or the man pages. For a command such as
+"git clone <repo>", you can use:
+
+------------------------------------------------
+$ git help clone
+------------------------------------------------
+
+or:
------------------------------------------------
$ man git-clone
------------------------------------------------
+linkgit:git-help[1] has a few more features and is self-documenting
+using:
+
+------------------------------------------------
+$ git help help
+------------------------------------------------
+
See also <<git-quick-start>> for a brief overview of git commands,
without any explanation.
--
1.6.0.4.617.g621cb
^ permalink raw reply related
* [PATCH 1/3] Documentation: fix links to "everyday.html"
From: Christian Couder @ 2008-11-14 12:26 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In some places the links are wrong. They should be:
"link:everyday.html", instead of: "linkgit:everyday[7]".
This patch fixes that.
Signed-off-by: Christian Couder <chriscool@tuxfamily.org>
---
Documentation/gitcore-tutorial.txt | 6 ++++--
Documentation/gitglossary.txt | 6 ++++--
2 files changed, 8 insertions(+), 4 deletions(-)
The purpose of this patch series is to make "git help"
more visible in the tutorials.
"git help" was discussed during the GitTogether'08 and
many people said that "git help" should be improved to
have more newby friendly features. The problem is that
if it is not visible in the first place, there is no
point of improving it.
The first patch in this series is just a link fix.
diff --git a/Documentation/gitcore-tutorial.txt b/Documentation/gitcore-tutorial.txt
index a417e59..61fc5d7 100644
--- a/Documentation/gitcore-tutorial.txt
+++ b/Documentation/gitcore-tutorial.txt
@@ -1690,8 +1690,10 @@ to follow, not easier.
SEE ALSO
--------
-linkgit:gittutorial[7], linkgit:gittutorial-2[7],
-linkgit:everyday[7], linkgit:gitcvs-migration[7],
+linkgit:gittutorial[7],
+linkgit:gittutorial-2[7],
+linkgit:gitcvs-migration[7],
+link:everyday.html[Everyday git],
link:user-manual.html[The Git User's Manual]
GIT
diff --git a/Documentation/gitglossary.txt b/Documentation/gitglossary.txt
index 565719e..d77a45a 100644
--- a/Documentation/gitglossary.txt
+++ b/Documentation/gitglossary.txt
@@ -16,8 +16,10 @@ include::glossary-content.txt[]
SEE ALSO
--------
-linkgit:gittutorial[7], linkgit:gittutorial-2[7],
-linkgit:everyday[7], linkgit:gitcvs-migration[7],
+linkgit:gittutorial[7],
+linkgit:gittutorial-2[7],
+linkgit:gitcvs-migration[7],
+link:everyday.html[Everyday git],
link:user-manual.html[The Git User's Manual]
GIT
--
1.6.0.4.617.g621cb
^ permalink raw reply related
* getting started with git
From: Ivan Senji @ 2008-11-14 10:16 UTC (permalink / raw)
To: git
Hello everyone!
I started using git recently to manage my personal projects and I really
like it. I develop on several different locations and have a little problem
that i couldn't find a way to solve.
On each location that i develop some project and configuration files are
different. But i would like them to be in the repository as a starting point
when checking out a project (example: opening a project on a dfferent OS in
eclipse... eclipse will find an error in the path to jdk and ask me to fix
that error by selecting a different jdk).
How to achieve that these files are in the repository but that any further
changes to them are not commited (or are commited localy but not pushed to a
remote repository)?
Is that even possible?
Thanks!
--
View this message in context: http://www.nabble.com/getting-started-with-git-tp20497802p20497802.html
Sent from the git mailing list archive at Nabble.com.
^ permalink raw reply
* Re: [PATCH 1/9 v4] bisect: add "git bisect replace" subcommand
From: Paolo Bonzini @ 2008-11-14 10:03 UTC (permalink / raw)
To: Christian Couder; +Cc: Junio C Hamano, Johannes Schindelin, git
In-Reply-To: <200811141034.06282.chriscool@tuxfamily.org>
>> users could also set up a few
>> special bisect/set-debug-to-1, bisect/remove-cflags-o2 and so on patches
>> that you could use for purposes other than ensuring known bugs are fixed.
>
> In this case it is similar to Junio's proposal. But I think that for changes
> like set-debug-to-1 and remove-cflags-o2, using the right make command
> should be enough.
Yeah, I couldn't think of a better usecase, but you got the idea.
>> Finally, you could have a [bisect] configuration section with entries
>> like "cherry-pick = BROKEN-SHA1 FIX-SHA1" and "git bisect" would apply
>> FIX-SHA1 automatically if the bisect tip were in BROKEN-SHA1..FIX-SHA1.
>
> Yes, but how do you share this between members of a team?
That's a common problem with stuff that goes in .gitconfig. It does not
belong in the repository, though...
Paolo
^ permalink raw reply
* Re: [PATCH] sha1_file: make sure correct error is propagated
From: Sam Vilain @ 2008-11-14 9:41 UTC (permalink / raw)
To: Francis Galiegue; +Cc: git
In-Reply-To: <200811140844.58746.fge@one2team.com>
On Fri, 2008-11-14 at 08:44 +0100, Francis Galiegue wrote:
> > So, if the mkstemp() fails with EPERM, don't try to create the
> > directory - return straight away.
> Are you sure you didn't mean EACCESS?
Ah, you're right there. Well, maybe this one should be as well:
Subject: sha1_file: accept EACCESS as equivalent to EPERM
This was testing for 'Operation not permitted' rather than any kind
of 'Permission Denied' error; prefer EACCESS.
Signed-off-by: Sam Vilain <sam@vilain.net>
--
Sorry for the inevitable wrapping/whitespace fail :(
diff --git a/sha1_file.c b/sha1_file.c
index 7662330..cd422e6 100644
--- a/sha1_file.c
+++ b/sha1_file.c
@@ -2231,7 +2231,7 @@ static int create_tmpfile(char *buffer, size_t
bufsiz, const char *filename)
memcpy(buffer, filename, dirlen);
strcpy(buffer + dirlen, "tmp_obj_XXXXXX");
fd = mkstemp(buffer);
- if (fd < 0 && dirlen && (errno != EPERM)) {
+ if (fd < 0 && dirlen && (errno != EACCESS)) {
/* Make sure the directory exists */
memcpy(buffer, filename, dirlen);
buffer[dirlen-1] = 0;
@@ -2257,7 +2257,7 @@ static int write_loose_object(const unsigned char
*sha1, char *hdr, int hdrlen,
filename = sha1_file_name(sha1);
fd = create_tmpfile(tmpfile, sizeof(tmpfile), filename);
if (fd < 0) {
- if (errno == EPERM)
+ if (errno == EACCESS || errno == EPERM)
return error("insufficient permission for adding an object to
repository database %s\n", get_object_directory());
else
return error("unable to create temporary sha1 filename %s: %s\n",
tmpfile, strerror(errno));
^ permalink raw reply related
* Re: [PATCH 1/9 v4] bisect: add "git bisect replace" subcommand
From: Christian Couder @ 2008-11-14 9:34 UTC (permalink / raw)
To: Paolo Bonzini; +Cc: Junio C Hamano, Johannes Schindelin, git
In-Reply-To: <491C58A3.2000609@gnu.org>
Le jeudi 13 novembre 2008, Paolo Bonzini a écrit :
> > Of course it also depends on how often people use "git bisect", but it
> > seems that there are people out there bisecting very frequently and
> > that these people care very much about bisectability of the tree.
>
> What about "git bisect cherry-pick COMMIT" which would do a "cherry-pick
> -n" of COMMIT after every bisection unless COMMIT is in the ancestry of
> the current revision? So if you have to bisect between A and B, and you
> know that a bug present between A and B was fixed by C, you could do
>
> git bisect good A
> git bisect bad B
> git bisect cherry-pick C
>
> This would subsume Junio's proposal:
Yes, it looks better than Junio's, except when there is no existing commit
that perfectly works.
> users could also set up a few
> special bisect/set-debug-to-1, bisect/remove-cflags-o2 and so on patches
> that you could use for purposes other than ensuring known bugs are fixed.
In this case it is similar to Junio's proposal. But I think that for changes
like set-debug-to-1 and remove-cflags-o2, using the right make command
should be enough.
> Finally, you could have a [bisect] configuration section with entries
> like "cherry-pick = BROKEN-SHA1 FIX-SHA1" and "git bisect" would apply
> FIX-SHA1 automatically if the bisect tip were in BROKEN-SHA1..FIX-SHA1.
Yes, but how do you share this between members of a team?
Your proposal and Junio's proposal also don't use real sha1 names for
commits that are tested, so it's more difficult to talk about them, share
them, use them, ...
Regards,
Christian.
^ permalink raw reply
* Re: [BUG] fatal error during merge
From: Anders Melchiorsen @ 2008-11-14 9:16 UTC (permalink / raw)
To: Alex Riesen
Cc: Junio C Hamano, SZEDER Gábor, Samuel Tardieu, git,
Johannes Schindelin
In-Reply-To: <20081114071636.GA4013@blimp.localdomain>
Alex Riesen wrote:
> And the patch isn't enough: the file Anders noticed missing is in the
> index (correctly) but somehow removed from worktree. Which is maybe
> because it _still_ was a rename: 99% similarity. Well, just
> "yes | tail -nNN" usually producess very similar data :)
Maybe reducing the example all the way down to "touch" lost the implicit
information that, indeed, it has to be a rename for this to fail.
Anders.
^ permalink raw reply
* Re: [PATCH v2 09/11] gitweb: git_is_head_detached() function
From: Giuseppe Bilotta @ 2008-11-14 8:52 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Jakub Narebski, Petr Baudis
In-Reply-To: <7vk5b6dd3t.fsf@gitster.siamese.dyndns.org>
On Fri, Nov 14, 2008 at 7:40 AM, Junio C Hamano <gitster@pobox.com> wrote:
> Giuseppe Bilotta <giuseppe.bilotta@gmail.com> writes:
>
>> The function checks if the HEAD for the current project is detached by
>> checking if 'git branch' returns "* (no branch)"
>
> This one looks more like "oops, the way detached HEAD is detected in 08 is
> sucky, let's cover it up by introducing a function as an afterthought."
Half and half: it _is_ an afterthought, and although it's sucky that's
not the reason why I decided to refactor it 8-)
> Have a patch that introduces git_is_head_detached() first, and then use
> that function to implement the feature. I personally think the user (that
> is, 08/11) is small and isolated enough that these two can be a single
> patch.
Will do. I did some patch squashing while preparing this set, but I
forgot to do this one.
>> +# check if current HEAD is detached
>> +sub git_is_head_detached {
>> + my @x = (git_cmd(), 'branch');
>> + my @ret = split("\n", qx(@x));
>> + return 0 + grep { /^\* \(no branch\)$/ } @ret;
>> +}
>
> Do not read from Porcelain in scripts.
>
> "git symbolic-ref HEAD" should error out when your HEAD is detached, and
> will return refs/heads/frotz when you are on frotz branch.
Eh, I was, like, 100% sure this was the wrong way to do it, but I
didn't have any idea on how to do it using the plumbing. Thanks, I'll
look into that.
> But realistically speaking, what does it mean to have a detached HEAD in a
> repository published via gitweb? First of all these things are supposed
> to be bare and there would be no checkout.
You know what's funny, when I first started working on the 'show
remote branches in gitweb' patchset, you had a similar objection, but
as you yourself pointed out
> But obviously people use gitweb/instaweb as a way to view their
> own live repository, and I think it makes sense to show and
> support remotes/ in such a case. It also would make sense to
> support detached HEAD there as well.
http://kerneltrap.org/mailarchive/git/2007/8/30/256411
and that's exactly the reason why I added the part about the detached head 8-)
I have been thinking about making this detached HEAD thing an
additional option, but it _really_ seemed like overkill.
--
Giuseppe "Oblomov" Bilotta
^ permalink raw reply
* Re: [PATCH] sha1_file: make sure correct error is propagated
From: Francis Galiegue @ 2008-11-14 7:44 UTC (permalink / raw)
To: Sam Vilain; +Cc: git
In-Reply-To: <1226647174-15844-1-git-send-email-sam@vilain.net>
Le vendredi 14 novembre 2008, Sam Vilain a écrit :
> From: Sam Vilain <samv@maia.lan>
>
> In the case that a object directory exists, but is not writable, the
> code path that tries to create it is followed and the returned errno
> and path that of the directory tried to be created. The resultant
> error message is confusing.
>
> So, if the mkstemp() fails with EPERM, don't try to create the
> directory - return straight away.
>
Are you sure you didn't mean EACCESS?
--
Francis Galiegue
ONE2TEAM
Ingénieur système
Mob : +33 (0) 6 83 87 78 75
Tel : +33 (0) 1 78 94 55 52
fge@one2team.com
40 avenue Raymond Poincaré
75116 Paris
^ permalink raw reply
* [PATCH] sha1_file: make sure correct error is propagated
From: Sam Vilain @ 2008-11-14 7:19 UTC (permalink / raw)
To: git; +Cc: Sam Vilain, Sam Vilain
From: Sam Vilain <samv@maia.lan>
In the case that a object directory exists, but is not writable, the
code path that tries to create it is followed and the returned errno
and path that of the directory tried to be created. The resultant
error message is confusing.
So, if the mkstemp() fails with EPERM, don't try to create the
directory - return straight away.
Signed-off-by: Sam Vilain <sam@vilain.net>
---
sha1_file.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/sha1_file.c b/sha1_file.c
index ab2b520..7662330 100644
--- a/sha1_file.c
+++ b/sha1_file.c
@@ -2231,7 +2231,7 @@ static int create_tmpfile(char *buffer, size_t bufsiz, const char *filename)
memcpy(buffer, filename, dirlen);
strcpy(buffer + dirlen, "tmp_obj_XXXXXX");
fd = mkstemp(buffer);
- if (fd < 0 && dirlen) {
+ if (fd < 0 && dirlen && (errno != EPERM)) {
/* Make sure the directory exists */
memcpy(buffer, filename, dirlen);
buffer[dirlen-1] = 0;
--
debian.1.5.6.1
^ permalink raw reply related
* Re: [BUG] fatal error during merge
From: Alex Riesen @ 2008-11-14 7:16 UTC (permalink / raw)
To: Junio C Hamano
Cc: Anders Melchiorsen, SZEDER Gábor, Samuel Tardieu, git,
Johannes Schindelin
In-Reply-To: <7vfxlvf8up.fsf@gitster.siamese.dyndns.org>
Junio C Hamano, Fri, Nov 14, 2008 01:29:34 +0100:
> "Anders Melchiorsen" <mail@cup.kalibalik.dk> writes:
>
> > Your patch got rid of the errors and it commits the merged tree. But the
> > working tree is not updated correctly, so the moved file disappears.
>
> Isn't this a long known breakage of D/F conflict check logic in
> merge-recursive backend?
Could be, but there is no conflicting entries in the merged branches.
All file names are different and the D/F transition happens completely
on one branch.
And the patch isn't enough: the file Anders noticed missing is in the
index (correctly) but somehow removed from worktree. Which is maybe
because it _still_ was a rename: 99% similarity. Well, just
"yes | tail -nNN" usually producess very similar data :)
Still broken, of course...
^ permalink raw reply
* Re: [PATCH 3/3] Add -k/--keep-going option to mergetool
From: Jeff King @ 2008-11-14 6:47 UTC (permalink / raw)
To: Charles Bailey
Cc: Junio C Hamano, git, Andreas Ericsson, Theodore Ts'o,
William Pursell
In-Reply-To: <1226580075-29289-4-git-send-email-charles@hashpling.org>
On Thu, Nov 13, 2008 at 12:41:15PM +0000, Charles Bailey wrote:
> This option stops git mergetool from aborting at the first failed merge.
> This allows some additional use patterns. Merge conflicts can now be
> previewed one at time and merges can also be skipped so that they can be
> performed in a later pass.
>
> There is also a mergetool.keepGoing configuration variable covering the
> same behaviour.
I think this series addresses the questions I remember from the first
posting, and it looks sane overall to me. My only two complaints are:
> Documentation/config.txt | 4 +++
> Documentation/git-mergetool.txt | 12 +++++++++-
> git-mergetool.sh | 46 ++++++++++++++++++++++++++++++--------
> 3 files changed, 51 insertions(+), 11 deletions(-)
This patch in particular changes some of the innards of mergetool, and
while the changes look good to me via reading, I would feel even more
comfortable if there were some tests (it looks like your previous t7610
gives at least a basic sanity check, but it might be nice to test to
make sure we detect merge failures, too).
> - return
> + return 0
> [...]
> - return
> + return 0
> [...]
> - exit 1
> + return 1
> [...]
> - exit 1
> + return 1
> [...]
> - exit 1
> + cleanup_temp_files
> + return 1
One of these is not like the others. Is there a reason to add a
cleanup_temp_files here (and if so, should it be noted in the commit
message, and/or be in a separate commit?).
-Peff
^ permalink raw reply
* Re: [PATCH v2 09/11] gitweb: git_is_head_detached() function
From: Junio C Hamano @ 2008-11-14 6:40 UTC (permalink / raw)
To: Giuseppe Bilotta; +Cc: git, Jakub Narebski, Petr Baudis
In-Reply-To: <1226616555-24503-10-git-send-email-giuseppe.bilotta@gmail.com>
Giuseppe Bilotta <giuseppe.bilotta@gmail.com> writes:
> The function checks if the HEAD for the current project is detached by
> checking if 'git branch' returns "* (no branch)"
This one looks more like "oops, the way detached HEAD is detected in 08 is
sucky, let's cover it up by introducing a function as an afterthought."
Have a patch that introduces git_is_head_detached() first, and then use
that function to implement the feature. I personally think the user (that
is, 08/11) is small and isolated enough that these two can be a single
patch.
> +# check if current HEAD is detached
> +sub git_is_head_detached {
> + my @x = (git_cmd(), 'branch');
> + my @ret = split("\n", qx(@x));
> + return 0 + grep { /^\* \(no branch\)$/ } @ret;
> +}
Do not read from Porcelain in scripts.
"git symbolic-ref HEAD" should error out when your HEAD is detached, and
will return refs/heads/frotz when you are on frotz branch.
But realistically speaking, what does it mean to have a detached HEAD in a
repository published via gitweb? First of all these things are supposed
to be bare and there would be no checkout.
^ 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