Junio C Hamano wrote:
Is that accurate? My impression has been:
The documentation liberally mixes US and UK English (en_US/UK)
norms for spelling and grammar, which is somewhat unfortunate.
In an ideal world, it would have been better if it consistently
used only one and
Hi Joey,
Joey Hess wrote[1]:
Commit c334b87b30c1464a1ab563fe1fb8de5eaf0e5bac caused a reversion in
git-cat-file --batch.
With an older version:
joey@gnu:~/tmp/rrrgit cat-file --batch
:file name
e69de29bb2d1d6434b8b29ae775ad8c2e48c5391 blob 0
With the new version:
David A. Greene gree...@obbligato.org writes:
elif [ $# -eq 2 ]; then
- cmd_add_repository $@
+ git rev-parse -q --verify $2^{commit} /dev/null ||
+ die '$2' does not refer to a commit
That doesn't make any sense. $2 is a commit in a remote repository
which
On Thu, Aug 01, 2013 at 11:40:03PM -0700, Jonathan Nieder wrote:
Commit c334b87b30c1464a1ab563fe1fb8de5eaf0e5bac caused a reversion in
git-cat-file --batch.
With an older version:
joey@gnu:~/tmp/rrrgit cat-file --batch
:file name
e69de29bb2d1d6434b8b29ae775ad8c2e48c5391 blob 0
On Fri, Aug 02, 2013 at 03:54:02AM -0700, Jeff King wrote:
We need to revert that commit before the release. It can either be
replaced with:
1. A --split (or similar) option to use the behavior only when
desired.
2. Enabling splitting only when %(rest) is used in the output
Hello,
I'd like to rewrite the repack shell script in C.
So I tried the naive approach reading the man page and
the script itself and write C program by matching each block/line
of the script with a function in C
Now I stumble upon other git commands (git pack-objects).
What's the best way to
On Fri, Aug 2, 2013 at 8:48 PM, Stefan Beller
stefanbel...@googlemail.com wrote:
Hello,
I'd like to rewrite the repack shell script in C.
So I tried the naive approach reading the man page and
the script itself and write C program by matching each block/line
of the script with a function in
On 13-08-02 02:25 AM, Jonathan Nieder wrote:
Junio C Hamano wrote:
Is that accurate? My impression has been:
The documentation liberally mixes US and UK English (en_US/UK)
norms for spelling and grammar, which is somewhat unfortunate.
In an ideal world, it would have been
Jeff King wrote:
By the way, Joey, I am not sure how safe git cat-file --batch-check is
for arbitrary filenames. In particular, I don't know how it would react
to a filename with an embedded newline (and I do not think it will undo
quoting). Certainly that does not excuse this regression; even
On Fri, Aug 2, 2013 at 8:27 AM, Joey Hess j...@kitenet.net wrote:
Jeff King wrote:
By the way, Joey, I am not sure how safe git cat-file --batch-check is
for arbitrary filenames. In particular, I don't know how it would react
to a filename with an embedded newline (and I do not think it will
Brandon Casey draf...@gmail.com writes:
+/*
+ * The LRU pack is the one with the oldest MRU window, preferring packs
+ * with no used windows, or the oldest mtime if it has no windows allocated.
+ */
+static void find_lru_pack(struct packed_git *p, struct packed_git **lru_p,
struct
Jeff King p...@peff.net writes:
We need to revert that commit before the release. It can either be
replaced with:
1. A --split (or similar) option to use the behavior only when
desired.
2. Enabling splitting only when %(rest) is used in the output format.
And I suppose it is too
On Fri, Aug 02, 2013 at 09:10:59PM +0700, Duy Nguyen wrote:
On Fri, Aug 2, 2013 at 8:48 PM, Stefan Beller
stefanbel...@googlemail.com wrote:
Hello,
I'd like to rewrite the repack shell script in C.
So I tried the naive approach reading the man page and
the script itself and write C
Jeff King p...@peff.net writes:
On Fri, Aug 02, 2013 at 03:54:02AM -0700, Jeff King wrote:
We need to revert that commit before the release. It can either be
replaced with:
1. A --split (or similar) option to use the behavior only when
desired.
2. Enabling splitting only when
On Fri, Aug 2, 2013 at 9:26 AM, Junio C Hamano gits...@pobox.com wrote:
Brandon Casey draf...@gmail.com writes:
+/*
+ * The LRU pack is the one with the oldest MRU window, preferring packs
+ * with no used windows, or the oldest mtime if it has no windows allocated.
+ */
+static void
On Fri, Aug 02, 2013 at 09:41:52AM -0700, Junio C Hamano wrote:
Of the two, I think the latter is more sensible; the former is
unnecessarily placing the burden on the user to match --split with
their use of %(rest). The second is pointless without the first.
A patch to implement (2) is
Jeff King p...@peff.net writes:
On Fri, Aug 02, 2013 at 09:41:52AM -0700, Junio C Hamano wrote:
Of the two, I think the latter is more sensible; the former is
unnecessarily placing the burden on the user to match --split with
their use of %(rest). The second is pointless without the
A commit has parent commits or parents, not commits.
Signed-off-by: Torstein Hegge he...@resisty.net
---
Documentation/rev-list-options.txt | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/Documentation/rev-list-options.txt
b/Documentation/rev-list-options.txt
index
Am 02.08.2013 06:33, schrieb Jens Müller:
Am 01.08.2013 09:28, schrieb Jakub Narebski:
There is also TopGit, which is feature-branch management tools (which
seems like what you want, from what you written below).
Indeed, thank you very much for pointing me to it. I have not read the
whole
Junio C Hamano wrote:
Here is what is on top of the revert that has been pushed out on
'pu'.
For what it's worth,
Reviewed-by: Jonathan Nieder jrnie...@gmail.com
[...]
To remain backwards compatible, we cannot split on whitespace by
default, hence we will ship 1.8.4 with the commit
ksaitoh...@gmail.com wrote on Fri, 02 Aug 2013 17:02 +0900:
I trying clone Perforce project and I found git-p4. It's a great tool!
And I don't know how to exclude special extension file in a directory?
(Practically, I want to exclude Excel files at git p4 clone/sync.)
In Perforce, View
From: John Keeping j...@keeping.me.uk
git-format-patch(1) says:
By default, the subject of a single patch is [PATCH] followed
by the concatenation of lines from the commit message up to the
first blank line (see the DISCUSSION section of git-commit(1)).
I think
$ git log --encoding
fatal: Option '--encoding' requires a value
$ git rev-list --encoding
fatal: Option '--encoding' requires a value
The argument to --encoding has always been mandatory. Unfortunately
manpages like git-rev-list(1), git-log(1), and git-show(1) have
described the option's
Signed-off-by: Jonathan Nieder jrnie...@gmail.com
---
I'm not thrilled with the wording. This can probably be explained
more simply. Ideas?
Documentation/pretty-options.txt | 10 --
1 file changed, 8 insertions(+), 2 deletions(-)
diff --git a/Documentation/pretty-options.txt
We have been passing enough information to enable the
compare-and-swap logic down to the transport layer, but the
transport helper was not passing it to smart-http transport.
Signed-off-by: Junio C Hamano gits...@pobox.com
---
* I didn't bother with the dumb commit walker push for obvious
Hi all,
This is a revival of [1], which declares encoding in emails to make it
more likely that they can be read. I like to think it avoids the
mistakes of previous attempts, but I'll let you judge. :)
Sorry for the long delay. Thoughts of all kinds welcome, as always.
Thanks,
Jonathan
This way the hook doesn't have to keep being tweaked as porcelain
learns new features like color and pagination.
While at it, replace the git rev-list | git shortlog idiom with
plain git shortlog for simplicity.
Except for depending less on the value of settings like '[log]
abbrevCommit', no
From: Gerrit Pape p...@smarden.org
Date: Thu, 11 Dec 2008 20:27:21 +
Some email clients (e.g., claws-mail) display the message body
incorrectly when the charset is not defined explicitly in a
Content-Type header. git log generates logs in UTF-8 encoding by
default, so add a Content-Type
Git commands write commit messages in UTF-8 by default, but that
default can be overridden by the [i18n] commitEncoding and
logOutputEncoding settings. With such a setting, the emails written
by the post-receive-email hook use a mixture of encodings:
1. Log messages use the configured log
wor...@alum.mit.edu (Dale R. Worley) writes:
I'm preparing some clarifications of SubmittingPatches to explain
things that a new person (e.g., me) would not know.
I am not sure if SubmittingPatches is a good place, though.
The document is a guidance for people who contribute to _this_
project.
Hi.
These set of patches refactor the log view to provide a behaviour that
is quite similar to, say, e-mail with Mutt. The key improvements are:
- The current commit is inferred based on the context. For example, if
you focus on the commit message of a particular commit, the correct
commit
This reverts commit 888611dd5d407775245d574a3dc5c01b5963a5ba. This is
because, in the re-engineered log view, scrolling the log with the
arrows now updates the diff in the diff view when the screen is
split. This resembles the earlier behaviour, and is also what users of
software like Mutt (which
In the log view, when scrolling across a commit, the diff view should
automatically switch to the commit whose context the cursor is on in
the log view. This commit changes things to catch the REQ_ENTER in the
log view and handle recalculation of the commit and diff display from
log_request,
This commit introduces and uses the log_select function to find the
correct commit in the unsplit log view. In the log view, if one
scrolls down across a commit line, the current commit (as displayed in
the status bar) gets updated, but not so when scrolling upward across
a commit. The log_select
Commit 52749 fixes a bug regarding testing the return of an open()
call for success/failure. Improve the testsuite test for that fix by
removing the helper program 'test-close-fd-0' and replacing it with
the shell redirection '-'. (The redirection is Posix, so it should
be portable.)
Hi,
Dale R. Worley wrote:
Commit 52749 fixes a bug regarding testing the return of an open()
$ git show 52749
fatal: ambiguous argument '52749': unknown revision or path not in the working
tree.
Could you mention its subject line or date so it's easier to find?
call for success/failure.
Hi,
I was pulling in some changes in the morning to find:
Auto packing the repository for optimum performance. You may also
run git gc manually. See git help gc for more information.
Being my usual impatient self, I opened another prompt and started
merging changes. After the checkout, it
Hi:
Long ago I added a remote to my repo. It is set to track what was then
WordPress' main release branch (3.4-branch) and created a local branch
to use it. Well, time marches on. I want to update my remote and
branch to track the new main release branch (3.6-branch).
Here's how I set things
On Sat, Aug 3, 2013 at 8:48 AM, Ramkumar Ramachandra artag...@gmail.com wrote:
Auto packing the repository for optimum performance. You may also
run git gc manually. See git help gc for more information.
Being my usual impatient self, I opened another prompt and started
merging changes.
This may happen when `git gc --auto` is run automatically, then the
user, to avoid wait time, switches to a new terminal, keeps working
and `git gc --auto` is started again because the first gc instance has
not clean up the repository.
Signed-off-by: Nguyễn Thái Ngọc Duy pclo...@gmail.com
---
I
On Fri, Aug 2, 2013 at 8:53 PM, Duy Nguyen pclo...@gmail.com wrote:
Good point. I think that is because gc does not check if gc is already
running. Adding such a check should not be too hard. I think gc could
save its pid in $GIT_DIR/auto-gc.pid. The next auto-gc checks this, if
the pid is
As git cherry-pick - or git merge - is convenient to
switch back to or merge the previous branch,
git cherry-pick - is abbreviation of git cherry-pick @{-1}
to pick up a commit from the previous branch conveniently.
Signed-off-by: Hiroshige Umino hiroshig...@gmail.com
---
builtin/revert.c
42 matches
Mail list logo
