* RE: for newbs = little exercise / tutorial / warmup for windows and other non-sophisticated new Git users :-) [Scanned]
From: Daniel Barkalow @ 2008-12-31 3:49 UTC (permalink / raw)
To: Conor Rafferty; +Cc: Jeff Whiteside, Boyd Stephen Smith Jr., git
In-Reply-To: <alpine.LNX.1.00.0812302143210.19665@iabervon.org>
On Tue, 30 Dec 2008, Daniel Barkalow wrote:
> On Wed, 31 Dec 2008, Conor Rafferty wrote:
>
> > -----Original Message-----
> > wtf is wrong with
> >
> > git checkout <something>
> >
> > ??
> >
> > ** It doesn't reliably put the files that were in that revision into the
> > working directory - a fairly major flaw, for what I'm using SCM for (and
> > 80% of the market IMHO)
>
> It certainly does for me; I rely on it pretty much constantly. Can you
> give a sequence of commands (ideally the whole sequence from the "git
> init") that leads to a difference?
Actually, I know what you must be doing:
$ git tag versionD
$ git checkout versionA
(versionA in the working directory)
$ rm *.*
(versionA with ABC.txt and AC.txt deleted)
$ git checkout versionB
(versionB with ABC.txt and AC.txt deleted)
If you've made any changes (including deleting files), "git checkout" (no
pathes) will preserve them. On the other hand, it will remove files that
are in the commit you're leaving and not in the commit you're going to. So
just don't remove the working directory files and you should be all set.
In order to get them back if you have removed them, you can do:
$ git checkout .
This will discard all of the changes you've made only to the working
directory; i.e., it'll recover the deleted files. You should also try "git
status" whenever anything's mysterious, because it will tell you what's
going on.
-Daniel
*This .sig left intentionally blank*
^ permalink raw reply
* Re: for newbs = little exercise / tutorial / warmup for windows and other non-sophisticated new Git users :-) [Scanned]
From: Boyd Stephen Smith Jr. @ 2008-12-31 3:40 UTC (permalink / raw)
To: Conor Rafferty; +Cc: Jeff Whiteside, Daniel Barkalow, git
In-Reply-To: <BB5F02FD3789B54E8964D38D6775E718242D36@ALTMORE-SVR.altmore.local>
[-- Attachment #1: Type: text/plain, Size: 1231 bytes --]
On Tuesday 2008 December 30 20:30:46 Conor Rafferty wrote:
> MERCURIAL:
>
> Update
> hg update [-C] [-d DATE] [[-r] REV]
Which is the role of "git checkout <branch>"
"git checkout <branch> <paths>" is similar to "hg revert -r <branch> <paths>",
but the later seems to handle your use case properly. I don't know much
about the workings of hg revert -- it might use the history to determine
what's correct, or completely bypass the existing "index" when determining
what to drop. In any case, it seems to work better for what you are trying
to do. Why not just use it?
I could do with more hg/bzr/darcs experience myself, but git seems to behave
the way I like it so it's what I use. When deciding on the right tool for
the job, it does help to have many. "To the man with only a hammer, all
problems look like nails."
That said, I'm pretty sure that if you hasn't specified '.' and just used "git
checkout <branch>" you wouldn't have seen those "artifacts".
--
Boyd Stephen Smith Jr. ,= ,-_-. =.
bss@iguanasuicide.net ((_/)o o(\_))
ICQ: 514984 YM/AIM: DaTwinkDaddy `-'(. .)`-'
http://iguanasuicide.net/ \_/
[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* RE: for newbs = little exercise / tutorial / warmup for windows and other non-sophisticated new Git users :-) [Scanned]
From: Daniel Barkalow @ 2008-12-31 3:10 UTC (permalink / raw)
To: Conor Rafferty; +Cc: Jeff Whiteside, Boyd Stephen Smith Jr., git
In-Reply-To: <BB5F02FD3789B54E8964D38D6775E718242D35@ALTMORE-SVR.altmore.local>
On Wed, 31 Dec 2008, Conor Rafferty wrote:
> -----Original Message-----
> wtf is wrong with
>
> git checkout <something>
>
> ??
>
> ** It doesn't reliably put the files that were in that revision into the
> working directory - a fairly major flaw, for what I'm using SCM for (and
> 80% of the market IMHO)
It certainly does for me; I rely on it pretty much constantly. Can you
give a sequence of commands (ideally the whole sequence from the "git
init") that leads to a difference?
The only case I know of where there will be files left over is if you
switch from a situation where you have an untracked file (e.g., you create
C.txt but don't add it to anything) to another situation where the file
still isn't tracked, it won't remove it. But, of course, you wouldn't
really want git to remove your uncommitted work in general, since it's
generally irreplaceable. It'll only be lacking files if it fails to switch
(if, for instance, you had uncommitted changes that conflict with the
changes that it would do), and it will give an error message in that case.
> if you must have
>
> git checkout <something> <paths>
>
> then instead use
>
> git checkout <something> <paths>
> git clean
>
> ** hmm, might try this - obviously as per Daniels post there is some
> undefined interaction happenign with the index, to screw up the working
> directory. I presume clean flushes the index?
git clean wouldn't remove those files, because they're supposed to be
there at that point.
In the sequence:
...
$ git tag versionD
$ git checkout versionA .
This means: "Update the index with the files in versionA, and working
directory from the index"
So now you're working on a commit based versionD (because you didn't
switch branches), and your work thus far, which is marked as ready for
your next commit, is to recover the removed files ABC.txt and AC.txt (from
versionA).
$ rm *.*
This removes those files again, but only in your working directory. Your
index still says that your next commit will recover them.
$ git checkout versionB .
This recovers ABC.txt and BC.txt (from versionB). Your index has ABC.txt,
BC.txt (from versionB), and AC.txt (from versionA), marked as going into
the next commit. It also puts all of these in your working directory (when
you might expect it to only put ABC.txt and BC.txt there).
So (a) you're still working on the commit after versionD, rather than
navagting history at all; and (b) you've recovered files from two
different commits.
Now:
$ git clean
will remove any files that you happen to have around, other than the one
you're confused about and trying to get rid of.
-Daniel
*This .sig left intentionally blank*
^ permalink raw reply
* Re: for newbs = little exercise / tutorial / warmup for windows and other non-sophisticated new Git users :-) [Scanned]
From: Boyd Stephen Smith Jr. @ 2008-12-31 2:56 UTC (permalink / raw)
To: Conor Rafferty; +Cc: Jeff Whiteside, Daniel Barkalow, git
In-Reply-To: <BB5F02FD3789B54E8964D38D6775E718242D35@ALTMORE-SVR.altmore.local>
[-- Attachment #1: Type: text/plain, Size: 1065 bytes --]
On Tuesday 2008 December 30 20:27:26 Conor Rafferty wrote:
> -----Original Message-----
> wtf is wrong with
>
> git checkout <something>
>
> ??
>
> ** It doesn't reliably put the files that were in that revision into the
> working directory - a fairly major flaw, for what I'm using SCM for (and
> 80% of the market IMHO)
And you would be wrong, IMHO. Many people have untracked files or directories
in their working directory ('cause they are working there) that they don't
want deleted willy-nilly. Build files, modifications that should be on a
different branch, etc. There's another thread active on the list complaining
that git removes too much from the working tree.
Most users of SCMs do make active modifications to the files in the SCM. It's
not a system only for archiving static projects.
--
Boyd Stephen Smith Jr. ,= ,-_-. =.
bss@iguanasuicide.net ((_/)o o(\_))
ICQ: 514984 YM/AIM: DaTwinkDaddy `-'(. .)`-'
http://iguanasuicide.net/ \_/
[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* [PATCH] Documentation/git-ls-files: --abbrev=<n> only useful with --stage
From: jidanni @ 2008-12-31 1:38 UTC (permalink / raw)
To: git
Else one wonders why one can't see the hex numbers it is talking about.
Signed-off-by: jidanni <jidanni@jidanni.org>
---
Documentation/git-ls-files.txt | 1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/Documentation/git-ls-files.txt b/Documentation/git-ls-files.txt
index 9f85d60..a1e952f 100644
--- a/Documentation/git-ls-files.txt
+++ b/Documentation/git-ls-files.txt
@@ -128,6 +128,7 @@ OPTIONS
Instead of showing the full 40-byte hexadecimal object
lines, show only handful hexdigits prefix.
Non default number of digits can be specified with --abbrev=<n>.
+ (Useful only with --stage.)
\--::
Do not interpret any more arguments as options.
--
1.6.0.6
^ permalink raw reply related
* man pages to subsections 1git...?
From: jidanni @ 2008-12-31 0:12 UTC (permalink / raw)
To: git
It seems like there are enough git man pages that they deserve their
own "honorary" subsections. Compare:
$ ls -R /usr/share/man/man?|sed ...|sort|uniq -c
19 1p
175 1posix
45 1ssl
10 1x
487 3perl
403 3pm
OK, the subsections would be 1git, 5git, and 7git.
However git-whatever is not something one can exactly can invoke from
the shell anymore, is it proper to have such a named man page?
Choices are e.g.,:
$ apropos apply
git-apply (1git) - Apply a patch on a git index file and a working tree
git apply (1git) - Apply a patch on a git index file and a working tree
apply (1git) - Apply a patch on a git index file and a working tree
Oh no, something wrong with each. You guys fight it out. I'm outta here.
^ permalink raw reply
* [PATCH] Documentation/git-rev-parse.txt: Clarify minimum length=4
From: jidanni @ 2008-12-31 2:38 UTC (permalink / raw)
To: git
Here I merely repeat "The minimum length is 4." from another part of
the page. However I do it in a critical spot, else users will think
that there is just no dress code for how short one's strings can be.
Proof: only the last line of:
git init
touch z
git add z
git cat-file -t e
git cat-file -t e6
git cat-file -t e69
git cat-file -t e69d
will finally output "blob".
Signed-off-by: jidanni <jidanni@jidanni.org>
---
Documentation/git-rev-parse.txt | 1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/Documentation/git-rev-parse.txt b/Documentation/git-rev-parse.txt
index 2921da3..8a4cdfc 100644
--- a/Documentation/git-rev-parse.txt
+++ b/Documentation/git-rev-parse.txt
@@ -154,6 +154,7 @@ blobs contained in a commit.
E.g. dae86e1950b1277e545cee180551750029cfe735 and dae86e both
name the same commit object if there are no other object in
your repository whose object name starts with dae86e.
+ The minimum length is 4.
* An output from 'git-describe'; i.e. a closest tag, optionally
followed by a dash and a number of commits, followed by a dash, a
--
1.6.0.6
^ permalink raw reply related
* Re: for newbs = little exercise / tutorial / warmup for windows and other non-sophisticated new Git users :-) [Scanned]
From: Jeff Whiteside @ 2008-12-31 2:35 UTC (permalink / raw)
To: Conor Rafferty; +Cc: Daniel Barkalow, Boyd Stephen Smith Jr., git
In-Reply-To: <BB5F02FD3789B54E8964D38D6775E718242D35@ALTMORE-SVR.altmore.local>
sir, i believe you're not reading what is typed.
> wtf is wrong with
>
> git checkout <something>
>
> ??
>
> ** It doesn't reliably put the files that were in that revision into the
> working directory - a fairly major flaw, for what I'm using SCM for (and
> 80% of the market IMHO)
yes it does. your example uses "git checkout versionB .", which is
NOT "git checkout <something>"
we are suggesting you do "git checkout versionB" which is different
(HINT: there is NO dot), and which i'm 99% positive will work.
if you still disagree, then i'm sure mercurial will be sufficient for
your needs, and all your dcvs book-lernin' over christmas will be
transferrable.
good luck with whatever option you choose.
^ permalink raw reply
* RE: for newbs = little exercise / tutorial / warmup for windows and other non-sophisticated new Git users :-) [Scanned]
From: Conor Rafferty @ 2008-12-31 2:30 UTC (permalink / raw)
To: Jeff Whiteside, Daniel Barkalow; +Cc: Boyd Stephen Smith Jr., git
MERCURIAL:
Update
hg update [-C] [-d DATE] [[-r] REV]
Update the repository's working directory (the "working copy") to the
specified revision of the repository or to the tip revision of the
current (named) branch if no revision is specified.
> I'm not looking for much....
-----Original Message-----
From: Jeff Whiteside [mailto:jeff.m.whiteside@gmail.com]
Sent: 31 December 2008 02:22
To: Daniel Barkalow
Cc: Conor Rafferty; Boyd Stephen Smith Jr.; git@vger.kernel.org
Subject: Re: for newbs = little exercise / tutorial / warmup for windows
and other non-sophisticated new Git users :-) [Scanned]
wtf is wrong with
git checkout <something>
??
if you must have
git checkout <something> <paths>
then instead use
git checkout <something> <paths>
git clean
but you will lose other files that aren't part of the repo but are still
in the project's dir (i.e. untracked files).
On Tue, Dec 30, 2008 at 4:15 PM, Daniel Barkalow <barkalow@iabervon.org>
wrote:
> On Tue, 30 Dec 2008, Conor Rafferty wrote:
>
>> I don't understand, sorry. I thought I'd already removed all files
>> from the local tree, in the $ rm *.* move just above the checkout
>
> That removes them from the filesystem, but they're still in the index.
> And "git checkout <something> ." first gets everything that *is* in
> "." in <something> into the index, and then gets everything from "."
> in the index into the filesystem.
>
> I suppose it is questionable as to whether it ought to copy paths that
> aren't in versionA from the index into the filesystem.
>
> To see this in a bit more detail, do:
>
> $ rm *.*
> $ git status
> (notice that the deletes are in the "won't be committed" section)
>
> Now, "git checkout <path>" will discard any changes in the "won't be
> committed" section for that path. Maybe "git checkout versionA <path>"
> should only discard changes that are in the "won't be committed"
> section for filenames that match that path and are in versionA (or are
> *different* in versionA and not removed?), but I think it's an area
> where, if you're expecting any particular behavior out of that
> command, you're likely to be surprised in some way in some situation.
>
> -Daniel
> *This .sig left intentionally blank*
> --
> To unsubscribe from this list: send the line "unsubscribe git" in the
> body of a message to majordomo@vger.kernel.org More majordomo info at
> http://vger.kernel.org/majordomo-info.html
>
^ permalink raw reply
* RE: for newbs = little exercise / tutorial / warmup for windows and other non-sophisticated new Git users :-) [Scanned]
From: Conor Rafferty @ 2008-12-31 2:27 UTC (permalink / raw)
To: Jeff Whiteside, Daniel Barkalow; +Cc: Boyd Stephen Smith Jr., git
-----Original Message-----
wtf is wrong with
git checkout <something>
??
** It doesn't reliably put the files that were in that revision into the
working directory - a fairly major flaw, for what I'm using SCM for (and
80% of the market IMHO)
if you must have
git checkout <something> <paths>
then instead use
git checkout <something> <paths>
git clean
** hmm, might try this - obviously as per Daniels post there is some
undefined interaction happenign with the index, to screw up the working
directory. I presume clean flushes the index?
but you will lose other files that aren't part of the repo but are still
in the project's dir (i.e. untracked files).
** don't care, I'll be removing them from working dir anyhow before
doing a rollback
On Tue, Dec 30, 2008 at 4:15 PM, Daniel Barkalow <barkalow@iabervon.org>
wrote:
> On Tue, 30 Dec 2008, Conor Rafferty wrote:
>
>> I don't understand, sorry. I thought I'd already removed all files
>> from the local tree, in the $ rm *.* move just above the checkout
>
> That removes them from the filesystem, but they're still in the index.
> And "git checkout <something> ." first gets everything that *is* in
> "." in <something> into the index, and then gets everything from "."
> in the index into the filesystem.
>
> I suppose it is questionable as to whether it ought to copy paths that
> aren't in versionA from the index into the filesystem.
>
> To see this in a bit more detail, do:
>
> $ rm *.*
> $ git status
> (notice that the deletes are in the "won't be committed" section)
>
> Now, "git checkout <path>" will discard any changes in the "won't be
> committed" section for that path. Maybe "git checkout versionA <path>"
> should only discard changes that are in the "won't be committed"
> section for filenames that match that path and are in versionA (or are
> *different* in versionA and not removed?), but I think it's an area
> where, if you're expecting any particular behavior out of that
> command, you're likely to be surprised in some way in some situation.
>
> -Daniel
> *This .sig left intentionally blank*
> --
> To unsubscribe from this list: send the line "unsubscribe git" in the
> body of a message to majordomo@vger.kernel.org More majordomo info at
> http://vger.kernel.org/majordomo-info.html
>
^ permalink raw reply
* Re: for newbs = little exercise / tutorial / warmup for windows and other non-sophisticated new Git users :-) [Scanned]
From: Sitaram Chamarty @ 2008-12-31 2:22 UTC (permalink / raw)
To: git
In-Reply-To: <BB5F02FD3789B54E8964D38D6775E718242D33@ALTMORE-SVR.altmore.local>
On 2008-12-30, Conor Rafferty <conor.rafferty@altmore.co.uk> wrote:
[re-arranged some of the quotes; it's not in the same order
as in your original email...]
> Even in clearcase this was a cinch.
Hey there's no need to use swear words ;-)
> Is there anyone who can see anyway to do this simply, without a script,
> without creating a branch ?
You'll have to unlearn this resistance to creating branches.
I've never used clearcase, but people tell me it is
expensive to create branches and/or merge them later --
almost a project in itself perhaps?
In git, however, creating a branch is as cheap as creating a
tag, so why not go with the flow until you're a little more
familiar with it?
> Personally I suspect "$ git checkout <version> ." is what should be
leave out the "." is all you needed to do.
> doing this (I have confidence in saying this because it seems to want to
> do this, and does it right at least half the time). But no-one wants to
> admit to the remotest possibility that it might be off ....
Because it's not off :-) You're using an unusual construct
that is not often used. (I've done path checkout of one or
a few files, but not the whole "." ever). So it took people
time to analyse what was happening -- such as suggesting you
use "git ls-files -s" to see what's in the index at each
stage.
May I ask where you got the idea that "." is needed? We
need to fix that source too ;-)
> In any case, a bunch of smart guys like you should be able to knock this
> functionality together in hours, if you put your mind to it.
> I know you guys have put a lot into this project and for many of you it
> defines who you are
> - but if you want ppl out there in the user world to take this stuff on,
> its gotta work for them
While I applaud your efforts to try and understand
everything in one long weekend, you'd have more fun if you
spaced it out a bit :-)
I'll also say that "ppl out there in the user world" will
not experiment the way you have -- they'll follow a basic
set of commands that work.
They'll even (gasp!) use the GUI. Believe me the GUIs are
pretty nice, though it won't let you checkout a tag (you can
checkout a branch, but not a tag -- because this gets you a
detached head which is a little too advanced for normal
folks I guess).
In other words, you're combining newbie and expert too
fast...
Finally, I heartily recommend reading the following article:
http://thedailywtf.com/Articles/Happy_Merge_Day!.aspx
If the hints in the article are not enough for you to figure
out this is about clearcase read the comments :-)
^ permalink raw reply
* Re: for newbs = little exercise / tutorial / warmup for windows and other non-sophisticated new Git users :-) [Scanned]
From: Jeff Whiteside @ 2008-12-31 2:22 UTC (permalink / raw)
To: Daniel Barkalow; +Cc: Conor Rafferty, Boyd Stephen Smith Jr., git
In-Reply-To: <alpine.LNX.1.00.0812301859100.19665@iabervon.org>
wtf is wrong with
git checkout <something>
??
if you must have
git checkout <something> <paths>
then instead use
git checkout <something> <paths>
git clean
but you will lose other files that aren't part of the repo but are
still in the project's dir (i.e. untracked files).
On Tue, Dec 30, 2008 at 4:15 PM, Daniel Barkalow <barkalow@iabervon.org> wrote:
> On Tue, 30 Dec 2008, Conor Rafferty wrote:
>
>> I don't understand, sorry. I thought I'd already removed all files from
>> the local tree, in the $ rm *.* move just above the checkout
>
> That removes them from the filesystem, but they're still in the index. And
> "git checkout <something> ." first gets everything that *is* in "." in
> <something> into the index, and then gets everything from "." in the index
> into the filesystem.
>
> I suppose it is questionable as to whether it ought to copy paths that
> aren't in versionA from the index into the filesystem.
>
> To see this in a bit more detail, do:
>
> $ rm *.*
> $ git status
> (notice that the deletes are in the "won't be committed" section)
>
> Now, "git checkout <path>" will discard any changes in the "won't be
> committed" section for that path. Maybe "git checkout versionA <path>"
> should only discard changes that are in the "won't be committed" section
> for filenames that match that path and are in versionA (or are
> *different* in versionA and not removed?), but I think it's an area where,
> if you're expecting any particular behavior out of that command, you're
> likely to be surprised in some way in some situation.
>
> -Daniel
> *This .sig left intentionally blank*
> --
> To unsubscribe from this list: send the line "unsubscribe git" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
^ permalink raw reply
* Re: for newbs = little exercise / tutorial / warmup for windows and other non-sophisticated new Git users :-)
From: Sitaram Chamarty @ 2008-12-31 1:43 UTC (permalink / raw)
To: git
In-Reply-To: <gje3ok$gnc$4@ger.gmane.org>
On 2008-12-30, Zorba <cr@altmore.co.uk> wrote:
> ** REPRODUCING Possible bug
[long script using "git checkout tag ." removed...]
Conor,
As Stephen said, you're using an extra "." which changes the
meaning completely.
In addition, the weird behaviour you see, where AC.txt
appears to have sneaked in when you do a "git checkout
versionB .", even though versionB does not have that file,
is also correct -- read the second para of the DESCRIPTION
section in "git help checkout", and note the phrase "update
the index ... before updating the working tree".
In other words, the special form of git checkout you used is
updating not only the working tree but also the index. So
when you checked out versionA in this manner, AC.txt got
into the index (as well as the working tree).
Your subsequent "rm *.*" only deeltes those files from the
working tree; they're still in the index. To see this, run
"git ls-files -s" just after each "rm *.*".
You can also get the results you *want* to get by running a
"git reset --hard" instead of "rm *.*", since your top
commit in the current branch (which is what this would
default to) has no files in it anyway.
Happy New Year from India to Northern Ireland and everyone
else in the world :-)
^ permalink raw reply
* Re: why still no empty directory support in git
From: David Brown @ 2008-12-31 1:06 UTC (permalink / raw)
To: Asheesh Laroia; +Cc: Git Mailing List
In-Reply-To: <alpine.DEB.2.00.0812300346040.19911@vellum.laroia.net>
On Tue, Dec 30, 2008 at 03:58:46AM -0500, Asheesh Laroia wrote:
> This is because git is removing these directories. There is a strict
> incompatibility between git rmdir()ing empty directories behind my back and
> Maildir systems.
So, would there be a hook that would run at all of the times git might
remove the directories, and the hook could just put them back if
missing?
The post-merge hook is certainly one place, but there are likely
others. You might also want one in post-checkout, but I'm guessing
that switching branches is going to be less frequent in a maildir
directory.
David
^ permalink raw reply
* Re: for newbs = little exercise / tutorial / warmup for windows and other non-sophisticated new Git users :-)
From: Zorba @ 2008-12-31 0:31 UTC (permalink / raw)
To: git
In-Reply-To: <alpine.LNX.1.00.0812301730440.19665@iabervon.org>
> So in order for this to make sense, you're going to need to know a little
> tiny bit about branches
** (sigh) At some level I knew I'd have to face up to this... - ok lets do
it
(which, fortunately, is trivial compared to
> branches in most SCMs). In git, a branch is a mutable pointer to a commit,
> which is the latest commit on the branch (all of the earlier commits on
> the branch are linked off of the latest one; each commit points to the one
> before). By default, you have a branch called "master", and that's the
> branch that your series of commands builds up. Now, at any given time, you
> can have a "current branch" (a.k.a. HEAD), which is the branch that you'd
> put a new commit on if you made one. "master" is your current branch while
> you're building up that history.
> When you want to navigate the history, however, you want to leave all of
> the branches alone and take your working directory into the history. This
> is known as being on "(no branch)" or, as Zippy would say, having a
> "detached HEAD". This way you leave the "master" branch pointing to
> versionD, which is, after all, the latest commit, while you get yourself
> an old version. You can do this with:
> $ git checkout versionA
>
> because you've made a tag for it. In order to get back to developing (as
> opposed to looking at history), you use:
>
> $ git checkout master
>
> (because "master" is your branch, while "versionA" is a tag).
>
> If you're on master, either after checking it out explicitly or before
> you've used checkout at all, doing:
>
> $ git checkout versionA .
>
> with *not* switch you away from the current branch, but will get the
> contents of "." from versionA into your index and working directory, and
> it doesn't remove things that you have currently.
** ok, thanks for explaining - one little dot and my HEAD don't get a
holiday !
Now, lets say we checkout versionB. I don't just want to be pointing at
versionB in the repo, I want an exact copy (no more, no less) of all the
files in version B, to be placed in the working tree. Currently this is not
happening reliably.
Is that too much to ask ?
^ permalink raw reply
* Re: What's cooking in git.git (Dec 2008, #04; Mon, 29)
From: Junio C Hamano @ 2008-12-31 0:22 UTC (permalink / raw)
To: Miklos Vajna; +Cc: Jakub Narebski, git
In-Reply-To: <20081231001036.GW21154@genesis.frugalware.org>
Miklos Vajna <vmiklos@frugalware.org> writes:
> On Tue, Dec 30, 2008 at 03:15:43PM -0800, Jakub Narebski <jnareb@gmail.com> wrote:
>> P.S. BTW. what is the status on using parse_options among git
>> commands?
>
> You mean the C or the shell commands?
>
> I sent the third version of the builtin-apply migration ($gmane/104029),
> but I got no answer so far, probably it was dropped on the floor by
> accident. ;-)
No, just I can be slow during a week like everybody else.
^ permalink raw reply
* RE: for newbs = little exercise / tutorial / warmup for windows and other non-sophisticated new Git users :-) [Scanned]
From: Daniel Barkalow @ 2008-12-31 0:15 UTC (permalink / raw)
To: Conor Rafferty; +Cc: Boyd Stephen Smith Jr., git
In-Reply-To: <BB5F02FD3789B54E8964D38D6775E718242D31@ALTMORE-SVR.altmore.local>
On Tue, 30 Dec 2008, Conor Rafferty wrote:
> I don't understand, sorry. I thought I'd already removed all files from
> the local tree, in the $ rm *.* move just above the checkout
That removes them from the filesystem, but they're still in the index. And
"git checkout <something> ." first gets everything that *is* in "." in
<something> into the index, and then gets everything from "." in the index
into the filesystem.
I suppose it is questionable as to whether it ought to copy paths that
aren't in versionA from the index into the filesystem.
To see this in a bit more detail, do:
$ rm *.*
$ git status
(notice that the deletes are in the "won't be committed" section)
Now, "git checkout <path>" will discard any changes in the "won't be
committed" section for that path. Maybe "git checkout versionA <path>"
should only discard changes that are in the "won't be committed" section
for filenames that match that path and are in versionA (or are
*different* in versionA and not removed?), but I think it's an area where,
if you're expecting any particular behavior out of that command, you're
likely to be surprised in some way in some situation.
-Daniel
*This .sig left intentionally blank*
^ permalink raw reply
* Re: for newbs = little exercise / tutorial / warmup for windows and other non-sophisticated new Git users :-) [Scanned]
From: Boyd Stephen Smith Jr. @ 2008-12-31 0:12 UTC (permalink / raw)
To: Conor Rafferty; +Cc: git
In-Reply-To: <BB5F02FD3789B54E8964D38D6775E718242D33@ALTMORE-SVR.altmore.local>
[-- Attachment #1: Type: text/plain, Size: 3297 bytes --]
On Tuesday 2008 December 30 16:55:38 Conor Rafferty wrote:
> Whoa there Stevey, I'm a windows user, don't forget
I just assumed you were also a git user. ;)
> However if this is what its gonna take to get what I want, then Im'
> outta here.
You aren't being entirely clear about what you want.
> Getting a snapshot on the filesystem, in terms of a directory tree (not
> a reference to, representation of etc etc. but a real life directory
> tree, files and folders that you can actually interact with - build,
> edit etc.), of a past version is a basic operation in my book.
> Even in clearcase this was a cinch.
Well, there's a lot of things about UNIX and Windows directories that git
doesn't store. It'll restore the contents, sure, but not the permissions,
timestamps, etc. However git also stores the *history*, if you don't care
about that, tarballs or zip archives might actually be a better system for
your purposes.
But, each time you commit you've made some snapshot (completeness depends on
what you staged with git add and friends) and recorded that snapshot as
a "later point in time" from the last snapshot you "git checkout"ed. That
new object (a "commit") can be identified by it's sha1. It holds a sha1 of
all it's parents (also "commits") and of the snapshot alone (a "tree").
You've also figured out how to use lightweight tags to give names (other than
their sha1) to your commits.
> Is there anyone who can see anyway to do this simply, without a script,
> without creating a branch ?
Branching is arguably easier than tagging, and probably what you want to do
instead. Sure, branches are mutable, but unsigned tags are also fairly
mutable.
> Personally I suspect "$ git checkout <version> ." is what should be
> doing this.
I'm pretty sure what you want is "git checkout <version>" not "git checkout
<version> <paths>". They operate differently. Modern git can checkout a
lightweight tag, but it's going to warn you that it not what you want.
> - but if you want ppl out there in the user world to take this stuff on,
> its gotta work for them
Maybe others do, but I don't really see git as an end-user tool. It's a
developer tool and rightly demands a bit of RTFMing before using it
effectively.
What you seem to *really* want is a bunch of named trees without any
relationship between one another. IMHO, git isn't really good at that (but
only because it demands to do more). A directory full of tarballs /
zip-archives and a couple of scripts you wrote yourself (extract.sh;
name-and-save.sh) would probably be better.
I admit that there seems to be quite a niche for some sort of trivially usable
VCS, but it needs to be good at merging spreadsheets, compressed/binary XML,
presentations/decks, and other things not-text, have a pretty GUI, and run
securely over TCP/IP ports that no one is willing to block. It will probably
be next to useless for doing what git was initially designed for (managing
Linux kernel patches).
--
Boyd Stephen Smith Jr. ,= ,-_-. =.
bss@iguanasuicide.net ((_/)o o(\_))
ICQ: 514984 YM/AIM: DaTwinkDaddy `-'(. .)`-'
http://iguanasuicide.net/ \_/
[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* Re: for newbs = little exercise / tutorial / warmup for windows and other non-sophisticated new Git users :-) [Scanned]
From: Boyd Stephen Smith Jr. @ 2008-12-30 23:31 UTC (permalink / raw)
To: Conor Rafferty; +Cc: git
In-Reply-To: <BB5F02FD3789B54E8964D38D6775E718242D31@ALTMORE-SVR.altmore.local>
[-- Attachment #1: Type: text/plain, Size: 1975 bytes --]
On Tuesday 2008 December 30 16:36:19 Conor Rafferty wrote:
> I don't understand, sorry. I thought I'd already removed all files from
> the local tree, in the $ rm *.* move just above the checkout
Yeah, I guess I missed that, and I am seeing some "odd" behavior from git
checkout <treeish> <path>, but I'm not an expert on exactly what that is
supposed to do, particularly when applied to a directory.
The description is:
"When <paths> are given, this command does not switch branches. It
updates the named paths in the working tree from the index file, or from a
named commit. [...] <tree-ish> argument can be used to specify a
specific tree-ish to update the index for
the given paths before updating the working tree."
I'm guess what is happening here is that the index is getting updated in a way
that includes both the files from the HEAD tree and from the named tree.
Then the modified index is written out, outputting all of them, effectively
doing some sort of "theirs" merge. It's not quite what I would expect but I
don't normally use git checkout <treeish> <path> when path indicates a
directory.
You should do a "git status" when you get ls output that is "unexpected".
Here, it confirms that the index has been updated (git thinks I've staged
some changes).
Personally, I expected "git checkout <treeish> <paths>" to bypass the index
entirely, the way "git commit <paths>" does, but this way also makes sense --
at least when applied to a single file. (And probably saves a good number of
git add commands...).
In short, while I can't say for sure, I'm pretty sure you don't want the "git
commit <treeish> <path>" form and want the "git commit <treeish>" form
instead.
--
Boyd Stephen Smith Jr. ,= ,-_-. =.
bss@iguanasuicide.net ((_/)o o(\_))
ICQ: 514984 YM/AIM: DaTwinkDaddy `-'(. .)`-'
http://iguanasuicide.net/ \_/
[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* Re: What's cooking in git.git (Dec 2008, #04; Mon, 29)
From: Miklos Vajna @ 2008-12-31 0:10 UTC (permalink / raw)
To: Jakub Narebski; +Cc: Junio C Hamano, git
In-Reply-To: <m3fxk5b6di.fsf@localhost.localdomain>
[-- Attachment #1: Type: text/plain, Size: 354 bytes --]
On Tue, Dec 30, 2008 at 03:15:43PM -0800, Jakub Narebski <jnareb@gmail.com> wrote:
> P.S. BTW. what is the status on using parse_options among git
> commands?
You mean the C or the shell commands?
I sent the third version of the builtin-apply migration ($gmane/104029),
but I got no answer so far, probably it was dropped on the floor by
accident. ;-)
[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* [RFC PATCH] builtin-apply: prevent non-explicit permission changes
From: Alexander Potashev @ 2008-12-30 23:53 UTC (permalink / raw)
To: Git Mailing List
Prevent 'git apply' from changing permissions without
'old mode'/'new mode' lines in patch.
(WARNING: this changes the behaviour of 'git apply')
Signed-off-by: Alexander Potashev <aspotashev@gmail.com>
---
Once upon a time there was a shell script in a Git repository. But that
shell script had 100644 permission (regular file). Then I did
'chmod +x', commit... but the shell script was related to my friend's
stuff in the repository and I received a patch from him regarding the
script. But the patch was against a repository version before
'chmod +x', thus it contained an index line such as the following:
index fc3c3a4..066a4ac 100644
(it still had '100644' permissions)
I have to note that there was no 'old/new mode' lines. But when I ran
'git am <patch>' it restored '100644' permissions. So, 'git am' changed
my permissions (100755 -> 100644) without any explicit permission
changes in the patch.
I think, 'git apply'/'git am' should apply only _changes_ _mentioned_ in
patch; if there's no 'old mode ...'/'new mode ...' lines in it, 'git
apply' shouldn't change the permissions.
Test cases are probably wanted, but I don't really know how to do them
and I'll only give a chain of commands to reproduce the issue:
mkdir repo
cd repo
git init
echo "This is a shell script" > script.sh
git add script.sh
git ci -m "initial commit"
echo "a new line and a newline" >> script.sh
git ci -a -m "only content changes" # aka patch to apply
git format-patch -1 # now we have a patch
git reset --hard HEAD^
chmod +x script.sh
git ci -a -m "permission changes"
git am 0001-only-content-changes.patch
stat -c %a script.sh # check the result
'stat' says '644' if 'git am' has changed the permissions or '755' if
it hasn't.
Alexander
builtin-apply.c | 3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/builtin-apply.c b/builtin-apply.c
index 07244b0..071f6d8 100644
--- a/builtin-apply.c
+++ b/builtin-apply.c
@@ -630,7 +630,7 @@ static int gitdiff_index(const char *line, struct patch *patch)
memcpy(patch->new_sha1_prefix, line, len);
patch->new_sha1_prefix[len] = 0;
if (*ptr == ' ')
- patch->new_mode = patch->old_mode = strtoul(ptr+1, NULL, 8);
+ patch->old_mode = strtoul(ptr+1, NULL, 8);
return 0;
}
@@ -2447,6 +2447,7 @@ static int check_preimage(struct patch *patch, struct cache_entry **ce, struct s
if (st_mode != patch->old_mode)
fprintf(stderr, "warning: %s has type %o, expected %o\n",
old_name, st_mode, patch->old_mode);
+ patch->new_mode = st_mode;
return 0;
is_new:
--
1.6.0.6
^ permalink raw reply related
* Re: git clone - failing on cygwin with git:// but not with ssh://
From: Daniel Barkalow @ 2008-12-30 23:52 UTC (permalink / raw)
To: Joe Casadonte; +Cc: git
In-Reply-To: <ud4fdxn08.fsf@terrapin.northbound-train.com>
On Sat, 27 Dec 2008, Joe Casadonte wrote:
> Hi,
>
> I'm new to git, so my apologies if I'm missing something pretty
> basic. Here's my setup:
>
> "Public" server
> ---------------
> OS: RedHat clone, 2.6.9 kernel
> git version: self-compiled, 1.6.0.6
>
> Test client #1 (works)
> ----------------------
> OS: RedHat clone, 2.6.9 kernel
> git version: self-compiled, 1.6.0.6
>
> Test client #2 (fails)
> ----------------------
> OS: Win XP Pro
> git version: cygwin compiled, 1.6.0.4
I'd try the msysgit version...
>
> I have a new repository on the "public" server, and have cloned it on
> test client #1 with:
>
> $ git clone git://foobar/myproj.git
> Initialized empty Git repository in /opt/myproj/.git/
> remote: Counting objects: 104, done.
> remote: Compressing objects: 100% (72/72), done.
> remote: Total 104 (delta 22), reused 104 (delta 22)
> Receiving objects: 100% (104/104), 76.97 KiB, done.
> Resolving deltas: 100% (22/22), done.
>
>
> I try the same thing on test box #2 and receive:
>
>
> D:\temp>git clone git://foobar/otminfmyproj.git
> Initialized empty Git repository in /cygdrive/d/temp/foobar/.git/
> fatal: read error (Socket operation on non-socket)
> fatal: early EOF
> fatal: index-pack failed
As Junio said, this smells like the build you have of git or of cygwin
aren't dealing correctly with Windows' non-POSIX-ness. The msysgit version
is more self-contained, and doesn't expect the system to be POSIX at all.
-Daniel
*This .sig left intentionally blank*
^ permalink raw reply
* Re: for newbs = little exercise / tutorial / warmup for windows and other non-sophisticated new Git users :-)
From: Daniel Barkalow @ 2008-12-30 23:29 UTC (permalink / raw)
To: Zorba; +Cc: git
In-Reply-To: <gje4ff$ip6$4@ger.gmane.org>
On Tue, 30 Dec 2008, Zorba wrote:
> > good news, use "git checkout versionA", not "git checkout versionA ."
> > (so, use it wihtout the dot), and you should be back in working order.
>
> ** yes but I don't get the files copied out into the tree which is all my
> little heart ever desired
So in order for this to make sense, you're going to need to know a little
tiny bit about branches (which, fortunately, is trivial compared to
branches in most SCMs). In git, a branch is a mutable pointer to a commit,
which is the latest commit on the branch (all of the earlier commits on
the branch are linked off of the latest one; each commit points to the one
before). By default, you have a branch called "master", and that's the
branch that your series of commands builds up. Now, at any given time, you
can have a "current branch" (a.k.a. HEAD), which is the branch that you'd
put a new commit on if you made one. "master" is your current branch while
you're building up that history.
When you want to navigate the history, however, you want to leave all of
the branches alone and take your working directory into the history. This
is known as being on "(no branch)" or, as Zippy would say, having a
"detached HEAD". This way you leave the "master" branch pointing to
versionD, which is, after all, the latest commit, while you get yourself
an old version. You can do this with:
$ git checkout versionA
because you've made a tag for it. In order to get back to developing (as
opposed to looking at history), you use:
$ git checkout master
(because "master" is your branch, while "versionA" is a tag).
If you're on master, either after checking it out explicitly or before
you've used checkout at all, doing:
$ git checkout versionA .
with *not* switch you away from the current branch, but will get the
contents of "." from versionA into your index and working directory, and
it doesn't remove things that you have currently.
> ** LOL, I have to admit I am enjoying this though, even if its driving me
> slightly potty - haha
> I didn't write these early versions so I just wanna have them around to
> rollback to if I end up hacking the thing to bits.
> But you're right - chances of using are slim - but you could say that about
> every version sitting in any given SCM repo.
> Thats why we have SCM, and why we insure our cars etc etc. :-)
Even if you never rolling back to it, it's useful for figuring out what
you did when.
-Daniel
*This .sig left intentionally blank*
^ permalink raw reply
* Re: is there an easier way to do this ?
From: Zorba @ 2008-12-30 23:20 UTC (permalink / raw)
To: git
In-Reply-To: <m3k59hb6xr.fsf@localhost.localdomain>
thanks Jakub, but I don't mind copying the versions in by hand and running
the git commits on them sequentially.
I only have 5 max historical versions to archive..
"Jakub Narebski" <jnareb@gmail.com> wrote in message
news:m3k59hb6xr.fsf@localhost.localdomain...
> "Zorba" <cr@altmore.co.uk> writes:
>
>> ok, now I'm in this for real, archiving versions of our website project
>> (5k
>> files approx)
>>
>> so here is the workflow:
>>
>> - copy version 1 files into GIT dir
>>
>> - open git bash
>>
>> $ git init
>>
>> $ git add .
>>
>> $ git commit -m "version1"
>>
>> all vanilla ? cool
>> next job = store version 2 [...]
>
> Check out contrib/fast-import/import-tars.perl
>
> --
> Jakub Narebski
> Poland
> ShadeHawk on #git
^ permalink raw reply
* Re: What's cooking in git.git (Dec 2008, #04; Mon, 29)
From: Jakub Narebski @ 2008-12-30 23:15 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vocyt1is2.fsf@gitster.siamese.dyndns.org>
Junio C Hamano <gitster@pobox.com> writes:
> with '-' are only in 'pu' while commits prefixed with '+' are
> in 'next'. The ones marked with '.' do not appear in any of the branches,
> but I am still holding onto them.
>
> The topics list the commits in reverse chronological order. The topics
> meant to be merged to the maintenance series have "maint-" in their names.
>
> ----------------------------------------------------------------
> [Actively cooking]
>
> * mk/gitweb-feature (Mon Dec 15 22:16:19 2008 -0800) 1 commit
> - gitweb: unify boolean feature subroutines
Nice thing from what I remember (I assume it is last incantation?).
> * jn/gitweb-blame (Thu Dec 11 01:33:29 2008 +0100) 3 commits
> - gitweb: cache $parent_commit info in git_blame()
> - gitweb: A bit of code cleanup in git_blame()
> - gitweb: Move 'lineno' id from link to row element in git_blame
>
> Jakub seemed to feel they are not yet ready.
This is, I think, ready. It is incremental AJAX-y blame in gitweb
that is not yet ready; this is simple cleanup and performance
improvement.
> * sc/gitweb-category (Fri Dec 12 00:45:12 2008 +0100) 3 commits
> - gitweb: Optional grouping of projects by category
> - gitweb: Split git_project_list_body in two functions
> - gitweb: Modularized git_get_project_description to be more generic
I think this needs a bit more cooking; with one more commit I think
you can have categories within requested sort order, and not always
sorted alphabetically.
> * gb/gitweb-patch (Thu Dec 18 08:13:19 2008 +0100) 4 commits
> - gitweb: link to patch(es) view in commit(diff) and (short)log view
> - gitweb: add patches view
> - gitweb: change call pattern for git_commitdiff
> - gitweb: add patch view
I think it is ready, or almost ready. I'll try to review this series
within a week. Feel free to prod me if I forget.
P.S. BTW. what is the status on using parse_options among git
commands?
--
Jakub Narebski
Poland
ShadeHawk on #git
^ 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