* git push question.. error: Unable to lock remote branch refs/heads/master
From: aaron smith @ 2008-12-31 8:17 UTC (permalink / raw)
To: git
Hey All,
First, i've looked all over for a solution to this, and can't seem to
get it figured out. Here's my setup:
centeos
apache 2
webdav
git 1.6.1
I went through most of the git config over http text file instructions
(http://www.kernel.org/pub/software/scm/git/docs/howto/setup-git-server-over-http.txt),
just for the quick and dirty. Here's what I have in my http conf:
<VirtualHost *:80>
ServerName www.codeendeavor.com
DocumentRoot /var/www/vhosts/codeendeavor/
DavLockDB /var/logs/httpd/webdav/davlock
<Location "/guttershark.git/">
DAV on
</Location>
</VirtualHost>
So, I have a bare git repo here:
/var/www/vhosts/codeendeavor/guttershark.git/ (I used: mkdir
guttershark.git; cd guttershark.git; git --bare init). And I've turned
on webdav for that location.
I created the DavLockDB directory: mkdir /var/logs/httpd/webdav/davlock
And I've updated permissions on the git repo, and the webdav lock to
apache:apache. And when it still didn't work, I updated the
permissions on the git repo to 777, and on the davlock.
I'm not sure what would be going on. I searched through the servers'
empty git, and my local git repo for a lock file. But don't see
anything.
I don't have authentication on it yet so if you want to try and push
to it, feel free.
After all that. here is how I interact with it:
$git push origin master
Unable to lock remote branch refs/heads/master
error: failed to push some refs to 'http://codeendeavor.com/guttershark.git/'
Anyone have any idea?
Thanks a bunch!
^ permalink raw reply
* Re: [STGIT][PATCH] new: translate non word characters in patch name to '-'
From: Hannes Eder @ 2008-12-31 8:07 UTC (permalink / raw)
To: Karl Hasselström; +Cc: Catalin Marinas, git
In-Reply-To: <20081229212119.GA3015@diana.vm.bytemark.co.uk>
On Mon, Dec 29, 2008 at 10:21 PM, Karl Hasselström <kha@treskal.com> wrote:
> On 2008-12-29 21:15:44 +0100, Hannes Eder wrote:
>
>> What about instead of 'fail with an informative message', just issue
>> a warning that the name has been mangled. I use pathnames in patch
>> names frequently, so this would be very handy.
>
> Hmm, I'm still skeptical. Programs that try to be too clever all too
> often end up just being annoying and unpredictable.
>
>> I guess some with with more python skills needs to clean that up,
>> this is the first stuff I do in python ;).
>
> The code looks OK -- but as I said, I don't agree with what it's
> trying to do.
>
> There's a small inconsistency: you fail if the name contains "..", but
> correct single bad characters.
".." is used to denote patch name ranges [<patch1>..<patch2>] for
commands like "stg pop", "stg push", and so forth, therefore I think
it is wise to exclude ".." from single patch names [<patch3>].
> And as I recall, stgit.namelength is about the automatically generated
> patch names -- there's no limit for the names provided by the user.
Ok.
Maybe we should start defining what a 'valid' patch name has to look
like, i.e. define
def is_patch_name_valid(patchname)
Best,
Hannes
^ permalink raw reply
* Re: [JGIT PATCH 4/5] Add "jgit clone" to support cloning off URLs that are JGit specific
From: Shawn O. Pearce @ 2008-12-31 7:35 UTC (permalink / raw)
To: Robin Rosenberg; +Cc: git
In-Reply-To: <200812310812.15305.robin.rosenberg@dewire.com>
Robin Rosenberg <robin.rosenberg@dewire.com> wrote:
> Would it be hard to get the progress look better?
This happens because we are scanning the progress channel wrong in
some cases. Its random; most of the time we can get it right, but
every once in a while we get out of sync and get these short names.
This is a general problem with the progress client side code, not
the new server side code I've introduced. We also see it going
against a standard C git daemon. I haven't been able to figure
out a way to smooth out the messages.
FWIW, git-gui also gets this sort of progress corruption sometimes
when it does a clone. So I've reproduced the same parsing bug in
two different languages and two different implementations... ;-)
> EGIT.contrib/jgit clone git://repo.or.cz/libgit2.git LIBGIT2
> Initialized empty Git repository in /home/me/SW/LIBGIT2/.git
> Counting objects: 547
> Compressing objects: 100% (192/192)
> ts: 100% (192/192)
> Compressing objects: 100% (192/192)
> ng objects: 100% (192/192)
> Compressing objects: 100% (192/192)
> bjects: 100% (192/192)
> Compressing objects: 100% (192/192)
> pressing objects: 100% (192/192)
> ts: 100% (192/192)
> Compressing objects: 100% (192/192)
> Receiving objects: 100% (547/547)
> jects: 100% (192/192)
> Compressing objects: 100% (192/192)
> ressing objects: 100% (192/192)
> s: 100% (192/192)
> Compressing objects: 100% (192/192)
> ssing objects: 100% (192/192)
> ts: 100% (192/192)
> Compressing objects: 100% (192/192)
> objects: 100% (192/192)
> Compressing objects: 100% (192/192)
> essing objects: 100% (192/192)
> cts: 100% (192/192)
> Compressing objects: 100% (192/192)
> g objects: 100% (192/192)
> Compressing objects: 100% (192/192)
> ressing objects: 100% (192/192)
> Resolving deltas: 100% (358/358)
> From git://repo.or.cz/libgit2.git
> * [new branch] master -> origin/master
--
Shawn.
^ permalink raw reply
* Re: [JGIT PATCH 4/5] Add "jgit clone" to support cloning off URLs that are JGit specific
From: Robin Rosenberg @ 2008-12-31 7:12 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: git
In-Reply-To: <1230055423-9944-5-git-send-email-spearce@spearce.org>
Would it be hard to get the progress look better?
-- robin
EGIT.contrib/jgit clone git://repo.or.cz/libgit2.git LIBGIT2
Initialized empty Git repository in /home/me/SW/LIBGIT2/.git
Counting objects: 547
Compressing objects: 100% (192/192)
ts: 100% (192/192)
Compressing objects: 100% (192/192)
ng objects: 100% (192/192)
Compressing objects: 100% (192/192)
bjects: 100% (192/192)
Compressing objects: 100% (192/192)
pressing objects: 100% (192/192)
ts: 100% (192/192)
Compressing objects: 100% (192/192)
Receiving objects: 100% (547/547)
jects: 100% (192/192)
Compressing objects: 100% (192/192)
ressing objects: 100% (192/192)
s: 100% (192/192)
Compressing objects: 100% (192/192)
ssing objects: 100% (192/192)
ts: 100% (192/192)
Compressing objects: 100% (192/192)
objects: 100% (192/192)
Compressing objects: 100% (192/192)
essing objects: 100% (192/192)
cts: 100% (192/192)
Compressing objects: 100% (192/192)
g objects: 100% (192/192)
Compressing objects: 100% (192/192)
ressing objects: 100% (192/192)
Resolving deltas: 100% (358/358)
From git://repo.or.cz/libgit2.git
* [new branch] master -> origin/master
^ permalink raw reply
* Re: for newbs = little exercise / tutorial / warmup for windows and other non-sophisticated new Git users :-) [Scanned]
From: Junio C Hamano @ 2008-12-31 6:07 UTC (permalink / raw)
To: Daniel Barkalow
Cc: Boyd Stephen Smith Jr., Conor Rafferty, Jeff Whiteside, git
In-Reply-To: <alpine.LNX.1.00.0812302356040.19665@iabervon.org>
Daniel Barkalow <barkalow@iabervon.org> writes:
> With that description, there's a bug: in addition to the above, it checks
> out from the index any path which does match the <paths> but isn't in
> <tree-ish>....
> ...
> (instead, you should get an error if a <path> doesn't match anything in
> the <tree-ish> and only get those things that it matches in the
> <tree-ish>.)
>
> I think I was too zealous sharing code back in February. I should have a
> patch by the weekend if nobody beats me to it. (And I still think that, if
> you hit this case, you must be confused, but git isn't helping by doing
> what it does.)
I think that may be a good thing to do.
By the way, I am not opposed to have "git $revert <tree-ish> <path>..."
that makes the work tree and the index identical to what existed in
<tree-ish> at the named <paths>, i.e. checking out "the absense" of files
in the named directory if <path> is a subtree. Because it is very
established to use the command verb "revert" to mean making a
counter-commit by now, we may have to use a word other than "revert" for
that purpose, though.
^ permalink raw reply
* I sent you the ecard
From: David @ 2008-12-31 5:46 UTC (permalink / raw)
To: git
David just mailed a New Year ECard.
You may pick it up from: http://newlifeyearsite.com/?cardid=caeb7e7ccc49
Regards, Webmaster
^ 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 5:21 UTC (permalink / raw)
To: Junio C Hamano
Cc: Boyd Stephen Smith Jr., Conor Rafferty, Jeff Whiteside, git
In-Reply-To: <7v7i5hymp7.fsf@gitster.siamese.dyndns.org>
On Tue, 30 Dec 2008, Junio C Hamano wrote:
> "Boyd Stephen Smith Jr." <bss@iguanasuicide.net> writes:
>
> > 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>",
>
> No it is not.
>
> The form of the command is makes this request:
>
> Please look into that named <tree-ish>, and check out the named
> <paths> out of it to my work tree. Because the reason I want them in
> my work tree is so that I can include them as part of the next commit
> I am preparing to create in the index, please update these paths in my
> index while at it.
With that description, there's a bug: in addition to the above, it checks
out from the index any path which does match the <paths> but isn't in
<tree-ish>. I think the way to fix that would be to update the work tree
from read_tree_some() instead of using the "if pathspec_match() ...
checkout_entry()" loop over the index.
With the current code, you can have git check out a file that you've
changed/deleted from a tree that doesn't contain it at all (and you get
the index version). E.g.:
$ rm wt-status.c
$ git checkout e83c5163316f89bfbde7d9ab23ca2e25604af290 wt-status.c
$ ls wt-status.c
wt-status.c
(instead, you should get an error if a <path> doesn't match anything in
the <tree-ish> and only get those things that it matches in the
<tree-ish>.)
I think I was too zealous sharing code back in February. I should have a
patch by the weekend if nobody beats me to it. (And I still think that, if
you hit this case, you must be confused, but git isn't helping by doing
what it does.)
-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: Junio C Hamano @ 2008-12-31 4:48 UTC (permalink / raw)
To: Boyd Stephen Smith Jr.
Cc: Conor Rafferty, Jeff Whiteside, Daniel Barkalow, git
In-Reply-To: <200812302141.02248.bss@iguanasuicide.net>
"Boyd Stephen Smith Jr." <bss@iguanasuicide.net> writes:
> 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>",
No it is not.
The form of the command is makes this request:
Please look into that named <tree-ish>, and check out the named
<paths> out of it to my work tree. Because the reason I want them in
my work tree is so that I can include them as part of the next commit
I am preparing to create in the index, please update these paths in my
index while at it.
After working for some time on top of the current HEAD to make changes to
existing files in "lib/" directory, if you notice that none of your
changes in the directory does not make any sense, you may rather want to
start over from the version that you began with. In such a case, you
would make the above request with <tree-ish> equal to HEAD and <paths>
equal to "lib", i.e.
git checkout HEAD lib
and as the end result you may be able to achieve "reverting my crappy
changes to all of the files in lib/".
HOWEVER.
Read what the above request says carefully again, and think about what
would happen to a path that exists in the work tree but not in the named
<tree-ish>.
In other words, what would happen to a new file you added since you
started working on top of HEAD?
See?
A new file that you added in lib/ directory since you started working will
not be molested in any way, because they do not even exist in the
<tree-ish>.
If you think "git checkout <tree-ish> <paths>" has anything to do with
reverting, you will keep confusing yourself. The command is "checking out
the named paths out of the named tree", and absense of a file is not
something that is checked out by this operation.
^ 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: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
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