* specify charset for commits (Was: [PATCH] Fix documentation copy&paste typo)
From: Uwe Kleine-König @ 2006-12-21 8:59 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vac1jre1u.fsf@assigned-by-dhcp.cox.net>
Hello Junio,
Junio C Hamano wrote:
> Me, keyboard and Emacs screwed up and stored it in ISO-2022
> instead of UTF-8. Sorry.
It's a pity, but too late to change.[1]
What do you think about a patch that makes git-commit-tree call iconv on
its input to get it to UTF-8 (or any other charset). Maybe it
makes sense to add another header to commit objects (e.g.
"charset UTF-8") if something in the commit object is non-ASCII?
In my eyes it would make sense to even force UTF-8 for commit logs (and
author, committer). The downside is that it becomes impossible to store
arbitrary byte sequences in commit objects. (IMHO not a real
limitation.)
Best regards
Uwe
[1] actually I think it's worse, because my iconv (from Debian's libc6
version 2.3.6.ds1-8) was unable to convert it correctly to utf-8 for
any encoding that starts with ISO-2022.
--
Uwe Kleine-König
http://www.google.com/search?q=sin%28pi%2F2%29
^ permalink raw reply
* Re: What's in git.git (stable), and Announcing GIT 1.4.4.3
From: Junio C Hamano @ 2006-12-21 8:52 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git
In-Reply-To: <Pine.LNX.4.63.0612210942580.19693@wbgn013.biozentrum.uni-wuerzburg.de>
Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> Hi,
>
> On Wed, 20 Dec 2006, Junio C Hamano wrote:
>
>> Look for X-master-at: header in my message to see if you have that
>> commit, please.
>
> Nice!
Sorry for not advertising. The header has been there for a long
time.
^ permalink raw reply
* Re: [RFC/PATCH] Implement poor-man's submodule support in pre-commit hook
From: Junio C Hamano @ 2006-12-21 8:49 UTC (permalink / raw)
To: Andy Parkins; +Cc: git
In-Reply-To: <200612210839.35980.andyparkins@gmail.com>
Andy Parkins <andyparkins@gmail.com> writes:
>> As you fix them and enhance the support, I suspect you would
>> want a separate command to manage .gitmodule file and submodules
>> referenced by it. I think it would be better to keep the patch
>> to the template to the minimum (for example, run "git submodule
>> update" if there is .gitmodules file at the toplevel), and
>> implement the body of the processing in "git-submodule.sh", or
>> something like that.
>
> That's an interesting idea. I was thinking that git-commit
> itself would have been the final target; but I certainly don't
> have any problem with a separate command.
I do not think the commit command would be the "final" one.
When you have a loosely coupled subproject, sometimes you might
want to check out subprojects recursively, so you would also
want "checkout" action to "git submodule", which might hook into
"git checkout" just like your patch hooked into "git commit".
Similarly your future versions certainly would want to hook into
"git fetch/pull".
Just like some peoples' workflow avoid "git pull" but do "git
fetch" and "git merge" as separate steps, some people may want
to disable the above "hooks", and prefer using "git submodule"
from the command line as a separate step, especially if they
want very loose coupling.
^ permalink raw reply
* Re: cloning the kernel - why long time in "Resolving 313037 deltas"
From: linux @ 2006-12-21 8:41 UTC (permalink / raw)
To: git
Remember, OS X is FreeBSD somehow layered on top of Mach 3.
In particular, it calls though to Mach for virtual memory.
And Mach is at its heart an academic design aiming for flexibility in
its VM system rather tha performance. In particular, its provisions
for user-space pagers.
I can easily believe that its mmap is 10x slower that Linux. 60x is.. a
bit extreme. A Darwin kernel hacker should probably get a nudge about it.
^ permalink raw reply
* Re: What's in git.git (stable), and Announcing GIT 1.4.4.3
From: Johannes Schindelin @ 2006-12-21 8:43 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vvek66wlv.fsf@assigned-by-dhcp.cox.net>
Hi,
On Wed, 20 Dec 2006, Junio C Hamano wrote:
> Look for X-master-at: header in my message to see if you have that
> commit, please.
Nice!
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH 2/3] Add a test for git-rerere
From: Junio C Hamano @ 2006-12-21 8:41 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git
In-Reply-To: <Pine.LNX.4.63.0612210927150.19693@wbgn013.biozentrum.uni-wuerzburg.de>
Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
>> > +rm $rr/postimage
>> > +echo -ne "$sha1\ta1\0" > .git/rr-cache/MERGE_RR
>>
>> Hmmmmmm. I've stayed away from "echo -e" so far...
>
> Rather do it with tr? Like this:
>
> echo -n "$sha1 a1X" | tr X '\0' > .git/rr-cache/MERGE_RR
Bog-standard old timer's way is not to use -n nor X but just do:
echo "stuff you want to NUL terminate" | tr '\012' '\0'
> Is $((1+2)) portable enough? I always thought this is a bashism...
That's also in ksh and dash (and in POSIX) and recent updates to
out *.sh scripts make liberal use of them. As long as you do
not overflow you are fine.
^ permalink raw reply
* Re: [RFC/PATCH] Implement poor-man's submodule support in pre-commit hook
From: Andy Parkins @ 2006-12-21 8:39 UTC (permalink / raw)
To: git; +Cc: Junio C Hamano
In-Reply-To: <7vslfae4uv.fsf@assigned-by-dhcp.cox.net>
On Wednesday 2006 December 20 19:37, Junio C Hamano wrote:
> I do not think these are insurmountable.
Me either. I wasn't really sure how warmly these patches would be received,
so thought some small patches that make the feature highly might be more
palatable. I actually don't think that the hook templates is the right place
for this work; submodule support is not something you would customise
per-repository, and so the hook scripts are manifestly the wrong place for
this.
> As you fix them and enhance the support, I suspect you would
> want a separate command to manage .gitmodule file and submodules
> referenced by it. I think it would be better to keep the patch
> to the template to the minimum (for example, run "git submodule
> update" if there is .gitmodules file at the toplevel), and
> implement the body of the processing in "git-submodule.sh", or
> something like that.
That's an interesting idea. I was thinking that git-commit itself would have
been the final target; but I certainly don't have any problem with a separate
command.
Andy
--
Dr Andy Parkins, M Eng (hons), MIEE
andyparkins@gmail.com
^ permalink raw reply
* Re: [PATCH 2/3] Add a test for git-rerere
From: Johannes Schindelin @ 2006-12-21 8:34 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7v4prqfm6c.fsf@assigned-by-dhcp.cox.net>
Hi,
On Wed, 20 Dec 2006, Junio C Hamano wrote:
> Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
>
> > +sha1=4f58849a60b4f969a2848966b6d02893b783e8fb
> > +rr=.git/rr-cache/$sha1
> > +test_expect_success 'recorded preimage' "grep ======= $rr/preimage"
> > +
> > +test_expect_success 'no postimage or thisimage yet' \
> > + "test ! -f $rr/postimage -a ! -f $rr/thisimage"
>
> I am worried that this test specifies the behaviour a bit too
> precisely. It is not t0000 basic where we want bit-for-bit
> match with the expected result. Wouldn't this test break when
> you further improve xdl_merge, for example?
In this case, I doubt that xdl_merge() can do _anything_. The example is
set up so it _must_ fail with any sane merge algorithm.
And I very much wanted the behaviour put down very precisely, so that I
catch any bugs in builtin-rerere. In fact, as I went, I wrote the test
with the original rerere, and then whipped the builtin until it conformed.
Since anyone modifying rerere's behaviour can modify this test to catch
that behaviour, too, I am not so worried.
> > +rm $rr/postimage
> > +echo -ne "$sha1\ta1\0" > .git/rr-cache/MERGE_RR
>
> Hmmmmmm. I've stayed away from "echo -e" so far...
Rather do it with tr? Like this:
echo -n "$sha1 a1X" | tr X '\0' > .git/rr-cache/MERGE_RR
> > +sha2=4000000000000000000000000000000000000000
> > +rr2=.git/rr-cache/$sha2
> > +mkdir $rr2
> > +echo Hello > $rr2/preimage
>
> Collisions are not so likely and perhaps we do not care.
Both. If collisions were likely, we both would know by now _and_ would be
in serious trouble. And we do not care, since there cannot be any other
directory in rr-cache, apart from $sha1/.
> > +case "$(date -d @11111111 +%s 2>/dev/null)" in
> > +[1-9]*)
> > + # it is a recent GNU date. good.
> > + now=$(date +%s)
> > + let almost_15_days_ago=$now+60-15*86400
> > + let just_over_15_days_ago=$now-1-15*86400
> > + let almost_60_days_ago=$now+60-60*86400
> > + let just_over_60_days_ago=$now-1-60*86400
>
> Hmmmmm. I've stayed away from "let" so far as well...
Is $((1+2)) portable enough? I always thought this is a bashism...
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH] Attempt to make git-checkout man page a bit more clear.
From: Sean @ 2006-12-21 8:31 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vbqlx1yht.fsf@assigned-by-dhcp.cox.net>
On Wed, 20 Dec 2006 23:47:42 -0800
Junio C Hamano <junkio@cox.net> wrote:
> The 'restore from arbitrary tree-ish' form does not take -m as
> far as I know.
>
> Although it might be interesting to do a single-file three-way
> merge, I do not think the command is _checkout_ anymore once it
> starts doing that.
Yeah, I should have caught that. As well, your explanation makes me
wonder if it makes sense to change <branch> in the third form to
<tree-ish> ? Would you like an updated patch or will you just make
the touch up(s) yourself?
Sean
^ permalink raw reply
* Re: [PATCH] hooks/pre-commit: add example to add Signed-off-by line to message
From: Johannes Schindelin @ 2006-12-21 8:26 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vejqufonm.fsf@assigned-by-dhcp.cox.net>
Hi,
On Wed, 20 Dec 2006, Junio C Hamano wrote:
> Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
>
> >> Why SQUASH_MSG? Doesn't it confuse git-explain when it wants to
> >> detect that you are in the middle of a squash merge?
> >
> > Yes, it confuses git-explain. Which did not existed when I concocted the
> > first (broken) version of this patch. There are only two ways to give
> > commit message templates AFAICT: misusing SQUASH_MSG and misusing
> > MERGE_MSG.
>
> I wonder...
>
> # An example hook script to check the commit log message.
> # Called by git-commit with one argument, the name of the file
> # that has the commit message. The hook should exit with non-zero
> # status after issuing an appropriate message if it wants to stop the
> # commit. The hook is allowed to edit the commit message file.
Yes, I missed that.
Ciao,
Dscho
^ permalink raw reply
* Re: Updated Kernel Hacker's guide to git
From: Linus Torvalds @ 2006-12-21 7:51 UTC (permalink / raw)
To: Jay Cliburn; +Cc: git, Jeff Garzik
In-Reply-To: <4589FD9E.2010000@bellsouth.net>
On Wed, 20 Dec 2006, Jay Cliburn wrote:
>
> $ git diff $(git merge-base master driver)..driver
Be careful. This ONLY works if you don't have criss-cross merges etc, so
you need to be somewhat careful about it. If you end up having a complex
merge history between the origin branch and your development tree, things
will stop working
So it's actually worth understanding what the above does.
Here's the picture to keep in mind: you started off with something like
this:
<- older newer ->
..--A---B---C---D
where the top commit was D, and you started doing your own work off there.
However, the tree you are tracking (doing "git fetch origin" or somethng)
ALSO continues, so soon enough you'll have a history that looks like
<- older newer ->
..--A---B---C---D---E---F---G---H <-"origin"
\
--X---Y---Z <- your "driver" branch"
where your work is the "X-Y-Z" sequence.
How, the reason you must NOT do
git diff origin..driver
or something like that, is that it will LITERALLY do a diff between those
two heads. And while that is a perfectly normal diff, it's not what you
want: it's the diff between the up-stream work and yours, and it will show
that a lot of work has _not_ happened in your branch (all the E-F-G-H
stuff), and then you've added some work (X-Y-Z).
What you obviously WANT to have is the "diff" between "D" (which was the
point where you started) and "Z" (which is where you are now. That's what
you want to send up-stream.
Now, the way people used to do this under CVS, was to simply _remember_ D.
Preferably by doing a tag at the point where they started working. Then
you can always diff against that tag.
You can do that in git too, of course, but it would just be stupid.
Because git actually _knows_ the history, so you can just ask git
"What is the most recent commit that both 'origin' and 'driver'
have in common?"
the answer, of course, is the very commit you want: D. And how do you ask
for that "most recent common commit"? That's right: it's called the "merge
base", because it's also the thing you'd use as the base in a bog-standard
three-way merge.
So "git merge-base origin driver" just returns "D", without you having had
to tag it or remember it at all.
So when you do
git diff $(git merge-base origin driver)..driver
you're literally asking for the diff between your current top of the
"driver" branch, and the place where you diverged from "origin".
Now, why do I mention the fact that THIS DOES NOT WORK if you do merges
and you no longer have a linear tree? Think about it. If you actually ever
pull on the up-stream and create a merge in your development tree, the
commit history graph will now look something like this:
<- older newer ->
..--A---B---C---D---E---F---G---H <-"origin"
\ \
--X---Y--M--Z <- your "driver" branch"
where the "M" commit is because you merged some new work from origin.
But see what that did to the most recent commit? Now, the most recent
commit is no longer "D". In fact, it's not even your "merge" commit, if
you think about it (even though you might naively think so), because that
merge commit doesn't even exist in "origin", so clearly it cannot be the
most recent common commit.
The most recent commit in common is "F". So now,
git diff $(git merge-base origin driver)..driver
will give the difference between _F_ and your current tip Z.
The thing is, THIS IS STILL THE RIGHT THING TO DO. It's magic. Since you
did a merge in M, all the things up until F have been merged into Z too,
so you actually NO LONGER want to diff against D. Nor do you want to diff
against M (since that would mean that you would not see the work you did
in X and Y).
By doing a diff against F (and your own merge having done the right
thing), you actually end up getting the "union" of work for X-Y-Z when you
do that magic command line. If you had done it against D, you'd have seen
the work in E and F that the merge M brought in - but you don't want that,
because you want just the work YOU did, not anything in "origin".
So what you want is actually exactly again the most recent common commit.
HOWEVER. While it magically "just works" in things like this, it doesn't
actually work for the really complex cases. If I've merged an eariler
version of your work AND you did a merge from me too, you can have a
criss-cross merge where there simply isn't one "most recent common commit"
at all any more, but two or more. And then you really do need to do more.
This is one reason why I suggest developers not merge from me very often:
if your development tree is just a straight line (ie you only had that one
merge), you can't ever even get in that situation, and perhaps as
importantly, if/when I pull from you, the result will also tend to look
more understandable to people who look at the history.
But another way to avoid a criss-cross merge is actually to never let me
see your tree at all, and then you can merge with me as often as you damn
well like. And in that case, the magic
git diff $(git merge-base origin driver)..driver
is always going to give you exactly what you want. You can use merges to
keep up-to-date, and always see what you want to send off by email
upstream. The history will look like crap (you'll end up having a ton of
merges in your tree), but if you aren't going to publicise your history
anyway (just the diff end result), why would you care?
(And yes, you can actually do "git diff origin...driver" with _three_
dots. I'm not even going to explain _why_ that works, because that's a
whole other kettle of fish, and is actually a magic special case in
builtin-diff.c. So feel free to use it because it's short and sweet, but
the long format is actually easier to explain what it actually MEANS).
Linus
^ permalink raw reply
* Re: [PATCH] Attempt to make git-checkout man page a bit more clear.
From: Junio C Hamano @ 2006-12-21 7:47 UTC (permalink / raw)
To: Sean; +Cc: git
In-Reply-To: <20061221015350.245cc964.seanlkml@sympatico.ca>
Sean <seanlkml@sympatico.ca> writes:
> diff --git a/Documentation/git-checkout.txt b/Documentation/git-checkout.txt
> index fbdbadc..97c3afe 100644
> --- a/Documentation/git-checkout.txt
> +++ b/Documentation/git-checkout.txt
> @@ -8,23 +8,29 @@ git-checkout - Checkout and switch to a branch
> SYNOPSIS
> --------
> [verse]
> +'git-checkout' [-f] [-m] <branch>
> +'git-checkout' [-f] [-b <new_branch> [-l]] [-m] [<commit-ish>]
> 'git-checkout' [-m] [<branch>] <paths>...
>
> DESCRIPTION
> -----------
> ...
> +With the third form, this command does *not* switch branches.
> +Instead, it replaces the contents of the named paths in your
> +working tree from the index. Here, the <branch> argument can be
> used to specify a specific tree-ish to update the index for the
> given paths before updating the working tree.
The 'restore from arbitrary tree-ish' form does not take -m as
far as I know.
Although it might be interesting to do a single-file three-way
merge, I do not think the command is _checkout_ anymore once it
starts doing that.
That is:
$ git checkout -f master
$ edit file.c
$ git that-funny-command next file.c
would steal the version of file.c from 'next', and merge the
change your locally did on top of 'master', and put it in your
working tree and in the index. Technically I can explain how
that work (and how it could be implemented -- which is trivial),
but I cannot explain what that operation _means_.
^ permalink raw reply
* Re: Updated Kernel Hacker's guide to git
From: Junio C Hamano @ 2006-12-21 7:32 UTC (permalink / raw)
To: Martin Langhoff; +Cc: git, Jay Cliburn
In-Reply-To: <46a038f90612202304uabdffacld857cfcb90ec3e76@mail.gmail.com>
"Martin Langhoff" <martin.langhoff@gmail.com> writes:
> On 12/21/06, Jay Cliburn <jacliburn@bellsouth.net> wrote:
>> $ git diff $(git merge-base master driver)..driver
>
> There is a nicer way to do it with 1.4.x git -- note the 3 dots:
>
> $ git diff master...driver
Careful.
I think Jay was looking at this kind of ancestry graph:
*---*---*---* driver
/
--o---o---x---x---x---x master
There might be quite a few merges on either side, but the point
is '*' are not yet 'in', and 'o' and 'x' are already in the
'upstream (but 'x' are not in Jay's driver yet).
The three dots would give both '*' and 'x'; I do not think that
is what Jay wants. A submitter to mainline usually wants only
'*' commits.
I've always thought that 'submission' is supposed to be done as
a series of patches, in which case a reasonable way would be to
do:
git format-patch -n master driver
If on the other hand a single roll-up patch is desired, I think
the most reasonable thing to do is to first merge the tip of the
master to the tip of driver, resolve all the conflicts as
needed, and take the diff between the 'master' and the result:
*---*---*---*---y driver (y is the test merge)
/ /
--o---o---x---x---x---x master
git checkout driver
git merge master
... resolve conflicts if any, then "git commit"
git diff master
This diff by definition should apply cleanly to the tip of
'master' and would result in the source that contains the
updates for the driver.
When you are done, it would be advisable to do:
git reset --hard HEAD^
to remove that 'y' merge, unless the merge involved a true
conflict resolution.
^ permalink raw reply
* Re: Updated Kernel Hacker's guide to git
From: Martin Langhoff @ 2006-12-21 7:04 UTC (permalink / raw)
To: Jay Cliburn; +Cc: git, Jeff Garzik
In-Reply-To: <4589FD9E.2010000@bellsouth.net>
On 12/21/06, Jay Cliburn <jacliburn@bellsouth.net> wrote:
> $ git diff $(git merge-base master driver)..driver
There is a nicer way to do it with 1.4.x git -- note the 3 dots:
$ git diff master...driver
cheers,
martin
^ permalink raw reply
* Re: Updated Kernel Hacker's guide to git
From: Jay Cliburn @ 2006-12-21 3:21 UTC (permalink / raw)
To: git; +Cc: Jeff Garzik
In-Reply-To: <4589F9B1.2020405@garzik.org>
Jeff Garzik wrote:
> I refreshed my git intro/cookbook for kernel hackers, at
> http://linux.yyz.us/git-howto.html
>
> This describes most of the commands I use in day-to-day kernel hacking.
> Let me know if there are glaring errors or missing key commands.
Thanks for doing this. I've referred to your previous page rather often
as I grope around trying to learn git and hack a vendor driver for
submittal into the mainline kernel.
One thing that baffled me was how to use git to create a "kitchen sink"
diff that would produce my entire driver suitable for submittal to lkml
for review. This probably isn't needed very often, but for new driver
submittals it's important to know how to do it. Francois Romieu showed
me how (assume the new driver branch is named "driver"):
$ git diff $(git merge-base master driver)..driver
As a beginner, this command continues to be utterly non-intuitive to me,
but it works. There may be other ways to do it, too.
The point is, I think you should add instructions on your cookbook that
address how to produce such a "kitchen sink" diff if you're submitting a
brand new driver to lkml. (Obviously I don't know what such a diff is
actually called.)
Jay
^ permalink raw reply
* Re: GIT - error: no such remote ref refs/heads/TestBranch
From: Carl Worth @ 2006-12-21 6:55 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7v1wmu5ecs.fsf@assigned-by-dhcp.cox.net>
[-- Attachment #1: Type: text/plain, Size: 3531 bytes --]
On Wed, 20 Dec 2006 15:36:51 -0800, Junio C Hamano wrote:
> Do you have comments on recent changes (both on 'master' and
> some parts of 'next') from teachability point of view? I think
> you are "the guilty guy" who defined the theme for v1.5.0 to be
> "usability and teachability" ;-).
I'm flattered to be blamed for what I consider a very good theme for
the release.
I don't have a lot of detailed comments right now other than to repeat
a "good job!" to everyone who has done a lot to improve things lately,
(coming up with more use-oriented documentation, adding a reasonable
shorthand "add"[*] for update-index, cleaning up a lot of bad error
message and needless spew, making much more reasonable default clone
behavior, etc. etc.). I think git's really come a long ways as far as
usability and teachability, (while nothing fundamental has really
changed and old-time users should hardly notice anything different).
I think I'll have a few minor tweaks to suggest to the documentation
if I get a chance to take a detailed pass over it, (which I hope to do
before the new year).
And I'd definitely like to enable "git checkout <revision>" with a new
complaint on git-commit before the 1.5 release. I'll see if I can't
find time to work on implementing that.
-Carl
[*] I'm still somewhat unsettled that the "new" add command conflates
the notions of adding content into the index for paths that previously
didn't exist in the index with the notion of updating the content in
the index for paths that did exist already. I think those notions are
generally distinct from the users point of view---the first changes a
file's state in a fundamental way, (from "untracked" to "tracked"),
while the second merely updates its content with no change to its
state.
One way to see the distinction is to imagine two different useful
operations "add all untracked file paths to the index" and "update
content for all tracked paths". If we had separate commands for 'add'
and 'update' then it would be natural to express these two variants
with "git add --all" and "git update --all".
As things stand now, the first operation is available already with
"git add .", (and oddly, with "git add", and I agree that should be
removed). Meanwhile the second operation is not currently available in
git, (but I recently proposed it as "git add -a|--all" in response to
a request). As pointed out in that thread, there's a bit of a problem
in that "git add --all" is really easy to mistake for a command that
would add all untracked files to the index, (since it's when adding
new paths that people will most often use "git add" so it will
naturally be associated with adding new paths). It's less likely for
users to establish the "update content" notion of "git add" since it
often won't be needed at all, (tutorials and the git-commit
documentation recommend "commit -a" to avoid the need to use "git add"
in its updating sense).
So, to summarize, I think it's good to have a much shorter command to
type than "update-index" for the update-content-of-path-in-index
operation. So using "add" for this is better than "update-index"
already. And if that's how it stays, I can certainly live with it.
But I think it might be even better if the updating notion were on a
separate command name (update ? stage ?), and this in spite of the
fact that fewer commands is generally better for learnability.
It's not a major issue---and it's nothing that I would make a big fuss
over, so feel free to ignore it if it appears a non-issue to you.
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* [PATCH] Attempt to make git-checkout man page a bit more clear.
From: Sean @ 2006-12-21 6:53 UTC (permalink / raw)
To: git
Signed-off-by: Sean Estabrooks <seanlkml@sympatico.ca>
---
Documentation/git-checkout.txt | 40 +++++++++++++++++++++++++++-------------
1 files changed, 27 insertions(+), 13 deletions(-)
A recent question on another list, quoted below, shows a
new git user getting stuck on something pretty simple:
>> I'm after all the source of the drm 2.3.0 release.
>>
>> How do I use git to get all the source that drm-2.3.0 tags?
>> I need the kernel drivers as well as the user land code
>> so the tarball is no use to me.
>>
>> All the git docs tell me how to create a tag, but I have not
>> found a single use show how to get a tree of files that correspond
>> to a tag.
Hopefully this patch is accurate and would help a bit.
Sean
diff --git a/Documentation/git-checkout.txt b/Documentation/git-checkout.txt
index fbdbadc..97c3afe 100644
--- a/Documentation/git-checkout.txt
+++ b/Documentation/git-checkout.txt
@@ -8,23 +8,29 @@ git-checkout - Checkout and switch to a branch
SYNOPSIS
--------
[verse]
-'git-checkout' [-f] [-b <new_branch> [-l]] [-m] [<branch>]
+'git-checkout' [-f] [-m] <branch>
+'git-checkout' [-f] [-b <new_branch> [-l]] [-m] [<commit-ish>]
'git-checkout' [-m] [<branch>] <paths>...
DESCRIPTION
-----------
-When <paths> are not given, this command switches branches by
-updating the index and working tree to reflect the specified
-branch, <branch>, and updating HEAD to be <branch> or, if
-specified, <new_branch>. Using -b will cause <new_branch> to
-be created.
-
-When <paths> are given, this command does *not* switch
-branches. It updates the named paths in the working tree from
-the index file (i.e. it runs `git-checkout-index -f -u`). In
-this case, `-f` and `-b` options are meaningless and giving
-either of them results in an error. <branch> argument can be
+Checkout the given branch, populating your working tree with its
+contents. In the first form listed above, this command only
+allows you to checkout an existing branch, not an arbitrary point
+from the history. You can use the git-branch command to create
+such branches.
+
+The second form of the command allows you to create a new branch
+and check it out in one step. You specify the new branch name
+with the "-b" option, followed by a reference to the commit that
+will become the HEAD of the new branch. Note that you can specify
+this commit by tag name, an existing branch name, or any other
+reference specification git allows.
+
+With the third form, this command does *not* switch branches.
+Instead, it replaces the contents of the named paths in your
+working tree from the index. Here, the <branch> argument can be
used to specify a specific tree-ish to update the index for the
given paths before updating the working tree.
@@ -32,7 +38,8 @@ given paths before updating the working tree.
OPTIONS
-------
-f::
- Force a re-read of everything.
+ Force a switch to the given branch even when uncommitted
+ changes in your working tree will be lost as a result.
-b::
Create a new branch named <new_branch> and start it at
@@ -92,6 +99,13 @@ You should instead write:
$ git checkout -- hello.c
------------
+. To create a branch based on the contents marked by a given tag
+and check it out in a single step:
++
+------------
+$ git checkout -b newbranch tag1.2.3
+------------
+
. After working in a wrong branch, switching to the correct
branch would be done using:
+
--
1.4.4.2.g8336
^ permalink raw reply related
* Re: Updated Kernel Hacker's guide to git
From: Nigel Cunningham @ 2006-12-21 5:53 UTC (permalink / raw)
To: Jeff Garzik; +Cc: Linux Kernel, Git Mailing List
In-Reply-To: <4589F9B1.2020405@garzik.org>
Hi.
On Wed, 2006-12-20 at 22:04 -0500, Jeff Garzik wrote:
> I refreshed my git intro/cookbook for kernel hackers, at
> http://linux.yyz.us/git-howto.html
>
> This describes most of the commands I use in day-to-day kernel hacking.
> Let me know if there are glaring errors or missing key commands.
Thanks for the work! I'd suggest also saying how to repack and cleanup.
Could also be a good idea to go through the steps for uploading to
master.kernel.org or elsewhere?
Regards,
Nigel
^ permalink raw reply
* Re: Updated Kernel Hacker's guide to git
From: Willy Tarreau @ 2006-12-21 5:44 UTC (permalink / raw)
To: Jeff Garzik; +Cc: Linux Kernel, Git Mailing List
In-Reply-To: <4589F9B1.2020405@garzik.org>
Hi Jeff !
On Wed, Dec 20, 2006 at 10:04:17PM -0500, Jeff Garzik wrote:
> I refreshed my git intro/cookbook for kernel hackers, at
> http://linux.yyz.us/git-howto.html
Thanks for this update, it was my most useful source of inspiration
when I started with git.
> This describes most of the commands I use in day-to-day kernel hacking.
> Let me know if there are glaring errors or missing key commands.
I very often use "git-format-patch -k -m" to produce individual patches
that I delay, merge in other branches, or even in other trees with
"git-am -k -3". I believe it was Davem who suggested this a while ago,
and I agree it's very convenient to maintain a patch collection (and
sometimes to clean them up).
Also, I think that for beginners, you have not insisted enough on the
fact that they should not modify the master branch, but that they
should immediately create their own branch before any local changes.
I got caught by this when I started, and had trouble playing with the
origin branch to try to fix my mistakes.
Overall it's a good tutorial anyway.
Cheers,
Willy
^ permalink raw reply
* Re: git 1.4.4.2 is giving the following errors...
From: Junio C Hamano @ 2006-12-21 5:29 UTC (permalink / raw)
To: git
In-Reply-To: <ace3f33d0612202115p3fedb169pf235c4556f2eef57@mail.gmail.com>
"srinivas naga vutukuri" <srinivas.vutukuri@gmail.com> writes:
> I am new to git.
Lose the CDPATH from your environment. It's a fine variable to
have in your interactive shells, but it never makes sense to
export into your environment.
^ permalink raw reply
* git 1.4.4.2 is giving the following errors...
From: srinivas naga vutukuri @ 2006-12-21 5:15 UTC (permalink / raw)
To: git
Hi,
I am new to git.
From the web site downloaded the 1.4.4.2 source and compiled on the
cygwin environment.
when am trying as an example to use the git,
------------------------------------snip----------------------------------------------------------
sh-3.2$ git clone git://git.kernel.org/pub/scm/git/git.git
: command not foundclone: line 7:
': not a valid identifier line 9: unset: `CDPATH
: command not foundclone: line 10:
'usr/local/bin/git-clone: line 11: syntax error near unexpected token `{
'usr/local/bin/git-clone: line 11: `die() {
sh-3.2$ git clone http://git.kernel.org/pub/scm/git/git.git
: command not foundclone: line 7:
': not a valid identifier line 9: unset: `CDPATH
: command not foundclone: line 10:
'usr/local/bin/git-clone: line 11: syntax error near unexpected token `{
'usr/local/bin/git-clone: line 11: `die() {
------------------------------------snip---------------------------------------------------------
i am facing the above prints. Could you please help me out, am i doing
any thing wrong?
best regards,
srinivas.
^ permalink raw reply
* [PATCH] Documentation/git-branch: new -r to delete remote-tracking branches.
From: Quy Tonthat @ 2006-12-21 4:18 UTC (permalink / raw)
To: git
Signed-off-by: Quy Tonthat <qtonthat@gmail.com>
---
For the version of git-branch currently in "next".
Documentation/git-branch.txt | 13 ++++++++-----
1 files changed, 8 insertions(+), 5 deletions(-)
diff --git a/Documentation/git-branch.txt b/Documentation/git-branch.txt
index 71417fe..c464bd2 100644
--- a/Documentation/git-branch.txt
+++ b/Documentation/git-branch.txt
@@ -11,7 +11,7 @@ SYNOPSIS
'git-branch' [-r | -a] [-v [--abbrev=<length>]]
'git-branch' [-l] [-f] <branchname> [<start-point>]
'git-branch' (-m | -M) [<oldbranch>] <newbranch>
-'git-branch' (-d | -D) <branchname>...
+'git-branch' (-d | -D) [-r] <branchname>...
DESCRIPTION
-----------
@@ -33,7 +33,8 @@ to happen.
With a `-d` or `-D` option, `<branchname>` will be deleted. You may
specify more than one branch for deletion. If the branch currently
-has a ref log then the ref log will also be deleted.
+has a ref log then the ref log will also be deleted. Use -r together with -d
+to delete remote-tracking branches.
OPTIONS
@@ -60,7 +61,7 @@ OPTIONS
Move/rename a branch even if the new branchname already exists.
-r::
- List the remote-tracking branches.
+ List or delete (if used with -d) the remote-tracking branches.
-a::
List both remote-tracking branches and local branches.
@@ -111,10 +112,12 @@ Delete unneeded branch::
------------
$ git clone git://git.kernel.org/.../git.git my.git
$ cd my.git
-$ git branch -D todo <1>
+$ git branch -d -r todo html man <1>
+$ git branch -D test <2>
------------
+
-<1> delete todo branch even if the "master" branch does not have all
+<1> delete remote-tracking branches "todo", "html", "man"
+<2> delete "test" branch even if the "master" branch does not have all
commits from todo branch.
--
1.4.4.1.GIT
^ permalink raw reply related
* Re: [RFC] gitweb wishlist and TODO list (part 1)
From: Robert Fitzsimons @ 2006-12-21 3:22 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git, Kernel Org Admin, Petr Baudis
In-Reply-To: <200612170000.06771.jnareb@gmail.com>
> * Cache validation and infinite cache for unchanging pages
>
> By itself cache validation would not bring much performance boost (for
> gitweb installations with large traffic), but with the reverse proxy,
> aka. caching engine, aka. HTTP accelerator in front of server this could
> help a lot.
There is no need for extra servers to provide server side caching.
Apache2 includes suitable modules (mod_cache) which can be configured to
cache in memory or disk the pages generated by gitweb.
For example the following apache2.conf entry will setup a 8MB mem cache
which will return cached pages even if the user tries to force a refresh
in their browser. The details are covered in the apache documentation
http://httpd.apache.org/docs/2.2/caching.html .
<IfModule mod_cache.c>
CacheDefaultExpire 60
CacheIgnoreCacheControl On
CacheIgnoreNoLastMod On
<IfModule mod_mem_cache.c>
CacheEnable mem /git/
MCacheSize 8192
MCacheMinObjectSize 512
MCacheMaxObjectSize 128000
MCacheRemovalAlgorithm LRU
</IfModule>
</IfModule>
mod_cache will only cache pages with a query string in the url if they
have an expires header. So we can put a temporary hack in using
mod_expires until gitweb sets an appropriate value.
<Location /git/>
ExpiresActive On
ExpiresDefault "access plus 1 minutes"
...
</Location>
Also the content type would need to be change to just return text/html
or MSIE will do the wrong think if it's given a application/xhtml+xml
page.
Robert
^ permalink raw reply
* Updated Kernel Hacker's guide to git
From: Jeff Garzik @ 2006-12-21 3:04 UTC (permalink / raw)
To: Linux Kernel; +Cc: Git Mailing List
I refreshed my git intro/cookbook for kernel hackers, at
http://linux.yyz.us/git-howto.html
This describes most of the commands I use in day-to-day kernel hacking.
Let me know if there are glaring errors or missing key commands.
Jeff
^ permalink raw reply
* Re: [BUG] daemon.c blows up on OSX
From: Albert Cahalan @ 2006-12-21 2:52 UTC (permalink / raw)
To: junkio, merlyn, git, linux-kernel
Linus Torvalds writes:
> So it would appear that for OS X, the
>
> #define _XOPEN_SOURCE_EXTENDED 1 /* AIX 5.3L needs this */
> #define _GNU_SOURCE
> #define _BSD_SOURCE
> sequence actually _disables_ those things.
Yes, of course. The odd one here is glibc.
Normal systems enable everything by default. As soon as you
specify a feature define, you get ONLY what you asked for.
I'm not sure why glibc is broken, but I suspect that somebody
wants to make everyone declare their code to be GNU source.
(despite many "GNU" things not working on the HURD at all)
Define _APPLE_C_SOURCE to make MacOS X give you everything.
^ 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