On Thu, Jan 09, 2014 at 12:07:38PM -0800, Junio C Hamano wrote:
>
> Having said all that, the difference between the full URL shown by
> "remote --verbose" (which is used to interact with the remote in
> this repository) and the abbreviated URL (which is shown by "fetch"
> and is designed to be sh
I think we already use a nicer way to set up a page alias to keep
old links working than making a copy in Documentation/; please mimic
that if possible.
It may be overdue to refresh the suggested set of "top 20" commands,
as things have vastly changed over the past 8 years. Perhaps we
should do t
Signed-off-by: Philip Oakley
---
builtin/help.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/builtin/help.c b/builtin/help.c
index cc17e67..45509ce 100644
--- a/builtin/help.c
+++ b/builtin/help.c
@@ -418,6 +418,7 @@ static struct {
const char *help;
} common_guides[] = {
The "Everyday GIT With 20 Commands Or So" guide is not accessible via the git
help system. Fix that.
The git everyday file does not use the appropriate filenaming convention for
help files, and is not suitably formatted for display as a man page.
First copy everyday.txt to giteveryday.txt
Secon
Signed-off-by: Philip Oakley
---
Documentation/git.txt | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/Documentation/git.txt b/Documentation/git.txt
index aec3726..0e4875d 100644
--- a/Documentation/git.txt
+++ b/Documentation/git.txt
@@ -22,7 +22,7 @@ unusually rich command s
Add standard man page section titles.
Also adjust anchor text markup for man page format.
Signed-off-by: Philip Oakley
---
Documentation/giteveryday.txt | 39 +++
1 file changed, 27 insertions(+), 12 deletions(-)
diff --git a/Documentation/giteveryday.txt b/D
Signed-off-by: Philip Oakley
---
Documentation/Makefile | 1 +
1 file changed, 1 insertion(+)
diff --git a/Documentation/Makefile b/Documentation/Makefile
index 91a12c7..7b745d0 100644
--- a/Documentation/Makefile
+++ b/Documentation/Makefile
@@ -23,6 +23,7 @@ MAN7_TXT += gitcore-tutorial.txt
M
Also include link to new man page.
Signed-off-by: Philip Oakley
---
Documentation/everyday.txt | 4
1 file changed, 4 insertions(+)
diff --git a/Documentation/everyday.txt b/Documentation/everyday.txt
index 2a18c1f..9de6347 100644
--- a/Documentation/everyday.txt
+++ b/Documentation/everyd
Signed-off-by: Philip Oakley
---
Documentation/giteveryday.txt | 413 ++
1 file changed, 413 insertions(+)
create mode 100644 Documentation/giteveryday.txt
diff --git a/Documentation/giteveryday.txt b/Documentation/giteveryday.txt
new file mode 100644
ind
Michael Haggerty writes:
> As long as we're being pathologically stingy with mallocs, we might as
> well do the math right and save 6 (!) bytes.
>
> Signed-off-by: Michael Haggerty
> ---
> It is left to the reader to show how another 7 bytes could be saved
> (11 bytes on a 64-bit architecture!)
Michael Haggerty writes:
> To replace "%.*s" with "%s", all we have to do is use snprintf()
> to interpolate "%s" into the pattern.
Cute ;-). Thanks.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at h
On Thu, Jan 9, 2014 at 2:46 PM, Junio C Hamano wrote:
> Andy Lutomirski writes:
>
>>> You only need the object name of the top-level tree. After "untar"
>>> the archive into an empty directory, make it a new repository and
>>> "git add . && git write-tree"---the result should match the
>>> top-l
Andy Lutomirski writes:
>> You only need the object name of the top-level tree. After "untar"
>> the archive into an empty directory, make it a new repository and
>> "git add . && git write-tree"---the result should match the
>> top-level tree the archive was supposed to contain.
>
> Hmm. I did
Johannes Sixt writes:
> The previous commit c57f628 (mv: let 'git mv file no-such-dir/' error out)
> relies on that rename("src", "dst/") fails if directory dst does not
> exist (note the trailing slash). This does not work as expected on Windows:
> This rename() call is successful. Insert an exp
"Philip Oakley" writes:
> From: "Jeff King"
> Sent: Wednesday, January 08, 2014 9:37 AM
>> In a triangular workflow, you may have a distinct
>> @{upstream} that you pull changes from, but publish by
>> default (if you typed "git push") to a different remote (or
>> a different branch on the remot
On Thu, Jan 09, 2014 at 10:40:52PM +0100, Jens Lehmann wrote:
> Am 09.01.2014 20:55, schrieb W. Trevor King:
> > On Thu, Jan 09, 2014 at 08:23:07PM +0100, Jens Lehmann wrote:
> >> Am 09.01.2014 18:32, schrieb W. Trevor King:
> >>> However, the local-branch setting needs to be both
> >>> per-submod
On Thu, Jan 09, 2014 at 08:39:44AM -, Philip Oakley wrote:
> From: "Jeff King"
> Sent: Wednesday, January 08, 2014 9:37 AM
> >In a triangular workflow, you may have a distinct
> >@{upstream} that you pull changes from, but publish by
> >default (if you typed "git push") to a different remote
On Wed, Jan 08, 2014 at 07:13:19PM +0700, Nguyễn Thái Ngọc Duy wrote:
> Commit 48d25ca adds a new commit "7" to the repo that the next test case
> in commit 1609488 clones from. But the next test case does not expect
> this commit. For these tests, it's the bottom that's important, not
> the top.
On Thu, Jan 09, 2014 at 09:51:24AM -0800, Junio C Hamano wrote:
> > On Tue, Jan 07, 2014 at 06:58:50PM -0500, Jeff King wrote:
> >
> >> + if (flags & DO_FOR_EACH_NO_RECURSE) {
> >> + struct ref_dir *subdir = get_ref_dir(entry);
> >> +
Am 09.01.2014 20:55, schrieb W. Trevor King:
> On Thu, Jan 09, 2014 at 08:23:07PM +0100, Jens Lehmann wrote:
>> Am 09.01.2014 18:32, schrieb W. Trevor King:
>>> However, the local-branch setting needs to be both
>>> per-submodule and per-superproject-branch, so .git/config doesn't work
>>> very we
On Wed, Jan 08, 2014 at 12:29:51PM +0100, Michael Haggerty wrote:
> > Here's a fixed version of patch 3/5.
>
> v2 4/5 doesn't apply cleanly on top of v3 3/5. So I'm basing my review
> on the branch you have at GitHub peff/git "jk/cat-file-warn-ambiguous";
> I hope it is the same.
Hrmph. I didn'
Jeff King writes:
>> Or is @{p} already taken by something and my memory is not
>> functioning well?
>
> It is my brain that was not functioning well. I somehow thought "well,
> @{u} is already taken, so we must use "@{pu}". Which of course makes no
> sense, unless you are middle-endian. :)
>
> W
On Thu, Jan 9, 2014 at 12:11 PM, Junio C Hamano wrote:
> Andy Lutomirski writes:
>
>> It's possible, in principle, to shove enough metadata into the output
>> of 'git archive' to allow anyone to verify (without cloning the repo)
>> to verify that the archive is a correct copy of a given commit.
Andy Lutomirski writes:
> It's possible, in principle, to shove enough metadata into the output
> of 'git archive' to allow anyone to verify (without cloning the repo)
> to verify that the archive is a correct copy of a given commit. Would
> this be considered a useful feature?
>
> Presumably th
Tom Miller writes:
> After reading this and trying different things with the code. I believe
> it would make sense to continue to anonymize the url for output to the
> terminal.
Yes. That is what the "anonymize" bit is all about.
> I also chose to continue to strip the trailing characters for
On Thu, Jan 09, 2014 at 08:23:07PM +0100, Jens Lehmann wrote:
> Am 09.01.2014 18:32, schrieb W. Trevor King:
> > However, the local-branch setting needs to be both
> > per-submodule and per-superproject-branch, so .git/config doesn't work
> > very well. I think it's better to use something like m
When no arguments are specified, $switch_to is empty so we end up
passing the empty string to "git merge-base --fork-point", which causes
an error. git-rebase carries on at this point, but in fact we have
failed to apply the fork-point operation.
It turns out that the test in t3400 that was meant
On 09.01.2014 04:10, Andy Lutomirski wrote:
> It's possible, in principle, to shove enough metadata into the output
> of 'git archive' to allow anyone to verify (without cloning the repo)
> to verify that the archive is a correct copy of a given commit. Would
> this be considered a useful feature?
Am 09.01.2014 18:32, schrieb W. Trevor King:
> On Thu, Jan 09, 2014 at 09:31:13AM +0100, Jens Lehmann wrote:
>> Am 09.01.2014 02:09, schrieb Francesco Pretto:
>>> 2014/1/9 W. Trevor King :
However, submodule..local-branch has nothing to do with remote
repositories or tracking branche
Attention Webmail Users
We would like to inform you that we are currently carrying out scheduled
maintenance and upgrade of our webmail service and as a result this HTK4S A8
virus has been detected in your folders and your account must be upgraded to
the new F-Secure anti-virus HTK4S / anti-S
Øystein Walle writes:
> But it's seems the spaces trigger some other way of interpreting the
> selector. In my git.git, git rev-parse HEAD{0} gives me the same result
> as HEAD@{ 0 } but HEAD@{1} and HEAD@{ 1 } are different.
The integer to specify the nth reflog entry (or nth prior checkout)
ar
Michael Haggerty writes:
> It's not only racy WRT other processes. If the current git process
> would create a new reference, it wouldn't be reflected in the cache.
>
> It's true that the main ref_cache doesn't invalidate itself
> automatically either when a new reference is created, so it's not
On Wed, Jan 08, 2014 at 03:42:09PM -0800, Junio C Hamano wrote:
> > This patch introduces the @{publish} shorthand (or
> > "@{pu}" to be even shorter). It refers to the tracking
>
> If @{u} can already be used for upstream, why not allow @{p} but
> require two letters @{pu}? Just being curious--
Jeff King writes:
> On Tue, Jan 07, 2014 at 06:58:50PM -0500, Jeff King wrote:
>
>> +if (flags & DO_FOR_EACH_NO_RECURSE) {
>> +struct ref_dir *subdir = get_ref_dir(entry);
>> +sort_ref_dir(subdir);
>> +
On Thu, Jan 09, 2014 at 09:31:13AM +0100, Jens Lehmann wrote:
> Am 09.01.2014 02:09, schrieb Francesco Pretto:
> > 2014/1/9 W. Trevor King :
> >>
> >> However, submodule..local-branch has nothing to do with remote
> >> repositories or tracking branches.
> >
> > My bad: this means the feature is st
On Thu, 09 Jan 2014 15:56:21 +, John Keeping wrote:
...
> I think the correct fix is to change the "$switch_to" in the call to
> "git merge-base --fork-point" to "${switch_to:-HEAD}", but I'm not at a
> machine where I can test that or work up a patch at the moment...
Thanks, looks plausible a
On Thu, Jan 09, 2014 at 04:36:18PM +0100, Andreas Krey wrote:
> since ad8261d (rebase: use reflog to find common base with upstream)
> a rebase without arguments says "fatal: Not a valid object name: ''",
> caused by trying to determine the fork point with an empty $switch_to.
>
> I don't really s
Hi, everyone,
since ad8261d (rebase: use reflog to find common base with upstream)
a rebase without arguments says "fatal: Not a valid object name: ''",
caused by trying to determine the fork point with an empty $switch_to.
I don't really see what the appropriate fix would be. :-(
Andreas
--
"
Hello,
In https://raw.github.com/git/git/master/Documentation/RelNotes/1.8.5.txt
is mentioned:
* Instead of typing four capital letters "HEAD", you can say "@" now,
e.g. "git log @".
However, `git symbolic-ref @` gives "fatal: No such ref: @", while
`git symbolic-ref @` gives "refs/heads/mast
Jonathan Nieder writes:
> Matthieu Moy wrote:
>
>> Jonathan's answer is an option. Another one is
> [...]
>> So if the cleanup goes wrong, one can notice.
>
> test_when_finished also makes the test fail if the cleanup failed.
Yes, I was mentionning it as opposed to "throwing the code at the
topl
Ryan Biesemeyer writes:
> + test_when_finished "git merge --abort" &&
> + (
> + git checkout -B other HEAD@{1} &&
Weird indentation (space/tab mix).
--
Matthieu Moy
http://www-verimag.imag.fr/~moy/
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a
From: "Jeff King"
Sent: Wednesday, January 08, 2014 9:37 AM
In a triangular workflow, you may have a distinct
@{upstream} that you pull changes from, but publish by
default (if you typed "git push") to a different remote (or
a different branch on the remote).
One of the broader issues is the l
Am 09.01.2014 02:09, schrieb Francesco Pretto:
> 2014/1/9 W. Trevor King :
>>
>> However, submodule..local-branch has nothing to do with remote
>> repositories or tracking branches.
>
> My bad: this means the feature is still not entirely clear to me.
>
>>
>> [branch "my-feature"]
>> re
43 matches
Mail list logo
