* old git reference manuals & release notes
From: Neal Kreitzinger @ 2011-11-12 3:44 UTC (permalink / raw)
To: git
Before the git-scm.com link to the reference manual went down last month,
the reference manual used to list the links to the manuals for all the major
git versions and the release notes for all git versions. This made it easy
to review release notes and manuals. Now the link only shows the latest git
manual. Is there a way I can access older manuals and release notes?
v/r,
neal
^ permalink raw reply
* Re: RFH: unexpected reflog behavior with --since=
From: Junio C Hamano @ 2011-11-12 6:50 UTC (permalink / raw)
To: Jeff King; +Cc: Eric Raible, git@vger.kernel.org
In-Reply-To: <20111109222032.GB31535@sigill.intra.peff.net>
Jeff King <peff@peff.net> writes:
> So I think the only decision is whether "--since" should respect the
> commit timestamps (and be used as a sort of "grep" filter for
> timestamps), or whether it should be respecting the fake history we
> create when doing a reflog walk.
>
> I think I am leaning towards the latter.
I tend to agree as far as the semantics go.
Also at least as a short term solution at the implementation level, I am
OK with the change. But in the longer term, I have this suspicion that we
should not be rewriting commit objects themselves with these phony data,
which makes things like "git log -g --stat" and "git log --parents -g"
totally useless.
That of course is not a fault of this patch; it does not make things any
worse than the original, and that is why I say I am OK with it.
Thanks.
^ permalink raw reply
* Re: [PATCH 3/4] pack-objects: don't traverse objects unnecessarily
From: Junio C Hamano @ 2011-11-12 6:55 UTC (permalink / raw)
To: Dan McGee; +Cc: git
In-Reply-To: <CAEik5nNmAnPni+rnLm7n5tO7f=LV_1TuTbVqxgjVaoqqaF_Ukw@mail.gmail.com>
Dan McGee <dpmcgee@gmail.com> writes:
> On Thu, Oct 27, 2011 at 5:26 PM, Junio C Hamano <gitster@pobox.com> wrote:
>
>> I am not sure if this produces the identical result that was benchmarked
>> in the original series.
> I was not either when I wrote the patch, and I had hoped to confirm
> the results you showed in the message of 1b4bb16b9ec.
I actually am reasonably sure the result will not be identical, but I also
do not think it matters. The differences would appear only for entries
that have been filled earlier, which should be a minority.
> unable to figure out how you generated those numbers so I wasn't able
> to do so (and had planned to get back to you to find out how you made
> those tables). Were you able to verify the ordering did not regress?
No; I was hoping you would redo the benchmark using 5f44324 (core: log
offset pack data accesses happened, 2011-07-06).
^ permalink raw reply
* Re: old git reference manuals & release notes
From: Junio C Hamano @ 2011-11-12 7:37 UTC (permalink / raw)
To: Neal Kreitzinger; +Cc: git
In-Reply-To: <j9kq3r$jk9$1@dough.gmane.org>
"Neal Kreitzinger" <neal@rsss.com> writes:
> Before the git-scm.com link to the reference manual went down last month,
> the reference manual used to list the links to the manuals for all the major
> git versions and the release notes for all git versions. This made it easy
> to review release notes and manuals. Now the link only shows the latest git
> manual. Is there a way I can access older manuals and release notes?
The HTML version of git documentation pages k.org used to serve were
specifically formatted to be served at that site, and sadly it is not
likely they will return anytime soon.
The k.org site kept these files under /pub/software/scm/git/docs/. The
in-development "master" version of pages were placed directly underneath
that directory, and the documentation pages for older versions were kept
in vX.Y.Z subdirectory of that directory.
The "master" version of the documents were formatted with a special macro
defined, and in that section, there were a bunch of links pointing at
vX.Y.Z/git.html. These links _knew_ about this directory layout to have
the current one at the top-level with stale ones in versioned directories.
I am not involved in the git-scm.com site that shows the documentation,
but I am guessing that it keeps an up to date copy of the preformatted
git-htmldocs repository and shows blob contents directly from the tip of
the history. The preformatted documents in git-htmldocs repository are
meant to be installed in machines of the end users, and do not expect that
end users would keep a forest of documents for all versions next to each
other. For that reason, they are not formatted with the links to older
versions.
So if you are asking for a way to access older versions without any effort
on your part, the answer is no, there is no way to do so. At least, not
that I know of.
If you are willing to do some work, you can keep a forest of documentation
pages for older versions yourself, and format the latest one with the
special macro defined to have the links that point to older versions. If
you can host that result somewhere on the net to help others, it would be
even better. I can tell you how to drive asciidoc to enable the links to
older versions if you are volunteering ;-)
^ permalink raw reply
* Re: Bash tab completion for _git_fetch alias is broken on Git 1.7.7.1
From: Scott Bronson @ 2011-11-12 8:08 UTC (permalink / raw)
To: SZEDER Gábor; +Cc: Nathan Broadbent, Johannes Sixt, Junio C Hamano, git
In-Reply-To: <20111110151412.GA11479@goldbirke>
2011/11/10 SZEDER Gábor <szeder@ira.uka.de>
> > On Thu, Nov 10, 2011 at 3:09 PM, Johannes Sixt <j.sixt@viscovery.net> wrote:
> > > Am 11/10/2011 4:21, schrieb Junio C Hamano:
> > > > Nathan Broadbent <nathan.f77@gmail.com> writes:
> > > >> Dear git mailing list,
> > > >> I'm assigning the `_git_fetch` bash tab completion to the alias `gf`,
> > > >> with the following command:
> > > >> complete -o default -o nospace -F _git_fetch gf
> > > >> The tab completion then works fine in git 1.7.0.4, but breaks on git
> > > >> 1.7.7.1, with the following error:
>
> I didn't actually tried, but I guess this is a side-effect of da4902a7
> (completion: remove unnecessary _get_comp_words_by_ref() invocations,
I looked into it and this is exactly right.
> Alternatively, you could easily create your own wrapper function
> around _git_fetch(), like this:
>
> _gf () {
> local cur prev words cword
> _get_comp_words_by_ref -n =: cur prev words cword
> _git_fetch
> }
>
>
> However.
>
> Having said all that, I'd like to point out that even if _git_fetch()
> didn't error out when called for the 'gf' alias, it still wouldn't
> work properly. After 'gf origin <TAB>' it offers the list of remotes
> again and it never offers refspecs, because it calls
> __git_complete_remote_or_refspec(), which
>
> - depends on the fact that there must be at least two words ('git'
> and 'fetch') on the command line before the remote, and
>
> - needs to know the git command (i.e. fetch, pull, or push) to offer
> the proper refspecs, but it can't find that out from your alias.
Very true. But if you tweak the completion variables, you can fool
_git_fetch into working perfectly:
_gf () {
COMP_LINE="git fetch${COMP_LINE#gf}"
let COMP_POINT+=7 # strlen('git fetch') - strlen('gf')
COMP_WORDS=(git fetch "${COMP_WORDS[@]:1}")
let COMP_CWORD+=1
local cur words cword prev
_get_comp_words_by_ref -n =: cur words cword prev
_git_fetch
}
Can anyone find a place where this would fail?
It would be pretty easy to write similar wrappers for _git_add,
_git_branch, and all the rest. [*]
Is there any possibility for a full set of wrappers (with better
names) to be merged into the git completions? A number of
peopl are disappointed that abbreviation completion doesn't
work anymore, myself included:
https://github.com/bobthecow/git-flow-completion/issues/2
https://github.com/ndbroadbent/scm_breeze/issues/11
I'm happy to write them if there's a chance they'd be merged.
Thank you for all the work you've done on the completions Gábor!
- Scott
* If I had more time, I'd be tempted to write a function that
would define all the wrapper functions.
define_wrapper add, ga
define_wrapper branch, gb
define_wrapper fetch, gf
...
Nothing a little eval metaprogramming can't solve. :)
^ permalink raw reply
* Re: Git: Unexpected behaviour?
From: Chris Packham @ 2011-11-12 8:25 UTC (permalink / raw)
To: J.V.; +Cc: git
In-Reply-To: <4EBDBCA2.7070603@gmail.com>
On 12/11/11 13:24, J.V. wrote:
> OK so "work tree" is a new term for me. I thought we were in isolated
> sandboxes called "branches" and changes made in a branch would stay in
> that branch regardless.
>
> so anything in the "work tree" is over layed on top of my branch if
> there are no conflicts?
Kind of. I'd say that your work tree is updated to match a branch when
you run git checkout initially. The branch is updated when you run git
commit (after staging changes in the index with git add or using -a).
^ permalink raw reply
* Re: Git: Unexpected behaviour?
From: Alexey Shumkin @ 2011-11-12 8:32 UTC (permalink / raw)
To: Jvsrvcs; +Cc: git
In-Reply-To: <1321044904175-6986736.post@n2.nabble.com>
the same situation and question were discussed and explained one
month earlier
take a look
http://thread.gmane.org/gmane.comp.version-control.git/183464
> Unexpected git behaviour
>
> ---
> # First create a local git repo
>
> $mkdir gitexample
> $git config --global user.name "my name"
> $git config --global user.email "me@me.com"
> $git init
> $git add .
> $git commit -m 'initial commit'
>
> # Create/Edit an empty file
> $vi readme.txt
>
> # add a single line: "this was added in the master branch."
> $git commit -a
>
> # create and checkout a new branch (from master)
> $git branch test
> $git checkout test
>
> # edit the readme.txt file and do not commit
> # add the text: "this was added in the test branch.", save and exit
> $vi readme.txt
>
> #now switch back to master
> $git checkout master
> $cat readme.txt
>
> #You will see both lines in the master.
>
> Question #1:
> Why was this line added in the *master branch?
>
>
> --- even further surprising
> In the master branch, now do a commit
> $git commit -a
>
> cat readme.txt ( you will see the line in the master now that was
> added in the test branch )
>
> Question #2:
> Why did this happen?
>
> # Now switch back to the test branch
> $git checkout test
> $cat readme.txt
>
> You will only see the one line: "This was added in the master branch"
>
> Question #3:
> Why did this happen?
>
> and NOT the line added in that branch: "this was added in the test
> branch" <= this line is gone
>
> What is the reason for this?
>
> 1) Why do I see uncommitted changes in the branches made off master
> in the master branch?
> 2) Why, if I commit them in the master, do the disappear in the
> branch in which they were made?
>
> This is confusing, I would think the * master branch would be left
> untouched. This would solve issue #2.
>
>
> --
> View this message in context:
> http://git.661346.n2.nabble.com/Git-Unexpected-behaviour-tp6986736p6986736.html
> Sent from the git mailing list archive at Nabble.com.
^ permalink raw reply
* git diff --numstat <branch> always shows dirty submodules
From: Gelonida N @ 2011-11-12 13:29 UTC (permalink / raw)
To: git
Hi,
I recently started using submodules and they behave mostly as I like to.
Normally I use diff --numstat <branch>
to check quickly whether I am aligned with another branch or not.
The (for me) annoying feature of submodules is, that they are always
reported to be different due to files, which are not under git.
I type git diff --numstat master
I get
1 1 mysubmodule
Now I check the differences with git diff master mysubmodule
diff --git a/mysubmodule b/mysubmodule
index 1382b73..f4f1f1d 160000
--- a/mysubmodule
+++ b/mysubmodule
@@ -1 +1 @@
-Subproject commit xxxxxxxxx
+Subproject commit xxxxxxxxx-dirty
So the only difference (which I wasn't interested in) is, that the
submodule is dirty.
Is there any quick way flag / helper script / . . .
to show differences between two branches without raising the fact, that
submodules are dirty?
>From a user perspective I don't see why this is reported.
I am not being warned about dirty files in the top level repository
^ permalink raw reply related
* Re: [PATCH 0/14] resumable network bundles
From: Tay Ray Chuan @ 2011-11-12 16:11 UTC (permalink / raw)
To: Jeff King; +Cc: git
In-Reply-To: <20111110074330.GA27925@sigill.intra.peff.net>
On Thu, Nov 10, 2011 at 3:43 PM, Jeff King <peff@peff.net> wrote:
> One possible option for resumable clones that has been discussed is
> letting the server point the client by http to a static bundle
> containing most of history, followed by a fetch from the actual git repo
> (which should be much cheaper now that we have all of the bundled
> history). This series implements "step 0" of this plan: just letting
> bundles be fetched across the network in the first place.
>
> Shawn raised some issues about using bundles for this (as opposed to
> accessing the packfiles themselves); specifically, this raises the I/O
> footprint of a repository that has to serve both the bundled version of
> the pack and the regular packfile.
>
> So it may be that we don't follow this plan all the way through.
> However, even if we don't, fetching bundles over http is still a useful
> thing to be able to do. Which makes this first step worth doing either
> way.
Jeff, this is a great series, I think the cleanups and refactors
should get integrated independently of the bundle-cloning stuff.
One thing I'm not comfortable with is the "flexibility" allowed in
bundle fetching - servers are allowed to send bundles if they see fit,
and we have to detect it when they do (if I'm reading the "surprised"
scenario in patch 9 correctly).
Perhaps we can expose bundle fetching through /objects/info/bundles?
It could possibly contain information about what bundles are available
and what revs they contain. If bundles are found, fetch them;
otherwise, go through the usual ref advertisement and other steps of
the pack protocol.
That way, we take out the "surprise" factor in the fetching protocol.
--
Cheers,
Ray Chuan
^ permalink raw reply
* Re: [PATCH 5/5] sequencer: revert d3f4628e
From: Ramkumar Ramachandra @ 2011-11-12 16:13 UTC (permalink / raw)
To: Jonathan Nieder; +Cc: Git List, Junio C Hamano, Christian Couder
In-Reply-To: <20111106004257.GG27272@elie.hsd1.il.comcast.net>
Hi Jonathan,
Jonathan Nieder writes:
> Is this patch just reverting a previous patch? If so, why doesn't the
> commit message use the usual format
>
> Revert "<commit message>"
>
> This reverts commit <unabbreviated object name>.
>
> <explanation>
> [...]
I'd have loved to use 'git revert d3f4628e', but that ends up creating
a lot more work: recall the big move made by 1/5? I'm trying to
"effectively port the inverse of the changes made by d3f4628e in
revert.c to sequencer.c" -- would you still like to see a git-revert
style commit message? Don't you think it'll be misleading?
Sorry about the shoddy commit messages though: I'm polishing the
series now that I'm convinced that it's heading in the right
direction. Hopefully, I'll have more to show soon.
Thanks.
-- Ram
^ permalink raw reply
* Re: Bash tab completion for _git_fetch alias is broken on Git 1.7.7.1
From: Scott Bronson @ 2011-11-12 17:50 UTC (permalink / raw)
To: SZEDER Gábor; +Cc: Nathan Broadbent, Johannes Sixt, Junio C Hamano, git
In-Reply-To: <CAKmUPx6TpbLL2GZq6G1nWPPBe=_SsqJmqXs1o9x5BxqR8y9h2Q@mail.gmail.com>
2011/11/12 Scott Bronson <bronson@rinspin.com>:
> 2011/11/10 SZEDER Gábor <szeder@ira.uka.de>
>> > On Thu, Nov 10, 2011 at 3:09 PM, Johannes Sixt <j.sixt@viscovery.net> wrote:
>> > > Am 11/10/2011 4:21, schrieb Junio C Hamano:
>> > > > Nathan Broadbent <nathan.f77@gmail.com> writes:
>> > > >> Dear git mailing list,
>> > > >> I'm assigning the `_git_fetch` bash tab completion to the alias `gf`,
>> > > >> with the following command:
>> > > >> complete -o default -o nospace -F _git_fetch gf
>> > > >> The tab completion then works fine in git 1.7.0.4, but breaks on git
>> > > >> 1.7.7.1, with the following error:
>> I didn't actually tried, but I guess this is a side-effect of da4902a7
>> (completion: remove unnecessary _get_comp_words_by_ref() invocations,
>> ...
>> Alternatively, you could easily create your own wrapper function
>> around _git_fetch(), like this:
> Very true. But if you tweak the completion variables, you can fool
> _git_fetch into working perfectly:
> * If I had more time, I'd be tempted to write a function that
> would define all the wrapper functions.
I couldn't stop thinking about it last night, I had to try it. Here's the
result, seems to work great:
__define_git_completion () {
eval "
_git_$2_shortcut () {
COMP_LINE=\"git $2\${COMP_LINE#$1}\"
let COMP_POINT+=$((4+${#2}-${#1}))
COMP_WORDS=(git $2 \"\${COMP_WORDS[@]:1}\")
let COMP_CWORD+=1
local cur words cword prev
_get_comp_words_by_ref -n =: cur words cword prev
_git_$2
}
"
}
__git_shortcut () {
type _git_$2_shortcut &>/dev/null || __define_git_completion $1 $2
alias $1="git $2 $3"
complete -o default -o nospace -F _git_$2_shortcut $1
}
__git_shortcut ga add
__git_shortcut gb branch
__git_shortcut gba branch -a
__git_shortcut gco checkout
__git_shortcut gci commit -v
__git_shortcut gcia commit '-a -v'
__git_shortcut gd diff
__git_shortcut gdc diff --cached
__git_shortcut gds diff --stat
__git_shortcut gf fetch
__git_shortcut gl log
__git_shortcut glp log -p
__git_shortcut gls log --stat
On Github:
https://github.com/bronson/dotfiles/blob/731bfd951be68f395247982ba1fb745fbed2455c/.bashrc#L81
It would be nice to see the __define_git_completion function merged
upstram. Possible?
- Scott
^ permalink raw reply
* Re: Bash tab completion for _git_fetch alias is broken on Git 1.7.7.1
From: Nathan Broadbent @ 2011-11-12 17:53 UTC (permalink / raw)
To: Scott Bronson; +Cc: SZEDER Gábor, Johannes Sixt, Junio C Hamano, git
In-Reply-To: <CAKmUPx67GMmF=dbFvYGq4x3NdfhWDE++dSSzbCqL9LYAF+j9ww@mail.gmail.com>
2011/11/13 Scott Bronson <bronson@rinspin.com>
>
> 2011/11/12 Scott Bronson <bronson@rinspin.com>:
> > 2011/11/10 SZEDER Gábor <szeder@ira.uka.de>
> >> > On Thu, Nov 10, 2011 at 3:09 PM, Johannes Sixt <j.sixt@viscovery.net> wrote:
> >> > > Am 11/10/2011 4:21, schrieb Junio C Hamano:
> >> > > > Nathan Broadbent <nathan.f77@gmail.com> writes:
> >> > > >> Dear git mailing list,
> >> > > >> I'm assigning the `_git_fetch` bash tab completion to the alias `gf`,
> >> > > >> with the following command:
> >> > > >> complete -o default -o nospace -F _git_fetch gf
> >> > > >> The tab completion then works fine in git 1.7.0.4, but breaks on git
> >> > > >> 1.7.7.1, with the following error:
> >> I didn't actually tried, but I guess this is a side-effect of da4902a7
> >> (completion: remove unnecessary _get_comp_words_by_ref() invocations,
> >> ...
> >> Alternatively, you could easily create your own wrapper function
> >> around _git_fetch(), like this:
> > Very true. But if you tweak the completion variables, you can fool
> > _git_fetch into working perfectly:
> > * If I had more time, I'd be tempted to write a function that
> > would define all the wrapper functions.
>
> I couldn't stop thinking about it last night, I had to try it. Here's the
> result, seems to work great:
>
>
> __define_git_completion () {
> eval "
> _git_$2_shortcut () {
> COMP_LINE=\"git $2\${COMP_LINE#$1}\"
> let COMP_POINT+=$((4+${#2}-${#1}))
> COMP_WORDS=(git $2 \"\${COMP_WORDS[@]:1}\")
> let COMP_CWORD+=1
>
> local cur words cword prev
> _get_comp_words_by_ref -n =: cur words cword prev
> _git_$2
> }
> "
> }
>
> __git_shortcut () {
> type _git_$2_shortcut &>/dev/null || __define_git_completion $1 $2
> alias $1="git $2 $3"
> complete -o default -o nospace -F _git_$2_shortcut $1
> }
>
> __git_shortcut ga add
> __git_shortcut gb branch
> __git_shortcut gba branch -a
> __git_shortcut gco checkout
> __git_shortcut gci commit -v
> __git_shortcut gcia commit '-a -v'
> __git_shortcut gd diff
> __git_shortcut gdc diff --cached
> __git_shortcut gds diff --stat
> __git_shortcut gf fetch
> __git_shortcut gl log
> __git_shortcut glp log -p
> __git_shortcut gls log --stat
>
>
> On Github:
> https://github.com/bronson/dotfiles/blob/731bfd951be68f395247982ba1fb745fbed2455c/.bashrc#L81
>
> It would be nice to see the __define_git_completion function merged
> upstram. Possible?
>
> - Scott
You are amazing!!! Thanks so much for this!
Nathan
^ permalink raw reply
* Re: [PATCH 0/14] resumable network bundles
From: Jeff King @ 2011-11-12 17:58 UTC (permalink / raw)
To: Tay Ray Chuan; +Cc: git
In-Reply-To: <CALUzUxqsLP11Tcsoc1tzGMfNcMqor2wQF+Yutu3FRiTin4Pnew@mail.gmail.com>
On Sun, Nov 13, 2011 at 12:11:31AM +0800, Tay Ray Chuan wrote:
> One thing I'm not comfortable with is the "flexibility" allowed in
> bundle fetching - servers are allowed to send bundles if they see fit,
> and we have to detect it when they do (if I'm reading the "surprised"
> scenario in patch 9 correctly).
Right.
> Perhaps we can expose bundle fetching through /objects/info/bundles?
But what if the server you are hitting doesn't have a git repo at all?
In the simplest case, a bundle provider should just be able to put a
file somewhere http-ccessible, without having any special directory
structure or other meta files.
Which means that we have to be prepared for the URL the user gave us to
be a bundle, not a git repo that contains bundles.
> It could possibly contain information about what bundles are available
> and what revs they contain. If bundles are found, fetch them;
> otherwise, go through the usual ref advertisement and other steps of
> the pack protocol.
This is "step 2" of my plan: hitting a git repo will provide a way of
redirecting to other, static storage. But I think it's important that
the other storage not just be a path in the existing repo, for two
reasons:
1. You might want to redirect the client off-server to a
higher-bandwidth static service like S3, or something backed by a
CDN.
2. The client might not be hitting you through http, so you can't
expect them to look at arbitrary repo files (like
objects/info/bundles). We need to provide the information over the
git protocol (my plan is to use a special ref name, like
"refs/mirrors" to encode the information).
> That way, we take out the "surprise" factor in the fetching protocol.
I don't think it's that big a deal. It influenced the way that patches 9
and 10 were written (patch 9 handles "surprise" bundles when fetching
info/refs, and then patch 10 falls back to fetching $URL without
info/refs). But even if we didn't have the "surprise" case, most of the
code in patch 9 would have just ended up in patch 10. That is, the
surprise case doesn't take much code, and doesn't have a negative impact
on the non-surprise case (i.e., until we see a bundle header, the
behavior is identical, just putting the refs into a memory buffer).
-Peff
^ permalink raw reply
* Verifying recent tags in git.git
From: Ramsay Jones @ 2011-11-12 16:35 UTC (permalink / raw)
To: Junio C Hamano; +Cc: GIT Mailing-list
Hi Junio,
I noticed that the v1.7.8-rc1 tag took about 24 hours to appear in the
kernel.org (and repo.or.cz) repository after you announced it and actually
pushed the branch out.
So, unusually, I decided to verify the tag when it did appear. However, it
did not verify! It seems that ever since v1.7.7 (ie v1.7.7.x and v1.7.8-rcx),
you have been signing the release tags with a new key-pair. (I assume that
you generated new keys at the beginning of October for use on kernel.org)
viz:
ramsay (master)$ git tag -v v1.7.7
object 703f05ad5835cff92b12c29aecf8d724c8c847e2
type commit
tag v1.7.7
tagger Junio C Hamano <gitster@pobox.com> 1317417666 -0700
Git 1.7.7
gpg: Signature made Fri Sep 30 22:21:06 2011 GMTDT using DSA key ID F3119B9A
gpg: Good signature from "Junio C Hamano <gitster@pobox.com>"
gpg: aka "Junio C Hamano <junkio@cox.net>"
gpg: aka "[jpeg image of size 1513]"
gpg: aka "Junio C Hamano <jch@google.com>"
gpg: aka "Junio C Hamano <junio@pobox.com>"
gpg: WARNING: This key is not certified with a trusted signature!
gpg: There is no indication that the signature belongs to the owner.
Primary key fingerprint: 3565 2A26 2040 E066 C9A7 4A7D C0C6 D9A4 F311 9B9A
ramsay (master)$ git tag -v v1.7.8-rc1
object 4cb6764227173a6483edbdad09121651bc0b01c3
type commit
tag v1.7.8-rc1
tagger Junio C Hamano <gitster@pobox.com> 1320713324 -0800
Git 1.7.8-rc1
gpg: Signature made Tue Nov 8 00:48:44 2011 GMTST using RSA key ID 96AFE6CB
gpg: Can't check signature: public key not found
error: could not verify the tag 'v1.7.8-rc1'
ramsay (master)$
Note the key ID 96AFE6CB.
Are you planning to create an junio-gpg-pub-v2 tag? (or are you making it
available from a keyserver?)
If I have missed an announcement on this, then sorry for the noise!
ATB,
Ramsay Jones
^ permalink raw reply
* Re: Git: Unexpected behaviour?
From: Junio C Hamano @ 2011-11-12 19:37 UTC (permalink / raw)
To: J.V.; +Cc: git
In-Reply-To: <4EBDBCA2.7070603@gmail.com>
"J.V." <jvsrvcs@gmail.com> writes:
> OK so "work tree" is a new term for me. I thought we were in isolated
> sandboxes called "branches" and changes made in a branch would stay in
> that branch regardless.
Do not think of "branches" as isolated _sandboxes_.
Rather, "branches" are where the independent states are to be _recorded_.
The recorded states only exist in the git repository, and to use its
contents (e.g. view in the pager or browser, edit in the editor, run the
compiler on,...), you need to materialize the contents of the branch
somewhere on the filesystem. Such a set of files on the filesystem form
the working tree. The act of doing so is called "checking out a branch".
After you check out a branch, your working tree can be used to record an
updated state to the branch, but notice the "can be" part. Changes you
make to the working tree are _not_ associated to the branch until you make
them so by committing. They are floating on top of the branch you have
currently checked out in your working tree, and "floating" was the key
part lacking in your understanding that started this thread. You are
allowed to check out another branch while you have a local change in the
working tree, and this is deliberately so. People often start working on a
branch (that is, they want to make a change and check out a branch, or
they happen to have a check-out of a branch and then the find something
they want to change), and then realize that the change logically does not
belong to the currently checked-out branch but some other branch. They
need to be able to check out another branch without losing the change they
already made in their working tree, and for such usage, the workflow
should look like:
$ git checkout master ;# on master branch
$ edit hello.c ;# some feature being added
... realize that this change does not belong to the master
... branch but is part of the "hello" branch you have been
... working on for the past few days
$ git checkout hello ;# check out the correct branch
... this keeps the local modification in hello.c (as long as
... the file you modified are the same between master and hello
... branches). Keep working on it and then finally...
$ git commit ;# on hello branch.
There is another unrelated use case in which people have local changes in
their working tree, but need to check out a different branch. The most
common is while you are working on a large feature that is not finished
yet on your "feature" branch, you hear from your boss that one trivial fix
for an urgent bug must be committed and pushed out on the "master" branch.
The feature you have in your working tree does not have anything to do
with the bug or the fix you are going to make for your boss. In such a
case, you would want to save away the changes for the feature, check out
the "master" branch and commit the fix, i.e.
$ git checkout feature ;# on feature
$ edit foo bar baz ;# some complicated change
... boss comes
$ git stash ;# stash away the current change
or
$ git commit -a -m 'wip'
$ git checkout master ;# emergency
$ edit ... ;# quickfix
$ git commit -m 'urgent fix...'
... emergency dealt with
$ git checkout feature
... back to what was being worked on
$ git stash pop
or
$ git reset HEAD^
^ permalink raw reply
* RFC: post-fetch hook
From: Joey Hess @ 2011-11-12 19:44 UTC (permalink / raw)
To: git
[-- Attachment #1: Type: text/plain, Size: 1149 bytes --]
A post-fetch hook would run on the local repository after a git-fetch or
git-pull. It would probably make sense for the hook to be sent the same
format input as the post-receive hook (although I don't need that information
myself). Like post-receive, it would not affect the outcome of the fetch. It
should be called late enough that it can manipulate the git repository
using the fetched refs.
My use case is in git-annex. It maintains its own, rather notes-like
branch. When remote versions of the branch have changed, they are
automatically merged into the local branch, using a union merge,
the next time git-annex is run. So normally it does not need this hook.
But, consider the case where git-annex has locally modified its branch,
and the remote tracking branch has also been modified. Now the user does
"git pull; git push". With the two git-annex branches diverged the
push fails. The user has to manually run "git annex merge" before
pushing to handle this.
If there was a post-fetch hook, git-annex could make it always run
git annex merge, and users would not need to deal with this situation.
--
see shy jo
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 828 bytes --]
^ permalink raw reply
* Re: Verifying recent tags in git.git
From: Stefan Naewe @ 2011-11-12 19:55 UTC (permalink / raw)
To: git
In-Reply-To: <4EBEA053.6040109@ramsay1.demon.co.uk>
Ramsay Jones <ramsay <at> ramsay1.demon.co.uk> writes:
>
> Hi Junio,
>
> I noticed that the v1.7.8-rc1 tag took about 24 hours to appear in the
> kernel.org (and repo.or.cz) repository after you announced it and actually
> pushed the branch out.
>
> [...]
> Note the key ID 96AFE6CB.
>
> Are you planning to create an junio-gpg-pub-v2 tag? (or are you making it
> available from a keyserver?)
What about this:
http://pgp.mit.edu:11371/pks/lookup?search=0x96AFE6CB&op=index&fingerprint=on
Stefan
^ permalink raw reply
* Re: git diff --numstat <branch> always shows dirty submodules
From: Jens Lehmann @ 2011-11-12 20:02 UTC (permalink / raw)
To: Gelonida N; +Cc: git
In-Reply-To: <j9lsc1$4uf$1@dough.gmane.org>
Am 12.11.2011 14:29, schrieb Gelonida N:
> I recently started using submodules and they behave mostly as I like to.
Good to hear that.
> Normally I use diff --numstat<branch>
> to check quickly whether I am aligned with another branch or not.
>
> The (for me) annoying feature of submodules is, that they are always
> reported to be different due to files, which are not under git.
>
>
> I type git diff --numstat master
> I get
> 1 1 mysubmodule
>
>
> Now I check the differences with git diff master mysubmodule
> diff --git a/mysubmodule b/mysubmodule
> index 1382b73..f4f1f1d 160000
> --- a/mysubmodule
> +++ b/mysubmodule
> @@ -1 +1 @@
> -Subproject commit xxxxxxxxx
> +Subproject commit xxxxxxxxx-dirty
>
> So the only difference (which I wasn't interested in) is, that the
> submodule is dirty.
>
> Is there any quick way flag / helper script / . . .
> to show differences between two branches without raising the fact, that
> submodules are dirty?
Yes, there is the "--ignore-submodules" command line option and the
diff.ignoreSubmodules (which can be set globally and/or per repo) and
submodule.<name.>ignore configuration settings. They can be set to
"untracked", "dirty" or "all" to control what you want to see.
Did you check areas in the Documentation where you did expect to find
them mentioned but they weren't? Then please say so that we can fix
that.
>> From a user perspective I don't see why this is reported.
> I am not being warned about dirty files in the top level repository
This is so you can't forget to add new files inside the submodule,
which can lead to breakage when other people clone the superproject
but won't get the new files from the submodule because you didn't
commit them there.
^ permalink raw reply
* Re: Update Linux kernel branch source from GIT
From: Thiago Farina @ 2011-11-12 20:59 UTC (permalink / raw)
To: Eric Kom; +Cc: Junio C Hamano, git
In-Reply-To: <4EBCB737.4090100@kom.za.net>
On Fri, Nov 11, 2011 at 3:48 AM, Eric Kom <erickom@kom.za.net> wrote:
> Good day,
>
> Am new on this list, and also compile the kernel linux from git after
> clone. since I don't use the tar kernel version, am use to clone a new
> kernel branch instead to update it via patch.
>
> Please can you explain to me how to make a patch after clone it?
>
To make a patch?
I think you want something like this (uncompleted/untested offhand):
$ git checkout -b my-patch origin/master
# hack on some files
$ git commit -a -s
# edit commit message
$ git format-patch
$ git send-email
Hugely these are the commands I'd use to make a change and send it out to LKML.
^ permalink raw reply
* Re: [RFC/PATCH] remote: add new sync command
From: Felipe Contreras @ 2011-11-12 22:07 UTC (permalink / raw)
To: Jeff King; +Cc: git
In-Reply-To: <20111111181352.GA16055@sigill.intra.peff.net>
On Fri, Nov 11, 2011 at 8:13 PM, Jeff King <peff@peff.net> wrote:
> On Fri, Nov 11, 2011 at 02:30:48PM +0200, Felipe Contreras wrote:
>
>> > Doesn't --all mean all refs, including tags and branches?
>>
>> Nope, only branches, try it. I also found it strange. And what is
>> more, you can't use --all and --tags at the same time. Totally
>> strange.
>
> Yeah, you're right. Sorry for my confusion.
>
> So in that sense, it is poorly named, and "--branches" (or "--heads")
> would be more accurate. At the same time, it is probably more likely
> what the user wants to do (you almost never want to push "refs/remotes",
> for example).
But you do want to push tags, and --all --tags doesn't sound right; if
I'm pushing everything, why do I specify I want to push more stuff.
And then, why it --all --tags disallowed?
> So I am a little hesitant to suggest changing it, even
> with a warning and deprecation period.
It is confusing and wrong, what more reason do you need?
>> And yes, in this particular use-case that's what I am trying to avoid,
>> but in other use-cases (like creating a new repo and pushing
>> *everything*), a *true* --all would be nice.
>
> Right. It looks like that is just spelled "--mirror" (which gives you
> pruning also), or "refs/*:refs/*" (without pruning). The latter is even
> more flexible, as you could do "refs/*:refs/foo/*" to keep several
> related backups in one upstream repo.
So, we agree that --all is the same as 'refs/heads/*'. Therefore we
already have this mixture of refspecs and options.
> Just to get back to the original patch for a second: are we in agreement
> that what you want to do with "sync" is almost possible now (modulo a
> separate --prune option), and that there is a separate issue of making
> friendlier syntax for a few common refspecs?
Yes.
>> > We could add syntactic sugar to make
>> > --branches mean "refs/heads/*". But I do worry that pseudo-options like
>> > that just end up creating more confusion (I seem to recall there being a
>> > lot of confusion about "--tags", which is more or less the same thing).
>>
>> But it's not, that could explain part of the confusion. I think these
>> would be totally intuitive.
>>
>> --branches
>> --tags
>> --other
>> --all
>> --update
>> --prune
>
> My problem with them syntactically is that you have option-looking
> things that are really not flags, but rather syntactic placeholders for
> refspecs.
We already have those: --all -> 'ref/heads/*', --tags -> 'refs/tags/*'.
> So you have:
>
> git push --prune remote --branches
>
> which looks wrong from the perspective of usual option-parsing rules.
> And does:
>
> git push remote --prune --branches
>
> work? Or:
>
> git push --prune --branches remote
>
> ?
>
> I think we could make them all work if we want. But somehow the syntaxes
> just look wrong to me. Using a non-dashed placeholder for special
> refspecs makes more sense to me like:
I don't see any problem with making them all work.
> git push --prune remote BRANCHES
>
> and then it really is just a special way of spelling "refs/heads/*". But
> then, I also think it's good for users to understand that the options
> are refspecs, and what that means. It's not a hard concept, and then
> when they inevitably say "how can I do BRANCHES, except put the result
> somewhere else in the remote namespace", it's a very natural extension
> to learn about the right-hand side o the refspec.
>
> Of course I also think BRANCHES looks ugly, and people should just learn
> "refs/heads/*".
Look, I'm all in favor of people learning stuff, but I have been
involved in Git since basically day 1, and up to this day I was (am?)
not familiar with refspecs, I don't use them regularly, and never
really had a need to, and that's fine. People are already complaining
about the learning curve of git, and what you are suggesting is that:
Instead of doing:
% git push remote --branches --tags
They should do:
% git push remote 'refs/heads/*' 'refs/tags/*'
I disagree, I think refspecs should remain as plumbing, and there must
be a porcelain way to achieve the options I proposed.
> I dunno. Maybe my brain is fried from knowing too much about how git
> works. I don't have much of an "ordinary user" perspective anymore.
Maybe :)
>> But what about 'git fetch'? You didn't comment anything. I think we
>> should try to be consistent in these imaginary future options, maybe
>> to devise a transition, or at least to identify good names for the new
>> options.
>
> Yeah, fetch makes it harder because the options may have subtly
> different meanings. Using non-option placeholders would work around
> that. You would still have options for pruning, which to me is not
> really a refspec, but an option that acts on the refspecs.
>
> From the list in your previous email, you wrote:
>
>> --prune -> rename to --prune-tracking?
>> --prune-local (new; prune local branches that don't exist on the remote)
>
> I think --prune wouldn't need renaming. If you fetch into tracking
> branches, then pruning would prune tracking branches. If you fetch as a
> mirror (refs/*:refs/*), then you would prune everything.
I'm not going to investigate the subtleties of these different setups,
I'm going to put my common user hat and ask; how do I fetch as a
mirror?
> And "--prune-local" doesn't seem like a fetch operation to me. Either
> you are mirroring, and --prune already handles it as above. Or you are
> interested in getting rid of branches whose upstream has gone away. But
> that's not a fetch operation; that's a branch operation.
This would make things more confusing to the user.
Say on one side I do this push?
% git push test --prune 'refs/heads/*' 'refs/tags/*'
What do I do in the other side to synchronize the repo?
% git fetch test --prune-local 'refs/heads/*:refs/heads/*'
'refs/tags/*:refs/tags/*'
I would prefer this of course:
% git fetch test --all --prune-local
But you are saying it should be:
% git fetch test 'refs/heads/*:refs/heads/*' 'refs/tags/*:refs/tags/*'
% git branch --prune-remote test
That doesn't sound right to me; mixing branch operations with a specific remote?
Again, I think conceptually it's much easier to think about these
operations to be related to a specific remote, sure, fetch and push
mostly deal with specific remotes, but even more 'git remote'.
--
Felipe Contreras
^ permalink raw reply
* Re: [PATCH 5/5] sequencer: revert d3f4628e
From: Jonathan Nieder @ 2011-11-12 22:40 UTC (permalink / raw)
To: Ramkumar Ramachandra; +Cc: Git List, Junio C Hamano, Christian Couder
In-Reply-To: <CALkWK0=QHUeKH6ccVLYJVW_RxXbEaLfwafTVzJ94+s49j=8QjA@mail.gmail.com>
Ramkumar Ramachandra wrote:
> I'm trying to
> "effectively port the inverse of the changes made by d3f4628e in
> revert.c to sequencer.c" -- would you still like to see a git-revert
> style commit message? Don't you think it'll be misleading?
My main complaint is that the subject line (and then the body) didn't
tell me what effect the patch would have in a self-contained way.
I don't think a git-revert style commit message would be misleading.
Couldn't you avoid confusing people by providing the relevant
information directly? "This commit was not made with 'git revert',
since there has been too much code reorganization in the meantime;
instead, I applied the inverse of the changes made by d3f4628e by
hand. This patch also tweaks the test added in that commit instead of
removing it."
> Sorry about the shoddy commit messages though: I'm polishing the
> series now that I'm convinced that it's heading in the right
> direction. Hopefully, I'll have more to show soon.
Thanks. I'll try not to be distracted and to just focus on the code
for the next round.
^ permalink raw reply
* Re: git diff --numstat <branch> always shows dirty submodules
From: Gelonida N @ 2011-11-13 0:45 UTC (permalink / raw)
To: git
In-Reply-To: <4EBED0ED.7060005@web.de>
Hi Jens,
Thanks a lot for your answer.
On 11/12/2011 09:02 PM, Jens Lehmann wrote:
> Am 12.11.2011 14:29, schrieb Gelonida N:
>> I recently started using submodules and they behave mostly as I like to.
>> Normally I use diff --numstat<branch>
>> to check quickly whether I am aligned with another branch or not.
>> . . .
>> Is there any quick way flag / helper script / . . .
>> to show differences between two branches without raising the fact, that
>> submodules are dirty?
>
> Yes, there is the "--ignore-submodules" command line option and the
> diff.ignoreSubmodules (which can be set globally and/or per repo) and
> submodule.<name.>ignore configuration settings. They can be set to
> "untracked", "dirty" or "all" to control what you want to see.
I tried this immediately and at works perfectly for git diff.
Please see also my comments at the end of this post
>
> Did you check areas in the Documentation where you did expect to find
> them mentioned but they weren't? Then please say so that we can fix
> that.
>
Apologies. My bad. I must have read the output of
git help diff
too quickly.
It is there plain as the day. :-(
>>> From a user perspective I don't see why this is reported.
>> I am not being warned about dirty files in the top level repository
>
> This is so you can't forget to add new files inside the submodule,
> which can lead to breakage when other people clone the superproject
> but won't get the new files from the submodule because you didn't
> commit them there.
Well I wouldn't expect to find this kind of info (by default) in the
output of a git-diff.
If you git-diff two branches of a project without submodules it doesn't
tell you either, that you have untracked files in the repository.
I would have expected this kind of output just as result of
'git status'
(as it is already today)
# modified: submodule (untracked content)
Git status reports untracked files in the super project AND in it
reports, that there are untracked files in the submodule.
So this seems to be more consistent to me than the diff case.
On the other hand I would consider it usefult if git status could
optionally report the complete list of untracked files also for the
submodules
(So far I didn't search in depth in doc whether there is a switch
for it.)
A first shot was reading the output of git help status:
> If status.submodulesummary is set to a non zero number or true (identical to -1 or an unlimited number), the
> submodule summary will be enabled for the long format and a summary of commits for modified submodules will
> be shown (see --summary-limit option of git-submodule(1)).
I put thus following lines in .git/config of my repository
status]
submodulesummary = true
but the untracked files of my submodule were not reported. (will follow
the doc of git-submodule)
What is also confusing to me is, that the setting
diff.ignoreSubmodules is also being used by git status.
There seems to be no variable
status.ignoreSubmodules
So it seems impossible (without aliases) to
have git diff NOT report the untracked files,
but git status report them.
I guess I'll go for a solution with git aliases
^ permalink raw reply
* Re: [PATCH] Copy resolve_ref() return value for longer use
From: Junio C Hamano @ 2011-11-13 5:57 UTC (permalink / raw)
To: Nguyễn Thái Ngọc Duy; +Cc: git, Tony Wang
In-Reply-To: <1320719428-1802-1-git-send-email-pclouds@gmail.com>
Nguyễn Thái Ngọc Duy <pclouds@gmail.com> writes:
> resolve_ref() may return a pointer to a static buffer. Callers that
> use this value outside of a block should copy the value to avoid some
> hidden resolve_ref() call that may change the static buffer's value.
>
> The bug found by Tony Wang <wwwjfy@gmail.com> in builtin/merge.c
> demonstrates this. The first call is in cmd_merge()
>
> branch = resolve_ref("HEAD", head_sha1, 0, &flag);
>
> Then deep in lookup_commit_or_die() a few lines after, resolve_ref()
> may be called again and destroy "branch".
>
> lookup_commit_or_die
> lookup_commit_reference
> lookup_commit_reference_gently
> parse_object
> lookup_replace_object
> do_lookup_replace_object
> prepare_replace_object
> for_each_replace_ref
> do_for_each_ref
> get_loose_refs
> get_ref_dir
> get_ref_dir
> resolve_ref
>
> Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com>
> ---
Thanks.
The above log message with the callchain would be a perfect explanation
for a patch to fix builtin/merge.c and nothing else, but among 50+
callsites of resolve_ref(), only 5 places are modified in this patch, and
it is not explained in the commit log message at all how they were chosen.
Were the other 40+ or so places inspected and deemed to be OK? Or is this
"I just did a few of them in addition to the immediate need of fixing what
was reported, and the rest are left as an exercise to the readers" patch?
Some variables that receive xstrdup()'ed result with this patch are
globals whose lifetime lasts while the process is alive, and I do not
think it is a huge problem that this patch does not free it, but it seems
the patch does not free some other function scope variables once their use
is done even when it is fairly easy to do so.
How much overhead would it incur if we return xstrdup()'ed memory from the
resolve_ref() and make it the caller's responsibility to free it? Would it
make the calling site too ugly?
^ permalink raw reply
* Re: [PATCH] Copy resolve_ref() return value for longer use
From: Nguyen Thai Ngoc Duy @ 2011-11-13 7:09 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Tony Wang
In-Reply-To: <7vehxcpns5.fsf@alter.siamese.dyndns.org>
2011/11/13 Junio C Hamano <gitster@pobox.com>:
> The above log message with the callchain would be a perfect explanation
> for a patch to fix builtin/merge.c and nothing else, but among 50+
> callsites of resolve_ref(), only 5 places are modified in this patch, and
> it is not explained in the commit log message at all how they were chosen.
> Were the other 40+ or so places inspected and deemed to be OK? Or is this
> "I just did a few of them in addition to the immediate need of fixing what
> was reported, and the rest are left as an exercise to the readers" patch?
I went through all of them. Most of them only checks if return value
is NULL, or does one-time string comparison. Others do xstrdup() to
save the return value. Will update the patch message to reflect this.
> Some variables that receive xstrdup()'ed result with this patch are
> globals whose lifetime lasts while the process is alive, and I do not
> think it is a huge problem that this patch does not free it, but it seems
> the patch does not free some other function scope variables once their use
> is done even when it is fairly easy to do so.
Will fix.
> How much overhead would it incur if we return xstrdup()'ed memory from the
> resolve_ref() and make it the caller's responsibility to free it? Would it
> make the calling site too ugly?
Given a lot of callsites do "if (resolve_ref(...)) ...", yes it may
look ugly. Though if you don't mind a bigger patch, we could turn
const char *resolve_ref(const char *path, const char *sha1, int
reading, int *flag);
to
int resolve_ref(const char *path, const char *sha1, int reading, int
*flag, char **ref);
where *ref is the current return value and is only allocated by
resolve_ref() if ref != NULL.
--
Duy
^ permalink raw reply
* [ANNOUNCE] Git 1.7.8.rc2
From: Junio C Hamano @ 2011-11-13 7:27 UTC (permalink / raw)
To: git; +Cc: Linux Kernel
A release candidate Git 1.7.8.rc2 is available for testing.
Since rc0, we killed all known regressions. Because there won't be any
more new feature merged until the 1.7.8 final, it is a good time for the
coolest kids on the block to start using the upcoming release before
others do.
The release tarballs are found at:
http://code.google.com/p/git-core/downloads/list
and their SHA-1 checksums are:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
b1cb030dee2b9ae024f4076fe5fadfea43edec4e git-1.7.8.rc2.tar.gz
cd30ce92f9518920ff8f9cdde0a8da5c856f6193 git-htmldocs-1.7.8.rc2.tar.gz
97d72c0c56e557eb3f11b9a3dcdb971e38eaee49 git-manpages-1.7.8.rc2.tar.gz
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)
iQIcBAEBAgAGBQJOv287AAoJELC16IaWr+bLGJwP/1ZL+9NcBiIWshqxrYaBACF6
dgLsK1M7iJBn95ye6xBp57uPeLGK9iv5qLvo5Wxoog8raWgceR3qXjZL3snfYlLO
Hz2P8Zb9EF80QfVs7RjkQYAJRaT/WzbSxoQF/ZUXHyLk2BHpw6YfYA0Vj0JJZ72l
bCYMnppi18uxLuUyf6/0ftlkadxv3L58VIaNWAp8NwuLuskucx64LZgYzwkaRFfO
YNWgV0zwimK+9SF/gnQ5cw55GCurs69HWoDVLJbnQuJbjiU3Kl9jehYBwTo/rPSn
vo03Foh3mV6u3DTovZARLF54goJvvc+JKKkFAdeY+dNKLdZQRdO+hrldGTeGKxVk
XissJxmsHm/DkXc15yIPu+iV5wmAXVc8BpTzK1NgleuOyz2qnvVrmY+ZOVQfM1BA
4zS6PMp/sgEJa6ybmwXuYY/JpJlgmEBsDk6MJOJ8RKt+q0qovB+2ltMJbFpqVnQR
VEswTvhBOmUSfKhiY68UmqE4H6vmSO5yOmo1VQKgCKzN7glcG/3wpIHNK9+QW9yE
eOQMSDdBQGGgzz7Y+bVwpbOpSUsc49MYit8T9wx/haNNCA3Fud1UUKbT+060/zQw
Tgv2gi/6L/vCcDhj7oersNYfpgilggYBeiADKsI1fw6SHzBpbWblJZTtjr1yplaZ
YG+o9yPd2EwA2tkosG51
=hXu/
-----END PGP SIGNATURE-----
Also the following public repositories all have a copy of the v1.7.8.rc2
tag and the master branch that the tag points at:
url = git://repo.or.cz/alt-git.git
url = https://code.google.com/p/git-core/
url = git://git.sourceforge.jp/gitroot/git-core/git.git
url = git://git-core.git.sourceforge.net/gitroot/git-core/git-core
url = https://github.com/gitster/git
----------------------------------------------------------------
Changes since v1.7.8-rc1 are as follows:
Felipe Contreras (1):
remote: fix remote set-url usage
Jeff King (1):
docs: don't mention --quiet or --exit-code in git-log(1)
Junio C Hamano (5):
remote: fix set-branches usage
docs: Update install-doc-quick
Git 1.7.7.3
Update draft release notes to 1.7.8
Git 1.7.8-rc2
Liu Yuan (1):
mktree: fix a memory leak in write_tree()
SZEDER Gábor (1):
completion: don't leak variable from the prompt into environment
^ 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