* [RFC/PATCH git-remote-bzr] Adapt to new semantics of remote-helper "import" command
From: Jonathan Nieder @ 2012-01-22 5:46 UTC (permalink / raw)
To: Gabriel Filion
Cc: git, Simon Poirier, Sverre Rabbelier, Jeff King, David Barr,
Dmitry Ivankov
Git 1.7.7 (commit 9504bc9d, "transport-helper: change import
semantics", 2011-07-16) incompatibly changed the interface of the
"import" capability.
Before, git would always send a single import command, which the
remote helper would respond to with a fast-import stream, terminated
by end of file, meaning there was no way to fetch multiple refs in one
connection. Nowadays, git instead sends a sequence of import lines:
import refs/heads/foo
import refs/heads/bar
terminated by a blank line. The helper is to respond with a
fast-import stream terminated by the "done" command and process
further commands until another blank line indicates the end of the
command stream.
---
Hi Simon and Gabriel,
Here's a rough patch against git://github.com/lelutin/git-remote-bzr.git
master.
Without this patch, whenever I try to use "git clone bzr::<something>",
after doing all the work it removes the resulting repo and exits with
status 141 (SIGPIPE). Maybe the transport-helper should mask SIGPIPE
when writing the final newline to avoid that.
I'd have prefered to write a patch for remote-bzr that works with
older versions of git fast-import, too, but it wasn't obvious how.
Hints welcome.
BTW, would you mind if I sent a patch to include git-remote-bzr in
git.git under contrib/?
Thanks for git remote-bzr! I'd be happy for any thoughts you have.
Ciao,
Jonathan
[1] http://thread.gmane.org/gmane.comp.version-control.git/176002/focus=176606
README.rst | 2 +-
git-remote-bzr | 33 ++++++++++++++++++++++++++++++---
2 files changed, 31 insertions(+), 4 deletions(-)
diff --git a/README.rst b/README.rst
index 3eb3e476..f4dbbeb2 100644
--- a/README.rst
+++ b/README.rst
@@ -34,7 +34,7 @@ Relevant bug reports
Requirements
------------
-- git 1.6.6 or later
+- git 1.7.7 or later
- python 2.5 +
- bzr 2.x
- bzr-fastimport
diff --git a/git-remote-bzr b/git-remote-bzr
index 1e3a05f9..501fffe3 100755
--- a/git-remote-bzr
+++ b/git-remote-bzr
@@ -49,7 +49,7 @@ def do_list(repo, args):
print # end list
-def do_import(repo, args):
+def import_one_ref(repo, args):
"""Import a fast-import stream that is exported from Bazaar."""
if len(args) != 1:
die("Import needs exactly one ref")
@@ -65,6 +65,23 @@ def do_import(repo, args):
if bzrp.wait():
die("'bzr fast-export' returned unexpectedly with code %d",
bzrp.returncode)
+ print "done"
+
+
+def do_import(repo,args):
+ import_one_ref(repo, args)
+
+ cmdline = True
+ while cmdline:
+ cmdline = next_command()
+ if not cmdline:
+ # Return to main processing loop
+ return True
+ cmd = cmdline.pop(0)
+ if cmd != "import":
+ warn("Unexpected command %s during import" % cmd)
+ return False
+ import_one_ref(repo, cmdline)
def do_push(repo, args):
@@ -123,8 +140,8 @@ def sanitize(value):
return value
-def read_one_line(repo):
- """Read and process one command."""
+def next_command():
+ """Read one command."""
line = sys.stdin.readline()
cmdline = line
@@ -138,6 +155,16 @@ def read_one_line(repo):
# Blank line means we're about to quit
return False
+ return cmdline
+
+
+def read_one_line(repo):
+ """Read and process one command."""
+ cmdline = next_command()
+
+ if not cmdline:
+ return False
+
cmd = cmdline.pop(0)
debug("Got command '%s' with args '%s'", cmd, ' '.join(cmdline))
--
1.7.9.rc2
^ permalink raw reply related
* Re: [PATCH V4] git on Mac OS and precomposed unicode
From: Nguyen Thai Ngoc Duy @ 2012-01-22 9:58 UTC (permalink / raw)
To: Torsten Bögershausen, Junio C Hamano; +Cc: git
In-Reply-To: <7vsjj8acmh.fsf@alter.siamese.dyndns.org>
On Sun, Jan 22, 2012 at 5:56 AM, Junio C Hamano <gitster@pobox.com> wrote:
> [Pinging Nguyen who has worked rather extensively on the start-up sequence
> for ideas.]
>
> Torsten Bögershausen <tboegi@web.de> writes:
>
> I'll try to reword the log message a bit below.
>
>> When a file called "LATIN CAPITAL LETTER A WITH DIAERESIS" (in utf-8
>> encoded as 0xc3 0x84) is created, the Mac OS filesystem converts
>> "precomposed unicode" into "decomposed unicode". readdir() will return
>> 0x41 0xcc 0x88 for such a file, that does not match what the caller
>> thought it created.
>>
>> To work around this braindamage, allow git on Mac OS to optionally use a
>> wrapper for readdir() that converts decomposed unicode back into the
>> precomposed form, which most other platforms use natively. This makes it
>> easier for Mac OS users to work together on the same project with people
>> on other platforms (Note that not all Windows versions support UTF-8
>> yet. Msysgit needs the unicode branch, cygwin supports UTF-8 since
>> 1.7). This allows sharing git repositories stored on a VFAT file system
>> (e.g. a USB stick), and mounted network share using samba.
I just have a quick look, you reencode opendir, readdir, and
closedir() to precomposed form. But files are still in decomposed
form, does open(<precomposed file>) work when only <decomposed file>
exists?
>> In order to prevent that ever a file name in decomposed unicode is
>> entering the index, a "brute force" attempt is taken: all arguments into
>> git (argv[1]..argv[n]) are converted into precomposed unicode. This is
>> done in git.c by calling precompose_argv(). This function is actually a
>> #define, and it is only defined under Mac OS. Nothing is converted on
>> any other platforms.
This is not entirely safe. Filenames can be taken from a file for
example (--stdin option or similar). Unless I'm mistaken, all file
names must enter git through the index, the conversion at read-cache.c
may be a better option.
>> Auto sensing:
>> When creating a new git repository with "git init" or "git clone",
>> "core.precomposedunicode" will be set "false".
This is a general comment on init auto detection feature. Perhaps we
should allow detection to be done when reinitializing a repo. Or at
least make an option to auto detect, print out new config values and
user can decide if they want to change current values themselves.
>> +void precompose_argv(int argc, const char **argv)
>> +{
>> + int i = 0;
>> + const char *oldarg;
>> + char *newarg;
>> + iconv_t ic_precompose;
>> +
>> + git_config(precomposed_unicode_config, NULL);
>
> As the first thing called after main(), I still doubt this is a safe thing
> to do (Pinging Nguyen who has worked rather extensively on the start-up
> sequence for ideas). This is ifdefed away and will not break things on
> other platforms, which may make it even harder to diagnose breakages.
This can't be worse than current state of pager and alias settings,
which need to be detected even before setup_git_directory* is run.
I'd rather encode at index level and read_directory() than at argv[].
But if reencoding argv is the only feasible way, perhaps put the
conversion in parse_options()? Config reading is usually done by then,
and we can move precomposed config reading to git_default_config. If
some commands do not use parse_options yet, this is a good opportunity
to do so (I'll send pack-objects's parse_options() patch soon).
--
Duy
^ permalink raw reply
* Re: [PATCH V4] git on Mac OS and precomposed unicode
From: Nguyen Thai Ngoc Duy @ 2012-01-22 10:03 UTC (permalink / raw)
To: Torsten Bögershausen, Junio C Hamano; +Cc: git
In-Reply-To: <CACsJy8BKQHLdoXfSKsULkWWbWjWEuZgr=bVNKmgCSArvwbf2UA@mail.gmail.com>
2012/1/22 Nguyen Thai Ngoc Duy <pclouds@gmail.com>:
>>> In order to prevent that ever a file name in decomposed unicode is
>>> entering the index, a "brute force" attempt is taken: all arguments into
>>> git (argv[1]..argv[n]) are converted into precomposed unicode.
Forgot one more thing. We have case-insensitive support in place
already, we can hook precomposed form conversion there before
comparing. In other words we just need to support
{pre,de}composed-insensitive string compare.
--
Duy
^ permalink raw reply
* Checkout tag?
From: Abscissa @ 2012-01-22 10:05 UTC (permalink / raw)
To: git
I've managed to figure out you switch branches with the checkout command,
like this:
>git checkout branch_name
Does that work for tags as well? The docs don't seem clear on that. If not,
how do you get the working copy to be a specific tag?
--
View this message in context: http://git.661346.n2.nabble.com/Checkout-tag-tp7213023p7213023.html
Sent from the git mailing list archive at Nabble.com.
^ permalink raw reply
* Re: Checkout tag?
From: Magnus Bäck @ 2012-01-22 10:11 UTC (permalink / raw)
To: Abscissa; +Cc: git
In-Reply-To: <1327226753653-7213023.post@n2.nabble.com>
On Sunday, January 22, 2012 at 11:05 CET,
Abscissa <bus_nabble_git@semitwist.com> wrote:
> I've managed to figure out you switch branches with the checkout
> command, like this:
>
> >git checkout branch_name
>
> Does that work for tags as well? The docs don't seem clear on that.
> If not, how do you get the working copy to be a specific tag?
Yes, "git checkout" works for branches, tags, commit SHA-1s, and
anything else that can be resolved to a SHA-1 identifying what to
check out. The git-checkout(1) man page says the following:
git checkout [--patch] [<tree-ish>] [--] <pathspec>...
... The <tree-ish> argument can be used to specify a
specific tree-ish (i.e. commit, tag or tree) ...
--
Magnus Bäck Opinions are my own and do not necessarily
SW Configuration Manager represent the ones of my employer, etc.
Sony Ericsson
^ permalink raw reply
* Re: Checkout tag?
From: Nguyen Thai Ngoc Duy @ 2012-01-22 10:18 UTC (permalink / raw)
To: Abscissa; +Cc: git
In-Reply-To: <1327226753653-7213023.post@n2.nabble.com>
On Sun, Jan 22, 2012 at 5:05 PM, Abscissa <bus_nabble_git@semitwist.com> wrote:
> I've managed to figure out you switch branches with the checkout command,
> like this:
>
>>git checkout branch_name
>
> Does that work for tags as well? The docs don't seem clear on that. If not,
> how do you get the working copy to be a specific tag?
Magnus already answered your checkout question. I just want to add
that you can view a tag's content even without checking out. For
example,"git archive" can create a zip/tarball of any tree-ish. "git
ls-tree" lets you view directory structure of a tree-ish, "git show
<tree-ish>:path" lets you view content of a specific file.
--
Duy
^ permalink raw reply
* Re: Checkout tag?
From: Abscissa @ 2012-01-22 10:25 UTC (permalink / raw)
To: git
In-Reply-To: <20120122101116.GA31022@jpl.local>
I saw that, but it seems to imply that it's not a simple:
>git checkout tag_name
because of the required <pathspec>, whatever that is.
--
View this message in context: http://git.661346.n2.nabble.com/Checkout-tag-tp7213023p7213061.html
Sent from the git mailing list archive at Nabble.com.
^ permalink raw reply
* Re: [linux.conf.au] VCS Interoperability
From: Ramkumar Ramachandra @ 2012-01-22 10:25 UTC (permalink / raw)
To: David Michael Barr; +Cc: git, Junio C Hamano, Jonathan Nieder, Dmitry Ivankov
In-Reply-To: <CAFfmPPOZfDdH+GF91Dxyy5yfX8TmGDmsbpHz=CVLcBY0c-pCsQ@mail.gmail.com>
Hi David,
David Michael Barr wrote:
> Thank you for the feedback, it helped a lot with picking a trajectory.
>
> Video is now available: http://youtu.be/0hVuv-wv4Dw
> Slides: http://barrbrain.github.com/vcs-interoperability.html
>
> It was my first conference presentation so the usual caveats apply.
> I was fortunate to have a small but interested audience.
>
> I look forward to constructive criticism so that I can better represent
> our community to the folk Down Under.
Thanks for the valuable criticism. A few thoughts:
1. We'll try to fix this over the next few weeks.
2. Subversion's architecture is well-compartmentalized: is this what
leads to communication gaps between the API layers?
3. What are your thoughts on lib'ifying Git so that others can call
into it using an API?
Cheers!
^ permalink raw reply
* Re: Checkout tag?
From: Abscissa @ 2012-01-22 10:26 UTC (permalink / raw)
To: git
In-Reply-To: <20120122101116.GA31022@jpl.local>
I saw that, but it seems to imply that it's not a simple:
>git checkout tag_name
because of the required <pathspec>, whatever that is.
--
View this message in context: http://git.661346.n2.nabble.com/Checkout-tag-tp7213023p7213063.html
Sent from the git mailing list archive at Nabble.com.
^ permalink raw reply
* Re: Checkout tag?
From: Abscissa @ 2012-01-22 10:26 UTC (permalink / raw)
To: git
In-Reply-To: <20120122101116.GA31022@jpl.local>
I saw that, but it seems to imply that it's not a simple:
>git checkout tag_name
because of the required <pathspec>, whatever that is.
--
View this message in context: http://git.661346.n2.nabble.com/Checkout-tag-tp7213023p7213066.html
Sent from the git mailing list archive at Nabble.com.
^ permalink raw reply
* Re: Checkout tag?
From: Abscissa @ 2012-01-22 10:27 UTC (permalink / raw)
To: git
In-Reply-To: <20120122101116.GA31022@jpl.local>
I saw that, but it seems to imply that it's not a simple:
>git checkout tag_name
because of the required <pathspec>, whatever that is.
--
View this message in context: http://git.661346.n2.nabble.com/Checkout-tag-tp7213023p7213069.html
Sent from the git mailing list archive at Nabble.com.
^ permalink raw reply
* Re: Checkout tag?
From: Abscissa @ 2012-01-22 10:27 UTC (permalink / raw)
To: git
In-Reply-To: <20120122101116.GA31022@jpl.local>
I saw that, but it seems to imply that it's not a simple:
>git checkout tag_name
because of the required <pathspec>, whatever that is.
--
View this message in context: http://git.661346.n2.nabble.com/Checkout-tag-tp7213023p7213072.html
Sent from the git mailing list archive at Nabble.com.
^ permalink raw reply
* Re: Checkout tag?
From: Abscissa @ 2012-01-22 10:28 UTC (permalink / raw)
To: git
In-Reply-To: <20120122101116.GA31022@jpl.local>
I saw that, but it seems to imply that it's not a simple:
>git checkout tag_name
because of the required <pathspec>, whatever that is.
--
View this message in context: http://git.661346.n2.nabble.com/Checkout-tag-tp7213023p7213074.html
Sent from the git mailing list archive at Nabble.com.
^ permalink raw reply
* Re: Checkout tag?
From: Abscissa @ 2012-01-22 10:28 UTC (permalink / raw)
To: git
In-Reply-To: <20120122101116.GA31022@jpl.local>
I saw that, but it seems to imply that it's not a simple:
>git checkout tag_name
because of the required <pathspec>, whatever that is.
--
View this message in context: http://git.661346.n2.nabble.com/Checkout-tag-tp7213023p7213076.html
Sent from the git mailing list archive at Nabble.com.
^ permalink raw reply
* Re: Checkout tag?
From: Abscissa @ 2012-01-22 10:29 UTC (permalink / raw)
To: git
In-Reply-To: <20120122101116.GA31022@jpl.local>
I saw that, but it seems to imply that it's not a simple:
>git checkout tag_name
because of the required <pathspec>, whatever that is.
--
View this message in context: http://git.661346.n2.nabble.com/Checkout-tag-tp7213023p7213078.html
Sent from the git mailing list archive at Nabble.com.
^ permalink raw reply
* Re: Checkout tag?
From: Abscissa @ 2012-01-22 10:29 UTC (permalink / raw)
To: git
In-Reply-To: <CACsJy8AUaJ_tkLSHYPZEPLuiNitRMS77b7n9JFeV6HABHj9Qiw@mail.gmail.com>
I saw that, but it seems to imply that it's not a simple:
>git checkout tag_name
because of the required <pathspec>, whatever that is.
--
View this message in context: http://git.661346.n2.nabble.com/Checkout-tag-tp7213023p7213081.html
Sent from the git mailing list archive at Nabble.com.
^ permalink raw reply
* Re: Checkout tag?
From: Abscissa @ 2012-01-22 10:34 UTC (permalink / raw)
To: git
In-Reply-To: <1327228177859-7213081.post@n2.nabble.com>
Sorry for the duplicates. Nabble kept crashing every time I tried to post,
but I guess it was crashing after it posted to the mailing list.
--
View this message in context: http://git.661346.n2.nabble.com/Checkout-tag-tp7213023p7213090.html
Sent from the git mailing list archive at Nabble.com.
^ permalink raw reply
* Re: Checkout tag?
From: Jakub Narebski @ 2012-01-22 11:30 UTC (permalink / raw)
To: Magnus Bäck; +Cc: Abscissa, git
In-Reply-To: <20120122101116.GA31022@jpl.local>
Magnus Bäck <magnus.back@sonyericsson.com> writes:
> On Sunday, January 22, 2012 at 11:05 CET,
> Abscissa <bus_nabble_git@semitwist.com> wrote:
>
> > I've managed to figure out you switch branches with the checkout
> > command, like this:
> >
> > $ git checkout branch_name
> >
> > Does that work for tags as well? The docs don't seem clear on that.
> > If not, how do you get the working copy to be a specific tag?
>
> Yes, "git checkout" works for branches, tags, commit SHA-1s, and
> anything else that can be resolved to a SHA-1 identifying what to
> check out. [...]
Note however that because you can generate new commits only on top of
local branches (refs/heads/*), if you check out something other than
local branch, e.g.:
$ git checkout v1.7.8
$ git checkout origin/next
$ git checkout HEAD^
you would be after such checkout in unnamed anonymous branch which
contents corresponds to what you checked out. This state is called
'detached HEAD', and shows e.g. in "git branch output as
$ git branch
* (no branch)
master
...
On the other hand if you don't want to checkout tag to explore it, but
set contents of working area to the state it was in given tag, you can
use
$ git checkout v1.7.8 -- .
HTH
P.S. Instead of Nabble you can use GMane interface, or just use email
(you don't have ot be subscribed to git@vger.kernel.org to post, and
it is custom here to send replies also to author(s)).
--
Jakub Narebski
^ permalink raw reply
* Re: Checkout tag?
From: Magnus Bäck @ 2012-01-22 11:31 UTC (permalink / raw)
To: Abscissa; +Cc: git
In-Reply-To: <1327227956026-7213061.post@n2.nabble.com>
On Sunday, January 22, 2012 at 11:25 CET,
Abscissa <bus_nabble_git@semitwist.com> wrote:
> I saw that, but it seems to imply that it's not a simple:
>
> >git checkout tag_name
>
> because of the required <pathspec>, whatever that is.
It isn't required. The part of the manual that I quoted (from Git
1.7.2.5) indicated that the pathspec is mandatory, but looking at
the command synopsis at the top of the man page it's actually listed
as optional.
Looking at an up to date Git 1.7.9-rc2 man page, it still seems
slightly inconsistent with itself. The synopsis at the top says
git checkout [-p|--patch] [<tree-ish>] [--] [<paths>...]
while the text in the DESCRIPTION section says
git checkout [-p|--patch] [<tree-ish>] [--] <pathspec>...
The DETACHED HEAD section of the man page contains an example of
checking out a tag, by the way.
If you're doubtful, why don't you just create a tag and try things
out for yourself?
--
Magnus Bäck Opinions are my own and do not necessarily
SW Configuration Manager represent the ones of my employer, etc.
Sony Ericsson
^ permalink raw reply
* Re: Including git-describe info as version strings for generic "-v" output
From: Dirk Süsserott @ 2012-01-22 16:03 UTC (permalink / raw)
To: Harry portobello; +Cc: Junio C Hamano, git
In-Reply-To: <7vd3acbtn3.fsf@alter.siamese.dyndns.org>
Am 21.01.2012 23:03 schrieb Junio C Hamano:
> Harry portobello <harryportobello@gmail.com> writes:
>
>> I hope the subject makes sense -- I'll explain what I'm trying to do.
>
> Perhaps take a look at GIT-VERSION-GEN that is part of the Git source?
At work, we have the same "problem". I solved it like so:
version.h:
----------------------------------------------
#ifndef __version_h__
#define __version_h__
#ifdef __cplusplus
extern "C" {
#endif
/*
* Returns a version string as defined with the -D compiler switch.
*/
char const * software_version();
#ifdef __cplusplus
}
#endif
#endif
----------------------------------------------
version.c:
----------------------------------------------
#include "version.h"
char const * software_version()
{
return SW_VERSION;
}
----------------------------------------------
And then make sure that ONLY version.c gets compiled like this:
gcc -DSW_VERSION=\"$(git describe --dirty)\" \
[other options] \
-c version.c -o version.o
Actually I use Scons to build my software (not Make). Scons
automatically keeps track of dependencies and changed compiler switches
between its runs. Thus it will re-compile version.c if the output of
git-describe changes. That's why Scons users must make sure that the
-D-switch is given only to version.c (else Scons would re-compile ALL
files because of the different argument to -D).
If you are using Make then make sure that version.c gets compiled
always. The drawback is that your app will be re-linked with every
single Make run.
That's why I prefer Scons: it calculates the dependencies on a checksum
basis. If the *contents* of version.c together with the compiler options
didn't change, it won't re-compile it. Furtermore: if the *contents* of
version.o didn't change, it won't re-link. Timestamps don't matter to
Scons. But that's another topic :-)
HTH
Dirk
^ permalink raw reply
* Re: Checkout tag?
From: Jonathan Nieder @ 2012-01-22 17:08 UTC (permalink / raw)
To: Magnus Bäck; +Cc: Abscissa, git, Jakub Narebski, Nguyen Thai Ngoc Duy
In-Reply-To: <20120122113115.GA31545@jpl.local>
Hi,
Magnus Bäck wrote:
> Looking at an up to date Git 1.7.9-rc2 man page, it still seems
> slightly inconsistent with itself. The synopsis at the top says
>
> git checkout [-p|--patch] [<tree-ish>] [--] [<paths>...]
>
> while the text in the DESCRIPTION section says
>
> git checkout [-p|--patch] [<tree-ish>] [--] <pathspec>...
Hmm, my copy says:
SYNOPSIS
git checkout [-q] [-f] [-m] [<branch>]
git checkout [-q] [-f] [-m] [--detach] [<commit>]
git checkout [-q] [-f] [-m] [[-b|-B|--orphan] <new_branch>] [<start_point>]
git checkout [-f|--ours|--theirs|-m|--conflict=<style>] [<tree-ish>] [--] <paths>...
git checkout [-p|--patch] [<tree-ish>] [--] [<paths>...]
DESCRIPTION
... overview ...
git checkout [<branch>], git checkout -b|-B <new_branch> [<start point>],
git checkout [--detach] [<commit>]
This form switches branches by updating the index, working
tree, and HEAD...
git checkout [-p|--patch] [<tree-ish>] [--] <pathspec>...
When <paths> or --patch are given, git checkout does not
switch branches. It updates the named paths...
So in the synopsis it lists five forms, and in the description section
it lists two forms, the first of which has three variants.
It's not immediately obvious to me which inconsistency you are
pointing to as a source of confusion. Could you elaborate, preferably
with suggested wording for a fix? If you can do so in the form of a
patch, all the better. ;-)
Thanks,
Jonathan
^ permalink raw reply
* What does "modified" in git status mean?
From: Mikolas @ 2012-01-22 16:57 UTC (permalink / raw)
To: git
I am using git version 1.7.5.1 under cygwin and I'm getting behavior that I'm
not understanding.
When I do 'git status' in the root directory of the repository, it shows no
difference. Once I cd to a subdirectory, it starts showing modifications.
However, 'git diff' shows nothing.
So it looks something like this:
$ git status
# On branch master
nothing to commit (working directory clean)
$ cd foo
$ 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: ../foo/bar
$ git diff
$
I put the following in my gitconfig but that doesn't seem to be doing much.
[core]
trustctime = false
autocrlf = input
So my questions are
1) Is there some way how to tell status to tell me *why* the files are marked
as modified?
2) Is it normal that git status behaves differently in different directories?
--mikolas
^ permalink raw reply
* Re: Checkout tag?
From: Magnus Bäck @ 2012-01-22 17:33 UTC (permalink / raw)
To: Jonathan Nieder
Cc: Magnus Bäck, Abscissa, git, Jakub Narebski,
Nguyen Thai Ngoc Duy
In-Reply-To: <20120122170800.GA29215@burratino>
On Sunday, January 22, 2012 at 18:08 CET,
Jonathan Nieder <jrnieder@gmail.com> wrote:
> Magnus Bäck wrote:
>
> > Looking at an up to date Git 1.7.9-rc2 man page, it still seems
> > slightly inconsistent with itself. The synopsis at the top says
> >
> > git checkout [-p|--patch] [<tree-ish>] [--] [<paths>...]
> >
> > while the text in the DESCRIPTION section says
> >
> > git checkout [-p|--patch] [<tree-ish>] [--] <pathspec>...
>
> Hmm, my copy says:
>
> SYNOPSIS
>
> git checkout [-q] [-f] [-m] [<branch>]
> git checkout [-q] [-f] [-m] [--detach] [<commit>]
> git checkout [-q] [-f] [-m] [[-b|-B|--orphan] <new_branch>] [<start_point>]
> git checkout [-f|--ours|--theirs|-m|--conflict=<style>] [<tree-ish>] [--] <paths>...
> git checkout [-p|--patch] [<tree-ish>] [--] [<paths>...]
Perhaps I wasn't clear -- I didn't mean that the synopsis *only* listed
the form in my original quote above.
> DESCRIPTION
>
> ... overview ...
>
> git checkout [<branch>], git checkout -b|-B <new_branch> [<start point>],
> git checkout [--detach] [<commit>]
>
> This form switches branches by updating the index, working
> tree, and HEAD...
>
> git checkout [-p|--patch] [<tree-ish>] [--] <pathspec>...
>
> When <paths> or --patch are given, git checkout does not
> switch branches. It updates the named paths...
>
> So in the synopsis it lists five forms, and in the description section
> it lists two forms, the first of which has three variants.
>
> It's not immediately obvious to me which inconsistency you are
> pointing to as a source of confusion. Could you elaborate,
> preferably with suggested wording for a fix?
I simply meant that
git checkout [-p|--patch] [<tree-ish>] [--] [<paths>...]
git checkout [-p|--patch] [<tree-ish>] [--] <pathspec>...
aren't identical even though I assume they describe the exact same
scenario. The first command synopsis makes it clear that paths are
optional while the second indicates that at least one path must be
specified (unless "..." means "zero, one, or more occurences").
Also, "paths" != "pathspec".
> If you can do so in the form of a patch, all the better. ;-)
Sure, but it won't be during the coming week. Not that the patch is
terribly difficult to prepare but because I need legal approval to
submit it, and it's not clear I'll have time to deal with all that
during my last week at work.
--
Magnus Bäck Opinions are my own and do not necessarily
SW Configuration Manager represent the ones of my employer, etc.
Sony Ericsson
^ permalink raw reply
* Re: What does "modified" in git status mean?
From: Seth Robertson @ 2012-01-22 17:56 UTC (permalink / raw)
To: Mikolas; +Cc: git
In-Reply-To: <loom.20120122T174204-274@post.gmane.org>
In message <loom.20120122T174204-274@post.gmane.org>, Mikolas writes:
1) Is there some way how to tell status to tell me *why* the files
are marked as modified?
Not as such. However, I do have a script which, when run from the
root of the working directory, manually compares the on-disk files to
what is checked into git. This would detect any whitespace or smudge
related changes, or of course any normal user changes.
git ls-tree --name-only -r HEAD | while read path; do if [ ! -f "$path" ]; then continue; fi; sha1=`git show "HEAD:$path" | sha1sum | awk '{print $1;}'`; sha2=`sha1sum "$path" | awk '{print $1;}'`; if [ $sha1 != $sha2 ]; then echo "<$sha1> <$sha2> $path"; fi; done
2) Is it normal that git status behaves differently in different directories?
I would say not, but perhaps you have a .gitattributes in that
directory? (Which would be a bug) Could you try with a more recent
version of git?
-Seth Robertson
^ permalink raw reply
* Re: [PATCH] t/Makefile: Use $(sort ...) explicitly where needed
From: Kirill Smelkov @ 2012-01-22 19:17 UTC (permalink / raw)
To: Kirill Smelkov; +Cc: Junio C Hamano, git
In-Reply-To: <20120120071936.GA22112@mini.zxlink>
On Fri, Jan 20, 2012 at 11:19:36AM +0400, Kirill Smelkov wrote:
> On Thu, Jan 19, 2012 at 11:14:18PM -0800, Junio C Hamano wrote:
> > Kirill Smelkov <kirr@navytux.spb.ru> writes:
> >
> > >> I do not necessarily buy your "so we HAVE TO, OR ELSE".
> > >>
> > >> Even though I can understand "We can sort the list of tests _if_ we do not
> > >> want them executed in seemingly random order when running 'make -j1'", I
> > >> tend to think that *if* is a big one. Aren't these tests designed not to
> > >> depend on each other anyway?
> > >
> > > Yes, they don't depend on each other, but what's the point in not
> > > sorting them? I usually watch test progress visually, and if tests are
> > > sorted, even with make -j4 they go more or less incrementally by their t
> > > number.
> > >
> > > On my netbook, adding $(sort ...) adds approximately 0.008s to make
> > > startup, so imho there is no performance penalty to adding that sort.
> >
> > Heh, who said anything about performance?
> >
> > I was pointing out that your justification "we HAVE TO" was wrong.
> >
> > If you are doing this for perceived prettyness and not as a fix for any
> > correctness issue, I want to see the patch honestly described as such;
> > that's all.
>
> I agree about rewording.
>
>
> > By the way, if I recall correctly, $(sort) in GNU make not just sorts but
> > as a nice side effect removes duplicates. So if we used a(n fictional)
> > construct in our Makefile like this:
> >
> > T = $(wildcard *.sh a.*)
> >
> > that might produce duplicates (i.e. "a.sh" might appear twice), which
> > might leave us two identical pathnames in $T and cause us trouble. Even
> > if we do not have such a use currently, rewriting $(wildcard) like your
> > patch does using $(sort $(wildcard ...)) may be a good way to future-proof
> > our Makefile, and if you justify your patch that way, it would be a
> > possible correctness hardening, not just cosmetics, and phrasing it with
> > "HAVE TO" may be justifiable.
> >
> > Care to try if $(wildcard *.sh a.*) give you duplicated output with newer
> > GNU make? I am lazy but am a bit curious ;-)
>
> Sure. Please give me time untill evening (GMT+0400), or maybe till the
> weekend.
Hello up there again. You are actually right about sort also working as uniq,
e.g. for the following Makefile
T := $(wildcard *.sh a.*)
$(info "T : $T")
$(info "sort(T): $(sort $T)")
$(error 1)
I'm getting duplicates for a.sh and $(sort) removes it
$ ls
0.sh a.sh b.sh c.sh Makefile
$ make -v |head -1
GNU Make 3.82.90
$ make # v v
"T : 0.sh c.sh a.sh b.sh a.sh"
"sort(T): 0.sh a.sh b.sh c.sh"
Makefile:4: *** 1. Stop.
BUT for older make the duplicate is there too:
$ /usr/bin/make -v | head -1
GNU Make 3.81 # this one has its base from 2006
$ /usr/bin/make # v v
"T : 0.sh a.sh b.sh c.sh a.sh"
"sort(T): 0.sh a.sh b.sh c.sh"
Makefile:4: *** 1. Stop.
so yes earlier $(wildcard) sorted the result and no, it sorted it not globally,
but separately for each pattern, so in presence of multiple pattern one could
not rely on implicit auto-uniq even for older make.
If we'd like to protect ourselves from duplicates, the sort should be there for
all makes.
Updated patch follows (sorry for my bad english, I'm too sleepy to get this
into shape even by mine standards...)
---- 8< ----
From: Kirill Smelkov <kirr@navytux.spb.ru>
Date: Sun, 4 Sep 2011 00:41:21 +0400
Subject: [PATCH] t/Makefile: Use $(sort ...) explicitly where needed
Starting from GNU Make 3.82 $(wildcard ...) no longer sorts the result
(from NEWS):
* WARNING: Backward-incompatibility!
Wildcards were not documented as returning sorted values, but the results
have been sorted up until this release.. If your makefiles require sorted
results from wildcard expansions, use the $(sort ...) function to request
it explicitly.
http://repo.or.cz/w/make.git/commitdiff/2a59dc32aaf0681dec569f32a9d7ab88a379d34f
I usually watch test progress visually, and if tests are sorted, even
with make -j4 they go more or less incrementally by their t number. On
the other side, without sorting, tests are executed in seemingly random
order even for -j1. Let's please maintain sane tests order for perceived
prettyness.
Another note is that in GNU Make sort also works as uniq, so after sort
being removed, we might expect e.g. $(wildcard *.sh a.*) to produce
duplicates for e.g. "a.sh". From this point of view, adding sort could
be seen as hardening t/Makefile from accidentally introduced dups.
It turned out that prevous releases of GNU Make did not perform full
sort in $(wildcard), only sorting results for each pattern, that's why
explicit sort-as-uniq is relevant even for older makes.
Signed-off-by: Kirill Smelkov <kirr@navytux.spb.ru>
---
t/Makefile | 6 +++---
1 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/t/Makefile b/t/Makefile
index 9046ec9..66ceefe 100644
--- a/t/Makefile
+++ b/t/Makefile
@@ -17,9 +17,9 @@ DEFAULT_TEST_TARGET ?= test
# Shell quote;
SHELL_PATH_SQ = $(subst ','\'',$(SHELL_PATH))
-T = $(wildcard t[0-9][0-9][0-9][0-9]-*.sh)
-TSVN = $(wildcard t91[0-9][0-9]-*.sh)
-TGITWEB = $(wildcard t95[0-9][0-9]-*.sh)
+T = $(sort $(wildcard t[0-9][0-9][0-9][0-9]-*.sh))
+TSVN = $(sort $(wildcard t91[0-9][0-9]-*.sh))
+TGITWEB = $(sort $(wildcard t95[0-9][0-9]-*.sh))
all: $(DEFAULT_TEST_TARGET)
--
1.7.9.rc2.124.ge3180
^ 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