* Re: Bug: UTF-16, UCS-4 and non-existing encodings for git log result in incorrect behavior
From: Johannes Schindelin @ 2008-11-12 14:22 UTC (permalink / raw)
To: Constantine Plotnikov; +Cc: git
In-Reply-To: <85647ef50811120532h778769ddx69f0b111dbad359a@mail.gmail.com>
Hi,
On Wed, 12 Nov 2008, Constantine Plotnikov wrote:
> If UTF-16[BE|LE] or UCS-4[BE|LE] encodings are used with git log, the
> git completes successfully but commit messages and author information
> are not shown. I suggest that git should fail with fatal error if such
> zero producing encoding is used.
>
> If the incorrect encoding name is used, the git log does not perform any
> re-encoding, but just display commits in their native encoding. I
> suggest that git should fail with fatal error in this case as well.
Have you set the correct encoding with i18n.commitEncoding? If not, you
should not be surprised: Git's default encoding is UTF-8, and that fact is
well documented, AFAICT.
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH 1/9 v4] bisect: add "git bisect replace" subcommand
From: Christian Couder @ 2008-11-12 14:15 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Johannes Schindelin, git
In-Reply-To: <7v8wrpyhhs.fsf@gitster.siamese.dyndns.org>
Le mercredi 12 novembre 2008, Junio C Hamano a écrit :
> Christian Couder <chriscool@tuxfamily.org> writes:
> > This subcommand should be used when you have a branch or a part of a
> > branch that isn't easily bisectable because of a bug that has been
> > fixed latter.
>
> While I acknowledge your effort to make bisect easier to use, I do
> not think this is going in the right direction, from the point of view of
> the workflow.
>
> I do agree that the issue it tries to solve is a problem in real life.
> When you want to hunt for a bug, it is certainly possible that your tests
> fail for a bug that is unrelated to what you are hunting for for a range
> of commits. Borrowing from your picture:
>
> ...--O--A--X1--X2--...--Xn--B--...
>
> non of the commit marked as Xi may not be testable.
>
> But at that point, will you really spend time to rebuild history between
> A and B by fixing an unrelated bug that hinders your bisect, so that you
> can have a parallel history that is bisectable? I doubt anybody would.
I think kernel developers and perhaps others do that somehow. I mean, there
is the following text in the git-bisect(1) documentation:
"
You may often find that during bisect you want to have near-constant tweaks
(e.g., s/#define DEBUG 0/#define DEBUG 1/ in a header file, or "revision
that does not have this commit needs this patch applied to work around
other problem this bisection is not interested in") applied to the revision
being tested.
To cope with such a situation, after the inner git-bisect finds the next
revision to test, with the "run" script, you can apply that tweak before
compiling, run the real test, and after the test decides if the revision
(possibly with the needed tweaks) passed the test, rewind the tree to the
pristine state. Finally the "run" script can exit with the status of the
real test to let the "git bisect run" command loop to determine the
outcome.
"
So we suggest that people patch at bisect time in case of problems. But I
think creating a parallel branch should be better in the long run, because
you can easily keep the work you did to make things easier to bisect and
you can easily share it with other people working with you. Also using "git
rebase -i" to create the fixed branch might be easier and more reliable
than trying to patch at each step.
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.
> Even if we assume that somebody wants to adopt the workflow to first fix
> an unrelated bug (that may be totally uninteresting for the purpose of
> solving the original issue he set out to figure out) to rewrite the
> history, what he first needs to do is to find out what part of the
> history to rewrite.
Not necessarily. People may decide to adopt a workflow that consists in
creating a fixed branch as soon as they know about a fix that may prevent
their code from being tested. This way they know that they will be able to
bisect at each commit of their full history.
> IOW, he needs to know A and B (and in general, the
> history is not even linear). Maybe he guesses what A and B is. But for
> one thing, after making the guess, he would certainly test A and B to see
> if the original issue exists at these commits. The sequence of commits
> Xi become irrelevant if A turns out to be bad or B turns out to be good.
Yes that's possible. But in some cases people might find it simpler (for
example because it might take a long time or a lot of manpower to fully
test one commit) to just create a fixed branch as soon as they find
something that prevents testing which might happen during a bisection or
not.
> And if A is good and B is bad, then the _original bug_ is in the very
> sequence of Xi you are going to rewrite. By the time you made a
> rewritten history with sequence of commits Yi to be grafted like this:
>
>
> C--Y1--Y2--...--Yn
> /
> ...--O--A--X1--X2--...--Xn--B--...
>
> to make it bisectable, it is very likely that you would have already seen
> the original bug.
I am not sure I understand/agree with that, because I think it may be quite
easy to make such a fixed branch, especially if the commit message of B is
a good one like "fix build problem on platform 'foo' introduced by A".
> In such a case where you need to figure out what an unrelated bug is, and
> which commit A and B are involved while bisecting, I think you are much
> better off using bisect skip, as Johannes mentioned earlier.
Even if there was a bisect skip command that could skip a range of commit,
you might find in the end that the original bug you are looking for was
introduced in a range you skipped.
> On the other hand, if you already have a well-known bug that was
> introduced at A whose fix at B is also very well-known, you would not
> even need a separate "bisect replace" command nor replace_parents()
> machinery only for the purpose of bisection, would you? In such a case I
> think you can just use a usual graft.
I don't know very much usual grafts but I think that the problem is that
usual grafts rewrite history for (nearly) all the commands.
It seems to me that with usual grafts for this purpose, people may for
example have problems refering to some commits, because it might happen
that the sha1 of a commit might be in a branch that has been grafted out
the current branch for easier bisecting.
For example in my patch series, the 2 last patches add a --no-replace option
to "git bisect", so that it's easy not to use "bisect-replace" branches if
one does not want too. And I fear that if graft use is generalized, it may
be necessary to add such options to many other commands (instead of just
one). And even then, people may want to use some of the grafts but not
others (for example grafts to see some very old commits imported after the
initial repo was created but not grafts to fix history) for some purposes
and a different set (for example all the grafts) for other purposes (like
bisecting).
> I have a separate idea make 'grafts' easier on object transfer, that is
> somewhat related to this one, by the way. Instead of making the grafts
> completely a local matter as we do now, we can reserve refs/replace/
> namespace, and record a new commit object to replace an existing commit
> whose object name is $sha1 as refs/replace/$sha1. We make almost all the
> commands except object enumeration (fsck, receive-pack, send-pack, prune,
> etc. Roughly speaking, anything that involves "rev-list --objects")
> honor this commit replacement, so that any time you ask for commit $sha1,
> the object layer gives you the replacement commit object back. In this
> way, you can clone or fetch from such a repository (along with refs in
> refs/replace/ hierarchy) and fsck/prune won't lose the original parents
> (because it does not see replacements). Things like paranoid update hook
> needs to become very careful about refs/replace/ for security reasons,
> but I think this would make the grafts much easier to use.
I agree that it would make grafts much easier to use (and would be very
security sensitive).
But except for grafts used to connect to old histories, do you know many
special commands other than "git bisect" that may use the refs/replace/
namespace?
I mean, it may be a good idea to use a special namespace with sha1 named
refs like "refs/xxx/$sha1" instead of branches named
like "bisect-replace-SHA1", but I think that it would be better if grafts
used to fix history for bisecting purpose would be separated from other
kind of grafts, for example perhaps in "refs/replace/bisect/$sha1".
Regards,
Christian.
^ permalink raw reply
* Re: Newbie questions regarding jgit
From: Farrukh Najmi @ 2008-11-12 14:05 UTC (permalink / raw)
To: Jonas Fonseca; +Cc: git
In-Reply-To: <2c6b72b30811111337v2fe23c75v25251838f721a007@mail.gmail.com>
Jonas Fonseca wrote:
...
>
>> Now I am wondering where to begin to learn how to do the equivalent of the
>> following commands via the gjit Java API:
>>
>> * git add /file/
>> * git rm /file/
>> * git mv /file
>> * Whatever is the git way to get a specific version of a file
>>
>
> JGit currently has two APIs for working with the index, which will
> allow you to add, remove and move data around in the tree. In nbgit I
> ended up using GitIndex, which I found easier to figure out. As I
> understand it, in the long run you want to use the DirCache API, but
> it is still a work in progress.
>
I am happy to use GitIndex now and switch to DirCache API later when it
is ready.
Can I please get some pseudo-code fragments on how to do the use cases I
identified above?
The javadoc is still not obvious to me.
>
>> I am hoping that there aremore docs, samples, tutorials etc. somewhere that
>> I am missing. Thanks for any help you can provide. Some pointers or code
>> fragments would be terrific.
>>
>
> I started working on a tutorial for JGit, but didn't get very far so
> it mostly consists of stub pages.
>
> - http://code.google.com/docreader/#p=egit&s=egit&t=JGitTutorial
>
> I have been working on moving the tutorial to maven project before
> starting to write the more code heavy topics. This would make it
> possible to include code snippets in the tutorial, while also allowing
> to compile and test the examples.
>
The wiki is an awesome resource even in its current state. Thank you.
I would be glad to help contribute improvements to wiki if you give me
write privilege. What I could do is take the help I get from the list and
then update wiki carefully as appropriate if you want me to help.
Thanks again to all of you for helping get me bootstrapped with gjit and
git.
--
Regards,
Farrukh Najmi
Web: http://www.wellfleetsoftware.com
^ permalink raw reply
* Bug: UTF-16, UCS-4 and non-existing encodings for git log result in incorrect behavior
From: Constantine Plotnikov @ 2008-11-12 13:32 UTC (permalink / raw)
To: git
If UTF-16[BE|LE] or UCS-4[BE|LE] encodings are used with git log, the
git completes successfully but commit messages and author information
are not shown. I suggest that git should fail with fatal error if such
zero producing encoding is used.
If the incorrect encoding name is used, the git log does not perform
any re-encoding, but just display commits in their native encoding. I
suggest that git should fail with fatal error in this case as well.
Regards,
Constantine
^ permalink raw reply
* Re: Possible bug: "git log" ignores "--encoding=UTF-8" option if --pretty=format:%e%n%s%n is used
From: Constantine Plotnikov @ 2008-11-12 13:08 UTC (permalink / raw)
To: Jeff King; +Cc: git
In-Reply-To: <20081112112654.GA20640@coredump.intra.peff.net>
On Wed, Nov 12, 2008 at 2:26 PM, Jeff King <peff@peff.net> wrote:
> [re-adding list to the cc]
>
> On Wed, Nov 12, 2008 at 02:11:46PM +0300, Constantine Plotnikov wrote:
>
>> > I don't actually use any encodings except UTF-8, so maybe there is some
>> > subtle reason not to do so that I don't understand, but I would have
>> > expected all of the format placeholders to respect any --encoding
>> > parameter.
>> >
>> Even if this is the bug, it would be better to leave the old behavior
>> for backward compatibility reasons and introduce new placeholders.
>> Currently tools have to decode messages according to the commit
>> encoding, and changing behavior of options will break these tools
>> that have implemented workaround for this problem.
>
> Are there such tools? I assumed they would have complained about this as
> a bug before writing their own encoding conversion tools. And this is,
> AFAIK, the first bug report.
>
> I don't mind playing it safe to avoid breaking other people's tools, but
> I'm also not excited about adding a second, "respect encoding" version
> of many placeholders (and it's not just %s and %b; I think you would
> need author and committer names and emails, too).
>
The reason for the request was that for IDE integration (I'm working
on the IDEA plugin), we need to work with past versions of the git as
well. However we could write that this is known git bug that will be
fixed in some future version and just to show incorrect data in
history view when non-UTF-8 encoding is used for a while. I hope that
non-UTF-8 encoding for commits is indeed a rare case, so users will
not complain much.
BTW for some reason --pretty=raw is affected by encoding option on the
command line. And this is a bit surprising as from description of the
raw format it looks like it should not be affected, because the
re-encoded commit is not "the entire commit exactly as stored in the
commit object". Possibly the man page should be updated to clarify
this.
Regards,
Constantine
^ permalink raw reply
* Re: [PATCH 2/2] Cached the git configuration, which is now noticibly faster on windows.
From: Arafangion @ 2008-11-12 11:54 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Simon Hausmann, Han-Wen Nienhuys, git
In-Reply-To: <7vzlk5u5rq.fsf@gitster.siamese.dyndns.org>
Thanks for making those patches more visible, however I do feel the need
to mention one thing I expected to have been raised during patch review:
1) The memory optimisation may cause significant slowdown, which wasn't
a big issue on my machine, perhaps because I'm _still_ trying to get it
to work on my particular repo. (It's still using too much memory), and I
have a very fast machine. It switches git-p4 from a RAM-intensive app
to a somewhat-less-RAM-intensive app at the cost of also becomming much
more CPU-intensive.
On Tue, 2008-11-11 at 16:50 -0800, Junio C Hamano wrote:
> Simon Hausmann <simon@lst.de> writes:
>
> > On Sunday 09 November 2008 Junio C Hamano, wrote:
> >> These are patches to fast-import/git-p4, which you two seem to in charge
> >> of.
> >>
> >> From: John Chapman <thestar@fussycoder.id.au>
> >> Subject: [PATCH 1/2] Added support for purged files and also optimised
> >> memory usage. Date: Sat, 8 Nov 2008 14:22:48 +1100
> >> Message-Id: <1226114569-8506-1-git-send-email-thestar@fussycoder.id.au>
> >>
> >> From: John Chapman <thestar@fussycoder.id.au>
> >> Subject: [PATCH 2/2] Cached the git configuration, which is now
> >> noticibly faster on windows. Date: Sat, 8 Nov 2008 14:22:49 +1100
> >> Message-Id: <1226114569-8506-2-git-send-email-thestar@fussycoder.id.au>
> >>
> >> It was unfortunately not immediately obvious from the Subject: line what
> >> these patches are about, and I am guessing you missed them because of that.
> >
> > Ack on both patches. The second one could be done better, as suggested
> > in the follow-ups, but both are clearly an improvement :)
>
> Thanks, both of you. Will apply.
>
^ permalink raw reply
* Re: Newbie questions regarding jgit
From: Farrukh Najmi @ 2008-11-12 12:51 UTC (permalink / raw)
To: git
In-Reply-To: <2c6b72b30811111401i3c995889n54407243a1072599@mail.gmail.com>
The jgit team, rocks! You guys are simply awesome in your
responsiveness. Thanks for a great project.
Please let me know if I can help with any maven related issues. Here is
a couple of
links I use to evangelize use of maven in OS projects:
Why Maven Rocks:
<http://farrukhnajmi.blogspot.com/2008/02/why-maven-rocks-in-beginning-there-was.html>
Why Maven - Wiki Page:
<http://ebxmlrr.wiki.sourceforge.net/whymaven>
Here are the main resources I use as reference for maven:
Maven Official Docs:
<http://maven.apache.org/guides/index.html>
Better Builds With Maven:
<http://www.topazproject.org/trac/attachment/wiki/MavenInfo/BetterBuildsWithMaven.pdf?format=raw>
I think it is great that the project supports maven at least partially
today.
I would suggest the project consider maven for all its
build/configuration management at some point in future.
It takes a little learning curve initially (most for dev team members
not users) but pays off handsomely very quickly.
Jonas Fonseca wrote:
...
> On Tue, Nov 11, 2008 at 22:44, Shawn O. Pearce <spearce@spearce.org> wrote:
>
>> Jonas Fonseca <jonas.fonseca@gmail.com> wrote:
>>
>>> I would also like to have a public available maven repository for
>>> JGit. If Shawn or Robin acks, I can look into hosting one in the SVN
>>> area of the Google Code project page. Given the lack of a real release
>>> cycle it probably only makes sense to have a snapshot repository.
>>>
...
--
Regards,
Farrukh Najmi
Web: http://www.wellfleetsoftware.com
^ permalink raw reply
* Re: Stgit and refresh-temp
From: Karl Hasselström @ 2008-11-12 12:46 UTC (permalink / raw)
To: Catalin Marinas; +Cc: Jon Smirl, Git Mailing List
In-Reply-To: <20081112080103.GA25454@diana.vm.bytemark.co.uk>
On 2008-11-12 09:01:03 +0100, Karl Hasselström wrote:
> On 2008-11-11 17:59:02 +0000, Catalin Marinas wrote:
>
> > 2008/11/7 Karl Hasselström <kha@treskal.com>:
> >
> > > On 2008-11-04 08:37:24 -0500, Jon Smirl wrote:
> > >
> > > > I hit a case when refreshing a buried patch that needed a
> > > > merge conflict sorted out. I'm unable to recover out of the
> > > > state.
> > >
> > > Hmm, so what you're saying is basically that you did something
> > > with "stg refresh -p" that caused a merge conflict, and that
> > > messed things up so that you needed to run "stg repair". Is that
> > > right?
> >
> > Could be related to this - if I run 'stg goto some-patch' and it
> > fails with a conflict, the HEAD points to the previous patch
> > though the stack has the conflicting patch as empty (which is
> > normal) and the conflicts in the index. Anything after that says
> > HEAD and top not equal and 'stg repair' is needed.
>
> Ah, yes, that could definitely be the same problem, since those two
> things end up calling the same functions to handle the conflict.
OK, I just got this error with goto. :-)
FWIW, the convenient way to recover is
$ git reset --soft $(stg id $(stg top))
This will point your branch head to the correct commit. stg repair
would pop the top patch, which is much less convenient in this case.
--
Karl Hasselström, kha@treskal.com
www.treskal.com/kalle
^ permalink raw reply
* Re: Possible bug: "git log" ignores "--encoding=UTF-8" option if --pretty=format:%e%n%s%n is used
From: Jeff King @ 2008-11-12 11:26 UTC (permalink / raw)
To: Constantine Plotnikov; +Cc: git
In-Reply-To: <85647ef50811120311q7bc5451x7c084fd2a7864177@mail.gmail.com>
[re-adding list to the cc]
On Wed, Nov 12, 2008 at 02:11:46PM +0300, Constantine Plotnikov wrote:
> > I don't actually use any encodings except UTF-8, so maybe there is some
> > subtle reason not to do so that I don't understand, but I would have
> > expected all of the format placeholders to respect any --encoding
> > parameter.
> >
> Even if this is the bug, it would be better to leave the old behavior
> for backward compatibility reasons and introduce new placeholders.
> Currently tools have to decode messages according to the commit
> encoding, and changing behavior of options will break these tools
> that have implemented workaround for this problem.
Are there such tools? I assumed they would have complained about this as
a bug before writing their own encoding conversion tools. And this is,
AFAIK, the first bug report.
I don't mind playing it safe to avoid breaking other people's tools, but
I'm also not excited about adding a second, "respect encoding" version
of many placeholders (and it's not just %s and %b; I think you would
need author and committer names and emails, too).
-Peff
^ permalink raw reply
* Re: [PATCH] git-diff: Add --staged as a synonym for --cached.
From: Jeff King @ 2008-11-12 11:06 UTC (permalink / raw)
To: Johannes Schindelin
Cc: Avery Pennarun, Junio C Hamano, Björn Steinbrink,
David Symonds, git, Stephan Beyer
In-Reply-To: <alpine.DEB.1.00.0811121205100.30769@pacific.mpi-cbg.de>
On Wed, Nov 12, 2008 at 12:10:57PM +0100, Johannes Schindelin wrote:
> Just in case anybody thought about creating tree objects on the fly and
> use their SHA-1s: that won't fly, as you can have unmerged entries in the
> index. So STAGED.. is a _fundamentally_ different thing from HEAD^..
I thought about that at first, too, but the working tree is even more
painful. You would have to hash every changed file on the filesystem to
create the tree object.
-Peff
^ permalink raw reply
* Re: [PATCH] git-diff: Add --staged as a synonym for --cached.
From: Johannes Schindelin @ 2008-11-12 11:10 UTC (permalink / raw)
To: Jeff King
Cc: Avery Pennarun, Junio C Hamano, Björn Steinbrink,
David Symonds, git, Stephan Beyer
In-Reply-To: <20081112083353.GB3817@coredump.intra.peff.net>
Hi,
On Wed, 12 Nov 2008, Jeff King wrote:
> On Mon, Nov 10, 2008 at 11:04:42PM -0500, Avery Pennarun wrote:
>
> > Speaking just for myself, I would find this all a lot less confusing
> > if "staged" were a refspec of some sort, not an option at all.
> >
> > git diff HEAD..STAGED
> > git diff STAGED..WORKTREE
> > git grep pattern STAGED HEAD sillybranch WORKTREE ^ignorebranch --
> > path/to/files
>
> I agree that such a thing is reasonably intuitive. I have thought about
> "magic" refspecs before; my local git has an "EMPTY" refspec which
> points to the empty tree for diffing. However, that was trivial to
> implement (since it turns into a sha1), and yours is very hard (since
> you will have to pass these "pretend" objects around).
>
> So I think it is a neat idea, but I am not volunteering to work on it.
> :)
Just in case anybody thought about creating tree objects on the fly and
use their SHA-1s: that won't fly, as you can have unmerged entries in the
index. So STAGED.. is a _fundamentally_ different thing from HEAD^..
Maybe we could play tricks with a special staged_commit (pretending to be
a commit with SHA-1 000000... so that git log STAGED.. would do the same
as plain git log, the rationale being that STAGED is no commit, so ^STAGED
should be a nop).
"git diff" would then have some special handling for the case that there
are exactly two revs, exactly one of them negative, and exactly one of
them being the staged_commit, passing off to the respective diff backends.
Ciao,
Dscho
^ permalink raw reply
* [PATCH] Doc: Add a simplified help on top of the "History Simplification"
From: Santi Béjar @ 2008-11-12 10:51 UTC (permalink / raw)
To: git; +Cc: Junio C Hamano, Nanako Shiraishi
Signed-off-by: Santi Béjar <santi@agolina.net>
---
Hi,
This is conceptually on top of:
[PATCH 2/2] Document "git log --simplify-by-decoration"
from Nanako. I do not touch the detailed help, I only add a simplified one at the top.
Santi
Documentation/rev-list-options.txt | 48 ++++++++++++++++++++++++++++++++++-
1 files changed, 46 insertions(+), 2 deletions(-)
diff --git a/Documentation/rev-list-options.txt b/Documentation/rev-list-options.txt
index 68a253f..8adce65 100644
--- a/Documentation/rev-list-options.txt
+++ b/Documentation/rev-list-options.txt
@@ -285,8 +285,52 @@ See also linkgit:git-reflog[1].
History Simplification
~~~~~~~~~~~~~~~~~~~~~~
-When optional paths are given, 'git rev-list' simplifies commits with
-various strategies, according to the options you have selected.
+Sometimes you are only interested in part of the history, for example the
+commits modifying a particular <paths>. But there are two parts of
+'History Simplification', one part is selecting the commits and the other
+is how to do it, as there are various strategies to simplify the history.
+
+The following options select the commits to be shown:
+
+<paths>::
+
+ Commits modifying the given <paths> are selected.
+
+--simplify-by-decoration::
+
+ Commits that are referred by some branch or tag are selected.
+
+Note that extra commits can be shown to give a meaningful history.
+
+The following options affect the way the simplification is performed:
+
+Default mode::
+
+ Simplifies the history to the simplest history explaining the
+ final state of the tree. Simplest because it prunes some side
+ branches if the end result is the same (i.e. merging branches
+ with the same content)
+
+--full-history::
+
+ As the default mode but does not prune some history.
+
+--dense::
+
+ Only the selected commits are shown, plus some to have a
+ meaningful history.
+
+--sparse::
+
+ All commits in the simplified history are shown.
+
+--simplify-merges::
+
+ Additional option to '--full-history' to remove some needless
+ merges from the resulting history, as there are no selected
+ commits contributing to this merge.
+
+A more detailed explanation follows.
Suppose you specified `foo` as the <paths>. We shall call commits
that modify `foo` !TREESAME, and the rest TREESAME. (In a diff
--
1.6.0.rc1.27.g9b6bf
^ permalink raw reply related
* Re: Possible bug: "git log" ignores "--encoding=UTF-8" option if --pretty=format:%e%n%s%n is used
From: Jeff King @ 2008-11-12 10:43 UTC (permalink / raw)
To: Constantine Plotnikov; +Cc: git
In-Reply-To: <85647ef50811111112o5449c12elfc571e46e607cfd0@mail.gmail.com>
On Tue, Nov 11, 2008 at 10:12:46PM +0300, Constantine Plotnikov wrote:
> is encoded using Windows-1251 and the second one using UTF-8. However
> in the description of the %s %b options nothing is said about which
> encoding is used and implied behavior is that they are affected by
> --encoding option.
>
> I suggest documenting that the placeholders %s and %b use native
> commit encoding and introducing the placeholders %S and %B options
> that use encoding specified on the command line or the default log
> encoding.
I don't actually use any encodings except UTF-8, so maybe there is some
subtle reason not to do so that I don't understand, but I would have
expected all of the format placeholders to respect any --encoding
parameter.
If that is the desired behavior, this should not be too hard to make a
patch for:
1. in pretty_print_commit, move the code path for userformat to just
after the re-encoding
2. pass the re-encoded buffer to format_commit_message, where it will
be put into the context struct
3. use the re-encoded buffer in parse_commit_header
Maybe it would make a good exercise for somebody who wants to dig into
git a little deeper? Volunteers?
> I also suggest adding %g and %G placeholders (%m placeholder is
> already occupied) that print the entire commit message instead of just
> the subject or the body. Currently the tools have to join the entire
> message from two parts when they are just interested in the entire
> message.
This actually annoyed me earlier today. What got me was that '%s%n%n%b'
doesn't necessarily give you the exact commit message; if it's a
one-liner (i.e., body is blank), then you end up with an extra newline.
Again, this should be a pretty easy exercise to add. Volunteers?
-Peff
^ permalink raw reply
* Re: [PATCH (GITK)] gitk: Fix transient windows on Win32 and MacOS.
From: Alexander Gavrilov @ 2008-11-12 10:36 UTC (permalink / raw)
To: Johannes Sixt; +Cc: Paul Mackerras, git
In-Reply-To: <491A9398.1060100@viscovery.net>
[-- Attachment #1: Type: text/plain, Size: 524 bytes --]
On Wed, Nov 12, 2008 at 11:28 AM, Johannes Sixt <j.sixt@viscovery.net> wrote:
> I assume that Alexander has another patch applied in addition to the one
> that he submitted, which, therefore, is no longer "based on a publically
> available version".
I'm sorry, it is indeed applied over another patch (attached because I
only have access to Gmail Web UI right now). These patches eventually
come from two ends of one long series that has been gradually applied
over the time, so I still think of them as a unit.
Alexander
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: 0001-gitk-Add-accelerators-to-frequently-used-menu-comma.patch --]
[-- Type: text/x-patch; name=0001-gitk-Add-accelerators-to-frequently-used-menu-comma.patch, Size: 3355 bytes --]
From fc6b3728e15483734ee44a35d5023660a7da8882 Mon Sep 17 00:00:00 2001
From: Alexander Gavrilov <angavrilov@gmail.com>
Date: Sun, 9 Nov 2008 13:00:45 +0300
Subject: [PATCH] gitk: Add accelerators to frequently used menu commands.
This commit documents keyboard accelerators used for menu
commands in the menu, as it is usually done, and adds some
more, e.g. F4 to invoke Edit View.
The changes include a workaround for handling Shift-F4 on
systems where XKB binds special XF86_Switch_VT_* symbols
to Ctrl-Alt-F* combinations. Tk often receives these codes
when Shift-F* is pressed, so it is necessary to bind the
relevant actions to them as well.
Signed-off-by: Alexander Gavrilov <angavrilov@gmail.com>
---
gitk | 36 +++++++++++++++++++++++++++++-------
1 files changed, 29 insertions(+), 7 deletions(-)
diff --git a/gitk b/gitk
index 18d153e..9b2a6e5 100755
--- a/gitk
+++ b/gitk
@@ -1801,6 +1801,11 @@ proc setoptions {} {
# command to invoke for command, or {variable value} for radiobutton
proc makemenu {m items} {
menu $m
+ if {[tk windowingsystem] eq {aqua}} {
+ set Meta1 Cmd
+ } else {
+ set Meta1 Ctrl
+ }
foreach i $items {
set name [mc [lindex $i 1]]
set type [lindex $i 2]
@@ -1826,7 +1831,9 @@ proc makemenu {m items} {
-value [lindex $thing 1]
}
}
- eval $m add $params [lrange $i 4 end]
+ set tail [lrange $i 4 end]
+ regsub -all {\yMeta1\y} $tail $Meta1 tail
+ eval $m add $params $tail
if {$type eq "cascade"} {
makemenu $m.$submenu $thing
}
@@ -1860,17 +1867,17 @@ proc makewindow {} {
makemenu .bar {
{mc "File" cascade {
{mc "Update" command updatecommits -accelerator F5}
- {mc "Reload" command reloadcommits}
+ {mc "Reload" command reloadcommits -accelerator Meta1-F5}
{mc "Reread references" command rereadrefs}
- {mc "List references" command showrefs}
- {mc "Quit" command doquit}
+ {mc "List references" command showrefs -accelerator F2}
+ {mc "Quit" command doquit -accelerator Meta1-Q}
}}
{mc "Edit" cascade {
{mc "Preferences" command doprefs}
}}
{mc "View" cascade {
- {mc "New view..." command {newview 0}}
- {mc "Edit view..." command editview -state disabled}
+ {mc "New view..." command {newview 0} -accelerator Shift-F4}
+ {mc "Edit view..." command editview -state disabled -accelerator F4}
{mc "Delete view" command delview -state disabled}
{xx "" separator}
{mc "All files" radiobutton {selectedview 0} -command {showview 0}}
@@ -2232,7 +2239,12 @@ proc makewindow {} {
bindkey <Key-Return> {dofind 1 1}
bindkey ? {dofind -1 1}
bindkey f nextfile
- bindkey <F5> updatecommits
+ bind . <F5> updatecommits
+ bind . <$M1B-F5> reloadcommits
+ bind . <F2> showrefs
+ bind . <Shift-F4> {newview 0}
+ catch { bind . <Shift-Key-XF86_Switch_VT_4> {newview 0} }
+ bind . <F4> edit_or_newview
bind . <$M1B-q> doquit
bind . <$M1B-f> {dofind 1 1}
bind . <$M1B-g> {dofind 1 0}
@@ -3624,6 +3636,16 @@ proc decode_view_opts {n view_args} {
set newviewopts($n,args) [shellarglist $oargs]
}
+proc edit_or_newview {} {
+ global curview
+
+ if {$curview > 0} {
+ editview
+ } else {
+ newview 0
+ }
+}
+
proc editview {} {
global curview
global viewname viewperm newviewname newviewopts
--
1.6.0.2.GIT
^ permalink raw reply related
* Re: git integration with monodevelop
From: Andreas Ericsson @ 2008-11-12 10:31 UTC (permalink / raw)
To: Git Mailing List, Shawn Pearce, Michael Hutchinson
In-Reply-To: <491AAE6D.8030304@op5.se>
Andreas Ericsson wrote:
> Recently, I've started learning C#. More for fun than anything else,
> but one of the mono core devs sniffed me out and said they've been
> thinking of porting jgit to C# to get a working IDE integration in
> monodevelop. Currently, the only option available (with IDE
> integration anyways) to the poor C# devs is either Microsoft's
> crappy VSS, or the less crappy but still far from fantastic
> Subversion.
>
> So in an effort to learn C#, I've decided to play along with this
> (hopefully with some help from the MonoDevelop team), but it seems
> to me that the best place to start is the fledgling libgit2 and link
> that with git-sharp. The primary reason for this is ofcourse that I
> think it'd be a terrible waste to have yet another from-scratch
> implementation of git in a new language (ruby, java, C#, C...). The
> secondary reason is that it would be neat to have more OSS projects
> use my favourite scm.
>
> Besides, getting something to rely on libgit2 early on is probably
> the best way to get more people interested in making development of
> it proceed rapidly.
>
> Thoughts anyone?
>
> Please reply-to-all as this goes cross-list
> (currently, Cc ae@op5.se, spearce@spearce.org, git@vger.kernel.org,
> m.j.hutchinson@gmail.com, in case monodevelop-list uses reply-to
> header).
>
Ouch. Scratch monodevelop-list from that Cc list. It appears to be
members-only (although not listed as such on their list-server).
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
^ permalink raw reply
* git integration with monodevelop
From: Andreas Ericsson @ 2008-11-12 10:22 UTC (permalink / raw)
To: Git Mailing List, Shawn Pearce, monodevelop-list,
Michael Hutchinson
Recently, I've started learning C#. More for fun than anything else,
but one of the mono core devs sniffed me out and said they've been
thinking of porting jgit to C# to get a working IDE integration in
monodevelop. Currently, the only option available (with IDE
integration anyways) to the poor C# devs is either Microsoft's
crappy VSS, or the less crappy but still far from fantastic
Subversion.
So in an effort to learn C#, I've decided to play along with this
(hopefully with some help from the MonoDevelop team), but it seems
to me that the best place to start is the fledgling libgit2 and link
that with git-sharp. The primary reason for this is ofcourse that I
think it'd be a terrible waste to have yet another from-scratch
implementation of git in a new language (ruby, java, C#, C...). The
secondary reason is that it would be neat to have more OSS projects
use my favourite scm.
Besides, getting something to rely on libgit2 early on is probably
the best way to get more people interested in making development of
it proceed rapidly.
Thoughts anyone?
Please reply-to-all as this goes cross-list
(currently, Cc ae@op5.se, spearce@spearce.org, git@vger.kernel.org,
m.j.hutchinson@gmail.com, in case monodevelop-list uses reply-to
header).
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
^ permalink raw reply
* Re: Stgit and refresh-temp
From: Karl Hasselström @ 2008-11-12 10:14 UTC (permalink / raw)
To: Catalin Marinas; +Cc: Jon Smirl, Git Mailing List
In-Reply-To: <b0943d9e0811120202wae88381j9fbc9f919b49dce5@mail.gmail.com>
On 2008-11-12 10:02:10 +0000, Catalin Marinas wrote:
> I think it's just a matter of updating HEAD on the "merge_conflict"
> path but I'm still not fully confident in modifying the new lib
> infrastructure.
You're probably right.
I'll do it, but you're welcome to beat me to it if you like; I promise
to read your patch extra carefully if you do.
(I'll drop you a mail when I start attacking this, to prevent any
duplicated work.)
> 2008/11/12 Karl Hasselström <kha@treskal.com>:
>
> > I'll build a test case for that as well.
>
> We test the conflicts quite a lot in the "push" tests but this
> command hasn't been converted to the new infrastructure yet.
Yes. As soon as we convert push and/or pop, this will be caught by the
test suite. But that just means the test suite needs extending ...
--
Karl Hasselström, kha@treskal.com
www.treskal.com/kalle
^ permalink raw reply
* Re: hosting git on a nfs
From: Julian Phillips @ 2008-11-12 10:10 UTC (permalink / raw)
To: Thomas Koch; +Cc: git, dabe
In-Reply-To: <200811121029.34841.thomas@koch.ro>
On Wed, 12 Nov 2008, Thomas Koch wrote:
> Hi,
>
> finally I managed to convince a critical mass of developers (our chief
> dev :-) in our company so that we are starting to migrate to GIT.
>
> The final question is, whether GIT will life peacefully on our cluster
> fileservers. The GIT repository dir (/var/cache/git) should be mounted
> via NFS via PAN on top of DRBD (so I was told).
>
> Are there any known problems with this setup? We're asking, because
> there are problems with SVN on such a setup[1].
>
> [1] http://subversion.tigris.org/faq.html#nfs
I've been running git on NFS for years (though it's only NFS exported
software RAID), and the only issue I've encountered is that it's not quite
as blisteringly fast as running git on a local disk.
--
Julian
---
There's something different about us -- different from people of Europe,
Africa, Asia ... a deep and abiding belief in the Easter Bunny.
-- G. Gordon Liddy
^ permalink raw reply
* Re: Stgit and refresh-temp
From: Catalin Marinas @ 2008-11-12 10:02 UTC (permalink / raw)
To: Karl Hasselström; +Cc: Jon Smirl, Git Mailing List
In-Reply-To: <20081112080103.GA25454@diana.vm.bytemark.co.uk>
2008/11/12 Karl Hasselström <kha@treskal.com>:
> On 2008-11-11 17:59:02 +0000, Catalin Marinas wrote:
>> Could be related to this - if I run 'stg goto some-patch' and it
>> fails with a conflict, the HEAD points to the previous patch though
>> the stack has the conflicting patch as empty (which is normal) and
>> the conflicts in the index. Anything after that says HEAD and top
>> not equal and 'stg repair' is needed.
>
> Ah, yes, that could definitely be the same problem, since those two
> things end up calling the same functions to handle the conflict.
I think it's just a matter of updating HEAD on the "merge_conflict"
path but I'm still not fully confident in modifying the new lib
infrastructure.
> I'll build a test case for that as well.
We test the conflicts quite a lot in the "push" tests but this command
hasn't been converted to the new infrastructure yet.
--
Catalin
^ permalink raw reply
* hosting git on a nfs
From: Thomas Koch @ 2008-11-12 9:29 UTC (permalink / raw)
To: git; +Cc: dabe
Hi,
finally I managed to convince a critical mass of developers (our chief
dev :-) in our company so that we are starting to migrate to GIT.
The final question is, whether GIT will life peacefully on our cluster
fileservers. The GIT repository dir (/var/cache/git) should be mounted
via NFS via PAN on top of DRBD (so I was told).
Are there any known problems with this setup? We're asking, because
there are problems with SVN on such a setup[1].
[1] http://subversion.tigris.org/faq.html#nfs
Best regards,
--
Thomas Koch, Software Developer
http://www.koch.ro
Young Media Concepts GmbH
Sonnenstr. 4
CH-8280 Kreuzlingen
Switzerland
Tel +41 (0)71 / 508 24 86
Fax +41 (0)71 / 560 53 89
Mobile +49 (0)170 / 753 89 16
Web www.ymc.ch
^ permalink raw reply
* Re: [RFC PATCH 0/4] deny push to current branch of non-bare repo
From: Jeff King @ 2008-11-12 8:44 UTC (permalink / raw)
To: Kyle Moffett; +Cc: Junio C Hamano, git, Sam Vilain
In-Reply-To: <f73f7ab80811111644y14f0e0ccweed44440356a6508@mail.gmail.com>
On Tue, Nov 11, 2008 at 07:44:06PM -0500, Kyle Moffett wrote:
> Hmm, I wonder if it would be possible to also add a "detach" variant;
> which would create a detached-HEAD at the current commit when
> automatically receiving a push to the working branch. I have a
> post-receive script that does so right now on a couple repositories.
> It's still a little confusing to someone actively working in the
> repository being pushed to, but it's much easier to explain than the
> current default behavior.
A neat idea, but I'm not sure what workflow that is meant to support.
Before you had:
1. git push non-bare-remote theirHEAD
2a. echo Oops, I've just screwed myself.
3a. ssh remote 'git reset --soft HEAD@{1}'
2b. echo Oops, I just screwed somebody else.
3b. echo sorry | mail somebody.else
With "refuse" you have:
1. git push non-bare-remote theirHEAD
2. echo Oops, rejected.
3. git push non-bare-remote theirHEAD:elsewhere
4a. ssh remote 'git merge elsewhere'
4b. echo 'please merge elsewhere' | mail somebody.else
which is an improvement. With "detach" you have:
1. git push non-bare-remote theirHEAD
2. echo Oh, now we've detached on the remote.
3a. ssh remote 'git checkout theirHEAD'
3b. echo 'please merge theirHEAD. BTW, you have been detached without
realizing it, so make sure you didn't lose any commits.' |
mail somebody.else
So I think in the case that you are working by yourself, you haven't
really saved much effort (you didn't have to repeat your push, but you
still have to go to the remote and checkout instead of merge). But if
you are pushing into somebody _else_'s repo, you have just mightily
confused them as they start to make commits on top of the detached HEAD.
Still, there may be some instances where moving to the detached HEAD is
preferable. But, like the "try to merge if we can" strategy, I think it
is better implemented by setting denyCurrentBranch to ignore and using a
hook for those instances. And if either hook becomes ubiquitous, maybe
it will be worth implementing within git itself (but I doubt it for
either, as the desired behavior is highly dependent on your personal
workflow).
-Peff
^ permalink raw reply
* Re: [PATCH 1/2] Document "git log --source"
From: Santi Béjar @ 2008-11-12 8:41 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Nanako Shiraishi, git
In-Reply-To: <7vbpwlvkfh.fsf@gitster.siamese.dyndns.org>
On Wed, Nov 12, 2008 at 1:48 AM, Junio C Hamano <gitster@pobox.com> wrote:
> Thanks; will queue this one, but Santi said he'll work on a replacement
> for 2/2 so I'll drop 2/2 from you for now.
Oh, please, for me you can apply 2/2, as it is clearly an improvement
and follows the style in the section. I can work on top of it.
Santi
^ permalink raw reply
* Re: [PATCH] git-diff: Add --staged as a synonym for --cached.
From: Jeff King @ 2008-11-12 8:33 UTC (permalink / raw)
To: Avery Pennarun
Cc: Junio C Hamano, Björn Steinbrink, Johannes Schindelin,
David Symonds, git, Stephan Beyer
In-Reply-To: <32541b130811102004n54a47331v48ba8d299039897f@mail.gmail.com>
On Mon, Nov 10, 2008 at 11:04:42PM -0500, Avery Pennarun wrote:
> Speaking just for myself, I would find this all a lot less confusing
> if "staged" were a refspec of some sort, not an option at all.
>
> git diff HEAD..STAGED
> git diff STAGED..WORKTREE
> git grep pattern STAGED HEAD sillybranch WORKTREE ^ignorebranch --
> path/to/files
I agree that such a thing is reasonably intuitive. I have thought about
"magic" refspecs before; my local git has an "EMPTY" refspec which
points to the empty tree for diffing. However, that was trivial to
implement (since it turns into a sha1), and yours is very hard (since
you will have to pass these "pretend" objects around).
So I think it is a neat idea, but I am not volunteering to work on it.
:)
-Peff
^ permalink raw reply
* Re: [PATCH 5/5] commit: only strip diff from message in verbose mode
From: Jeff King @ 2008-11-12 8:29 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Santi Béjar, git
In-Reply-To: <20081112082552.GE3751@coredump.intra.peff.net>
On Wed, Nov 12, 2008 at 03:25:52AM -0500, Jeff King wrote:
> +test_expect_success 'diff in message is retained without -v' '
> + git commit --amend -F diff &&
> + check_message diff
> +'
> +
> +test_expect_failure 'diff in message is retained with -v' '
> + git commit --amend -F diff -v &&
> + check_message diff
> +'
I put in this expect_failure to remind us that we could be doing better.
The solution you proposed would fix this test. Another idea I had was to
use a bogus diff header, and match on that. Something like:
diff --git --verbose-commit a/file b/file
and searching for "diff --git --verbose-commit", which would not trigger
on any diffs (unless, of course, you were trying to explain how the
verbose mode worked in your commit message :) ).
But that doesn't cover any other special input (i.e., lines beginning
with '#'), and would probably require an ugly hack to the diff machinery
(some diff option for "add these bogus diff command line options").
-Peff
^ permalink raw reply
* Re: [PATCH (GITK)] gitk: Fix transient windows on Win32 and MacOS.
From: Johannes Sixt @ 2008-11-12 8:28 UTC (permalink / raw)
To: Paul Mackerras; +Cc: Alexander Gavrilov, git
In-Reply-To: <18714.36964.666759.654975@cargo.ozlabs.ibm.com>
Paul Mackerras schrieb:
> Johannes Sixt writes:
>> Alexander Gavrilov schrieb:
>>> Transient windows cause problems on these platforms:
>> ...
>>> diff --git a/gitk b/gitk
>>> index 9b2a6e5..e6aafe8 100755
>> I'd appreciate if you could make it a habit to base your patches on
>> versions of gitk etc. that are available from a public repository
>
> You mean, like, git://git.kernel.org/pub/scm/gitk/gitk.git, for
> instance? :) That is the primary repository for gitk and it seems to
> be what Alexander bases his patches on.
Yes, I mean exactly this repository. It doesn't have 9b2a6e5:
$ git fetch gitk
$ git show 9b2a6e5 --
fatal: bad revision '9b2a6e5'
I assume that Alexander has another patch applied in addition to the one
that he submitted, which, therefore, is no longer "based on a publically
available version".
-- Hannes
^ 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