* Re: [Git 1.7.6.557.gcee4] git stash
From: Hilco Wijbenga @ 2011-08-22 18:43 UTC (permalink / raw)
To: Brandon Casey; +Cc: David Caldwell, Git Users
In-Reply-To: <euT1_KmfLWaxwFqOd8u_Zv-flc6Wr9rvg1tf_39P-YMaH8T-tpKl94WG8yCIAmW0AMLjdqnjA3I2uGRQf9YpY513-Io-lue5aNPuVDv8Qp8@cipher.nrlssc.navy.mil>
On 22 August 2011 10:15, Brandon Casey
<brandon.casey.ctr@nrlssc.navy.mil> wrote:
> On 08/22/2011 01:01 AM, Hilco Wijbenga wrote:
>> Hi David,
>>
>> I noticed your very timely change to git stash in the current master
>> branch. I tried it but it doesn't behave as I was expecting/hoping.
>
> It looks like it is actually creating the stash correctly, but it's
> just not deleting the ignored directory.
>
> But, there is a small problem with your command sequence...
>
>> hilco@centaur ~/tmp/repo repo$ git --version
>> git version 1.7.6.557.gcee4
>> hilco@centaur ~/tmp/repo repo$ git init
>> Initialized empty Git repository in /home/hilco/tmp/repo/.git/
>> hilco@centaur ~/tmp/repo repo (master #)$ cat >>.gitignore <<- EOF
>>> *.ignore
>>> ignore-dir/
>>> EOF
>> hilco@centaur ~/tmp/repo repo (master #%)$ mkdir src
>> hilco@centaur ~/tmp/repo repo (master #%)$ touch file.txt src/code.txt
>> hilco@centaur ~/tmp/repo repo (master #%)$ git add -A .
>> hilco@centaur ~/tmp/repo repo (master #)$ git commit -m '1'
>> [master (root-commit) 0fb4106] 1
>> 1 files changed, 2 insertions(+), 0 deletions(-)
>> create mode 100644 .gitignore
>> create mode 100644 file.txt
>> create mode 100644 src/code.txt
>> hilco@centaur ~/tmp/repo repo (master)$ touch file-a.ignore src/file-b.ignore
>> hilco@centaur ~/tmp/repo repo (master %)$ echo "hello">src/code.txt
>> hilco@centaur ~/tmp/repo repo (master *%)$ mkdir ignore-dir
>> hilco@centaur ~/tmp/repo repo (master *%)$ touch
>> ignore-dir/{file.ignore,file.txt}
>> hilco@centaur ~/tmp/repo repo (master *%)$ git status
>> # On branch master
>> # Changes not staged for commit:
>> # (use "git add <file>..." to update what will be committed)
>> # (use "git checkout -- <file>..." to discard changes in working directory)
>> #
>> # modified: src/code.txt
>> #
>> # Untracked files:
>> # (use "git add <file>..." to include in what will be committed)
>> #
>> # file-a.ignore
>> # ignore-dir/
>> # src/file-b.ignore
> ^^^^^^^^^^^^^^^^^
> Why are these entries here?
My bad. I had a script that ran the commands but I decided to try run
them on the CL so I copy-pasted them. That changed the tabs to spaces
and ruined .gitignore.
>> no changes added to commit (use "git add" and/or "git commit -a")
>
> if your .gitignore file looks like this:
>
> $ cat .gitignore
> *.ignore
> ignore-dir/
>
> then why are those items showing up under "Untracked files:" in the call
> to git status above? /methinks something is wrong with your .gitignore
> file. It doesn't matter in this case, since --all will cause stash to
> stash the untracked files regardless of whether they are ignored.
>
>> hilco@centaur ~/tmp/repo repo (master *%)$ git stash --no-keep-index --all
>> Saved working directory and index state WIP on master: 0fb4106 1
>> HEAD is now at 0fb4106 1
>> Not removing ignore-dir/
>> hilco@centaur ~/tmp/repo repo (master $%)$ git status
>> # On branch master
>> # Untracked files:
>> # (use "git add <file>..." to include in what will be committed)
>> #
>> # ignore-dir/
>> nothing added to commit but untracked files present (use "git add" to track)
>
> Also, in the future it would be nicer if you provided your list of
> commands separately, at the beginning, linked together with &&.
> This makes it easier to copy/paste into my terminal, rather than
> having to extract the commands out from within the body.
> Like this (slightly simplified):
>
> git --version &&
> git init &&
> cat <<-\EOF >.gitignore &&
> *.ignore
> ignore-dir/
> EOF
> mkdir src &&
> touch file.txt src/code.txt &&
> git add . &&
> git commit -m 'initial commit' &&
> touch file-a.ignore src/file-b.ignore &&
> echo "hello" >src/code.txt &&
> mkdir ignore-dir &&
> touch ignore-dir/{file.ignore,file.txt} &&
> git status &&
> git stash --all &&
> git status || echo 'FAILURE'
Noted. Will do.
>> So it quite explicitly states "Not removing ignore-dir/".
>
> That message is from git-clean, and it is the real problem.
>
>> How do I
>> make sure it also stashes the ignore-dir directory?
>
> It actually did stash the ignore-dir, it just didn't remove it from
> the working directory at the end. Try deleting the ignore-dir by
> hand and then applying the stash, ignore-dir and its content should
> be recreated.
>
> Something like this is probably the appropriate fix:
>
> diff --git a/git-stash.sh b/git-stash.sh
> index f4e6f05..a2d4b4d 100755
> --- a/git-stash.sh
> +++ b/git-stash.sh
> @@ -240,7 +240,7 @@ save_stash () {
> test "$untracked" = "all" && CLEAN_X_OPTION=-x || CLEAN_X_OPTION
> if test -n "$untracked"
> then
> - git clean --force --quiet $CLEAN_X_OPTION
> + git clean --force --quiet -d $CLEAN_X_OPTION
> fi
>
> if test "$keep_index" = "t" && test -n $i_tree
>
> Needs tests.
I just tried it with the extra -d and it all seems to work
beautifully. Should your patch be sent anywhere?
^ permalink raw reply
* Re: Behaviour of git apply --directory
From: Junio C Hamano @ 2011-08-22 18:28 UTC (permalink / raw)
To: Andrew Berry; +Cc: git
In-Reply-To: <E21BC0F8-2DF0-44AB-B18A-013451CDB670@sentex.net>
Andrew Berry <andrewberry@sentex.net> writes:
> The behaviour of git apply --directory seems a little confusing. It
> looks to be dependent on the current directory, but I can't use relative
> paths to apply a patch in one directory to a sibling directory. Absolute
> paths don't work either. I'd expected the parameter to either be
> relative to the git repository root, or to expand relative directories.
I do not think that parameter does not have anything to do with your
cwd. As the documentation says:
--directory=<root>::
Prepend <root> to all filenames. If a "-p" argument was also passed,
it is applied before prepending the new root.
For example, a patch that talks about updating `a/git-gui.sh` to `b/git-gui.sh`
can be applied to the file in the working tree `modules/git-gui/git-gui.sh` by
running `git apply --directory=modules/git-gui`.
the parameter is just a fixed string that is used to modify the path that
appears in the patch before it gets applied, and has nothing to do with
your current (or previous for that matter) working directory.
Suppose you have a patch that tries to update "COPYING". Such a patch
generated by Git would look like this:
diff --git a/COPYING b/COPYING
index 536e555..ee559b1 100644
--- a/COPYING
+++ b/COPYING
@@ -1,3 +1,4 @@
+GPL GPL GPL
Note that the only valid version of the GPL as far as this project
is concerned is _this_ particular version of the license (ie v2, not
Further suppose that you have already rearranged your project so that that
file appears in licenses/gpl directory, and your $(cwd) is licenses/
subdirectory of your working tree.
You would give --directory=licenses/gpl/ without passing any custom -p
parameter. This internally turns the patch being applied into something
like:
diff --git a/licenses/gpl/COPYING b/licenses/gpl/COPYING
index 536e555..ee559b1 100644
--- a/licenses/gpl/COPYING
+++ b/licenses/gpl/COPYING
@@ -1,3 +1,4 @@
+GPL GPL GPL
Note that the only valid version of the GPL as far as this project
is concerned is _this_ particular version of the license (ie v2, not
Because the patch application in git is always relative to the top level
of your working tree no matter where you are, this applies to the path you
intended it to.
Here is a sample transcript to try it yourself.
$ (echo GPL GPL GPL; cat COPYING) >x && cat x >COPYING
$ git diff >P.diff
$ git checkout COPYING
$ mkdir -p licenses/gpl
$ git mv COPYING licenses/gpl
$ cd licenses
$ git apply -v --directory=licenses/gpl ../P.diff
Checking patch licenses/gpl/COPYING...
Applied patch licenses/gpl/COPYING cleanly.
$ git diff
diff --git a/licenses/gpl/COPYING b/licenses/gpl/COPYING
index 536e555..ee559b1 100644
--- a/licenses/gpl/COPYING
+++ b/licenses/gpl/COPYING
@@ -1,3 +1,4 @@
+GPL GPL GPL
Note that the only valid version of the GPL as far as this project
is concerned is _this_ particular version of the license (ie v2, not
^ permalink raw reply
* Re: [PATCH] Grammar and wording fixes in gitrepository-layout
From: Junio C Hamano @ 2011-08-22 18:09 UTC (permalink / raw)
To: git; +Cc: Ben Walton
In-Reply-To: <1313808187-1666-1-git-send-email-bwalton@artsci.utoronto.ca>
Ben Walton <bwalton@artsci.utoronto.ca> writes:
> This patch corrects a few grammar issues in gitrepository-layout.txt
> and also rewords a few sections for clarity.
Thanks, Ben.
I notice that there are issues, not introduced with your patch, that we
may want to address further, though.
> Signed-off-by: Ben Walton <bwalton@artsci.utoronto.ca>
> ---
> Documentation/gitrepository-layout.txt | 46 +++++++++++++++----------------
> 1 files changed, 22 insertions(+), 24 deletions(-)
>
> diff --git a/Documentation/gitrepository-layout.txt b/Documentation/gitrepository-layout.txt
> index eb3d040..02a6167 100644
> --- a/Documentation/gitrepository-layout.txt
> +++ b/Documentation/gitrepository-layout.txt
> @@ -23,32 +23,30 @@ objects::
> Object store associated with this repository. Usually
> an object store is self sufficient (i.e. all the objects
> that are referred to by an object found in it are also
> - found in it), but there are couple of ways to violate
> - it.
> + found in it), but there are a few ways to violate it.
> +
> . You could populate the repository by running a commit walker
> -without `-a` option. Depending on which options are given, you
> +without `-a` option. Depending on the options given, you
> could have only commit objects without associated blobs and
> trees this way, for example. A repository with this kind of
> incomplete object store is not suitable to be published to the
> -outside world but sometimes useful for private repository.
> +outside world but is sometimes useful in a private repository.
Here "a commit walker" refers to the "http-fetch" dumb http walker, which
was unclear and confusing even to me, but more importantly, I wonder if we
even want to condone the use of it to break the repository integrity in
such a way that other tools in git toolset do not even give support.
Other items in this list, namely shallow-clone and borrowing objects from
alternates, are supported configurations in which .git/objects do _not_
have all the objects, but "http-fetch without -a" that pulls in commits
without their associated trees and blobs do not even pass "fsck" and worse
yet cannot be "fixed" later by fetching missing objects on top, like
a shallow clone does by allowing deepening it later.
Perhaps we should deprecate http-fetch without -a and drop this item from
the list?
> +. You could be using the `objects/info/alternates` or
> +`$GIT_ALTERNATE_OBJECT_DIRECTORIES` mechanisms to 'borrow'
> objects from other object stores. A repository with this kind
> of incomplete object store is not suitable to be published for
> -use with dumb transports but otherwise is OK as long as
> -`objects/info/alternates` points at the right object stores
> -it borrows from.
> +use with dumb transports but is otherwise OK as long as
> +`objects/info/alternates` points at the right object stores.
The last three words in the original are meant to clarify and define what
"the right object stores" are. Was there a compelling reason to drop them?
> objects/[0-9a-f][0-9a-f]::
> Traditionally, each object is stored in its own file.
I would suggest further rewording this to something like:
A newly created object is stored in its own file.
> @@ -120,15 +118,15 @@ HEAD::
> HEAD can also record a specific commit directly, instead of
> being a symref to point at the current branch. Such a state
> is often called 'detached HEAD', and almost all commands work
> -identically as normal. See linkgit:git-checkout[1] for
> +as they normally would. See linkgit:git-checkout[1] for
> details.
We may want to reword the sentence that begins with "almost all commands"
further. In the early days after detached HEAD support was introduced, we
may have left cases where the result was _undefined_ for commands that
would not make sense unless you are on a branch, but by now what we have
should behave sensibly by either erroring out when the operation does not
make sense unless you are on a real branch, or doing something useful.
> branches::
> A slightly deprecated way to store shorthands to be used
> - to specify URL to 'git fetch', 'git pull' and 'git push'
> - commands is to store a file in `branches/<name>` and
> - give 'name' to these commands in place of 'repository'
> - argument.
> + to specify a URL to 'git fetch', 'git pull' and 'git push'.
> + A file can be stored as `branches/<name>` and then
> + 'name' can be givent to these commands in place of
s/givent to/given to/
> + 'repository' argument.
We would at least need "See linkgit:..." to say what is expected in this
file and how it is used (the information is in urls-remotes.txt but that
is not a top-level file, so it needs to refer to git-fetch and git-push
instead).
> @@ -173,9 +171,9 @@ info/exclude::
> at it. See also: linkgit:gitignore[5].
>
> remotes::
> - Stores shorthands to be used to give URL and default
> - refnames to interact with remote repository to
> - 'git fetch', 'git pull' and 'git push' commands.
> + Stores shorthands for URL and default refnames for use
> + when interacting with remote repositories via 'git fetch',
> + 'git pull' and 'git push' commands.
Likewise.
Also I would personally consider "branches" and "remotes" both "slightly
deprecated". "git init", "git clone", and "git remote" stopped populating
these long time ago.
^ permalink raw reply
* Re: Malformed branch name in fast-export when specifying non-HEAD/branch revision
From: Sverre Rabbelier @ 2011-08-22 18:05 UTC (permalink / raw)
To: Jeff King; +Cc: Junio C Hamano, Elijah Newren, Owen Stephens, git
In-Reply-To: <20110822175705.GB1945@sigill.intra.peff.net>
Heya,
On Mon, Aug 22, 2011 at 10:57, Jeff King <peff@peff.net> wrote:
> I just read through the remote-helper threads from early June, and the
> only mention of triggering that is when you actually have a rename
> (i.e., your "refs/heads/foo" becomes remote's "refs/heads/bar", but we
> mention "refs/heads/foo" in the export stream). I was thinking there was
> another case, but I couldn't find mention of it.
The patches Dscho and I sent are in response to the RFC patches (that
are currently "stalled" in whats-cooking) I added on top of the series
that rerolled yours.
> Yeah, the behavior of your patch looks fine to me. I thought the point
> in contention was that having export understand refspecs would fix a lot
> of _other_ cases, too.
Right. Sadly it doesn't look like I'll have time to try and fix 'git
bundle' anytime soon, so this'll remain broken.
--
Cheers,
Sverre Rabbelier
^ permalink raw reply
* Re: Malformed branch name in fast-export when specifying non-HEAD/branch revision
From: Jeff King @ 2011-08-22 17:57 UTC (permalink / raw)
To: Sverre Rabbelier; +Cc: Junio C Hamano, Elijah Newren, Owen Stephens, git
In-Reply-To: <CAGdFq_gx+NutDCU7egr_fYUvVG=g1t76LiV1SV-W=0KWBTjHyQ@mail.gmail.com>
On Mon, Aug 22, 2011 at 09:54:47AM -0700, Sverre Rabbelier wrote:
> Do you agree that this is expected behavior?
>
> $ git init test
> Initialized empty Git repository in /home/sverre/code/test/.git/
> $ cd test/
> $ echo content >> foo
> sverre@laptop-sverre:~/code/test
> $ git add foo
> $ git commit -m first
> [master (root-commit) 821176f] first
> 1 files changed, 1 insertions(+), 0 deletions(-)
> create mode 100644 foo
> $ echo content >> foo
> $ git commit -am second
> [master 1934282] second
> 1 files changed, 1 insertions(+), 0 deletions(-)
> $ git branch other
> $ git fast-export ^master other
> reset refs/heads/other
> from 1934282469e3a83a5ef827fd31e074cfb4f3eadf
Yeah, that seems reasonable to me.
> Because in current git.git, this doesn't work (the above is generated
> using a git that has the patch series Dscho and I sent out). Current
> git will instead do the following:
>
> $ git fast-export ^master other
> reset refs/heads/other
> from :0
>
> The 'from :0' here is obviously a bug (which is fixed by our patch series).
Yep, the current behavior is definitely wrong. But I thought your
question was about accidentally mentioning refs/heads/master, which this
doesn't do (nor should it).
I just read through the remote-helper threads from early June, and the
only mention of triggering that is when you actually have a rename
(i.e., your "refs/heads/foo" becomes remote's "refs/heads/bar", but we
mention "refs/heads/foo" in the export stream). I was thinking there was
another case, but I couldn't find mention of it.
> You might wonder, 'why would anyone do that', well, for example, they
> might be using marks:
>
> $ git fast-export --export-marks=marksfile master > /dev/null
> $ git fast-export --import-marks=marksfile other
> reset refs/heads/other
> from :4
>
> Again, the above is generated with my patched git, current git.git
> simply outputs nothing.
>
> $ git fast-export --import-marks=marksfile other
Yeah, the behavior of your patch looks fine to me. I thought the point
in contention was that having export understand refspecs would fix a lot
of _other_ cases, too.
-Peff
^ permalink raw reply
* Re: [Git 1.7.6.557.gcee4] git stash
From: Brandon Casey @ 2011-08-22 17:15 UTC (permalink / raw)
To: Hilco Wijbenga; +Cc: David Caldwell, Git Users
In-Reply-To: <CAE1pOi1D+J5_fmsdhho1FRAipyO3Ri7GS_wy4fTNtCGbatDaDg@mail.gmail.com>
On 08/22/2011 01:01 AM, Hilco Wijbenga wrote:
> Hi David,
>
> I noticed your very timely change to git stash in the current master
> branch. I tried it but it doesn't behave as I was expecting/hoping.
It looks like it is actually creating the stash correctly, but it's
just not deleting the ignored directory.
But, there is a small problem with your command sequence...
> hilco@centaur ~/tmp/repo repo$ git --version
> git version 1.7.6.557.gcee4
> hilco@centaur ~/tmp/repo repo$ git init
> Initialized empty Git repository in /home/hilco/tmp/repo/.git/
> hilco@centaur ~/tmp/repo repo (master #)$ cat >>.gitignore <<- EOF
>> *.ignore
>> ignore-dir/
>> EOF
> hilco@centaur ~/tmp/repo repo (master #%)$ mkdir src
> hilco@centaur ~/tmp/repo repo (master #%)$ touch file.txt src/code.txt
> hilco@centaur ~/tmp/repo repo (master #%)$ git add -A .
> hilco@centaur ~/tmp/repo repo (master #)$ git commit -m '1'
> [master (root-commit) 0fb4106] 1
> 1 files changed, 2 insertions(+), 0 deletions(-)
> create mode 100644 .gitignore
> create mode 100644 file.txt
> create mode 100644 src/code.txt
> hilco@centaur ~/tmp/repo repo (master)$ touch file-a.ignore src/file-b.ignore
> hilco@centaur ~/tmp/repo repo (master %)$ echo "hello">src/code.txt
> hilco@centaur ~/tmp/repo repo (master *%)$ mkdir ignore-dir
> hilco@centaur ~/tmp/repo repo (master *%)$ touch
> ignore-dir/{file.ignore,file.txt}
> hilco@centaur ~/tmp/repo repo (master *%)$ git status
> # On branch master
> # Changes not staged for commit:
> # (use "git add <file>..." to update what will be committed)
> # (use "git checkout -- <file>..." to discard changes in working directory)
> #
> # modified: src/code.txt
> #
> # Untracked files:
> # (use "git add <file>..." to include in what will be committed)
> #
> # file-a.ignore
> # ignore-dir/
> # src/file-b.ignore
^^^^^^^^^^^^^^^^^
Why are these entries here?
> no changes added to commit (use "git add" and/or "git commit -a")
if your .gitignore file looks like this:
$ cat .gitignore
*.ignore
ignore-dir/
then why are those items showing up under "Untracked files:" in the call
to git status above? /methinks something is wrong with your .gitignore
file. It doesn't matter in this case, since --all will cause stash to
stash the untracked files regardless of whether they are ignored.
> hilco@centaur ~/tmp/repo repo (master *%)$ git stash --no-keep-index --all
> Saved working directory and index state WIP on master: 0fb4106 1
> HEAD is now at 0fb4106 1
> Not removing ignore-dir/
> hilco@centaur ~/tmp/repo repo (master $%)$ git status
> # On branch master
> # Untracked files:
> # (use "git add <file>..." to include in what will be committed)
> #
> # ignore-dir/
> nothing added to commit but untracked files present (use "git add" to track)
Also, in the future it would be nicer if you provided your list of
commands separately, at the beginning, linked together with &&.
This makes it easier to copy/paste into my terminal, rather than
having to extract the commands out from within the body.
Like this (slightly simplified):
git --version &&
git init &&
cat <<-\EOF >.gitignore &&
*.ignore
ignore-dir/
EOF
mkdir src &&
touch file.txt src/code.txt &&
git add . &&
git commit -m 'initial commit' &&
touch file-a.ignore src/file-b.ignore &&
echo "hello" >src/code.txt &&
mkdir ignore-dir &&
touch ignore-dir/{file.ignore,file.txt} &&
git status &&
git stash --all &&
git status || echo 'FAILURE'
> So it quite explicitly states "Not removing ignore-dir/".
That message is from git-clean, and it is the real problem.
> How do I
> make sure it also stashes the ignore-dir directory?
It actually did stash the ignore-dir, it just didn't remove it from
the working directory at the end. Try deleting the ignore-dir by
hand and then applying the stash, ignore-dir and its content should
be recreated.
Something like this is probably the appropriate fix:
diff --git a/git-stash.sh b/git-stash.sh
index f4e6f05..a2d4b4d 100755
--- a/git-stash.sh
+++ b/git-stash.sh
@@ -240,7 +240,7 @@ save_stash () {
test "$untracked" = "all" && CLEAN_X_OPTION=-x || CLEAN_X_OPTION
if test -n "$untracked"
then
- git clean --force --quiet $CLEAN_X_OPTION
+ git clean --force --quiet -d $CLEAN_X_OPTION
fi
if test "$keep_index" = "t" && test -n $i_tree
Needs tests.
-Brandon
^ permalink raw reply related
* Re: How to check out the repository at a particular point in time
From: Jens Lehmann @ 2011-08-22 16:56 UTC (permalink / raw)
To: rdiezmail-temp2; +Cc: Thomas Rast, git, in-git-vger
In-Reply-To: <1314026326.37332.YahooMailClassic@web25408.mail.ukl.yahoo.com>
Am 22.08.2011 17:18, schrieb R. Diez:
> But that problem the daily build is trying to solve is precisely that it's
> too hard to keep track of all component versions in all repositories. Things
> just move too fast, and as far as I understand it, git submodules require
> manual intervention. If I ever tag anything manually, it must have already
> passed the daily build!
Submodules can easily be scripted too. Why don't you let your buildsystem
automatically create a commit with the current HEADs in the superproject
when building and testing all repositories was successful? Then each
developer can use one of those superproject commits as starting point and
happily hack away on a repository. And as a bonus he can see in the
superproject how many changes he did from the nightly build he started
with. And if he doesn't care, he can forget about the superproject until
he needs to sync again.
> The development model looks like this: the latest HEAD versions of all
> components should always work well with each other. If something breaks,
> the daily build will let the developer know by the next day. If two
> developers make incompatible changes, they'll speak to each other and
> commit their changes within a few hours. During that time, they will be
> trouble, but that's quite alright (at least for the moment).
You can decide later if you want to use the superproject to coordinate
such possibly conflicting changes, but that would mean your developers
would have to commit their changes in the superproject too.
^ permalink raw reply
* Re: Malformed branch name in fast-export when specifying non-HEAD/branch revision
From: Sverre Rabbelier @ 2011-08-22 16:54 UTC (permalink / raw)
To: Jeff King; +Cc: Junio C Hamano, Elijah Newren, Owen Stephens, git
In-Reply-To: <20110822161932.GA1945@sigill.intra.peff.net>
Heya,
On Mon, Aug 22, 2011 at 09:19, Jeff King <peff@peff.net> wrote:
> Hmm. Maybe I am misremembering the problem, but I thought that worked
> already. If you say:
>
> git fast-export refs/heads/foo
>
> you should get only reset/commit lines in the output for refs/heads/foo,
> no?
>
> Now I can't seem to replicate the case where refs/heads/master is
> mentioned, but you didn't want it to be. I may have to go back and
> re-read the thread from a month or two ago when we discussed these
> issues.
Do you agree that this is expected behavior?
$ git init test
Initialized empty Git repository in /home/sverre/code/test/.git/
$ cd test/
$ echo content >> foo
sverre@laptop-sverre:~/code/test
$ git add foo
$ git commit -m first
[master (root-commit) 821176f] first
1 files changed, 1 insertions(+), 0 deletions(-)
create mode 100644 foo
$ echo content >> foo
$ git commit -am second
[master 1934282] second
1 files changed, 1 insertions(+), 0 deletions(-)
$ git branch other
$ git fast-export ^master other
reset refs/heads/other
from 1934282469e3a83a5ef827fd31e074cfb4f3eadf
Because in current git.git, this doesn't work (the above is generated
using a git that has the patch series Dscho and I sent out). Current
git will instead do the following:
$ git fast-export ^master other
reset refs/heads/other
from :0
The 'from :0' here is obviously a bug (which is fixed by our patch series).
You might wonder, 'why would anyone do that', well, for example, they
might be using marks:
$ git fast-export --export-marks=marksfile master > /dev/null
$ git fast-export --import-marks=marksfile other
reset refs/heads/other
from :4
Again, the above is generated with my patched git, current git.git
simply outputs nothing.
$ git fast-export --import-marks=marksfile other
--
Cheers,
Sverre Rabbelier
^ permalink raw reply
* Re: Malformed branch name in fast-export when specifying non-HEAD/branch revision
From: Jeff King @ 2011-08-22 16:19 UTC (permalink / raw)
To: Sverre Rabbelier; +Cc: Junio C Hamano, Elijah Newren, Owen Stephens, git
In-Reply-To: <CAGdFq_iiTt8F+kPXwZZT3fAKwZLCpPr7BOYtistxvv6s52Q5nQ@mail.gmail.com>
On Sun, Aug 21, 2011 at 03:29:38PM -0700, Sverre Rabbelier wrote:
> > Yes, this was the conclusion I came to when I looked at this a month or
> > so ago. You really need to give fast-export a mapping of objects to
> > refnames, and it should output ref names _only_ for the mapping. That
> > would handle this "not a ref" case, but would also let you push
> > "refs/heads/foo" when it is equivalent to "refs/heads/master", without
> > fast-export mentioning "refs/heads/master" at all.
>
> Does this bring any new insights into how the problem I was pointing
> out (trying to push next if master points at the same commit does
> nothing) could/should be solved?
Hmm. Maybe I am misremembering the problem, but I thought that worked
already. If you say:
git fast-export refs/heads/foo
you should get only reset/commit lines in the output for refs/heads/foo,
no?
Now I can't seem to replicate the case where refs/heads/master is
mentioned, but you didn't want it to be. I may have to go back and
re-read the thread from a month or two ago when we discussed these
issues.
-Peff
^ permalink raw reply
* Re: git svn --stdlayout 's little quirk.
From: Hin-Tak Leung @ 2011-08-22 15:57 UTC (permalink / raw)
To: Michael J Gruber; +Cc: Eric Wong, madduck, git
In-Reply-To: <4E52759E.3020005@drmicha.warpmail.net>
--- On Mon, 22/8/11, Michael J Gruber <git@drmicha.warpmail.net> wrote:
> >> It is not trying to do that at all. git-svn is
> trying to
> >> figure out what
> >> the "base path" is in an svn repo which possibly
> hosts
> >> multiple repos,
> >> and that is what the message reports.
> >
> > Okay... thanks for clarifying that. Maybe it could try
> to be clever? Afterall, --stdlayout isn't compatible with a
> URL ending in "trunk" (or having 'trunk' as part of the
> URL). Just a suggestion.
>
> You *could* have this layout:
>
> foo/trunk/trunk
> foo/trunk/tags/v1
> foo/trunk/tags/v2
>
> That's a perfectly valid layout. The fact that it is
> stupidly named
> should not activate git-svn magic.
Fair enough. Perhaps --stdlayout in combination with URL having "trunk" in the name can emit a warning? e.g. "are you sure? That looks a bit stupidly named". I wrote because I think git-svn could either try a bit harder at guessing, or be a bit clearer about the repository not conforming to a standard layout (if the URL is wrong).
Hin-Tak
^ permalink raw reply
* Behaviour of git apply --directory
From: Andrew Berry @ 2011-08-22 15:21 UTC (permalink / raw)
To: git
[-- Attachment #1: Type: text/plain, Size: 386 bytes --]
Hi,
The behaviour of git apply --directory seems a little confusing. It looks to be dependent on the current directory, but I can't use relative paths to apply a patch in one directory to a sibling directory. Absolute paths don't work either. I'd expected the parameter to either be relative to the git repository root, or to expand relative directories.
Any thoughts?
--Andrew
[-- Attachment #2: smime.p7s --]
[-- Type: application/pkcs7-signature, Size: 2488 bytes --]
^ permalink raw reply
* Re: git svn --stdlayout 's little quirk.
From: Michael J Gruber @ 2011-08-22 15:28 UTC (permalink / raw)
To: htl10; +Cc: Eric Wong, madduck, git
In-Reply-To: <1314025898.45043.YahooMailClassic@web29503.mail.ird.yahoo.com>
Hin-Tak Leung venit, vidit, dixit 22.08.2011 17:11:
> --- On Mon, 22/8/11, Michael J Gruber <git@drmicha.warpmail.net> wrote:
>
>> Hin-Tak Leung venit, vidit, dixit
>> 21.08.2011 11:38:
>>> --- On Sat, 20/8/11, Eric Wong <normalperson@yhbt.net>
>> wrote:
>>>
>>>>> I think I found a small bug in git 1.7.6.
>> Having
>>>> "trunk" at the end of
>>>>> the url in combination of --stdlayout is
>> wrong, but it
>>>> looks like that
>>>>> git-svn tries to cope, but doesn't go try far
>> enough:
>>>>>
>>>>> Doing this:
>>>>> ----------------
>>>>> git svn clone --stdlayout http://quick-settings.googlecode.com/svn/trunk/
>>>> android-quick-settings
>>>>
>>>> --stdlayout expects the "root" path of the code
>> you're
>>>> interested
>>>> in (not necessarily the SVN repository root, but
>> in this
>>>> case they
>>>> could be the same).
>>>>
>>>> Try the following instead:
>>>>
>>>> git svn clone --stdlayout \
>>>> http://quick-settings.googlecode.com/svn
>>>> android-quick-settings
>>>
>>> I know this is the correct way - what I meant was
>> that, having "trunk" at the end is wrong but git-svn appears
>> to try to correct it automatically, but haven't quite
>> succceeded.
>>
>> It is not trying to do that at all. git-svn is trying to
>> figure out what
>> the "base path" is in an svn repo which possibly hosts
>> multiple repos,
>> and that is what the message reports.
>
> Okay... thanks for clarifying that. Maybe it could try to be clever? Afterall, --stdlayout isn't compatible with a URL ending in "trunk" (or having 'trunk' as part of the URL). Just a suggestion.
You *could* have this layout:
foo/trunk/trunk
foo/trunk/tags/v1
foo/trunk/tags/v2
That's a perfectly valid layout. The fact that it is stupidly named
should not activate git-svn magic.
Michael
^ permalink raw reply
* Re: How to check out the repository at a particular point in time
From: R. Diez @ 2011-08-22 15:18 UTC (permalink / raw)
To: Thomas Rast; +Cc: git, in-git-vger
In-Reply-To: <201108221525.32982.trast@student.ethz.ch>
Hallo Thomas Rast:
Thanks for your quick answer. Please see mine below.
> The @{date} and @{n} syntax refers to the reflog, which as
> the name
> tries to imply, is a log of where *your local ref* was at
> that
> time/step. Since the HEAD ref is by definition what
> you have checked
> out at the moment, HEAD@{1 hour ago} indeed refers to last
> year's version.
OK, thanks. That kind of example would be nice to have in the "git checkout" documentation page. In the meantime, I've seen on the Internet that other people also got caught by this... let's say... 'unintuitive' behaviour or documentation. 8-)
> It is a git-log option (or more precisely, revision walker
> option).
In the meantime, I've seen this done with "git rev-list" instead, like this:
git rev-list -n 1 --before="2010-11-01 11:45:16 +0000" master
Is that the same as with git-log ?
> The main problem is that your request is not very
> well-defined: in
> nonlinear history there will in general be more than one
> commit at the
> time requested.
>
> ---a----b----c----M---- (M is a merge)
> \ /
> d-----e----f
>
> ^----
> April 1st
>
> Suppose you ask git for "the newest commit as of April 1st"
> in this history. Is it supposed to give you b or d?
I still don't quite understand how git works, but let me risk a naive statement here. If "a-b-c-M" were 'master', and "d-e-f" were 'new-feature', then on April 1st the current version on 'master' is 'b', because I merged the 'new-feature' branch at a later point in time. Does that make sense?
> Step back and consider the real problem here. In the
You're right in saying there is a race condition here between developers, and the right solution would be of course to tag which versions work well with each other.
But that problem the daily build is trying to solve is precisely that it's too hard to keep track of all component versions in all repositories. Things just move too fast, and as far as I understand it, git submodules require manual intervention. If I ever tag anything manually, it must have already passed the daily build!
The development model looks like this: the latest HEAD versions of all components should always work well with each other. If something breaks, the daily build will let the developer know by the next day. If two developers make incompatible changes, they'll speak to each other and commit their changes within a few hours. During that time, they will be trouble, but that's quite alright (at least for the moment).
I just didn't want the daily build to add to the uncertainty of what went wrong by introducing a few hours' worth of random time skew to the mix.
The daily build server needs to check out from git the head status at say 02:00 am on all repositories, as if the server had so many CPUs that it had ran a "git pull" for all of them simultaneously. That's close enough for my purposes. Like stated above, if someone merges some old branch at 02:01 am, a user that did a "git pull" on master at 02:00 am would not have seen that merge, that's the effect I would like to achieve.
In the future there will probably be a stable HEAD branch and a development branch with the same name across all git repositories, and the daily build can do both every day. Or maybe the stable versions will not come from git any more, but from .tar.gz files. Another solution to automate releases without so much human intervention would be as follows: if the automated build and automated testing succeeded 3 hours ago, then that timestamp can be entered in the database of "pretty sure it works" versions. The timestamp becomes effectively the version number. Manually coordinating all participants is hard if you don't have so many human resources.
Thanks again,
R. Diez
^ permalink raw reply
* Re: git svn --stdlayout 's little quirk.
From: Hin-Tak Leung @ 2011-08-22 15:11 UTC (permalink / raw)
To: Michael J Gruber; +Cc: Eric Wong, madduck, git
In-Reply-To: <4E521AD3.4040204@drmicha.warpmail.net>
--- On Mon, 22/8/11, Michael J Gruber <git@drmicha.warpmail.net> wrote:
> Hin-Tak Leung venit, vidit, dixit
> 21.08.2011 11:38:
> > --- On Sat, 20/8/11, Eric Wong <normalperson@yhbt.net>
> wrote:
> >
> >>> I think I found a small bug in git 1.7.6.
> Having
> >> "trunk" at the end of
> >>> the url in combination of --stdlayout is
> wrong, but it
> >> looks like that
> >>> git-svn tries to cope, but doesn't go try far
> enough:
> >>>
> >>> Doing this:
> >>> ----------------
> >>> git svn clone --stdlayout http://quick-settings.googlecode.com/svn/trunk/
> >> android-quick-settings
> >>
> >> --stdlayout expects the "root" path of the code
> you're
> >> interested
> >> in (not necessarily the SVN repository root, but
> in this
> >> case they
> >> could be the same).
> >>
> >> Try the following instead:
> >>
> >> git svn clone --stdlayout \
> >> http://quick-settings.googlecode.com/svn
> >> android-quick-settings
> >
> > I know this is the correct way - what I meant was
> that, having "trunk" at the end is wrong but git-svn appears
> to try to correct it automatically, but haven't quite
> succceeded.
>
> It is not trying to do that at all. git-svn is trying to
> figure out what
> the "base path" is in an svn repo which possibly hosts
> multiple repos,
> and that is what the message reports.
Okay... thanks for clarifying that. Maybe it could try to be clever? Afterall, --stdlayout isn't compatible with a URL ending in "trunk" (or having 'trunk' as part of the URL). Just a suggestion.
Hin-Tak
^ permalink raw reply
* Missing blobs after pruning dangling commits
From: Marcin Wiśnicki @ 2011-08-22 14:29 UTC (permalink / raw)
To: git
Hello,
recently I had git-fsck report some dangling references:
$ git fsck
dangling commit 9275ee571ead7a75ba57e16ba23155a178459918
dangling commit 047bd63ae82b7540098515467f50562e374edada
dangling commit 839cee3c8e16231e6523ecf8b855ef0863787990
dangling commit f7cb119ea71cb3cc739331f2e26bf3e9fdbba24a
dangling commit 68d41b28f320aff303c5a89b25e2243ad2e526f2
dangling commit effcf50a636d2f08e21706f41eb8ae3c4c577166
This is completely local (isolated) repository.
Based on related FAQ entry ("remove old objects after filter-branch"),
I did this:
$ git reflog expire --expire=0 --all
$ git repack -ad
$ git prune
Unfortunately, now fsck complains:
$ git fsck
missing blob 6d2ddd86d4594f8c756cc31b72d61653255a3161
missing blob 6c537408f0b2226c0b6dae9b0ef0f92710fb25ed
missing blob 2db55c1e39fd80e39eccefc617b852d3ac93abe9
$ git --version
git version 1.7.6.msysgit.0
Is this a bug ?
Also, how can I find where this blob came from. I've tried grepping
all commits in original repo (from backup):
$ gitwhich() {
git log --all --pretty=format:'%T %H' | while read tree commit; do
git ls-tree -r $tree | grep -q $1 && echo $commit;
done
}
$ gitwhich 2db55c1e39fd80e39eccefc617b852d3ac93abe9
but nothing was found.
^ permalink raw reply
* Re: How to check out the repository at a particular point in time
From: Thomas Rast @ 2011-08-22 13:25 UTC (permalink / raw)
To: rdiezmail-temp2; +Cc: git
In-Reply-To: <1314015902.48377.YahooMailClassic@web25403.mail.ukl.yahoo.com>
I'll basically reply from bottom up so you can see the motivation and
then my suggestions for the solution.
R. Diez wrote:
>
> Note that this looks up the state of your local ref at
> a given time; e.g., what was in your local master branch last week.
> If you want to look at commits made during certain times,
> see --since and --until.
[...]
> Say, for example, an hour ago I had temporarily checked out last
> year's versions, but half an hour ago I went back to this year's
> versions. If I check out at HEAD@{1 hour ago}, will I get then last
> year's version, or this year's?
The @{date} and @{n} syntax refers to the reflog, which as the name
tries to imply, is a log of where *your local ref* was at that
time/step. Since the HEAD ref is by definition what you have checked
out at the moment, HEAD@{1 hour ago} indeed refers to last year's
version.
> Anyway, my real problem is with the mentioned --until option. "git
> checkout" does not understand that option, so I guess I need to feed
> the date to some other git command in order to get the commit ID for
> "git checkout", right? Can someone help me here?
It is a git-log option (or more precisely, revision walker option).
The main problem is that your request is not very well-defined: in
nonlinear history there will in general be more than one commit at the
time requested.
---a----b----c----M---- (M is a merge)
\ /
d-----e----f
^---- April 1st
Suppose you ask git for "the newest commit as of April 1st" in this
history. Is it supposed to give you b or d? [If you think nonlinear
history is easy, try to figure out a good rule in the presence of time
skew, where misconfigured clocks/timezones resulted in parents being
younger than children.]
Hence:
> For extra karma points, git checkout could understand the --until option itself.
It probably never will, because that is an ill-defined request.
You can indeed say
git log -1 --until="april 1"
to get *one* commit that happened before April 1st, but which one is
up to the order internally used by git. You can also say
git log -1 --first-parent --until="april 1"
to get the first such commit along the first-parent ancestry, which
might suit the ticket.
But there is a more fundamental issue. Let me explain.
> I'm writing a daily build script for all the OpenRISC components, so
> every day I need to check out several git repositories with the
> source code of many tools that depend on each other.
>
> The hole process takes hours. In order to minimize the risk of
> repository skew
Step back and consider the real problem here. In the simplest case
you are getting two components A and B which depend on each other,
e.g., A depends on B. But there is a race condition in the case where
a user updates an API between them in a backward-incompatible way: she
has to update both A and B, and an unfortunate coworker/buildbot may
pull old-A and new-B (or vice versa) and get a broken build.
[Incidentally this seems to be a frequent problem with SVN externals.]
You might say: if only we had a way to record the fact that the
"blessed" version of B to go with old-A is old-B, and for new-A it's
new-B.
And indeed we do. Submodules were invented to allow B to be "linked"
into A's repository, such that a checkout of any commit of A "knows"
the correct corresponding version of B. A user who updates the API
can record the update to B inside the API-changing commit in A.
So while you can kludge your way around the problem with clever use of
'git log --until', submodules would be the "correct" solution.
--
Thomas Rast
trast@{inf,student}.ethz.ch
^ permalink raw reply
* Re: Branches & directories
From: Kyle Moffett @ 2011-08-22 12:46 UTC (permalink / raw)
To: Hilco Wijbenga
Cc: Michael Witten, Junio C Hamano, Evan Shelhamer, Git Mailing List
In-Reply-To: <CAE1pOi1J5DKtnyUQzu1K7G1+HLsWWCN7thCf6W8MwSzt4_vtOw@mail.gmail.com>
On Mon, Aug 22, 2011 at 01:36, Hilco Wijbenga <hilco.wijbenga@gmail.com> wrote:
> On 21 August 2011 20:01, Kyle Moffett <kyle@moffetthome.net> wrote:
>> On Sun, Aug 21, 2011 at 22:13, Hilco Wijbenga <hilco.wijbenga@gmail.com> wrote:
>>> Thanks for sticking it out. :-) That all makes sense. I think it's all
>>> pretty clear now.
>>
>> It's worth mentioning that in most cases you DON'T want to delete untracked and
>> ignored files when switching branches.
>
> For the record, I don't want them deleted but replaced with the
> artifacts in the other branch. A bit wasteful but it saves a lot of
> build time.
>
>> For example, when I'm doing kernel development, I will frequently do this:
>>
>> $ git checkout -b my-new-feature origin/master
>> [...hack hack hack...]
>> $ make -j16 && make install && reboot
>> [...find unrelated bug...]
>> $ git checkout -b my-new-bugfix origin/master
>> [...fix the bug...]
>> $ make -j16 && make install && reboot
>> $ git commit -m 'I fixed this bug'
>> $ git checkout my-new-feature
>> $ git rebase my-new-bugfix
>> $ make -j16 && make install && reboot
>>
>> To avoid wasting time I don't want to completely rebuild the kernel each
>> and every time I switch branches, I just want to rebuild the files that
>> changed when I switched. The way GIT works lets me do that quite
>> easily, and the kernel Makefiles detect the changed files and rebuild
>> the minimum amount necessary.
>>
>> GIT's behavior when you switch between branches is effectively the
>> same as applying a patch generated by diffing between the two
>> branches. Any files which would not be changed are left alone, their
>> timestamps completely unchanged.
>
> For small changes that makes perfect sense. I'm at a stage where APIs
> are still evolving and changing an API means rebuilding lots of code.
> I'd like to avoid that.
>
>> It sounds like Eclipse is simply not detecting changes to your working
>> tree by outside programs, and as a result it's not rebuilding files and
>> indexes the way that it should.
>
> While Eclipse isn't great at detecting such changes, this isn't really
> an Eclipse problem. It's just that lots of things are still changing
> and that leads to lots of building.
>
>> Obviously the easiest way to work around that issue is "git clean",
>> which has options to select all untracked files or just ignored ones.
>
> As I mentioned above, I don't want to *delete* untracked/ignored
> files, I just want them to stick to the branch I was working on. So if
> I change to a different branch I get the appropriate build artifacts.
>
> Something like: git stash --everything "All artifacts for
> this-branch." && git checkout other-branch && git stash apply
> stash-for-other-branch.
When I am in those sorts of situations I generally just use separate
working directories or separate checkouts entirely; if you really prefer
to have everything in one directory you would be better served by
integrating "ccache" into your workflow.
In particular, even "git stash" intentionally does not preserve file times,
so you would end up rebuilding everything anyways because all of your
source files would be as new as your object files.
If you use "ccache" then it does not matter what branches you are
on; identical source files and compiler options will be looked up in the
cache and the result (if found) copied to the output file.
Cheers,
Kyle Moffett
^ permalink raw reply
* Re: [PATCH v3 1/5] git-p4: Allow setting rename/copy detection threshold
From: Vitor Antunes @ 2011-08-22 12:44 UTC (permalink / raw)
To: Pete Wyckoff; +Cc: git, Tor Arvid Lund
In-Reply-To: <20110822121837.GA3761@arf.padd.com>
On Mon, Aug 22, 2011 at 1:18 PM, Pete Wyckoff <pw@padd.com> wrote:
> This series looks great. Thanks for fixing the --bool issue and
> the tests.
Thank *you* for the help and suggestions.
--
Vitor Antunes
^ permalink raw reply
* How to check out the repository at a particular point in time
From: R. Diez @ 2011-08-22 12:25 UTC (permalink / raw)
To: git
Hi all:
I'm writing a daily build script for all the OpenRISC components, so every day I need to check out several git repositories with the source code of many tools that depend on each other.
The hole process takes hours. In order to minimize the risk of repository skew, I thought I could just take the current date and time, clone all repositories to my local PC and check them all out at that particular timestamp.
I figured out that something like git "checkout HEAD@{2011-08-21 10:00:00}" does not really cut it. I'm getting this warning:
warning: Log for 'HEAD' only goes back to Sun, 21 Aug 2011 10:00:02 +0200.
The reason is, the timestamp was taken at 10:00, and the repository was cloned 2 seconds later, which means that 10:00 is earlier than the repository. That was totally unexpected, but then I found this in the documentation for "gitrevisions":
Note that this looks up the state of your local ref at
a given time; e.g., what was in your local master branch last week.
If you want to look at commits made during certain times,
see --since and --until.
I guess that means the HEAD@{date} syntax does not do what I expected. But hey, it's not the first time I find the git docs hard to follow... }8-)
By the way, it would be nice if the gitrevisions documentation could be improved, as I still don't understand what that really means. Say, for example, an hour ago I had temporarily checked out last year's versions, but half an hour ago I went back to this year's versions. If I check out at HEAD@{1 hour ago}, will I get then last year's version, or this year's?
Anyway, my real problem is with the mentioned --until option. "git checkout" does not understand that option, so I guess I need to feed the date to some other git command in order to get the commit ID for "git checkout", right? Can someone help me here?
Or even better, can someone add this kind of explanation to the "git checkout" documentation? If you are used to other version control systems, and wish to checkout the versions at a particular date, that's the documentation page you first look at.
For extra karma points, git checkout could understand the --until option itself.
Many thanks in advance,
R. Diez
^ permalink raw reply
* Re: [PATCH v3 1/5] git-p4: Allow setting rename/copy detection threshold
From: Pete Wyckoff @ 2011-08-22 12:18 UTC (permalink / raw)
To: Vitor Antunes; +Cc: git, Tor Arvid Lund
In-Reply-To: <1314001989-29017-2-git-send-email-vitor.hda@gmail.com>
vitor.hda@gmail.com wrote on Mon, 22 Aug 2011 09:33 +0100:
> Copy and rename detection arguments (-C and -M) allow setting a threshold value
> for the similarity ratio. If the similarity is below this threshold the rename
> or copy is ignored and the file is added as new.
> This patch allows setting git-p4.detectRenames and git-p4.detectCopies options
> to an integer value to set the respective threshold.
>
> Signed-off-by: Vitor Antunes <vitor.hda@gmail.com>
This series looks great. Thanks for fixing the --bool issue and
the tests.
Acked-by: Pete Wyckoff <pw@padd.com>
-- Pete
^ permalink raw reply
* [PATCH 2/2] fast-import: allow to tag newly created objects
From: Dmitry Ivankov @ 2011-08-22 12:10 UTC (permalink / raw)
To: git; +Cc: Jonathan Nieder, Shawn O. Pearce, David Barr, Dmitry Ivankov
In-Reply-To: <1314015019-6636-1-git-send-email-divanorama@gmail.com>
fast-import allows to tag objects by sha1 and to query sha1 of objects
being imported. So it should allow to tag these objects, make it do so.
Signed-off-by: Dmitry Ivankov <divanorama@gmail.com>
---
fast-import.c | 10 +++++++---
t/t9300-fast-import.sh | 26 ++++++++++++++++++++++++++
2 files changed, 33 insertions(+), 3 deletions(-)
diff --git a/fast-import.c b/fast-import.c
index 0b0f598..11eb6bf 100644
--- a/fast-import.c
+++ b/fast-import.c
@@ -2690,9 +2690,13 @@ static void parse_new_tag(void)
type = oe->type;
hashcpy(sha1, oe->idx.sha1);
} else if (!get_sha1(from, sha1)) {
- type = sha1_object_info(sha1, NULL);
- if (type < 0)
- die("Not a valid object: %s", from);
+ struct object_entry *oe = find_object(sha1);
+ if (!oe) {
+ type = sha1_object_info(sha1, NULL);
+ if (type < 0)
+ die("Not a valid object: %s", from);
+ } else
+ type = oe->type;
} else
die("Invalid ref name or SHA1 expression: %s", from);
read_next_command();
diff --git a/t/t9300-fast-import.sh b/t/t9300-fast-import.sh
index 41f0d02..efe9779 100755
--- a/t/t9300-fast-import.sh
+++ b/t/t9300-fast-import.sh
@@ -188,12 +188,32 @@ test_expect_success \
test_cmp expect marks.new'
test_tick
+new_blob=$(echo testing | git hash-object --stdin)
cat >input <<INPUT_END
tag series-A-blob-2
from $(git rev-parse refs/heads/master:file3)
data <<EOF
Tag blob by sha1.
EOF
+
+blob
+mark :6
+data <<EOF
+testing
+EOF
+
+commit refs/heads/new_blob
+committer <> 0 +0000
+data 0
+M 644 :6 new_blob
+#pretend we got sha1 from fast-import
+ls "new_blob"
+
+tag series-A-blob-3
+from $new_blob
+data <<EOF
+Tag new_blob.
+EOF
INPUT_END
cat >expect <<EOF
@@ -202,12 +222,18 @@ type blob
tag series-A-blob-2
Tag blob by sha1.
+object $new_blob
+type blob
+tag series-A-blob-3
+
+Tag new_blob.
EOF
test_expect_success \
'A: tag blob by sha1' \
'git fast-import <input &&
git cat-file tag tags/series-A-blob-2 >actual &&
+ git cat-file tag tags/series-A-blob-3 >>actual &&
test_cmp expect actual'
test_tick
--
1.7.3.4
^ permalink raw reply related
* [PATCH 1/2] fast-import: add tests for tagging blobs
From: Dmitry Ivankov @ 2011-08-22 12:10 UTC (permalink / raw)
To: git; +Cc: Jonathan Nieder, Shawn O. Pearce, David Barr, Dmitry Ivankov
In-Reply-To: <1314015019-6636-1-git-send-email-divanorama@gmail.com>
fast-import allows to create an annotated tag that annotates a blob,
via mark or direct sha1 specification.
For mark it works, for sha1 it tries to read the object. It tries to
do so via read_sha1_file, and then checks the size to be at least 46.
That's weird, let's just allow to (annotated) tag any object referenced
by sha1. If the object originates from our packfile, we still fail though.
Signed-off-by: Dmitry Ivankov <divanorama@gmail.com>
---
fast-import.c | 10 +++-------
t/t9300-fast-import.sh | 41 +++++++++++++++++++++++++++++++++++++++++
2 files changed, 44 insertions(+), 7 deletions(-)
diff --git a/fast-import.c b/fast-import.c
index 7cc2262..0b0f598 100644
--- a/fast-import.c
+++ b/fast-import.c
@@ -2690,13 +2690,9 @@ static void parse_new_tag(void)
type = oe->type;
hashcpy(sha1, oe->idx.sha1);
} else if (!get_sha1(from, sha1)) {
- unsigned long size;
- char *buf;
-
- buf = read_sha1_file(sha1, &type, &size);
- if (!buf || size < 46)
- die("Not a valid commit: %s", from);
- free(buf);
+ type = sha1_object_info(sha1, NULL);
+ if (type < 0)
+ die("Not a valid object: %s", from);
} else
die("Invalid ref name or SHA1 expression: %s", from);
read_next_command();
diff --git a/t/t9300-fast-import.sh b/t/t9300-fast-import.sh
index f256475..41f0d02 100755
--- a/t/t9300-fast-import.sh
+++ b/t/t9300-fast-import.sh
@@ -94,6 +94,12 @@ data <<EOF
An annotated tag without a tagger
EOF
+tag series-A-blob
+from :3
+data <<EOF
+An annotated tag that annotates a blob.
+EOF
+
INPUT_END
test_expect_success \
'A: create pack from stdin' \
@@ -152,6 +158,18 @@ test_expect_success 'A: verify tag/series-A' '
'
cat >expect <<EOF
+object $(git rev-parse refs/heads/master:file3)
+type blob
+tag series-A-blob
+
+An annotated tag that annotates a blob.
+EOF
+test_expect_success 'A: verify tag/series-A-blob' '
+ git cat-file tag tags/series-A-blob >actual &&
+ test_cmp expect actual
+'
+
+cat >expect <<EOF
:2 `git rev-parse --verify master:file2`
:3 `git rev-parse --verify master:file3`
:4 `git rev-parse --verify master:file4`
@@ -171,6 +189,29 @@ test_expect_success \
test_tick
cat >input <<INPUT_END
+tag series-A-blob-2
+from $(git rev-parse refs/heads/master:file3)
+data <<EOF
+Tag blob by sha1.
+EOF
+INPUT_END
+
+cat >expect <<EOF
+object $(git rev-parse refs/heads/master:file3)
+type blob
+tag series-A-blob-2
+
+Tag blob by sha1.
+EOF
+
+test_expect_success \
+ 'A: tag blob by sha1' \
+ 'git fast-import <input &&
+ git cat-file tag tags/series-A-blob-2 >actual &&
+ test_cmp expect actual'
+
+test_tick
+cat >input <<INPUT_END
commit refs/heads/verify--import-marks
committer $GIT_COMMITTER_NAME <$GIT_COMMITTER_EMAIL> $GIT_COMMITTER_DATE
data <<COMMIT
--
1.7.3.4
^ permalink raw reply related
* [PATCH 0/2] fast-import: tag any object by sha1
From: Dmitry Ivankov @ 2011-08-22 12:10 UTC (permalink / raw)
To: git; +Cc: Jonathan Nieder, Shawn O. Pearce, David Barr, Dmitry Ivankov
fast-export can export annotated tags that annotate any type of object.
It specifies objects via mark references and fast-import accepts this.
fast-import also allows to specify objects via sha1, and to query sha1
for a object being imported. So it should allow to tag a pre-existing
or being-imported objects by their sha1. And it currently does not:
- for pre-existing it kind of assumes it is a OBJ_COMMIT, read_sha1_file()s
and checks only for (size >= 46), weird
- for being-imported objects it calls read_sha1_file too and fails
Just make it produce expected tags in these cases. Add a test for this.
Dmitry Ivankov (2):
fast-import: add tests for tagging blobs
fast-import: allow to tag newly created objects
fast-import.c | 14 +++++-----
t/t9300-fast-import.sh | 67 ++++++++++++++++++++++++++++++++++++++++++++++++
2 files changed, 74 insertions(+), 7 deletions(-)
--
1.7.3.4
^ permalink raw reply
* Re: [PATCH] Do not use C++-style comments
From: Johan Herland @ 2011-08-22 11:55 UTC (permalink / raw)
To: Michael Haggerty; +Cc: git, Junio C Hamano
In-Reply-To: <1314009232-6194-1-git-send-email-mhagger@alum.mit.edu>
On Monday 22. August 2011, Michael Haggerty wrote:
> Detected by "gcc -std=iso9899:1990 ...". This patch applies against
> "maint".
>
> Signed-off-by: Michael Haggerty <mhagger@alum.mit.edu>
> ---
> notes.c | 2 +-
> 1 files changed, 1 insertions(+), 1 deletions(-)
>
> diff --git a/notes.c b/notes.c
> index f6ce848..93e9868 100644
> --- a/notes.c
> +++ b/notes.c
> @@ -1105,7 +1105,7 @@ int remove_note(struct notes_tree *t, const
> unsigned char *object_sha1) hashcpy(l.key_sha1, object_sha1);
> hashclr(l.val_sha1);
> note_tree_remove(t, t->root, 0, &l);
> - if (is_null_sha1(l.val_sha1)) // no note was removed
> + if (is_null_sha1(l.val_sha1)) /* no note was removed */
ACK!
...Johan
--
Johan Herland, <johan@herland.net>
www.herland.net
^ permalink raw reply
* [PATCH] Do not use C++-style comments
From: Michael Haggerty @ 2011-08-22 10:33 UTC (permalink / raw)
To: git; +Cc: Junio C Hamano, Johan Herland, Michael Haggerty
Detected by "gcc -std=iso9899:1990 ...". This patch applies against
"maint".
Signed-off-by: Michael Haggerty <mhagger@alum.mit.edu>
---
notes.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/notes.c b/notes.c
index f6ce848..93e9868 100644
--- a/notes.c
+++ b/notes.c
@@ -1105,7 +1105,7 @@ int remove_note(struct notes_tree *t, const unsigned char *object_sha1)
hashcpy(l.key_sha1, object_sha1);
hashclr(l.val_sha1);
note_tree_remove(t, t->root, 0, &l);
- if (is_null_sha1(l.val_sha1)) // no note was removed
+ if (is_null_sha1(l.val_sha1)) /* no note was removed */
return 1;
t->dirty = 1;
return 0;
--
1.7.6.8.gd2879
^ permalink raw reply related
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