* [RESEND PATCH] fast-import: Cleanup mode setting.
From: Felipe Contreras @ 2009-01-14 1:37 UTC (permalink / raw)
To: git; +Cc: Shawn O. Pearce, Johannes Schindelin, Miklos Vajna,
Felipe Contreras
"S_IFREG | mode" probably is only required for 0644 and 0755.
Signed-off-by: Felipe Contreras <felipe.contreras@gmail.com>
---
fast-import.c | 7 ++++---
1 files changed, 4 insertions(+), 3 deletions(-)
diff --git a/fast-import.c b/fast-import.c
index a6bce66..f0e08ac 100644
--- a/fast-import.c
+++ b/fast-import.c
@@ -1872,12 +1872,13 @@ static void file_change_m(struct branch *b)
if (!p)
die("Corrupt mode: %s", command_buf.buf);
switch (mode) {
+ case 0644:
+ case 0755:
+ mode |= S_IFREG;
case S_IFREG | 0644:
case S_IFREG | 0755:
case S_IFLNK:
case S_IFGITLINK:
- case 0644:
- case 0755:
/* ok */
break;
default:
@@ -1944,7 +1945,7 @@ static void file_change_m(struct branch *b)
typename(type), command_buf.buf);
}
- tree_content_set(&b->branch_tree, p, sha1, S_IFREG | mode, NULL);
+ tree_content_set(&b->branch_tree, p, sha1, mode, NULL);
}
static void file_change_d(struct branch *b)
--
1.6.0.6.5.ga66c
^ permalink raw reply related
* Re: [RESEND PATCH] fast-import: Cleanup mode setting.
From: Johannes Schindelin @ 2009-01-14 2:08 UTC (permalink / raw)
To: Felipe Contreras; +Cc: git, Shawn O. Pearce, Miklos Vajna
In-Reply-To: <1231897027-16197-1-git-send-email-felipe.contreras@gmail.com>
Hi,
On Wed, 14 Jan 2009, Felipe Contreras wrote:
> "S_IFREG | mode" probably is only required for 0644 and 0755.
Why should we want to have that patch? IOW what does it fix, and what
might it break?
Ciao,
Dscho
^ permalink raw reply
* Re: [RESEND PATCH] fast-import: Cleanup mode setting.
From: Shawn O. Pearce @ 2009-01-14 2:16 UTC (permalink / raw)
To: Felipe Contreras; +Cc: git, Johannes Schindelin, Miklos Vajna
In-Reply-To: <1231897027-16197-1-git-send-email-felipe.contreras@gmail.com>
Felipe Contreras <felipe.contreras@gmail.com> wrote:
> "S_IFREG | mode" probably is only required for 0644 and 0755.
>
> Signed-off-by: Felipe Contreras <felipe.contreras@gmail.com>
Acked-by: Shawn O. Pearce <spearce@spearce.org>
> ---
> fast-import.c | 7 ++++---
> 1 files changed, 4 insertions(+), 3 deletions(-)
>
> diff --git a/fast-import.c b/fast-import.c
> index a6bce66..f0e08ac 100644
> --- a/fast-import.c
> +++ b/fast-import.c
> @@ -1872,12 +1872,13 @@ static void file_change_m(struct branch *b)
> if (!p)
> die("Corrupt mode: %s", command_buf.buf);
> switch (mode) {
> + case 0644:
> + case 0755:
> + mode |= S_IFREG;
> case S_IFREG | 0644:
> case S_IFREG | 0755:
> case S_IFLNK:
> case S_IFGITLINK:
> - case 0644:
> - case 0755:
> /* ok */
> break;
> default:
> @@ -1944,7 +1945,7 @@ static void file_change_m(struct branch *b)
> typename(type), command_buf.buf);
> }
>
> - tree_content_set(&b->branch_tree, p, sha1, S_IFREG | mode, NULL);
> + tree_content_set(&b->branch_tree, p, sha1, mode, NULL);
> }
>
> static void file_change_d(struct branch *b)
> --
> 1.6.0.6.5.ga66c
>
--
Shawn.
^ permalink raw reply
* Re: [RESEND PATCH] fast-import: Cleanup mode setting.
From: Shawn O. Pearce @ 2009-01-14 2:17 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Felipe Contreras, git, Miklos Vajna
In-Reply-To: <alpine.DEB.1.00.0901140308200.3586@pacific.mpi-cbg.de>
Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
> On Wed, 14 Jan 2009, Felipe Contreras wrote:
>
> > "S_IFREG | mode" probably is only required for 0644 and 0755.
>
> Why should we want to have that patch? IOW what does it fix, and what
> might it break?
It cleans up the code to make it more readable.
It makes no sense to be doing S_IFREG | S_IFLINK, which happens when
the input is for a symlink. It doesn't break anything to do that |
operation, but it also looks damn odd when reading the function.
--
Shawn.
^ permalink raw reply
* Re: [RESEND PATCH] fast-import: Cleanup mode setting.
From: Johannes Schindelin @ 2009-01-14 2:28 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: Felipe Contreras, git, Miklos Vajna
In-Reply-To: <20090114021751.GW10179@spearce.org>
Hi,
On Tue, 13 Jan 2009, Shawn O. Pearce wrote:
> Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
> > On Wed, 14 Jan 2009, Felipe Contreras wrote:
> >
> > > "S_IFREG | mode" probably is only required for 0644 and 0755.
> >
> > Why should we want to have that patch? IOW what does it fix, and what
> > might it break?
>
> It cleans up the code to make it more readable.
>
> It makes no sense to be doing S_IFREG | S_IFLINK, which happens when
> the input is for a symlink. It doesn't break anything to do that |
> operation, but it also looks damn odd when reading the function.
Imagining myself reading the commit message 6 months from now, in all
likeliness I will have wished that those two paragraphs were in there.
Verbatim.
Ciao,
Dscho
^ permalink raw reply
* Re: [RESEND PATCH] fast-import: Cleanup mode setting.
From: Shawn O. Pearce @ 2009-01-14 2:29 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Felipe Contreras, git, Miklos Vajna
In-Reply-To: <alpine.DEB.1.00.0901140326530.3586@pacific.mpi-cbg.de>
Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
> On Tue, 13 Jan 2009, Shawn O. Pearce wrote:
> >
> > It cleans up the code to make it more readable.
> >
> > It makes no sense to be doing S_IFREG | S_IFLINK, which happens when
> > the input is for a symlink. It doesn't break anything to do that |
> > operation, but it also looks damn odd when reading the function.
>
> Imagining myself reading the commit message 6 months from now, in all
> likeliness I will have wished that those two paragraphs were in there.
> Verbatim.
Maybe Junio or Felipe can copy it into the message.
Or you can use a git note now to attach it to the commit Junio
hasn't yet created, so you can look it up in the future. :-)
--
Shawn.
^ permalink raw reply
* git merge and cherry-pick and duplicated commits?
From: skillzero @ 2009-01-14 2:40 UTC (permalink / raw)
To: git
I created a branch from master, did a commit (8e9fdd), then did 2 more
commits (11c59c and 7024d), then did another commit (2daf23). From
master, I did a commit (47bd1b) then cherry-pick'd 2 commits from the
branch (11c59c and 7024d). When merged the branch into master, I see
the 2 cherry-picked commits twice in the log (once from the original
cherry-pick's and again from the merge).
I thought git would realize that master already had those 2 commits
and not add them again when merging?
^ permalink raw reply
* Re: [RESEND PATCH] fast-import: Cleanup mode setting.
From: Felipe Contreras @ 2009-01-14 2:46 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: Johannes Schindelin, git, Miklos Vajna
In-Reply-To: <20090114022933.GX10179@spearce.org>
[-- Attachment #1: Type: text/plain, Size: 1025 bytes --]
On Wed, Jan 14, 2009 at 4:29 AM, Shawn O. Pearce <spearce@spearce.org> wrote:
> Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
>> On Tue, 13 Jan 2009, Shawn O. Pearce wrote:
>> >
>> > It cleans up the code to make it more readable.
>> >
>> > It makes no sense to be doing S_IFREG | S_IFLINK, which happens when
>> > the input is for a symlink. It doesn't break anything to do that |
>> > operation, but it also looks damn odd when reading the function.
>>
>> Imagining myself reading the commit message 6 months from now, in all
>> likeliness I will have wished that those two paragraphs were in there.
>> Verbatim.
>
> Maybe Junio or Felipe can copy it into the message.
>
> Or you can use a git note now to attach it to the commit Junio
> hasn't yet created, so you can look it up in the future. :-)
How about the attached patch?
"S_IFREG | mode" probably is only required for 0644 and 0755.
It doesn't make sense to do S_IFREG | S_IFLINK (0100000 | 0120000),
since no bits are changed.
--
Felipe Contreras
[-- Attachment #2: 0001-fast-import-Cleanup-mode-setting.patch --]
[-- Type: application/octet-stream, Size: 1324 bytes --]
From 2eee342bb2613a3378ea05d22ecdcc31e58f2e22 Mon Sep 17 00:00:00 2001
From: Felipe Contreras <felipe.contreras@gmail.com>
Date: Mon, 22 Dec 2008 04:13:59 +0200
Subject: [PATCH] fast-import: Cleanup mode setting.
"S_IFREG | mode" probably is only required for 0644 and 0755.
It doesn't make sense to do S_IFREG | S_IFLINK (0100000 | 0120000),
since no bits are changed.
Signed-off-by: Felipe Contreras <felipe.contreras@gmail.com>
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
---
fast-import.c | 7 ++++---
1 files changed, 4 insertions(+), 3 deletions(-)
diff --git a/fast-import.c b/fast-import.c
index a6bce66..f0e08ac 100644
--- a/fast-import.c
+++ b/fast-import.c
@@ -1872,12 +1872,13 @@ static void file_change_m(struct branch *b)
if (!p)
die("Corrupt mode: %s", command_buf.buf);
switch (mode) {
+ case 0644:
+ case 0755:
+ mode |= S_IFREG;
case S_IFREG | 0644:
case S_IFREG | 0755:
case S_IFLNK:
case S_IFGITLINK:
- case 0644:
- case 0755:
/* ok */
break;
default:
@@ -1944,7 +1945,7 @@ static void file_change_m(struct branch *b)
typename(type), command_buf.buf);
}
- tree_content_set(&b->branch_tree, p, sha1, S_IFREG | mode, NULL);
+ tree_content_set(&b->branch_tree, p, sha1, mode, NULL);
}
static void file_change_d(struct branch *b)
--
1.6.0.6.5.ga66c
^ permalink raw reply related
* Re: [RESEND PATCH] fast-import: Cleanup mode setting.
From: Shawn O. Pearce @ 2009-01-14 2:51 UTC (permalink / raw)
To: Felipe Contreras; +Cc: Johannes Schindelin, git, Miklos Vajna
In-Reply-To: <94a0d4530901131846u2121e433ka8620fbb37c8470b@mail.gmail.com>
Felipe Contreras <felipe.contreras@gmail.com> wrote:
>
> How about the attached patch?
>
> "S_IFREG | mode" probably is only required for 0644 and 0755.
>
> It doesn't make sense to do S_IFREG | S_IFLINK (0100000 | 0120000),
> since no bits are changed.
Looks fine to me.
--
Shawn.
^ permalink raw reply
* Re: ETA for release of gjit 0.4?
From: Jonas Fonseca @ 2009-01-14 3:14 UTC (permalink / raw)
To: Robin Rosenberg; +Cc: Farrukh Najmi, Shawn O. Pearce, git
In-Reply-To: <200812160517.33975.robin.rosenberg.lists@dewire.com>
Robin Rosenberg <robin.rosenberg.lists@dewire.com> wrote Tue, Dec 16, 2008:
> Jonas, could you help us on this:
Sorry for the long delay. I completely overlooked this. In case it is
still relevant ...
> [INFO] ------------------------------------------------------------------------
> [ERROR] BUILD ERROR
> [INFO] ------------------------------------------------------------------------
> [INFO] Error deploying artifact: Failed to transfer file: http://egit.googlecode.com/svn/maven/snapshot-repository//org/spearce/jgit/0.4.0/jgit-0.4.0.jar. Return code is: 401
>
> I added this (nah, naming it release-repository didn't work either)
>
> <repository>
> <id>jgit-maven-release-repository</id>
> <name>JGit Maven Release Repository</name>
> <url>https://egit.googlecode.com/svn/maven/snapshot-repository/</url>
> <uniqueVersion>true</uniqueVersion>
> </repository>
This will end up mixing snapshots and releases ...
> (tried all combinations of dav/not-dav, http/https). Seems I don't have a dav provider,
> but https should work, right?
Well, I don't know, but I would expect the "dav:" to be required. I used
the Google Maven Repository pom.xml[0] as a template, which should give
something like:
<repository>
<id>jgit-maven-repository</id>
<name>JGit Maven Repository</name>
<url>dav:https://egit.googlecode.com/svn/maven/repository/</url>
</repository>
[0] http://google-maven-repository.googlecode.com/svn/snapshot-repository/com/google/google/1-SNAPSHOT/google-1-20080826.150842-5.pom
> and to ~/.m2/settings.xml
>
> <servers>
> <server>
> <id>jgit-maven-snapshot-repository</id>
> <username>tried both my project email and gmail email</username>
> <password>nah, won't show you</password>
> </server>
> </servers>
Try:
<servers>
<server>
<id>jgit-maven-repository</id>
<username>robin.rosenberg</username>
<password>Password from http://code.google.com/hosting/settings</password>
</server>
</servers>
Hope this helps.
--
Jonas Fonseca
^ permalink raw reply
* Re: [RFC/PATCH] gitweb: Fix nested links problem with ref markers
From: Giuseppe Bilotta @ 2009-01-14 3:56 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git
In-Reply-To: <200901140117.38803.jnareb@gmail.com>
On Tue, Jan 13, 2009 at 7:17 PM, Jakub Narebski <jnareb@gmail.com> wrote:
> On Tue, 13 Jan 2009, Giuseppe Bilotta wrote:
>> On Mon, Jan 12, 2009 at 7:13 PM, Jakub Narebski <jnareb@gmail.com> wrote:
>>> On Mon, 12 Jan 2009, Giuseppe Bilotta wrote:
>>>> On Sun, Jan 11, 2009 at 8:15 PM, Jakub Narebski <jnareb@gmail.com> wrote:
>
> [...]
>> Notice that nested links are actually valid *XML*. Indeed, I asked on
>> www-style and they suggested leaving the problem as-is, serving as
>> html+xml which is what we do.
>
> But nested links are neither valid HTML nor valid XHTML. This
> restriction (no nested links) is IMVHO quite sensible
Sensible? I think it's idiotic, especially since CSS does not and
cannot provide enough expression power to obtain the same layout and
functionality as what can be achieved by nesting links, so that to
achieve these results one has to resort to horirble trickes,
effectively destroying the whole purporse of HTML+CSS which is to
separate layout from semantics.
But anyway.
>> The float thing was the second suggestion I was given on www-style.
>
> What was the first suggestion? And what is www-style?
The first suggestion was to just leave things as they are. www-style
is www-style@w3c.org, the CSS mailing list of the W3C
>> Can you provide a patch I can apply to my tree for testing to see how
>> it comes up?
>
> Here it is. Note that CSS could be I think reduced. The size of
> gitweb.perl changes is affected by changing calling convention for
> git_print_header_html subroutine.
It's funny, I was working on a very similar patch myself a couple of
days ago, but couldn't get the horizontal filler after the link to
work properly, which is why I asked on www-style.
I'll test your patch and let you know.
> There is also strange artifact at least in Mozilla 1.17.2: if I hover
> over ref marker, the subject (title) gets darker background. Curious...
Might be some kind of bug with the capturing vs bubbling phase.
--
Giuseppe "Oblomov" Bilotta
^ permalink raw reply
* [PATCH] Noted that vi is the final choice of editor in git help commit
From: Craig Fratrik @ 2009-01-13 22:33 UTC (permalink / raw)
To: git; +Cc: Craig Fratrik
---
Documentation/git-commit.txt | 4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/Documentation/git-commit.txt b/Documentation/git-commit.txt
index b5d81be..1b9e7a5 100644
--- a/Documentation/git-commit.txt
+++ b/Documentation/git-commit.txt
@@ -318,8 +318,8 @@ ENVIRONMENT AND CONFIGURATION VARIABLES
---------------------------------------
The editor used to edit the commit log message will be chosen from the
GIT_EDITOR environment variable, the core.editor configuration variable, the
-VISUAL environment variable, or the EDITOR environment variable (in that
-order).
+VISUAL environment variable, the EDITOR environment variable, or finally 'vi'
+(in that order).
HOOKS
-----
--
1.6.0.4.608.ga9645.dirty
^ permalink raw reply related
* .ft tag in man
From: bill lam @ 2009-01-14 5:21 UTC (permalink / raw)
To: git
The diagram in man contain some .ft tag, eg inside
PAGE=less git help rebase
it contains
.ft C
A---B---C topic
/
D---E---F---G master
.ft
Is that intended or just an artefact?
--
regards,
====================================================
GPG key 1024D/4434BAB3 2008-08-24
gpg --keyserver subkeys.pgp.net --recv-keys 4434BAB3
唐詩244 柳宗元 江雪
千山鳥飛絕 萬徑人蹤滅 孤舟簑笠翁 獨釣寒江雪
^ permalink raw reply
* question about COMMIT_EDITMSG crlf
From: Frank Li @ 2009-01-14 5:17 UTC (permalink / raw)
To: git
I want to use notepad replace default vim at commit message editor.
git commit will create COMMIT_EDITMSG at .git directory. This file is
unix text mode.
Is there any config change it to windows text mode?
^ permalink raw reply
* Re: git merge and cherry-pick and duplicated commits?
From: Brian Gernhardt @ 2009-01-14 5:31 UTC (permalink / raw)
To: skillzero; +Cc: git
In-Reply-To: <2729632a0901131840v5c7ce0c7l3f87c03caabf68de@mail.gmail.com>
On Jan 13, 2009, at 9:40 PM, skillzero@gmail.com wrote:
> I created a branch from master, did a commit (8e9fdd), then did 2 more
> commits (11c59c and 7024d), then did another commit (2daf23). From
> master, I did a commit (47bd1b) then cherry-pick'd 2 commits from the
> branch (11c59c and 7024d). When merged the branch into master, I see
> the 2 cherry-picked commits twice in the log (once from the original
> cherry-pick's and again from the merge).
Before the cherry-picks, your repository looks like this
o-o (master: 47bd1b)
\
o-A-B-o (branch:2daf23)
A and B are the two commits you cherry-picked (11c59c and 7024d)
After the cherry-picks, the repo looks like this:
o-o-A'-B' (master)
\
o-A-B-o (branch:2daf23)
A and A' are different commits. Same with B and B'. If you check the
SHA1 of master at this point, it will NOT be 702fd... (B). Cherry
pick creates a new commit that (as far as git is concerned) is totally
unrelated.
After the merge, you get:
o-o-A'-B'-o (master)
\ /
o-A-B-o
Since git has no knowledge that the cherry-picked (A' B') commits are
related to their originals (A B), it displays both to you. If you
want, you can use the -x flag when you use "git cherry-pick" to add a
line that describes the original source of the patch in the new commit
which eases confusion when you look at the history, but will not stop
them from being displayed.
(The reason git will still display them is that the cherry-picked
commits may be different if there were conflicting changes on the
branches. Also, hiding those commits would give a false view of
history since the changes were actually added to the repository
twice. Using gitk or "git log --graph" will show the commits on two
different lines of development.)
> I thought git would realize that master already had those 2 commits
> and not add them again when merging?
The simplest method is to rebase branch after doing the cherry-picks.
This should only be done if your branch has not been published. From
after the cherry-picks:
o-o-A'-B' (master)
\
o-A-B-o (branch:2daf23)
"git rebase master branch" would give you
o-o-A'-B' (master)
\
o'-o' (branch)
Git should detect that the changes from A and B were already present
in master during the rebase and skip the commits.
~~ Brian Gernhardt
^ permalink raw reply
* Re: .ft tag in man
From: Junio C Hamano @ 2009-01-14 5:35 UTC (permalink / raw)
To: bill lam; +Cc: git
In-Reply-To: <20090114052126.GA6849@b2j>
bill lam <cbill.lam@gmail.com> writes:
> The diagram in man contain some .ft tag, eg inside
> PAGE=less git help rebase
> it contains
>
> .ft C
> A---B---C topic
> /
> D---E---F---G master
> .ft
No, I do not see that neither on my Debian nor on k.org's FC 9.
Perhaps you are using different version of asciidoc/docbook/xmlto
toolchain?
I think we added compatibility definitions in our Makefile to deal with
differences between AsciiDoc 7 vs 8, but I do not recall offhand what
misformatting one would get if it is set incorrectly..
^ permalink raw reply
* Re: How to pull remote branch with specified commit id?
From: thestar @ 2009-01-14 5:54 UTC (permalink / raw)
To: Brad King; +Cc: Johannes Sixt, Git Mailinglist
In-Reply-To: <496D0E65.3000200@kitware.com>
> Johannes Sixt wrote:
>> Consider this: You accidentally push a branch with confidential data to a
>> public repository. You notice it early, and quickly delete the branch
>> using 'git push the-repo :refs/heads/that-branch'. At this time the
>> objects with the confidential data are still lingering in the public
>> repository. But with the current behavior noone can access them even if
>> the SHA1 happens to be known.
Doesn't this line of reasoning only apply to the ssh and git transports?
(ie, the file and rsync transport would retrieve it regardless)
^ permalink raw reply
* Re: git merge and cherry-pick and duplicated commits?
From: skillzero @ 2009-01-14 6:21 UTC (permalink / raw)
To: git
In-Reply-To: <5EA96780-EF4C-4B31-9C60-6ABAF21663FA@silverinsanity.com>
On Tue, Jan 13, 2009 at 9:31 PM, Brian Gernhardt
<benji@silverinsanity.com> wrote:
> After the cherry-picks, the repo looks like this:
>
> o-o-A'-B' (master)
> \
> o-A-B-o (branch:2daf23)
>
> A and A' are different commits. Same with B and B'. If you check the SHA1
> of master at this point, it will NOT be 702fd... (B). Cherry pick creates a
> new commit that (as far as git is concerned) is totally unrelated.
That's what I was somewhat disappointed by. Even though the result of
the commit had a different hash, I assumed git would keep some kind of
internal per-commit hash so it could tell later that two commits were
the same and not re-apply them.
> The simplest method is to rebase branch after doing the cherry-picks. This
> should only be done if your branch has not been published.
The problem is, by the time I wanted to do the cherry-pick, I had
already committed other stuff to the branch. I tried doing 'git rebase
master branch' when on master and it just applied all the stuff from
master to branch.
Is there any way to apply a commit to 2 different branches (which have
diverged) in a way that git will remember so that when the 2 branches
merge later, it won't result in duplicate commits? I find that I often
make changes that days or weeks later find out that some other branch
needs that change and by then, there have been lots of commits to both
branches after the commit I want.
^ permalink raw reply
* Re: .ft tag in man
From: Todd Zullinger @ 2009-01-14 6:45 UTC (permalink / raw)
To: Junio C Hamano; +Cc: bill lam, git
In-Reply-To: <7veiz678m2.fsf@gitster.siamese.dyndns.org>
[-- Attachment #1: Type: text/plain, Size: 2258 bytes --]
Junio C Hamano wrote:
> bill lam <cbill.lam@gmail.com> writes:
>
>> The diagram in man contain some .ft tag, eg inside
>> PAGE=less git help rebase
>> it contains
>>
>> .ft C
>> A---B---C topic
>> /
>> D---E---F---G master
>> .ft
>
> No, I do not see that neither on my Debian nor on k.org's FC 9.
I began seeing this on Fedora 10. Defining DOCBOOK_XSL_172 fixed
that issue, but seems to have caused another. :/
For example, in git-diff.1, without DOCBOOK_XSL_172, I see:
.ft C
$ git diff (1)
$ git diff --cached (2)
$ git diff HEAD (3)
.ft
With DOCBOOK_XSL_172, I get this:
$ git diff ▓fB(3)▓fR
$ git diff --cached ▓fB(2)▓fR
$ git diff HEAD ▓fB(3)▓fR
The '.ft' problem is gone, but '\fB' and '\fR' are replaced by '▓fB'
and '▓fR', respectively. The paragraphs that follow such a list of
commands show more ugliness:
⌂sp ▓fB1. ▓fRChanges in the working tree not yet staged for the
next commit. ⌂br ▓fB2. ▓fRChanges between the index and your
last commit; what you would be committing if you run "git commit"
without "-a" option. ⌂br ▓fB3. ▓fRChanges in the working tree
since your last commit; what you would be committing if you run
"git commit -a" ⌂br
Defining ASCIIDOC8 seems to have no effect on this problem.
> Perhaps you are using different version of asciidoc/docbook/xmlto
> toolchain?
On Fedora 10, these are the versions:
asciidoc-8.2.5-2.fc9
docbook-dtds-1.0-41.fc10
docbook-style-xsl-1.74.0-4.fc10
xmlto-0.0.21-2.fc10
Fedora 9 has:
asciidoc-8.2.5-2.fc9
docbook-dtds-1.0-38.fc9
docbook-style-xsl-1.73.2-10.fc9
xmlto-0.0.20-3.fc9
--
Todd OpenPGP -> KeyID: 0xBEAF0CE3 | URL: www.pobox.com/~tmz/pgp
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Once ... in the wilds of Afghanistan, I lost my corkscrew, and we were
forced to live on nothing but food and water for days.
-- W.C. Fields
[-- Attachment #2: Type: application/pgp-signature, Size: 542 bytes --]
^ permalink raw reply
* Re: [PATCH next] git-notes: fix printing of multi-line notes
From: Junio C Hamano @ 2009-01-14 6:48 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Tor Arne Vestbø, git
In-Reply-To: <alpine.DEB.1.00.0901132339270.3586@pacific.mpi-cbg.de>
Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> On Tue, 13 Jan 2009, Tor Arne Vestbø wrote:
>
>> The line length was read from the same position every time,
>> causing mangled output when printing notes with multiple lines.
>>
>> Also, adding new-line manually for each line ensures that we
>> get a new-line between commits, matching git-log for commits
>> without notes.
>>
>> Signed-off-by: Tor Arne Vestbø <tavestbo@trolltech.com>
>> ---
>
> Patch looks good, so
>
> Acked-by: Johannes Schindelin <johannes.schindelin@gmx.de>
>
> For extra browny points, you could add a test with multi-line notes.
Yeah, not just "extra", having tests is a good way to make sure a new
feature like this evolves healthily.
Tor?
^ permalink raw reply
* Re: How to pull remote branch with specified commit id?
From: Johannes Sixt @ 2009-01-14 7:01 UTC (permalink / raw)
To: Brad King; +Cc: Git Mailinglist
In-Reply-To: <496D0E65.3000200@kitware.com>
Brad King schrieb:
> Johannes Sixt wrote:
>> Consider this: You accidentally push a branch with confidential data to a
>> public repository. You notice it early, and quickly delete the branch
>> using 'git push the-repo :refs/heads/that-branch'. At this time the
>> objects with the confidential data are still lingering in the public
>> repository. But with the current behavior noone can access them even if
>> the SHA1 happens to be known.
>
> Might a repack (perhaps an automatic one) put the object in a pack
> (perhaps in a delta chain) that can be fetched through another ref?
No, assuming that-branch was the only ref that contained the objects.
Even if the repack happens before the branch is deleted, the objects that
were *only* in that-branch will not be sent out.
-- Hannes
^ permalink raw reply
* Re: How to pull remote branch with specified commit id?
From: Johannes Sixt @ 2009-01-14 7:02 UTC (permalink / raw)
To: thestar; +Cc: Brad King, Git Mailinglist
In-Reply-To: <20090114165447.qdlwqqfnk4goccgg@webmail.fussycoder.id.au>
thestar@fussycoder.id.au schrieb:
>> Johannes Sixt wrote:
>>> Consider this: You accidentally push a branch with confidential data
>>> to a
>>> public repository. You notice it early, and quickly delete the branch
>>> using 'git push the-repo :refs/heads/that-branch'. At this time the
>>> objects with the confidential data are still lingering in the public
>>> repository. But with the current behavior noone can access them even if
>>> the SHA1 happens to be known.
>
> Doesn't this line of reasoning only apply to the ssh and git transports?
> (ie, the file and rsync transport would retrieve it regardless)
You are right. Http and rsync would happily ship the object.
-- Hannes
^ permalink raw reply
* Re: question about COMMIT_EDITMSG crlf
From: Junio C Hamano @ 2009-01-14 7:04 UTC (permalink / raw)
To: Frank Li; +Cc: git
In-Reply-To: <1976ea660901132117l7947157fw2922465a9b3945dc@mail.gmail.com>
"Frank Li" <lznuaa@gmail.com> writes:
> I want to use notepad replace default vim at commit message editor.
> git commit will create COMMIT_EDITMSG at .git directory. This file is
> unix text mode.
> Is there any config change it to windows text mode?
Nothing I can think of, other than using customized commit templates,
which I suspect is a bit overkill and at the same time misses the point
for this use case.
^ permalink raw reply
* Re: question about COMMIT_EDITMSG crlf
From: Johannes Sixt @ 2009-01-14 7:18 UTC (permalink / raw)
To: Frank Li; +Cc: git
In-Reply-To: <1976ea660901132117l7947157fw2922465a9b3945dc@mail.gmail.com>
Frank Li schrieb:
> I want to use notepad replace default vim at commit message editor.
> git commit will create COMMIT_EDITMSG at .git directory. This file is
> unix text mode.
> Is there any config change it to windows text mode?
No, there isn't. But perhaps you can use WordPad instead of Notepad? There
are reports that this worked.
You could also write a wrapper script that transforms the file before it
calls Notepad on it (untested):
#!/bin/bash
sed -e $'s/\r?$/\r/' < "$1" > .git/tmp$$ &&
mv .git/tmp$$ "$1" &&
notepad "$1"
I think git commit removes the trailing CRs automatically, so they don't
end up in the commit message.
-- Hannes
^ permalink raw reply
* Re: git merge and cherry-pick and duplicated commits?
From: skillzero @ 2009-01-14 7:33 UTC (permalink / raw)
To: git
In-Reply-To: <5EA96780-EF4C-4B31-9C60-6ABAF21663FA@silverinsanity.com>
I guess maybe a better question is how do people normally handle
situations like mine where I did some work on branch X and I later
realize I need only a portion of that work on branch Y? I'm not sure
how I can change my workflow to completely eliminate these situations.
For example, I often start a branch to add a new feature and I end up
fixing bug A on that branch. Then other people on my team decide they
need the fix for bug A immediately and can't wait for me to finish my
feature branch and do a full merge.
Is there some way I can change my workflow such that I can fix bug A
(maybe on a separate branch?) and somehow apply it to both both
branches in a way that won't result in duplicate commits?
Does this kind of thing ever happen with the Linux kernel or git
itself: somebody does a fix as part of their topic branch and the
Linux kernel or git master wants that particular fix now, but is not
ready for the full topic branch? Would they just suggest the fix be
separated into its own topic branch and that merged? If so, how would
that new topic branch merge into the original topic branch without
resulting in a duplicate commit when it's later merged into master?
^ 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