* 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
* Re: Why can't git pull --rebase work if there are modified files?
From: Thomas Rast @ 2008-12-30 23:09 UTC (permalink / raw)
To: skillzero; +Cc: git
In-Reply-To: <2729632a0812301340y735c3946weee55c9856d4e6a9@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 2219 bytes --]
skillzero@gmail.com wrote:
> If I have locally modified files and I try to 'git pull --rebase', it
> fails because of the locally modified files. If I don't use the
> --rebase option, it works (but generates a merge commit if I have
> local commits). Why does rebasing require an unmodified checkout? It
> seems like it should only stop if I something in the newly fetched
> changes conflict with my local changes.
First you need to be aware that 'git pull --rebase' is conceptually
the same as 'git fetch && git rebase upstream', where 'upstream' is
the remote branch tracked by your current branch. (The canonical
choice is upstream=origin/foo for a branch foo.) git-fetch is of no
further interest to the discussion, as it does not touch the working
tree in any way.
git-rebase is not concerned with "newly fetched changes". It
*rewinds* your branch to the updated 'upstream' tip, and then
*rebuilds* your commits on top of that. This involves a lot of
resetting and applying patches, which appears to be why it enforces a
clean working tree.
You can use git-stash (see the man page) to temporarily save away your
uncommitted changes, however. Maybe you could even write a patch to
git-rebase that lets it automatically save and restore uncommitted
changes?
> I almost always have modified files in my checkout for things I'm
> working on. I also often have a commit or two that haven't been pushed
> because I'm waiting until I get to a good point before pushing. If I
> do 'git pull', I end up with a merge commit each time. That's why I
> want to use --rebase, but for it to work, I have to git stash, then
> rebase then git stash pop.
You could probably improve your workflow a lot by using topic
branches. See the recently added gitworkflows manpage, also available
at
http://www.kernel.org/pub/software/scm/git-core/docs/gitworkflows.html
or, e.g., Tv's excellent introduction to git called "Version Control
for Du^H^HDevelopers":
http://eagain.net/blog/2008/08/11/ep-talk-videos.html
(Pretty much the second half is about branch workflows, topic branches
are explicitly introduced at ~44:15.)
--
Thomas Rast
trast@{inf,student}.ethz.ch
[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* Re: is there an easier way to do this ?
From: Jakub Narebski @ 2008-12-30 23:03 UTC (permalink / raw)
To: Zorba; +Cc: git
In-Reply-To: <gjc52u$ehc$4@ger.gmane.org>
"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: gitweb $export_ok question
From: Jakub Narebski @ 2008-12-30 23:02 UTC (permalink / raw)
To: Thomas Amsler; +Cc: git@vger.kernel.org
In-Reply-To: <m3sko5b84t.fsf@localhost.localdomain>
Jakub Narebski <jnareb@gmail.com> writes:
> in the GITWEB_CONFIG file (usually gitweb_config.perl, installed
> in the same place as gitweb.cgi) [...]
I'm sorry, I forgot about GITWEB_CONFIG_SYSTEM which as you
wrote is by default /etc/gitweb.conf (and is also Perl).
--
Jakub Narebski
Poland
ShadeHawk on #git
^ 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-30 22:55 UTC (permalink / raw)
To: Boyd Stephen Smith Jr.; +Cc: git
Whoa there Stevey, I'm a windows user, don't forget
I mighta had a chance at following this 10-12 years ago when last I did
some scripting, but not now
Its very generous of you to go to all this bother and I'm mighty
grateful.
However if this is what its gonna take to get what I want, then Im'
outta here.
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.
Is there anyone who can see anyway to do this simply, without a script,
without creating a branch ?
Personally I suspect "$ git checkout <version> ." is what should be
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 ....
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
<END>impassioned plea</>
-----Original Message-----
From: Boyd Stephen Smith Jr. [mailto:bss@iguanasuicide.net]
Sent: 30 December 2008 22:17
To: Conor Rafferty
Cc: git@vger.kernel.org
Subject: Re: for newbs = little exercise / tutorial / warmup for windows
and other non-sophisticated new Git users :-) [Scanned]
On Tuesday 2008 December 30 15:49:22 Boyd Stephen Smith Jr. wrote:
> On Tuesday 2008 December 30 15:27:33 you wrote:
> > conorr@KINKLADZE /w/GITPLATFORM/swproj $ git status # On branch
> > master nothing to commit (working directory clean)
> >
> > conorr@KINKLADZE /w/GITPLATFORM/swproj $ git checkout versionA .
> >
> > conorr@KINKLADZE /w/GITPLATFORM/swproj $ ls ABC.txt AC.txt
> >
> > conorr@KINKLADZE /w/GITPLATFORM/swproj $ rm *.*
> >
> > conorr@KINKLADZE /w/GITPLATFORM/swproj $ git checkout versionB .
> >
> > conorr@KINKLADZE /w/GITPLATFORM/swproj $ ls ABC.txt AC.txt BC.txt
>
> Not a bug. git checkout <commit> <paths> does not delete files by
design.
> Try using "git checkout versionB" instead (no paths specified), and it
> will properly remove AC.txt from your working tree as well as warning
> you that "You're Doing It Wrong" (tm).
This may be what you want:
(commands)
mkdir test && cd test && git init &&
echo 'ABC' > ABC.txt && echo 'AC' > AC.txt && echo 'BC' > BC.txt && echo
'C' > C.txt &&
find -name '*C*' -print0 | xargs -r0 -- git add -- && git commit -m '"C"
files.' && git branch versionC master &&
git checkout -b versionA master &&
find -type f -not -wholename '*.git*' -not -name '*A*' -print0 | \
xargs -r0 -- git rm -- &&
git commit -m 'Removed non-"A" files.' &&
git checkout -b versionB &&
find -type f -not -wholename '*.git*' -not -name '*B*' -print0 | \
xargs -r0 -- git rm -- &&
git commit -m 'Removed non-"B" files.' &&
git checkout -b versionD master &&
find -type f -not -wholename '*.git*' -not -name '*D*' -print0 | \
xargs -r0 -- git rm -- && git commit -m 'Removed non-"D" files.'
&&
git checkout master && git branch -v --abbrev=4 && ls -l && git checkout
versionA && ls -l && git checkout versionB && ls -l && git checkout
versionC && ls -l && git checkout versionD && ls -l
(output)
/home/bss/test
Initialized empty Git repository in /home/bss/test/.git/ Created initial
commit 8dbf3a1: All files.
4 files changed, 4 insertions(+), 0 deletions(-) create mode 100644
ABC.txt create mode 100644 AC.txt create mode 100644 BC.txt create
mode 100644 C.txt Switched to a new branch "versionA"
rm 'BC.txt'
rm 'C.txt'
Created commit a06e10c: Removed non-"A" files.
2 files changed, 0 insertions(+), 2 deletions(-) delete mode 100644
BC.txt delete mode 100644 C.txt Switched to a new branch "versionB"
rm 'AC.txt'
Created commit 2029ca2: Removed non-"B" files.
1 files changed, 0 insertions(+), 1 deletions(-) delete mode 100644
AC.txt Switched to a new branch "versionD"
rm 'ABC.txt'
rm 'AC.txt'
rm 'BC.txt'
rm 'C.txt'
Created commit 1793ba0: Removed non-"D" files.
4 files changed, 0 insertions(+), 4 deletions(-) delete mode 100644
ABC.txt delete mode 100644 AC.txt delete mode 100644 BC.txt delete
mode 100644 C.txt Switched to branch "master"
* master 8dbf "C" files.
versionA a06e Removed non-"A" files.
versionB 2029 Removed non-"B" files.
versionC 8dbf "C" files.
versionD 1793 Removed non-"D" files.
total 16
-rw-r--r-- 1 bss users 4 2008-12-30 16:10 ABC.txt
-rw-r--r-- 1 bss users 3 2008-12-30 16:10 AC.txt
-rw-r--r-- 1 bss users 3 2008-12-30 16:10 BC.txt
-rw-r--r-- 1 bss users 2 2008-12-30 16:10 C.txt Switched to branch
"versionA"
total 8
-rw-r--r-- 1 bss users 4 2008-12-30 16:10 ABC.txt
-rw-r--r-- 1 bss users 3 2008-12-30 16:10 AC.txt Switched to branch
"versionB"
total 4
-rw-r--r-- 1 bss users 4 2008-12-30 16:10 ABC.txt Switched to branch
"versionC"
total 16
-rw-r--r-- 1 bss users 4 2008-12-30 16:10 ABC.txt
-rw-r--r-- 1 bss users 3 2008-12-30 16:10 AC.txt
-rw-r--r-- 1 bss users 3 2008-12-30 16:10 BC.txt
-rw-r--r-- 1 bss users 2 2008-12-30 16:10 C.txt Switched to branch
"versionD"
total 0
--
Boyd Stephen Smith Jr. ,= ,-_-. =.
bss@iguanasuicide.net ((_/)o o(\_))
ICQ: 514984 YM/AIM: DaTwinkDaddy `-'(. .)`-'
http://iguanasuicide.net/ \_/
^ permalink raw reply
* Re: for newbs = little exercise / tutorial / warmup for windows and other non-sophisticated new Git users :-)
From: Boyd Stephen Smith Jr. @ 2008-12-30 22:39 UTC (permalink / raw)
To: Zorba; +Cc: git
In-Reply-To: <200812301617.15496.bss@iguanasuicide.net>
[-- Attachment #1: Type: text/plain, Size: 544 bytes --]
On Tuesday 2008 December 30 16:17:11 Boyd Stephen Smith Jr. wrote:
> git checkout -b versionB &&
Should be:
git checkout -b versionB master &&
to match the other section and fix this part of the output:
> Switched to branch "versionB"
> total 4
> -rw-r--r-- 1 bss users 4 2008-12-30 16:10 ABC.txt
--
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: gitweb $export_ok question
From: Jakub Narebski @ 2008-12-30 22:37 UTC (permalink / raw)
To: Thomas Amsler; +Cc: git@vger.kernel.org
In-Reply-To: <9B3762519053E645820D9CEBD18B3734023A9FBA00@XEDAMAIL2.ex.ad3.ucdavis.edu>
Thomas Amsler <tpamsler@ucdavis.edu> writes:
> Hello,
>
> I am trying to get the gitweb $export_ok to work. According the
> installation instructions:
>
> Alternatively, you can configure gitweb to only list and allow
> viewing of the explicitly exported repositories, via the
> GITWEB_EXPORT_OK build configuration variable (or the $export_ok
> variable in gitweb config file). If it evaluates to true, gitweb
> shows repositories only if this file exists in its object database
> (if directory has the magic file named $export_ok).
>
> ... I set $export_ok = "true" in my /etc/gitweb.conf file.
[...]
$export_ok is not a boolean, is the _name_ of a file, which if it
is present, then repository is exported to gitweb, and if it is not,
it is invisible to gitweb. It means that if for example we have
$export_ok = "gitweb-export-ok";
in the GITWEB_CONFIG file (usually gitweb_config.perl, installed
in the same place as gitweb.cgi), the repo.git is exported only
if it has file gitweb-export-ok in it.
This mechanism is similar to git-daemon and its magic file
"git-daemon-export-ok".
--
Jakub Narebski
Poland
ShadeHawk on #git
^ 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-30 22:36 UTC (permalink / raw)
To: Boyd Stephen Smith Jr.; +Cc: git
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
-----Original Message-----
From: Boyd Stephen Smith Jr. [mailto:bss@iguanasuicide.net]
Sent: 30 December 2008 21:49
To: Conor Rafferty
Cc: git@vger.kernel.org
Subject: Re: for newbs = little exercise / tutorial / warmup for windows
and other non-sophisticated new Git users :-) [Scanned]
On Tuesday 2008 December 30 15:27:33 you wrote:
> conorr@KINKLADZE /w/GITPLATFORM/swproj $ git status # On branch master
> nothing to commit (working directory clean)
>
> conorr@KINKLADZE /w/GITPLATFORM/swproj $ git checkout versionA .
>
> conorr@KINKLADZE /w/GITPLATFORM/swproj $ ls ABC.txt AC.txt
>
> conorr@KINKLADZE /w/GITPLATFORM/swproj $ rm *.*
>
> conorr@KINKLADZE /w/GITPLATFORM/swproj $ git checkout versionB .
>
> conorr@KINKLADZE /w/GITPLATFORM/swproj $ ls ABC.txt AC.txt BC.txt
Not a bug. git checkout <commit> <paths> does not delete files by
design.
Try using "git checkout versionB" instead (no paths specified), and it
will properly remove AC.txt from your working tree as well as warning
you that "You're Doing It Wrong" (tm).
--
Boyd Stephen Smith Jr. ,= ,-_-. =.
bss@iguanasuicide.net ((_/)o o(\_))
ICQ: 514984 YM/AIM: DaTwinkDaddy `-'(. .)`-'
http://iguanasuicide.net/ \_/
^ permalink raw reply
* Re: Extracting a single commit or object
From: Shawn O. Pearce @ 2008-12-30 22:21 UTC (permalink / raw)
To: yitzhakbg; +Cc: git
In-Reply-To: <21223948.post@talk.nabble.com>
yitzhakbg <yitzhakbg@gmail.com> wrote:
>
> How would I extract a single commit from a repository by it's SHA1 (or any
> other treeish)?
> For that matter, how is any one single object extracted? Examples please.
git cat-file $type $sha1
e.g.
git cat-file commit $commitsha1
git cat-file blob $blobsha1
If you need to inspect a tree, ls-tree is probably better:
git ls-tree $commitsha1
git ls-tree $treesha1
--
Shawn.
^ permalink raw reply
* Re: for newbs = little exercise / tutorial / warmup for windows and other non-sophisticated new Git users :-)
From: Boyd Stephen Smith Jr. @ 2008-12-30 22:17 UTC (permalink / raw)
To: Zorba; +Cc: git
In-Reply-To: <200812301549.26538.bss@iguanasuicide.net>
[-- Attachment #1: Type: text/plain, Size: 4075 bytes --]
On Tuesday 2008 December 30 15:49:22 Boyd Stephen Smith Jr. wrote:
> On Tuesday 2008 December 30 15:27:33 you wrote:
> > conorr@KINKLADZE /w/GITPLATFORM/swproj
> > $ git status
> > # On branch master
> > nothing to commit (working directory clean)
> >
> > conorr@KINKLADZE /w/GITPLATFORM/swproj
> > $ git checkout versionA .
> >
> > conorr@KINKLADZE /w/GITPLATFORM/swproj
> > $ ls
> > ABC.txt AC.txt
> >
> > conorr@KINKLADZE /w/GITPLATFORM/swproj
> > $ rm *.*
> >
> > conorr@KINKLADZE /w/GITPLATFORM/swproj
> > $ git checkout versionB .
> >
> > conorr@KINKLADZE /w/GITPLATFORM/swproj
> > $ ls
> > ABC.txt AC.txt BC.txt
>
> Not a bug. git checkout <commit> <paths> does not delete files by design.
> Try using "git checkout versionB" instead (no paths specified), and it will
> properly remove AC.txt from your working tree as well as warning you
> that "You're Doing It Wrong" (tm).
This may be what you want:
(commands)
mkdir test && cd test && git init &&
echo 'ABC' > ABC.txt && echo 'AC' > AC.txt &&
echo 'BC' > BC.txt && echo 'C' > C.txt &&
find -name '*C*' -print0 | xargs -r0 -- git add -- &&
git commit -m '"C" files.' && git branch versionC master &&
git checkout -b versionA master &&
find -type f -not -wholename '*.git*' -not -name '*A*' -print0 | \
xargs -r0 -- git rm -- &&
git commit -m 'Removed non-"A" files.' &&
git checkout -b versionB &&
find -type f -not -wholename '*.git*' -not -name '*B*' -print0 | \
xargs -r0 -- git rm -- &&
git commit -m 'Removed non-"B" files.' &&
git checkout -b versionD master &&
find -type f -not -wholename '*.git*' -not -name '*D*' -print0 | \
xargs -r0 -- git rm -- && git commit -m 'Removed non-"D" files.' &&
git checkout master && git branch -v --abbrev=4 && ls -l &&
git checkout versionA && ls -l &&
git checkout versionB && ls -l &&
git checkout versionC && ls -l &&
git checkout versionD && ls -l
(output)
/home/bss/test
Initialized empty Git repository in /home/bss/test/.git/
Created initial commit 8dbf3a1: All files.
4 files changed, 4 insertions(+), 0 deletions(-)
create mode 100644 ABC.txt
create mode 100644 AC.txt
create mode 100644 BC.txt
create mode 100644 C.txt
Switched to a new branch "versionA"
rm 'BC.txt'
rm 'C.txt'
Created commit a06e10c: Removed non-"A" files.
2 files changed, 0 insertions(+), 2 deletions(-)
delete mode 100644 BC.txt
delete mode 100644 C.txt
Switched to a new branch "versionB"
rm 'AC.txt'
Created commit 2029ca2: Removed non-"B" files.
1 files changed, 0 insertions(+), 1 deletions(-)
delete mode 100644 AC.txt
Switched to a new branch "versionD"
rm 'ABC.txt'
rm 'AC.txt'
rm 'BC.txt'
rm 'C.txt'
Created commit 1793ba0: Removed non-"D" files.
4 files changed, 0 insertions(+), 4 deletions(-)
delete mode 100644 ABC.txt
delete mode 100644 AC.txt
delete mode 100644 BC.txt
delete mode 100644 C.txt
Switched to branch "master"
* master 8dbf "C" files.
versionA a06e Removed non-"A" files.
versionB 2029 Removed non-"B" files.
versionC 8dbf "C" files.
versionD 1793 Removed non-"D" files.
total 16
-rw-r--r-- 1 bss users 4 2008-12-30 16:10 ABC.txt
-rw-r--r-- 1 bss users 3 2008-12-30 16:10 AC.txt
-rw-r--r-- 1 bss users 3 2008-12-30 16:10 BC.txt
-rw-r--r-- 1 bss users 2 2008-12-30 16:10 C.txt
Switched to branch "versionA"
total 8
-rw-r--r-- 1 bss users 4 2008-12-30 16:10 ABC.txt
-rw-r--r-- 1 bss users 3 2008-12-30 16:10 AC.txt
Switched to branch "versionB"
total 4
-rw-r--r-- 1 bss users 4 2008-12-30 16:10 ABC.txt
Switched to branch "versionC"
total 16
-rw-r--r-- 1 bss users 4 2008-12-30 16:10 ABC.txt
-rw-r--r-- 1 bss users 3 2008-12-30 16:10 AC.txt
-rw-r--r-- 1 bss users 3 2008-12-30 16:10 BC.txt
-rw-r--r-- 1 bss users 2 2008-12-30 16:10 C.txt
Switched to branch "versionD"
total 0
--
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
* Extracting a single commit or object
From: yitzhakbg @ 2008-12-30 22:15 UTC (permalink / raw)
To: git
How would I extract a single commit from a repository by it's SHA1 (or any
other treeish)?
For that matter, how is any one single object extracted? Examples please.
Thanks,
YBG
--
View this message in context: http://www.nabble.com/Extracting-a-single-commit-or-object-tp21223948p21223948.html
Sent from the git mailing list archive at Nabble.com.
^ permalink raw reply
* Re: for newbs = little exercise / tutorial / warmup for windows and other non-sophisticated new Git users :-)
From: Jeff Whiteside @ 2008-12-30 22:03 UTC (permalink / raw)
To: Zorba; +Cc: git
In-Reply-To: <gje4ff$ip6$4@ger.gmane.org>
>> 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
you dont "get the files copied out into the tree"... i have zero idea
what that means wihtout punctuation and context, but i'm pretty sure
that you want to do a "git checkout versionA", not "git checkout
versionA .". if i'm wrong, then maybe try a git clean?
> 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. :-)
i punish myself for saying what i did. shame on me. you're totally right.
^ permalink raw reply
* Re: for newbs = little exercise / tutorial / warmup for windows and other non-sophisticated new Git users :-)
From: Boyd Stephen Smith Jr. @ 2008-12-30 21:49 UTC (permalink / raw)
To: Zorba; +Cc: git
In-Reply-To: <gje3ok$gnc$4@ger.gmane.org>
[-- Attachment #1: Type: text/plain, Size: 1031 bytes --]
On Tuesday 2008 December 30 15:27:33 you wrote:
> conorr@KINKLADZE /w/GITPLATFORM/swproj
> $ git status
> # On branch master
> nothing to commit (working directory clean)
>
> conorr@KINKLADZE /w/GITPLATFORM/swproj
> $ git checkout versionA .
>
> conorr@KINKLADZE /w/GITPLATFORM/swproj
> $ ls
> ABC.txt AC.txt
>
> conorr@KINKLADZE /w/GITPLATFORM/swproj
> $ rm *.*
>
> conorr@KINKLADZE /w/GITPLATFORM/swproj
> $ git checkout versionB .
>
> conorr@KINKLADZE /w/GITPLATFORM/swproj
> $ ls
> ABC.txt AC.txt BC.txt
Not a bug. git checkout <commit> <paths> does not delete files by design.
Try using "git checkout versionB" instead (no paths specified), and it will
properly remove AC.txt from your working tree as well as warning you
that "You're Doing It Wrong" (tm).
--
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: git-ls-files -l
From: Jakub Narebski @ 2008-12-30 21:47 UTC (permalink / raw)
To: Linus Torvalds; +Cc: jidanni, git
In-Reply-To: <alpine.LFD.2.00.0812301226110.3082@localhost.localdomain>
On Tue, 30 Dec 2008, Linus Torvalds wrote:
> On Tue, 30 Dec 2008, Jakub Narebski wrote:
> >
> > I think it would be easy to add '-l' also to git-ls-files. Please
> > remember to provide size only for blobs, as provoding size for trees
> > would make it harder to change to future packv4, where tree objects
> > would be stored deconstructed.
>
> Personally, more than "git ls-files -l", I've occasionally wanted a real
> "git ls" that really looks more like "ls". That includes:
>
> - turning a list of files in a subdirectory into a "directory" entry
> (which is not very natural for "git ls-files" as an index operation,
> since the index is fundamentally flat).
>
> - yes, adding "-l" as an option, but really showing the stat information.
> Right now, you can do "git ls-files --stage", and it will show a kind
> of extended information, but while it shows the mode, it doesn't show
> the owner/timestamp/etc parts of the index, and those are sometimes
> interesting.
Good idea.
I guess we could put shortened sha-1 of object in place of owner and
group info which is not present in index, and perhaps stage number
instead of number of hard links. I wonder a bit about formatting
timestamps, if to follow "ls -l" format there...
> Btw, the "ls-tree -l" format is not nice. Don't use it as a basis
> to pattern "ls -l" (or if you want to just extend ls-tree, whatever).
Well, "ls-tree -l" is just "ls-tree" with size added. You would
probably want to use "git ls-tree -l --abbrev" instead for human
consumption.
--
Jakub Narebski
Poland
^ permalink raw reply
* Why can't git pull --rebase work if there are modified files?
From: skillzero @ 2008-12-30 21:40 UTC (permalink / raw)
To: git
If I have locally modified files and I try to 'git pull --rebase', it
fails because of the locally modified files. If I don't use the
--rebase option, it works (but generates a merge commit if I have
local commits). Why does rebasing require an unmodified checkout? It
seems like it should only stop if I something in the newly fetched
changes conflict with my local changes.
I almost always have modified files in my checkout for things I'm
working on. I also often have a commit or two that haven't been pushed
because I'm waiting until I get to a good point before pushing. If I
do 'git pull', I end up with a merge commit each time. That's why I
want to use --rebase, but for it to work, I have to git stash, then
rebase then git stash pop.
^ permalink raw reply
* Re: for newbs = little exercise / tutorial / warmup for windows and other non-sophisticated new Git users :-)
From: Zorba @ 2008-12-30 21:39 UTC (permalink / raw)
To: git
In-Reply-To: <3ab397d0812301035w3dcd872fkae9509629a0ed7de@mail.gmail.com>
Thnks for reviewing !
"Jeff Whiteside" <jeff.m.whiteside@gmail.com> wrote in message
news:3ab397d0812301035w3dcd872fkae9509629a0ed7de@mail.gmail.com...
>> commit -a detects that files have been deleted, and takes them out of the
>> index !
>> could also have used $ git rm <specific files> and then $ git commit ..
>
> hey! i like your changes! the post is pretty polished now. the only
> thing else i would change (srysry), is the above. "-a detects that
> files have been deleted" -> heh, not true. you don't need -a here;
> it does something else.
** haven't had time to review this but from what you say it looks like I
forgot to take this out
> okay i just recreated your repo and did the same thing. with your
> syntax "git checkout versionA ." i got the same result, and i'm not
> sure why, but i think it was because of the detached head.
** at Yves' (demerphq) request I reproduced and posted the exact sequence of
commands
this was from a reboot, going straight into git bash and running the warmup
with NO git-resets at all
> 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
> the other (good?) news is that you probably _do_ want to be using git
> reset --hard in your case, because you're trying to build up a history
> from some project, so you do want to erase some faulty commits after
> you bodge something or miss some files.
** yes, now I know that git-reset is only for destruction, not navigation
> the bad news is that my opinion is that you should probably move on
> with your life, because my own past tells me that you'll never
> actually use those old project versions, hahah :p
** 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. :-)
^ permalink raw reply
* Re: for newbs = little exercise / tutorial / warmup for windows and other non-sophisticated new Git users :-)
From: Zorba @ 2008-12-30 21:27 UTC (permalink / raw)
To: git
In-Reply-To: <gjdmm6$9oj$4@ger.gmane.org>
** REPRODUCING Possible bug
rebooted PC, opened a new git bash, and started from scratch - see console
output below
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
Welcome to Git (version 1.6.0.2-preview20080923)
Run 'git help git' to display the help index.
Run 'git help <command>' to display help for specific commands.
conorr@KINKLADZE /w/GITPLATFORM
$ mkdir swproj
conorr@KINKLADZE /w/GITPLATFORM
$ cd swproj
conorr@KINKLADZE /w/GITPLATFORM/swproj
$ cat > ABC.txt
ABC
conorr@KINKLADZE /w/GITPLATFORM/swproj
$ cat > BC.txt
BC
conorr@KINKLADZE /w/GITPLATFORM/swproj
$ cat > AC.txt
AC
conorr@KINKLADZE /w/GITPLATFORM/swproj
$ cat > C.txt
C
conorr@KINKLADZE /w/GITPLATFORM/swproj
$ ls
ABC.txt AC.txt BC.txt C.txt
conorr@KINKLADZE /w/GITPLATFORM/swproj
$ git init
Initialized empty Git repository in w:/GITPLATFORM/swproj/.git/
conorr@KINKLADZE /w/GITPLATFORM/swproj
$ git add *a*.txt
conorr@KINKLADZE /w/GITPLATFORM/swproj
$ git commit -m "version A"
Created initial commit 2b88490: version A
2 files changed, 2 insertions(+), 0 deletions(-)
create mode 100644 ABC.txt
create mode 100644 AC.txt
conorr@KINKLADZE /w/GITPLATFORM/swproj
$ git tag versionA 2b88
conorr@KINKLADZE /w/GITPLATFORM/swproj
$ git rm AC.txt
rm 'AC.txt'
conorr@KINKLADZE /w/GITPLATFORM/swproj
$ git add BC.txt
conorr@KINKLADZE /w/GITPLATFORM/swproj
$ git status
# On branch master
# Changes to be committed:
# (use "git reset HEAD <file>..." to unstage)
#
# deleted: AC.txt
# new file: BC.txt
#
# Untracked files:
# (use "git add <file>..." to include in what will be committed)
#
# C.txt
conorr@KINKLADZE /w/GITPLATFORM/swproj
$ git commit -m "version B"
Created commit c1e1cf8: version B
2 files changed, 1 insertions(+), 1 deletions(-)
delete mode 100644 AC.txt
create mode 100644 BC.txt
conorr@KINKLADZE /w/GITPLATFORM/swproj
$ git tag versionB c1e1
conorr@KINKLADZE /w/GITPLATFORM/swproj
$ git add *c*.txt
conorr@KINKLADZE /w/GITPLATFORM/swproj
$ git commit -m "version C"
Created commit 66c62fd: version C
1 files changed, 1 insertions(+), 0 deletions(-)
create mode 100644 C.txt
conorr@KINKLADZE /w/GITPLATFORM/swproj
$ git tag versionC 66c6
conorr@KINKLADZE /w/GITPLATFORM/swproj
$ rm *.*
conorr@KINKLADZE /w/GITPLATFORM/swproj
$ ls
conorr@KINKLADZE /w/GITPLATFORM/swproj
$ git commit -a -m "version D"
Created commit eee4a13: version D
3 files changed, 0 insertions(+), 3 deletions(-)
delete mode 100644 ABC.txt
delete mode 100644 BC.txt
delete mode 100644 C.txt
conorr@KINKLADZE /w/GITPLATFORM/swproj
$ git tag versionD eee4
conorr@KINKLADZE /w/GITPLATFORM/swproj
$ git status
# On branch master
nothing to commit (working directory clean)
conorr@KINKLADZE /w/GITPLATFORM/swproj
$ git checkout versionA .
conorr@KINKLADZE /w/GITPLATFORM/swproj
$ ls
ABC.txt AC.txt
conorr@KINKLADZE /w/GITPLATFORM/swproj
$ rm *.*
conorr@KINKLADZE /w/GITPLATFORM/swproj
$ git checkout versionB .
conorr@KINKLADZE /w/GITPLATFORM/swproj
$ ls
ABC.txt AC.txt BC.txt
conorr@KINKLADZE /w/GITPLATFORM/swproj
$ rm *.*
conorr@KINKLADZE /w/GITPLATFORM/swproj
$ git checkout versionC .
conorr@KINKLADZE /w/GITPLATFORM/swproj
$ ls
ABC.txt AC.txt BC.txt C.txt
conorr@KINKLADZE /w/GITPLATFORM/swproj
$ rm *.*
conorr@KINKLADZE /w/GITPLATFORM/swproj
$ git checkout versionD .
conorr@KINKLADZE /w/GITPLATFORM/swproj
$ ls
ABC.txt AC.txt BC.txt C.txt
conorr@KINKLADZE /w/GITPLATFORM/swproj
$ gitk
conorr@KINKLADZE /w/GITPLATFORM/swproj
$ comment: gitk shows that versionA & C are correct, but B & D are wrong
^ 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