* Re: Announcement: Git Extensions stable (windows shell extensions)
From: Peter Krefting @ 2008-12-19 10:36 UTC (permalink / raw)
To: Henk; +Cc: git
In-Reply-To: <1229547366402-1669761.post@n2.nabble.com>
Henk:
> I just rereleased a 0.9 version without the visual studio plugin. Too bad it
> causes problems, I will try to fix them soon. I was able to reproduce the
> error on my laptop, so thats a good start.
I tried with the 0.91 version but ran into a different problem:
"The system cannot open the device or file specified."
followed by
"The installer has encountered an unexpected error installing this
package. This may indicate a problem with this package. The error code
is 2755."
--
\\// Peter - http://www.softwolves.pp.se/
^ permalink raw reply
* remote tracking branch deletion problem
From: Thomas Jarosch @ 2008-12-19 11:57 UTC (permalink / raw)
To: git; +Cc: Junio C Hamano
Hello together,
while playing around with git, I stumbled upon a strange remote tracking
branch deletion problem. It seems I'm unable to delete the remote tracking
branch "origin/HEAD" using git 1.6.0.5. Here's what I did:
[tomj@storm repo]$ git init
Initialized empty Git repository in /tmp/repo/.git/
[tomj@storm repo]$ echo "test" >test
[tomj@storm repo]$ git add test
[tomj@storm repo]$ git commit -m "Test"
[tomj@storm tmp]$ git clone repo alice
Initialized empty Git repository in /tmp/alice/.git/
[tomj@storm alice]$ git branch -r
origin/HEAD
origin/master
[tomj@storm alice]$ git branch -r -d origin/HEAD
Deleted remote branch origin/HEAD.
[tomj@storm alice]$ git branch -r -d origin/master
Deleted remote branch origin/master.
[tomj@storm alice]$ ls -al .git/refs/remotes/origin/HEAD
-rw-rw---- 1 tomj intra2net 32 19. Dec 12:43 .git/refs/remotes/origin/HEAD
[tomj@storm alice]$ git branch -r
error: refs/remotes/origin/HEAD points nowhere!
Is this supposed to be? git 1.6.1.rc3.35.gc0ceb shows a similar behavior.
Cheers,
Thomas
^ permalink raw reply
* [PATCH] Documentation: fix typos, grammar, asciidoc syntax
From: Markus Heidelberg @ 2008-12-19 12:14 UTC (permalink / raw)
To: gitster; +Cc: git
Signed-off-by: Markus Heidelberg <markus.heidelberg@web.de>
---
Documentation/diff-format.txt | 2 +-
Documentation/diff-generate-patch.txt | 6 +++---
Documentation/git-commit.txt | 2 +-
Documentation/git-diff-tree.txt | 4 ++--
Documentation/git-mailinfo.txt | 2 +-
Documentation/git-receive-pack.txt | 4 ++--
Documentation/git-reflog.txt | 4 ++--
Documentation/git-show-branch.txt | 4 ++--
Documentation/git-submodule.txt | 2 +-
Documentation/git-update-index.txt | 8 ++++----
Documentation/gitcore-tutorial.txt | 8 ++++----
Documentation/gitk.txt | 4 ++--
Documentation/i18n.txt | 4 ++--
13 files changed, 27 insertions(+), 27 deletions(-)
diff --git a/Documentation/diff-format.txt b/Documentation/diff-format.txt
index aafd3a3..1eeb1c7 100644
--- a/Documentation/diff-format.txt
+++ b/Documentation/diff-format.txt
@@ -58,7 +58,7 @@ Possible status letters are:
be committed)
- X: "unknown" change type (most probably a bug, please report it)
-Status letters C and M are always followed by a score (denoting the
+Status letters C and R are always followed by a score (denoting the
percentage of similarity between the source and target of the move or
copy), and are the only ones to be so.
diff --git a/Documentation/diff-generate-patch.txt b/Documentation/diff-generate-patch.txt
index 517e1eb..0f25ba7 100644
--- a/Documentation/diff-generate-patch.txt
+++ b/Documentation/diff-generate-patch.txt
@@ -143,15 +143,15 @@ different from it.
A `-` character in the column N means that the line appears in
fileN but it does not appear in the result. A `+` character
-in the column N means that the line appears in the last file,
+in the column N means that the line appears in the result,
and fileN does not have that line (in other words, the line was
added, from the point of view of that parent).
In the above example output, the function signature was changed
from both files (hence two `-` removals from both file1 and
file2, plus `++` to mean one line that was added does not appear
-in either file1 nor file2). Also two other lines are the same
-from file1 but do not appear in file2 (hence prefixed with ` +`).
+in either file1 nor file2). Also eight other lines are the same
+from file1 but do not appear in file2 (hence prefixed with `{plus}`).
When shown by `git diff-tree -c`, it compares the parents of a
merge commit with the merge result (i.e. file1..fileN are the
diff --git a/Documentation/git-commit.txt b/Documentation/git-commit.txt
index 6203461..b5d81be 100644
--- a/Documentation/git-commit.txt
+++ b/Documentation/git-commit.txt
@@ -166,7 +166,7 @@ FROM UPSTREAM REBASE" section in linkgit:git-rebase[1].)
'git-commit' if any paths are given on the command line,
in which case this option can be omitted.
If this option is specified together with '--amend', then
- no paths need be specified, which can be used to amend
+ no paths need to be specified, which can be used to amend
the last commit without committing changes that have
already been staged.
diff --git a/Documentation/git-diff-tree.txt b/Documentation/git-diff-tree.txt
index 5d48664..23b7abd 100644
--- a/Documentation/git-diff-tree.txt
+++ b/Documentation/git-diff-tree.txt
@@ -43,7 +43,7 @@ include::diff-options.txt[]
show tree entry itself as well as subtrees. Implies -r.
--root::
- When '--root' is specified the initial commit will be showed as a big
+ When '--root' is specified the initial commit will be shown as a big
creation event. This is equivalent to a diff against the NULL tree.
--stdin::
@@ -63,7 +63,7 @@ and terminated by a newline) is printed before the difference. When
comparing commits, the ID of the first (or only) commit, followed by a
newline, is printed.
+
-The following flags further affects the behavior when comparing
+The following flags further affect the behavior when comparing
commits (but not trees).
-m::
diff --git a/Documentation/git-mailinfo.txt b/Documentation/git-mailinfo.txt
index 31eccea..8d95aaa 100644
--- a/Documentation/git-mailinfo.txt
+++ b/Documentation/git-mailinfo.txt
@@ -13,7 +13,7 @@ SYNOPSIS
DESCRIPTION
-----------
-Reading a single e-mail message from the standard input, and
+Reads a single e-mail message from the standard input, and
writes the commit log message in <msg> file, and the patches in
<patch> file. The author name, e-mail and e-mail subject are
written out to the standard output to be used by 'git-am'
diff --git a/Documentation/git-receive-pack.txt b/Documentation/git-receive-pack.txt
index 6b2f8c4..514f03c 100644
--- a/Documentation/git-receive-pack.txt
+++ b/Documentation/git-receive-pack.txt
@@ -86,7 +86,7 @@ post-receive Hook
-----------------
After all refs were updated (or attempted to be updated), if any
ref update was successful, and if $GIT_DIR/hooks/post-receive
-file exists and is executable, it will be invoke once with no
+file exists and is executable, it will be invoked once with no
parameters. The standard input of the hook will be one line
for each successfully updated ref:
@@ -133,7 +133,7 @@ post-update Hook
----------------
After all other processing, if at least one ref was updated, and
if $GIT_DIR/hooks/post-update file exists and is executable, then
-post-update will called with the list of refs that have been updated.
+post-update will be called with the list of refs that have been updated.
This can be used to implement any repository wide cleanup tasks.
The exit code from this hook invocation is ignored; the only thing
diff --git a/Documentation/git-reflog.txt b/Documentation/git-reflog.txt
index d99236e..7f7a544 100644
--- a/Documentation/git-reflog.txt
+++ b/Documentation/git-reflog.txt
@@ -28,7 +28,7 @@ updated. This command is to manage the information recorded in it.
The subcommand "expire" is used to prune older reflog entries.
Entries older than `expire` time, or entries older than
-`expire-unreachable` time and are not reachable from the current
+`expire-unreachable` time and not reachable from the current
tip, are removed from the reflog. This is typically not used
directly by the end users -- instead, see linkgit:git-gc[1].
@@ -71,7 +71,7 @@ them.
which in turn defaults to 90 days.
--expire-unreachable=<time>::
- Entries older than this time and are not reachable from
+ Entries older than this time and not reachable from
the current tip of the branch are pruned. Without the
option it is taken from configuration
`gc.reflogExpireUnreachable`, which in turn defaults to
diff --git a/Documentation/git-show-branch.txt b/Documentation/git-show-branch.txt
index d3f2588..8277577 100644
--- a/Documentation/git-show-branch.txt
+++ b/Documentation/git-show-branch.txt
@@ -30,7 +30,7 @@ OPTIONS
-------
<rev>::
Arbitrary extended SHA1 expression (see linkgit:git-rev-parse[1])
- that typically names a branch HEAD or a tag.
+ that typically names a branch head or a tag.
<glob>::
A glob pattern that matches branch or tag names under
@@ -172,7 +172,7 @@ only the primary branches. In addition, if you happen to be on
your topic branch, it is shown as well.
------------
-$ git show-branch --reflog='10,1 hour ago' --list master
+$ git show-branch --reflog="10,1 hour ago" --list master
------------
shows 10 reflog entries going back from the tip as of 1 hour ago.
diff --git a/Documentation/git-submodule.txt b/Documentation/git-submodule.txt
index babaa9b..2f207fb 100644
--- a/Documentation/git-submodule.txt
+++ b/Documentation/git-submodule.txt
@@ -87,7 +87,7 @@ use by subsequent users cloning the superproject. If the URL is
given relative to the superproject's repository, the presumption
is the superproject and submodule repositories will be kept
together in the same relative location, and only the
-superproject's URL need be provided: git-submodule will correctly
+superproject's URL needs to be provided: git-submodule will correctly
locate the submodule using the relative URL in .gitmodules.
status::
diff --git a/Documentation/git-update-index.txt b/Documentation/git-update-index.txt
index 1d9d81a..25e0bbe 100644
--- a/Documentation/git-update-index.txt
+++ b/Documentation/git-update-index.txt
@@ -55,7 +55,7 @@ OPTIONS
default behavior is to error out. This option makes
'git-update-index' continue anyway.
---ignore-submodules:
+--ignore-submodules::
Do not try to update submodules. This option is only respected
when passed before --refresh.
@@ -78,9 +78,9 @@ OPTIONS
--assume-unchanged::
--no-assume-unchanged::
- When these flags are specified, the object name recorded
+ When these flags are specified, the object names recorded
for the paths are not updated. Instead, these options
- sets and unsets the "assume unchanged" bit for the
+ set and unset the "assume unchanged" bit for the
paths. When the "assume unchanged" bit is on, git stops
checking the working tree files for possible
modifications, so you need to manually unset the bit to
@@ -122,7 +122,7 @@ you will need to handle the situation manually.
'git-update-index' refuses an attempt to add `path/file`.
Similarly if a file `path/file` exists, a file `path`
cannot be added. With --replace flag, existing entries
- that conflicts with the entry being added are
+ that conflict with the entry being added are
automatically removed with warning messages.
--stdin::
diff --git a/Documentation/gitcore-tutorial.txt b/Documentation/gitcore-tutorial.txt
index 96bf353..da8fa44 100644
--- a/Documentation/gitcore-tutorial.txt
+++ b/Documentation/gitcore-tutorial.txt
@@ -999,8 +999,8 @@ Fast forward
2 files changed, 2 insertions(+), 0 deletions(-)
----------------
-Because your branch did not contain anything more than what are
-already merged into the `master` branch, the merge operation did
+Because your branch did not contain anything more than what had
+already been merged into the `master` branch, the merge operation did
not actually do a merge. Instead, it just updated the top of
the tree of your branch to that of the `master` branch. This is
often called 'fast forward' merge.
@@ -1353,7 +1353,7 @@ $ GIT_DIR=my-git.git git init
------------
Make sure this directory is available for others you want your
-changes to be pulled by via the transport of your choice. Also
+changes to be pulled via the transport of your choice. Also
you need to make sure that you have the 'git-receive-pack'
program on the `$PATH`.
@@ -1512,7 +1512,7 @@ You can repack this private repository whenever you feel like.
6. Push your changes to the public repository, and announce it
to the public.
-7. Every once in a while, "git-repack" the public repository.
+7. Every once in a while, 'git-repack' the public repository.
Go back to step 5. and continue working.
diff --git a/Documentation/gitk.txt b/Documentation/gitk.txt
index 317f631..4673a75 100644
--- a/Documentation/gitk.txt
+++ b/Documentation/gitk.txt
@@ -21,7 +21,7 @@ git repository.
OPTIONS
-------
-To control which revisions to shown, the command takes options applicable to
+To control which revisions to show, the command takes options applicable to
the 'git-rev-list' command (see linkgit:git-rev-list[1]).
This manual page describes only the most
frequently used options.
@@ -80,7 +80,7 @@ Examples
--------
gitk v2.6.12.. include/scsi drivers/scsi::
- Show as the changes since version 'v2.6.12' that changed any
+ Show the changes since version 'v2.6.12' that changed any
file in the include/scsi or drivers/scsi subdirectories
gitk --since="2 weeks ago" \-- gitk::
diff --git a/Documentation/i18n.txt b/Documentation/i18n.txt
index 2cdacd9..708da6c 100644
--- a/Documentation/i18n.txt
+++ b/Documentation/i18n.txt
@@ -7,11 +7,11 @@ At the core level, git is character encoding agnostic.
to be what lstat(2) and creat(2) accepts. There is no such
thing as pathname encoding translation.
- - The contents of the blob objects are uninterpreted sequence
+ - The contents of the blob objects are uninterpreted sequences
of bytes. There is no encoding translation at the core
level.
- - The commit log messages are uninterpreted sequence of non-NUL
+ - The commit log messages are uninterpreted sequences of non-NUL
bytes.
Although we encourage that the commit log messages are encoded
--
1.6.1.rc3.27.gf650d1
^ permalink raw reply related
* [PATCH] Documentation: sync example output with git output
From: Markus Heidelberg @ 2008-12-19 12:14 UTC (permalink / raw)
To: gitster; +Cc: git
Don't confuse the user with old git messages.
Signed-off-by: Markus Heidelberg <markus.heidelberg@web.de>
---
Documentation/git-checkout.txt | 1 -
Documentation/git-reset.txt | 2 +-
Documentation/gitcore-tutorial.txt | 11 +++++------
Documentation/pretty-formats.txt | 6 +++---
4 files changed, 9 insertions(+), 11 deletions(-)
diff --git a/Documentation/git-checkout.txt b/Documentation/git-checkout.txt
index 79824f4..9cd5151 100644
--- a/Documentation/git-checkout.txt
+++ b/Documentation/git-checkout.txt
@@ -232,7 +232,6 @@ the `-m` option, you would see something like this:
------------
$ git checkout -m mytopic
Auto-merging frotz
-merge: warning: conflicts during merge
ERROR: Merge conflict in frotz
fatal: merge program failed
------------
diff --git a/Documentation/git-reset.txt b/Documentation/git-reset.txt
index 29156f6..2049f3d 100644
--- a/Documentation/git-reset.txt
+++ b/Documentation/git-reset.txt
@@ -130,7 +130,7 @@ Undo a merge or pull::
$ git pull <1>
Auto-merging nitfol
CONFLICT (content): Merge conflict in nitfol
-Automatic merge failed/prevented; fix up by hand
+Automatic merge failed; fix conflicts and then commit the result.
$ git reset --hard <2>
$ git pull . topic/branch <3>
Updating from 41223... to 13134...
diff --git a/Documentation/gitcore-tutorial.txt b/Documentation/gitcore-tutorial.txt
index 96bf353..df48045 100644
--- a/Documentation/gitcore-tutorial.txt
+++ b/Documentation/gitcore-tutorial.txt
@@ -899,7 +899,7 @@ file, which had no differences in the `mybranch` branch), and say:
----------------
Auto-merging hello
CONFLICT (content): Merge conflict in hello
- Automatic merge failed; fix up by hand
+ Automatic merge failed; fix conflicts and then commit the result.
----------------
It tells you that it did an "Automatic merge", which
@@ -993,7 +993,7 @@ would be different)
----------------
Updating from ae3a2da... to a80b4aa....
-Fast forward
+Fast forward (no commit created; -m option ignored)
example | 1 +
hello | 1 +
2 files changed, 2 insertions(+), 0 deletions(-)
@@ -1265,9 +1265,8 @@ file, using 3-way merge. This is done by giving
------------
$ git merge-index git-merge-one-file hello
-Auto-merging hello.
-merge: warning: conflicts during merge
-ERROR: Merge conflict in hello.
+Auto-merging hello
+ERROR: Merge conflict in hello
fatal: merge program failed
------------
@@ -1447,7 +1446,7 @@ public repository you might want to repack & prune often, or
never.
If you run `git repack` again at this point, it will say
-"Nothing to pack". Once you continue your development and
+"Nothing new to pack.". Once you continue your development and
accumulate the changes, running `git repack` again will create a
new pack, that contains objects created since you packed your
repository the last time. We recommend that you pack your project
diff --git a/Documentation/pretty-formats.txt b/Documentation/pretty-formats.txt
index f18d33e..0a8a948 100644
--- a/Documentation/pretty-formats.txt
+++ b/Documentation/pretty-formats.txt
@@ -30,7 +30,7 @@ This is designed to be as compact as possible.
commit <sha1>
Author: <author>
- Date: <author date>
+ Date: <author date>
<title line>
@@ -49,9 +49,9 @@ This is designed to be as compact as possible.
* 'fuller'
commit <sha1>
- Author: <author>
+ Author: <author>
AuthorDate: <author date>
- Commit: <committer>
+ Commit: <committer>
CommitDate: <committer date>
<title line>
--
1.6.1.rc3.27.gf650d1
^ permalink raw reply related
* Re: is it possible filter the revision history of a single file into another repository?
From: Whit Armstrong @ 2008-12-19 13:08 UTC (permalink / raw)
To: Thomas Jarosch; +Cc: git, Junio C Hamano
In-Reply-To: <200812191044.47830.thomas.jarosch@intra2net.com>
thanks, Thomas. I could definitely pull from your tree. seems like
the path of least resistance to get my repo split.
Cheers,
Whit
On Fri, Dec 19, 2008 at 4:44 AM, Thomas Jarosch
<thomas.jarosch@intra2net.com> wrote:
> On Thursday, 18. December 2008 20:51:38 Whit Armstrong wrote:
>> Sorry, seem to be getting this error:
>> `/home/whit/dvl/risk.metrics.utils/RiskMetrics/.git-rewrite/t/../index.new'
>>: No such file or directory
>>
>> do I need to set up the index file first?
>
> Hmm, I guess you have an empty commit in your repository like I did.
> This is currently a corner case in update-index, which does not create empty
> index files. I posted a patch a few days ago and Junio posted an updated
> version of that. I could send you my version for git 1.6.0.5 if you need it.
>
>> Is there a good site that documents this procedure?
>
> A good start is the git-filter-branch man page and the mailinglist archive.
>
> Thomas
>
>
^ permalink raw reply
* Re: is it possible filter the revision history of a single file into another repository?
From: Thomas Jarosch @ 2008-12-19 13:17 UTC (permalink / raw)
To: Whit Armstrong; +Cc: git, Junio C Hamano
In-Reply-To: <8ec76080812190508v2ef0f982pab66a698f06a80d5@mail.gmail.com>
On Friday, 19. December 2008 14:08:23 Whit Armstrong wrote:
> thanks, Thomas. I could definitely pull from your tree. seems like
> the path of least resistance to get my repo split.
Here's the patch I use for git 1.6.0.5. According to Junio
it has the small drawback of always writing out the index,
even if there are no changes.
If you need an updated patch against HEAD, look for Junio's reply
to my patch in the list archive.
Enjoy,
Thomas
Signed-off-by: Thomas Jarosch <thomas.jarosch@intra2net.com>
--- git-1.6.0.5/builtin-update-index.c 2008-12-08 02:21:49.000000000 +0100
+++ git-1.6.0.5.index/builtin-update-index.c 2008-12-13 12:43:14.000000000
+0100
@@ -297,6 +297,8 @@ static void read_index_info(int line_ter
struct strbuf buf;
struct strbuf uq;
+ int found_something = 0;
+
strbuf_init(&buf, 0);
strbuf_init(&uq, 0);
while (strbuf_getline(&buf, stdin, line_termination) != EOF) {
@@ -307,6 +309,8 @@ static void read_index_info(int line_ter
unsigned long ul;
int stage;
+ found_something = 1;
+
/* This reads lines formatted in one of three formats:
*
* (1) mode SP sha1 TAB path
@@ -382,6 +386,11 @@ static void read_index_info(int line_ter
bad_line:
die("malformed index info %s", buf.buf);
}
+
+ /* Force creation of empty index - needed by git filter-branch */
+ if (!found_something)
+ active_cache_changed = 1;
+
strbuf_release(&buf);
strbuf_release(&uq);
}
^ permalink raw reply
* Re: remote tracking branch deletion problem
From: Michael J Gruber @ 2008-12-19 14:56 UTC (permalink / raw)
To: Thomas Jarosch; +Cc: git, Junio C Hamano
In-Reply-To: <200812191257.18678.thomas.jarosch@intra2net.com>
Thomas Jarosch venit, vidit, dixit 19.12.2008 12:57:
> Hello together,
>
> while playing around with git, I stumbled upon a strange remote tracking
> branch deletion problem. It seems I'm unable to delete the remote tracking
> branch "origin/HEAD" using git 1.6.0.5. Here's what I did:
>
> [tomj@storm repo]$ git init
> Initialized empty Git repository in /tmp/repo/.git/
>
> [tomj@storm repo]$ echo "test" >test
> [tomj@storm repo]$ git add test
> [tomj@storm repo]$ git commit -m "Test"
>
> [tomj@storm tmp]$ git clone repo alice
> Initialized empty Git repository in /tmp/alice/.git/
>
> [tomj@storm alice]$ git branch -r
> origin/HEAD
> origin/master
>
> [tomj@storm alice]$ git branch -r -d origin/HEAD
> Deleted remote branch origin/HEAD.
> [tomj@storm alice]$ git branch -r -d origin/master
> Deleted remote branch origin/master.
>
> [tomj@storm alice]$ ls -al .git/refs/remotes/origin/HEAD
> -rw-rw---- 1 tomj intra2net 32 19. Dec 12:43 .git/refs/remotes/origin/HEAD
> [tomj@storm alice]$ git branch -r
> error: refs/remotes/origin/HEAD points nowhere!
>
> Is this supposed to be? git 1.6.1.rc3.35.gc0ceb shows a similar behavior.
I think the point here is that HEAD is really a symref. "git remote rm
origin" makes sure that symrefs are removed, and is the right command to
use here.
"git branch -r -d", as well as "git update-ref -d" fail to remove HEAD
because it's really not a branch but a symref.
You can use "git update-ref -d --no-deref" to remove HEAD.
Making builtin-branch use delete_ref(,,REF_ISSYMREF) leads to success
for your above commands. I don't know about side effects, though all
tests pass. Is this sensible?
I guess I should come up with a test for this along with the patch.
Michael
^ permalink raw reply
* Re: jgit doesn't support "compare with" and "replace with"?
From: Shawn O. Pearce @ 2008-12-19 15:20 UTC (permalink / raw)
To: Martin_S; +Cc: git
In-Reply-To: <1229677848765-1677009.post@n2.nabble.com>
Martin_S <iksdrijf@yahoo.com> wrote:
>
> Hi, I'm using eclipse 3.4 and jgit 0.4. The right click context menus don't
> list "compare with" and "replace with". Am I doing something wrong?
We haven't implemented them in EGit. So its not surprising that
they aren't appearing.
--
Shawn.
^ permalink raw reply
* how to check remote git repo for updates without pull/fetch
From: Ivan Zorin @ 2008-12-19 16:15 UTC (permalink / raw)
To: git
Hello. I have not very hard question, but I don't know how to better do
it - could you tell me, please, does exist some way to check remote git
repository for updates without downloading any essential files? I
suppose, that such command should just type something like: "already
updated", if current working tree identical to remote repo, and
something like "there is some updates in remote repo", if remote repo
has some new commits and/or branches. Thanks.
^ permalink raw reply
* Re: how to check remote git repo for updates without pull/fetch
From: Shawn O. Pearce @ 2008-12-19 16:33 UTC (permalink / raw)
To: Ivan Zorin; +Cc: git
In-Reply-To: <494BC89F.9070107@gmail.com>
Ivan Zorin <ivan.a.zorin@gmail.com> wrote:
> Hello. I have not very hard question, but I don't know how to better do
> it - could you tell me, please, does exist some way to check remote git
> repository for updates without downloading any essential files? I
> suppose, that such command should just type something like: "already
> updated", if current working tree identical to remote repo, and
> something like "there is some updates in remote repo", if remote repo
> has some new commits and/or branches. Thanks.
There aren't any commands to do it.
What you could do is write a script based upon git ls-remote. A
really simple one might be:
#!/bin/sh
remote=$1
o=.git/remote_cache.$remote
n=$o.new$$
git ls-remote $remote >$n
if [ -f $o ]
then
if diff $o $n >/dev/null
then
echo "No changes"
else
mv $n $o
echo "Updates available"
else
mv $n $o
echo "New remote remembered..."
fi
A much more complex one would actually rewrite refs/heads/ to
the correct refs/remotes/ namespace on your local repository and
compare the remote ref values to the local refs/remotes values.
Patches for git fetch --pretend or something might be interesting.
Though I recall a thread about this before on the MLand saying there
was no point. Its not like you can see how big the download would
be until after its over.
--
Shawn.
^ permalink raw reply
* Re: how to check remote git repo for updates without pull/fetch
From: Ivan Zorin @ 2008-12-19 16:39 UTC (permalink / raw)
To: git
In-Reply-To: <494BC89F.9070107@gmail.com>
> does exist some way to check remote git repository for updates without downloading any essential files?
Well, actually, I think, that I've found one of possible soulution already:
First, check remote repo:
$ git ls-remote /path/to/git/repo
<some sha1-hash> HEAD
...
Then check local repo:
$ cat .git/HEAD
ref: refs/heads/master
$ cat .git/refs/heads/master
<other sha1-hash>
So, if both hashes identical, then current working tree with HEAD, which points to "master", already up-to-dated,
but if they don't, then there is some updates at remote repo.
^ permalink raw reply
* Re: [PATCH] Simplified GIT usage guide
From: C. Scott Ananian @ 2008-12-19 17:08 UTC (permalink / raw)
To: Michael J Gruber; +Cc: David Howells, git, linux-kernel
In-Reply-To: <494B68B8.20107@drmicha.warpmail.net>
On Fri, Dec 19, 2008 at 4:26 AM, Michael J Gruber
<git@drmicha.warpmail.net> wrote:
> C. Scott Ananian venit, vidit, dixit 19.12.2008 01:47:
>> On Fri, Dec 12, 2008 at 1:28 PM, David Howells <dhowells@redhat.com> wrote:
>>> Add a guide to using GIT's simpler features.
>>> diff --git a/Documentation/git-haters-guide.txt b/Documentation/git-haters-guide.txt
>>> +In the above example, I've assumed that you've got your own tree with the head
>>> +at commit C3, and that you've got a branch that you want to merge, which has
>>> +its head at commit B3. After merging them, you'd end up with a directed,
>>> +cyclic tree:
>>
>> That should be, "acyclic". There are no cycles, because the graph is directed.
>
> Well, directed graphs can have cycles. But the revision graph of a
> revision control system has to be an acyclic directed graph. Otherwise
> parenthood would be a complicated matter ;)
I mean that the example given didn't have a cycle (even though it has
nodes arranged in a circle) because of the orientation of the edges.
But you're right, "directed acyclic graph" is a better correction; the
nodes in git do not form a tree.
--scott
--
( http://cscott.net/ )
^ permalink raw reply
* Re: Git Notes idea.
From: Govind Salinas @ 2008-12-19 17:18 UTC (permalink / raw)
To: Jeff King; +Cc: Johannes Schindelin, Git Mailing List
In-Reply-To: <20081217101110.GC18265@coredump.intra.peff.net>
On Wed, Dec 17, 2008 at 4:11 AM, Jeff King <peff@peff.net> wrote:
> On Wed, Dec 17, 2008 at 04:43:57AM +0100, Johannes Schindelin wrote:
>
>> > I agree, I haven't thought of any fix along these lines other than to
>> > make gc do the clean up.
>>
>> I have, and IIRC I briefly mentioned it back then. Basically, you will
>> have to add a "git notes gc" or some such, which basically reads in the
>> whole notes, traverses all reachable commits, marking the corresponding
>> notes, and then writes out all marked notes (leaving the other notes
>> behind).
>
> I was thinking something similar, but I think it is even easier. Make
> the rule "if we still have the object, then we still have the note".
> That has three benefits:
>
> - implementation is simple: for each note $n, delete it unless
> has_sha1_file($n).
>
> - it handles notes on non-commit objects
>
> - it kills off notes when an object is _pruned_, not when it stops
> being _reachable_. So if I delete a branch with a commit found
> nowhere else, its notes will hang around until it is actually pruned.
> If I pull it from lost+found, I still keep the notes.
>
> Note that all of this garbage collection of notes is really just
> removing them from the most current notes _tree_. If the notes structure
> is actually composed of commits, then old notes that are "deleted" will
> still be available historically.
>
This is my concern with keeping a history of the notes pseudo-branch. Let
us say that I do the following
1) on branch A commit a
2) add note a`
3) on branch B commit b
4) add note b`
5) on branch B commit c
6) add note c`
7) delete branch A
8) gc after a time such that a is pruned
Now either I will always have anote a`
^ permalink raw reply
* Re: Git Notes idea.
From: Govind Salinas @ 2008-12-19 17:38 UTC (permalink / raw)
To: Jeff King; +Cc: Johannes Schindelin, Git Mailing List
In-Reply-To: <5d46db230812190918qf22b874n8d8aeea557083df8@mail.gmail.com>
Sorry, hit the send key accidentally.
On Wed, Dec 17, 2008 at 4:11 AM, Jeff King <peff@peff.net> wrote:
> On Wed, Dec 17, 2008 at 04:43:57AM +0100, Johannes Schindelin wrote:
>
> > I agree, I haven't thought of any fix along these lines other than to
> > make gc do the clean up.
>
> I have, and IIRC I briefly mentioned it back then. Basically, you will
>> have to add a "git notes gc" or some such, which basically reads in the
>> whole notes, traverses all reachable commits, marking the corresponding
>> notes, and then writes out all marked notes (leaving the other notes
>> behind).
>
> I was thinking something similar, but I think it is even easier. Make
> the rule "if we still have the object, then we still have the note".
> That has three benefits:
>
> - implementation is simple: for each note $n, delete it unless
> has_sha1_file($n).
>
> - it handles notes on non-commit objects
>
> - it kills off notes when an object is _pruned_, not when it stops
> being _reachable_. So if I delete a branch with a commit found
> nowhere else, its notes will hang around until it is actually pruned.
> If I pull it from lost+found, I still keep the notes.
>
> Note that all of this garbage collection of notes is really just
> removing them from the most current notes _tree_. If the notes structure
> is actually composed of commits, then old notes that are "deleted" will
> still be available historically.
>
This is my concern with keeping a history of the notes pseudo-branch. Let
me restate what you are saying with an example
1) on branch A commit a
2) add note a`
3) on branch B commit b
4) add note b`
5) on branch B commit c
6) add note c`
7) delete branch A
8) gc after a time such that a is pruned
Now either I will always have a note a` as an object forever even though
the only commit that points to it is gone or I have to re-write the history of
the notes branch from the point that it was added.
Given this problem, is it really such a good idea to keep the history?
Of course the other side of this conversation is that the merge operation
will be more complex since the following can also happen
9) push notes
10) user 2 pulls notes but still has commit a and note a`
On the other, other hand, pushing and pulling notes if a history is kept
will have to involve a lot of rebasing/merging.
Just to throw an idea out...
A possible solution is that notes are per-branch,
refs/notes/heads/master
refs/notes/heads/foo/bar
refs/notes/remotes/baz/bang
and then it is easier to deal with. A published branch's notes are isolated
from the changes in unpublished branches. And since published branches
aren't *supposed* to change, then the notes should also always be fast
forwards. Similarly, if a branch is not considered stable, like pu or even
next, then the associated notes branch could be forced in the same way.
Rebase, cherry-pick and merge (and possibly branch/checkout) would have
to be updated to handle notes, which is the down side. It also doesn't solve
the issue of a history causing us to keep notes after the aren't useful anymore.
So perhaps we could use the above layout with no history?
Thanks,
Govind.
^ permalink raw reply
* Re: Git Notes idea.
From: Govind Salinas @ 2008-12-19 17:42 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Jeff King, Git Mailing List
In-Reply-To: <alpine.DEB.1.00.0812171233270.28560@intel-tinevez-2-302>
On Wed, Dec 17, 2008 at 5:38 AM, Johannes Schindelin
<Johannes.Schindelin@gmx.de> wrote:
> Hi,
>
> On Wed, 17 Dec 2008, Jeff King wrote:
>> If he is planning on doing a separate pyrite implementation, then it
>> _hasn't_ been implemented yet. And I don't care there if he uses hash
>> tables or sorted lists or whatever. I think the most important thing is
>> getting down the design of the _data structure_, so that we can have a
>> compatible implementation inside git itself.
>
> Well, I don't care about pyrite. As far as I am concerned, it might as
> well use an incompatible version. I really don't care.
Well I do care. It would not be a good thing for anyone to have 2 separate
systems for notes. Let us say that someone who you work with uses pyrite
and you don't. They will add notes which you can't see and vice versa.
Thanks,
Govind.
^ permalink raw reply
* Re: [PATCH] Make git revert warn the user when reverting a merge commit.
From: Alan @ 2008-12-19 18:07 UTC (permalink / raw)
To: Boyd Stephen Smith Jr.
Cc: git, Junio C Hamano, Johannes Schindelin, Linus Torvalds
In-Reply-To: <200812182129.01021.bss@iguanasuicide.net>
On Thu, 2008-12-18 at 21:29 -0600, Boyd Stephen Smith Jr. wrote:
> On Thursday 2008 December 18 21:03:46 Junio C Hamano wrote:
> > Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> > > warning("revert on a merge commit may not do what you "
> > > "expect.");
> >
> > [T]he new warning does
> > not give you enough clue where to go next, so this warning does not give
> > real value. It is pretty much meaningless noise to users.
>
> At least, it might make someone read the manpage again. Still, I'm unhappy
> with the message, but I didn't want to be too wordy. A URL or manpage
> reference would be nice, but I didn't know of a good guide that explained the
> dangers of reverting a merge commit as well as Linus's emails.
That would be OK if the man page actually explained how this is supposed
to work. it does not. (Especially where it concerns "parent number"
and reverts of merges, which has no real explanation.)
^ permalink raw reply
* [PATCH] Clarify git-format-patch --in-reply-to
From: jidanni @ 2008-12-19 19:12 UTC (permalink / raw)
To: gitster; +Cc: git
In-Reply-To: <7vzlitho1o.fsf@gitster.siamese.dyndns.org>
Signed-off-by: jidanni <jidanni@jidanni.org>
diff --git a/git-format-patch.txt b/git-format-patch.txt
index ee27eff..04958de 100644
--- a/git-format-patch.txt
+++ b/git-format-patch.txt
@@ -130 +130,2 @@ include::diff-options.txt[]
- provide a new patch series.
+ provide a new patch series. Generates coresponding References and
+ In-Reply-To headers. Angle brackets around <Message-Id> are optional.
--
1.5.6.5
^ permalink raw reply related
* How to extract files out of a "git bundle", no matter what?
From: jidanni @ 2008-12-19 19:29 UTC (permalink / raw)
To: mdl123; +Cc: git
Someone has handed you a "git bundle".
How do you get the files out of it?
If it were cpio, you would use -i, if it were tar, you would use -x...
You read the git-bundle man page.
You only get as far as
# git-bundle verify bundle.bdl
The bundle contains 1 ref
d01... /heads/master
The bundle requires these 0 ref
bundle.bdl is okay
The rest is mish-mosh. There should be an emergency example for non
git club members, even starting from apt-get install git-core, of the
all the real steps needed _to get the files out of the bundle_.
Assume the user _just wants to get the files out of the bundle_ and
not learn about or participate in some project.
^ permalink raw reply
* Re: How to extract files out of a "git bundle", no matter what?
From: Shawn O. Pearce @ 2008-12-19 19:32 UTC (permalink / raw)
To: jidanni; +Cc: mdl123, git
In-Reply-To: <87iqpgc6bn.fsf@jidanni.org>
jidanni@jidanni.org wrote:
> Someone has handed you a "git bundle".
> How do you get the files out of it?
> If it were cpio, you would use -i, if it were tar, you would use -x...
> You read the git-bundle man page.
> You only get as far as
> # git-bundle verify bundle.bdl
> The bundle contains 1 ref
> d01... /heads/master
> The bundle requires these 0 ref
> bundle.bdl is okay
>
> The rest is mish-mosh. There should be an emergency example for non
> git club members, even starting from apt-get install git-core, of the
> all the real steps needed _to get the files out of the bundle_.
>
> Assume the user _just wants to get the files out of the bundle_ and
> not learn about or participate in some project.
You can't just "get the files out". A bundle contains deltas,
where you need the base in order to recreate the file content.
It can't be unpacked in a vacuum.
To unpack a bundle you need to clone the project and then fetch
from it:
git clone src...
git pull bundle.bdl master
If the bundle requires 0 refs (like above) then you can init a
new repository and should be able to fetch from it:
git init
git pull bundle.bdl master
--
Shawn.
^ permalink raw reply
* Re: How to extract files out of a "git bundle", no matter what?
From: Mark Levedahl @ 2008-12-19 19:57 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: jidanni, git
In-Reply-To: <20081219193256.GU32487@spearce.org>
Shawn O. Pearce wrote:
>
> If the bundle requires 0 refs (like above) then you can init a
> new repository and should be able to fetch from it:
>
> git init
> git pull bundle.bdl master
>
>
With relatively recent git (not sure the version), you can just do
git clone bundle.bdl
Mark
^ permalink raw reply
* Re: How to extract files out of a "git bundle", no matter what?
From: Junio C Hamano @ 2008-12-19 20:07 UTC (permalink / raw)
To: jidanni; +Cc: mdl123, git
In-Reply-To: <87iqpgc6bn.fsf@jidanni.org>
jidanni@jidanni.org writes:
> Someone has handed you a "git bundle".
> How do you get the files out of it?
> If it were cpio, you would use -i, if it were tar, you would use -x...
> You read the git-bundle man page.
> You only get as far as
> # git-bundle verify bundle.bdl
> The bundle contains 1 ref
> d01... /heads/master
> The bundle requires these 0 ref
> bundle.bdl is okay
>
> The rest is mish-mosh.
The last example in the git-bundle man page might be a bit cryptic but
that is how bundles are expected to be used. To give people repository
access who do not have real network connection other than Sneakernet.
For one shot extraction, defining a remote in the config is overkill and
you could just say:
git ls-remote bundle.bdl
to see what branches it contains and if you are interested in its
master branch and want to merge it to your history, then
git pull bundle.bdl master
should do that.
^ permalink raw reply
* Re: How to extract files out of a "git bundle", no matter what?
From: jidanni @ 2008-12-19 20:13 UTC (permalink / raw)
To: mdl123; +Cc: spearce, git
In-Reply-To: <494BFCAF.9060703@verizon.net>
SOP> If the bundle requires 0 refs (like above) then you can init a
SOP> new repository and should be able to fetch from it:
SOP> git init
SOP> git pull bundle.bdl master
Phew, that worked. Thank you!
ML> With relatively recent git (not sure the version), you can just do
ML> git clone bundle.bdl
Not with git version 1.5.6.5, Debian sid.
Anyway, for man page completeness, I still see the day when:
SOP> You can't just "get the files out". A bundle contains deltas,
SOP> where you need the base in order to recreate the file content.
SOP> It can't be unpacked in a vacuum.
That is nice by we here at the forensics department of XYZ police
force just need to get the files out. We tried "PK UNZIP" but that
didn't extract them. We contacted the Computer Science Dept. but
that's who they're holding hostage.
SOP> To unpack a bundle you need to clone the project and then fetch
SOP> from it:
SOP> git clone src...
SOP> git pull bundle.bdl master
That is nice but the perpetrators have destroyed everything except for
that one bundle.bdl file, which contains the password to defuse the
time bomb.
There must be a way to make a "phony tree" or whatever to "attach to"
so extraction can proceed. Be sure to spell it all out on the
git-bundle man page as a reference in case some non-computer people
need to do aforementioned emergency extraction one day.
^ permalink raw reply
* Re: How to extract files out of a "git bundle", no matter what?
From: Jeff King @ 2008-12-19 20:21 UTC (permalink / raw)
To: jidanni; +Cc: mdl123, spearce, git
In-Reply-To: <87zlirc49l.fsf@jidanni.org>
On Sat, Dec 20, 2008 at 04:13:26AM +0800, jidanni@jidanni.org wrote:
> There must be a way to make a "phony tree" or whatever to "attach to"
> so extraction can proceed. Be sure to spell it all out on the
> git-bundle man page as a reference in case some non-computer people
> need to do aforementioned emergency extraction one day.
No, that information may not even be in the bundle at all (unless it is
a bundle that has a 0-ref basis). In particular, if a bundle contains
changes between some commit A and some commit B, then:
- files that were not changed between A and B will not be included at
all
- the object pack in the bundle is "thin", meaning it may contain
deltas against objects that are reachable from A, but not B. So even
_within_ a changed file, you may see only the changes from A to B.
If the bundle has a 0-ref basis, then you can clone straight from the
bundle, which must have everything.
-Peff
^ permalink raw reply
* Re: How to extract files out of a "git bundle", no matter what?
From: jidanni @ 2008-12-19 20:35 UTC (permalink / raw)
To: peff; +Cc: mdl123, spearce, git
In-Reply-To: <20081219202118.GA26513@coredump.intra.peff.net>
JK> In particular, if a bundle contains changes between some commit A
JK> and some commit B, then:
JK> - files that were not changed between A and B will not be included at
JK> all
JK> - the object pack in the bundle is "thin", meaning it may contain
JK> deltas against objects that are reachable from A, but not B. So even
JK> _within_ a changed file, you may see only the changes from A to B.
OK, we here at the police forensics department would be very happy if
we could at least get some ASCII out of that .BDL file, even if it is
just a diff shred,
- The password to the time bomb was BLORFZ
+ The password to the time bomb is NORFLZ
that would be fine. All we know is after the work PACK it is all
binary, and git-unpack-objects and git-unpack-file don't work on it.
^ permalink raw reply
* Re: jgit doesn't support "compare with" and "replace with"?
From: Robin Rosenberg @ 2008-12-19 20:39 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: Martin_S, git
In-Reply-To: <20081219152045.GR32487@spearce.org>
fredag 19 december 2008 16:20:45 skrev Shawn O. Pearce:
> Martin_S <iksdrijf@yahoo.com> wrote:
> >
> > Hi, I'm using eclipse 3.4 and jgit 0.4. The right click context menus don't
> > list "compare with" and "replace with". Am I doing something wrong?
>
> We haven't implemented them in EGit. So its not surprising that
> they aren't appearing.
Actually, we had it in v0.3 though it didn't always work. In particular it didn't work on
Windows...
The history rewrited killed it, but re-adding it would not be to hard, It's mostly about passing two explicit
versions to compare, which is already done in
The old version disappeared in 07f04ae5b1771069667028d225196daff29402a0, checkout out and rebuild
if you are really desperate. Reverting it is an option, but that is not trivial either so going forward and
reimplementing it (correctly this time) is a more appealing approach. Dependig on your needs, i.e. if
you only don't need clone/fetch/push you could go back to the commit mentioned above. The closest
tagged version is v0.3.1. As a bonus it draws the graph correctly, though it is not optimal.
-- robin
^ 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