* Re: reset reports file as modified when it's in fact deleted
From: Junio C Hamano @ 2011-11-12 0:11 UTC (permalink / raw)
To: Jeff King; +Cc: Carlos Martín Nieto, git
In-Reply-To: <20111111182109.GB16055@sigill.intra.peff.net>
Jeff King <peff@peff.net> writes:
> On Fri, Nov 11, 2011 at 08:43:34AM -0800, Junio C Hamano wrote:
>
> I agree the naming is awkward (but then, I think the "needs update"
> message is awkward ;) ). But my interpretation was: if you want the
> index to be in sync with the working tree, you must do this. Hence:
>
> $EDITOR file ;# triggers needs_update
> git update-index file ;# and do update in index
> rm file ;# triggers needs rm
> git rm --cached file ;# and do rm in index
The word "update" at the plumbing level simply means "update the path in
the index". At the Porcelain level you have to use "git add" or "git rm"
depending on different kind of "needs update", which may be argued an
inconsistency, but at the plumbing level everything is done with the same
update-index command, and "needs update" is the word that matches your
interpretation.
I however think the topic was about updating the Porclain-ish output that
is similar to "status -s" output. And at that level, paths marked with M/T
and D are dealt differently by end users ("add" vs "rm").
And the ? : expressions the patch is touching is about mapping the state
of the path to your "you must do this" interpretation. What is being
mapped is the state, so it would be more natural to have the variable
"modified_fmt" hold the result of the mapping "you must do...", instead of
calling the variable in terms of "you must do this if you were working at
the plumbing level", which is where the original needs_update_fmt naming
comes from.
>> An obvious solution would be to rename all of them to be based on "what
>> happened to the path". E.g. "modified_fmt" would be set to either "M" or
>> "needs update", and "removed_fmt" would be set to either "D" or "needs
>> update", etc.
>
> I'm happy to make that change. What do you think of the feature overall?
The "feature" is more or less "Meh" to me; I do not mind differentiating M
and D there because the necessary information is already there in the
codepath, but if we were to really do that, then the variables must be
renamed. We shouldn't name them after "you must do this at the plumbing
level" like we have done so far, and instead use "the path is in this
state". This is even more so if we were to further split a single "state"
that plumbing layer considers the same and gives the same "needs X" to
different states that Porcelains would give different messages in the
future.
> And should typechanges also be handled here (it's no extra work for git
> to detect them; we just have to pass the TYPE_CHANGED flag back up the
> stack)?
As long as "pass ... back up the stack" does not result in too much
ugliness in the code, I am OK with it.
^ permalink raw reply
* Re: Git: Unexpected behaviour?
From: J.V. @ 2011-11-12 0:24 UTC (permalink / raw)
Cc: git
In-Reply-To: <4EBD9428.3030506@gmail.com>
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?
On 11/11/2011 2:31 PM, Chris Packham wrote:
> Hi,
>
> On 12/11/11 09:55, Jvsrvcs wrote:
>> 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
> One thing to remember is that this is the same as "git add readme.txt"
> and "git commit" (I'll explain why below).
>
>> # 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
> At this point the changes are in the work tree. They aren't added to the
> test branch until you commit them.
>
>> #now switch back to master
>> $git checkout master
> When you have uncommited changes in the work tree that don't conflict
> with the contents of the branch you are checking out git will happily
> carry them along for you. If they did conflict then git would refuse to
> switch to the new branch.
>
>> $cat readme.txt
>>
>> #You will see both lines in the master.
>>
>> Question #1:
>> Why was this line added in the *master branch?
> Because the second change hasn't been committed it isn't in either
> branch. It's in the work tree.
>
>> --- 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?
> Because you asked for it to 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?
> Because the second change was committed (in the master branch) it is
> no-longer floating in the work tree so when you switch branches you get
> the contents of the file in that branch.
>
>> 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.
>>
> Hopefully this will explain things a little better
>
> [work-tree] -- git add -> [index] -- git commit --> [HEAD]
>
> work-tree: the area on the file system where your code is checked out.
> index: also known as the staging area, this is represents what will end
> up in the next commit.
> HEAD: a general term for the current branch.
>
> As you can see that until a change is committed it isn't in _any_
> branch. When you type "git checkout test" or "git checkout master" HEAD
> will be updated. Changes in the work-tree or the index will be carried
> along (provided they don't conflict with the new HEAD).
>
> Hope that helps.
>
>
^ permalink raw reply
* Re: Git: CVS to Git import
From: Jonathan Nieder @ 2011-11-12 0:24 UTC (permalink / raw)
To: Jvsrvcs; +Cc: Jakub Narebski, git
In-Reply-To: <m3obwimdi1.fsf@localhost.localdomain>
Hi,
Jakub Narebski wrote:
> Jvsrvcs <jvsrvcs@gmail.com> writes:
>> Git: CVS to Git import
>>
>> We are moving from CVS to Git and want to know if anyone has had any
>> experience there doing this and could share do's / dont's, best practices
>> when doing the initial import.
[...]
> I think that Eric S Raymond "DVCS Migration Guide"
>
> http://www.catb.org/esr/dvcs-migration-guide.html
That page says that "git cvsimport" tends to be your best bet. But my
experience is exactly the opposite --- git-cvsimport can make a lot of
mistakes, some of them documented in the ISSUES section of its
manpage, and it is hard to notice until later.
I've have good experiences using cvs2git from
<git://repo.or.cz/cvs2svn.git> (but note that it does not support
incremental imports).
> and reposurgeon tool (to clean up conversion artifacts)
>
> http://www.catb.org/esr/reposurgeon/
Last time I checked, reposurgeon loads the entire history in memory.
For projects with a longer history, "git filter-branch" might be a
better fit.
By the way, thanks for writing. If your experience results in some
ideas for improving Documentation/gitcvs-migration.txt page, we'll
probably be happy to take them. :)
Good luck,
Jonathan
^ permalink raw reply
* Fw:“เพียงดิน” ยอมรับ ทำระยำเพื่อดึงกระแสสู้น้ำท่วม
From: 4everche @ 2011-11-12 2:03 UTC (permalink / raw)
To: git
“เพียงดิน” ยอมรับ ทำระยำเพื่อดึงกระแสสู้น้ำท่วม
เมื่อหลายวันมานี้พี่น้องเสื้อแดงใน Internetfreedom คงเห็นแล้วว่า “เพียงดิน”
ได้ตั้งกระทู้จุดพลุมากมาย ด่าเสื้อแดงเป็นควายบ้าง ด่าอาจารย์สมศักดิ์ เจียมธีรสกุลบ้าง หรือ
กล่าวพาดพิงถึงสถาบันว่าอยู่เบื้องหลังน้ำท่วม และอีกมากโดยไม่มีสาระเลย เพียงแต่ต้องการให้คน
เข้ามาอ่านมากๆ เมื่อพี่น้องเสื้อแดงจับได้ไล่ทันและถูกวิพากษ์วิจารณ์อย่างหนักก็หลบหน้าไปพักหนึ่ง
แต่คนใน IF ตั้งข้อสังเกตว่ามีนามแฝงอื่นเข้ามาตั้งกระทู้และมีเนื้อหาสำนวนคล้ายกับ “เพียงดิน”
ในที่สุด Seeds of Democracy รายการของ“เพียงดิน” ก็ออกมาแบ่งรับแบ่งสู้ว่า ไม่อยากให้
พี่น้องเสื้อแดงสนใจเรื่องน้ำท่วมมากเกินไปจนลืมอุดมกาณ์ จึงได้คิดจะดึงกระแสสู้กับเรื่องน้ำท่วมเท่านั้น
ไม่ได้ตั้งใจทำเรื่องเลวเลวแบบนี้
^ permalink raw reply
* 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
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