* Re: [PATCH 3/3] Teach "git branch" about --new-workdir
From: Junio C Hamano @ 2007-07-23 4:45 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: Johannes Schindelin, Julian Phillips, git, gitster
In-Reply-To: <20070723035644.GC32566@spearce.org>
"Shawn O. Pearce" <spearce@spearce.org> writes:
> I live by new-workdir. I do everything with it. And today I just
> spent over an hour sorting out cases where my many, many workdirs
> have different refs than their base repositories, because their
> packed-refs files are different. Grrrrrrrrrrrrrrrrrr.
>
> So we really need to make anyone that edits packed-refs (and
> maybe also config) resolve the symlink and do the edit in the
> target directory. Then we can consider adding this workdir thing
> to core git.
This is actually not limited to packed-refs file, but applies to
other things as well.
I have been wondering if something like this patch would be
sufficient. The idea essentially is to take the lock on the
link target when we try to take a lock on something that is a
symlink pointing elsewhere.
---
lockfile.c | 11 +++++++++++
1 files changed, 11 insertions(+), 0 deletions(-)
diff --git a/lockfile.c b/lockfile.c
index fb8f13b..7fc71d9 100644
--- a/lockfile.c
+++ b/lockfile.c
@@ -28,6 +28,17 @@ static void remove_lock_file_on_signal(int signo)
static int lock_file(struct lock_file *lk, const char *path)
{
int fd;
+ struct stat st;
+
+ if ((!lstat(path, &st)) && S_ISLNK(st.st_mode)) {
+ ssize_t sz;
+ static char target[PATH_MAX];
+ sz = readlink(path, target, sizeof(target));
+ if (sz < 0)
+ warning("Cannot readlink %s", path);
+ else
+ path = target;
+ }
sprintf(lk->filename, "%s.lock", path);
fd = open(lk->filename, O_RDWR | O_CREAT | O_EXCL, 0666);
if (0 <= fd) {
^ permalink raw reply related
* Re: Feedback on native Win32 git from a Perl perspective
From: Adam Kennedy @ 2007-07-23 4:50 UTC (permalink / raw)
To: Martin Langhoff; +Cc: git
In-Reply-To: <46a038f90707200632u1ce762c1i70eb1586e2542256@mail.gmail.com>
Hi Martin
The situation you are in sounds somewhat similar the one we had with our
Win32 Perl distribution releases.
The main problem is that on Windows for the most part there is just no
concept of "first install $something" (be that a run-time, cygwin, or
whatever).
You will find, as we did, that the expectation is that there is one
installer, you run it, and it does everything.
For the Vanilla/Strawberry Perl installers (http://vanillaperl.com/) the
approach we ended up with to get full toolchain functionality out of the
box was to bundle a copy of the MinGW packages we needed, as well as
bundling a copy of dmake.
The approach ActivePerl takes is to not bundle any of these parts, and
expects you to download and install dmake and a compiler seperately, and
we've had a lot of praise from people with Strawberry in particular
because it "just works".
You run the installer, and once it finishes the cpan client works
exactly the same as it does on Unix.
I think you may end up having to take a similar approach with git.
Create a single installer that contains both the git binaries, and
copies of any tools you needed embedded in them (ideally in a seperate
bin directory so that they are NOT in the path, with git referring to
them explicitly).
Adam K
Martin Langhoff wrote:
> On 7/20/07, Adam Kennedy <adam@phase-n.com> wrote:
>> A quick review of native Win32 git provoked by the current conversation
>> amoungst the Perl core maintainers about changing version control
>> systems and whether to go with svn or git (the main two candidates).
>
> Hi Adam,
>
> The problem you hit is that you need the MinGW runtime -- I forget its
> name -- and that will have installed an item in your start menu. It's
> for a terminal that has all the MinGW stuff, you get a nice bash
> shell. I opened, added the GIT install directory to the path, and was
> all set.
>
> I think Sam Vilain (aka mugwump) is going to / at / returning from
> OSCON this week, so he migth take a while to reply. Oh, I see he
> posted in your blog too.
>
> He's been running imports of the Perl dev trees into git, they'll be
> at http://git.catalyst.net.nz/gitweb - fetchable via http at
> http://git.catalyst.net.nz/git/perl.git
>
> My notes above are because I have _just_ been setting up git at
> aclient site on Win32. Took me a bit of fiddling as I hadn't used
> Windows in years, but I got it going...
>
> - needs the mingw runtime - trivial
> - runs pretty well from the commandline - impressed
> - gitk and other Tk-based utilities work great ( _very_ impressed)
> but I had to fixup the wish executable name - minor
> - the http protocol wasn't supported out of the box in the version I
> got, a pain for anon checkouts, and I've seen some discussion about
> that on the list -- unsure here
>
> In terms of http support -- IIRC the problem is handling of forked
> processes, but there might be a way to sidestep the problem. Very
> early versions of git did some odd curl cmdline that Cogito copied.
> Serialised, slow and not one bit as smart as what we do now, but we
> can perhaps reuse some of that.
>
> Some things you point out can be improved once things are more
> polished -- like adding links to gitk and git gui but we'd need to
> sort out how to do this in a directory context. Heh - maybe we need
> one of those explorer.exe extensions...
>
> From a "we are very limited Windows users" POV, no, we don't have
> TortoiseSVN unfortunately. But for developers used to mixed cli/gui
> environments, like I'm sure most Perl developers are, it'll be a
> breeze. It does need a bit of a howto though.
>
>> For reference, the reviewer (me) has 10 years of experience with Perl
>> development across both Windows, Linux, BSD, Solaris, Mac (old and new).
>
> I'm guess in general terms I have a somewhat similar bg -- though I
> don't develop Perl ;-) -- and perhaps it's a bit of luck. I had
> _never_ seen MinGW (I do know CygWin) and perhaps it was a stroke of
> luck that it only took me about 45 minutes to get things going,
> figuring out the stuff noted above.
>
> cheers,
>
>
>
> martin
>
^ permalink raw reply
* Re: [PATCH 3/3] Teach "git branch" about --new-workdir
From: Shawn O. Pearce @ 2007-07-23 5:14 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Johannes Schindelin, Julian Phillips, git
In-Reply-To: <7v1wezohi4.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano <gitster@pobox.com> wrote:
> "Shawn O. Pearce" <spearce@spearce.org> writes:
>
> > I live by new-workdir. I do everything with it. And today I just
> > spent over an hour sorting out cases where my many, many workdirs
> > have different refs than their base repositories, because their
> > packed-refs files are different. Grrrrrrrrrrrrrrrrrr.
> >
> > So we really need to make anyone that edits packed-refs (and
> > maybe also config) resolve the symlink and do the edit in the
> > target directory. Then we can consider adding this workdir thing
> > to core git.
>
> This is actually not limited to packed-refs file, but applies to
> other things as well.
Yes, but most other things aren't symlinks, they are in symlinked
directories. But better to cover it in a single location and have
it Just Work(tm) then to special case things.
> diff --git a/lockfile.c b/lockfile.c
> index fb8f13b..7fc71d9 100644
> --- a/lockfile.c
> +++ b/lockfile.c
> @@ -28,6 +28,17 @@ static void remove_lock_file_on_signal(int signo)
> static int lock_file(struct lock_file *lk, const char *path)
> {
> int fd;
> + struct stat st;
> +
> + if ((!lstat(path, &st)) && S_ISLNK(st.st_mode)) {
> + ssize_t sz;
> + static char target[PATH_MAX];
> + sz = readlink(path, target, sizeof(target));
> + if (sz < 0)
> + warning("Cannot readlink %s", path);
> + else
> + path = target;
> + }
> sprintf(lk->filename, "%s.lock", path);
> fd = open(lk->filename, O_RDWR | O_CREAT | O_EXCL, 0666);
> if (0 <= fd) {
Right. But don't you have to resolve target relative to path?
If the symlink is an absolute path its fine as-is, but if it was
relative its relative to path, not pwd.
--
Shawn.
^ permalink raw reply
* RFC: git pull or git rebase?
From: Michael S. Tsirkin @ 2007-07-23 5:22 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
Hi!
I'm working on several kernel-related projects at the same time:
- some of them are small, and private, so I do a fetch
and rebase to update to Linus' code, to keep history clean
- some of them are larger, and involve several other people,
so I do git pull (the history is messy anyway)
Problem is, I get confused sometimes and do a git pull
instead of git rebase, or vice versa. Of course I can just
reset to ORIG_HEAD when I realise my mistake.
However, I wonder whether this happens to others, too.
Would it make sense to add a branch attribute that says
"do not pull this branch" or "do not rebase this branch"?
Maybe even make git do the right thing automatically,
so that git would look at this attribute and perform
pull or rebase as appropriate?
Thanks,
--
MST
^ permalink raw reply
* Re: [PATCH 3/3] Teach "git branch" about --new-workdir
From: Shawn O. Pearce @ 2007-07-23 5:22 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Johannes Schindelin, Julian Phillips, git
In-Reply-To: <20070723051437.GE32566@spearce.org>
"Shawn O. Pearce" <spearce@spearce.org> wrote:
> Junio C Hamano <gitster@pobox.com> wrote:
> > static int lock_file(struct lock_file *lk, const char *path)
> > {
> > int fd;
> > + struct stat st;
> > +
> > + if ((!lstat(path, &st)) && S_ISLNK(st.st_mode)) {
> > + ssize_t sz;
> > + static char target[PATH_MAX];
> > + sz = readlink(path, target, sizeof(target));
> > + if (sz < 0)
> > + warning("Cannot readlink %s", path);
> > + else
> > + path = target;
> > + }
> > sprintf(lk->filename, "%s.lock", path);
> > fd = open(lk->filename, O_RDWR | O_CREAT | O_EXCL, 0666);
> > if (0 <= fd) {
>
> Right. But don't you have to resolve target relative to path?
> If the symlink is an absolute path its fine as-is, but if it was
> relative its relative to path, not pwd.
It might just be OK to refuse to lock a symlink that isn't absolute.
git-new-workdir already uses absolute paths to setup the symlinks.
--
Shawn.
^ permalink raw reply
* Re: [RFC PATCH] Re: Empty directories...
From: David Kastrup @ 2007-07-23 6:05 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git
In-Reply-To: <85644cf3mf.fsf@lola.goethe.zz>
David Kastrup <dak@gnu.org> writes:
> Jakub Narebski <jnareb@gmail.com> writes:
>
>> I think it would be best implemented by repository config, e.g.
I got sidetracked here: the gitignore stuff has in the dirmod scheme
actually no code or concept overlap with the actual scheme, so it can
be considered a distraction for now and its implementation and
discussion tabled. It has one disadvantage: in order to get
_recursive_ behavior in one tree, one needs to use the "." pattern in
the .gitignore file of the respective directory, and having a
.gitignore file in that directory sort of defeats the idea of not
having .gitignore directories around... Of course, a single
.gitignore file is better than ones one has to distribute through the
tree.
>> core.dirManagement or something like that, which could be set to
>> 1. "autoremove" or something like that, which gives old behavior
>> of untracking directory if it doesn't have any tracked files
>> in it, and removing directory if it doesn't have any files
>> in it.
>
> That's actually not _tracking_ a directory at all, but rather
> maintaining an independent directory in the parallel repository
> universe. No information specific to directories passes the index.
Note: that was merely a comment on semantics, not on the matter.
>> 2. "noremove" or something like that, which changes the behaviour
>> to _never_ untrack directory automatically. This can be done
>> without any changes to 'tree' object nor index. It could be useful
>> for git-svn repositories.
>
> I don't see how this could occur. Automatic _untracking_ would happen
> when one untracks (aka removes) a parent directory. But one would not
> do this while keeping the child.
Correction: if there was a --directory option and one used it for
git-rm (or no -r was given, so just one directory level was effected),
one _could_ untrack stuff on the git side accidentally. And for
something like git-svn, this might be a bad idea. So there is
conceivably a market for an option that never untracks a non-empty
tree.
>> 3. "marked" or something like that, for which you have to explicitely
>> mark directories which are not to be removed when empty.
>
> Equivalent to 1 in my scheme.
At least if scheme 1 does not forbid some _explicit_ way of saying
"track this and I really mean it".
>> 4. "recursive" or something like that, which would automatically mark
>> as "sticky" all subdirectories added in a "sticky" repository.
>
> If they are covered by the add and not just implied by childs. That is,
> git-add a/b
> will not make "a" sticky while
> git-add a
> will make a/b sticky.
Addition: I was thinking so much of my implementation and its
semantics that I did not consider one possibility that you might mean
here:
When adding a/b, always also add a (and the whole hierarchy above it)
automatically as sticky. Namely disallow unsticky directories in the
repository at all. That would mean that
git-add a/b;git-commit -m x;git-rm a/b;git-commit -m x
might not be a noop if a was not in the repository previously: it
would cause a to stay around sticky until removed. With all other
schemes, however, it would cause a to be removed "on behalf of the
user" even if the user intended it to stay around.
Indeed, this scheme might by far be the easiest to understand. Having
no autoremoval at all in levels higher than the deleted level is
something that people might easily understand: delayed removal just
does not happen anymore, and git never deletes a directory unless told
to.
--
David Kastrup, Kriemhildstr. 15, 44793 Bochum
^ permalink raw reply
* What is a reasonable mixed workflow for git/git-cvsserver?
From: Steffen Prohaska @ 2007-07-23 6:28 UTC (permalink / raw)
To: Git Mailing List
I plan to migrate a project from cvs to git and provide
legacy support for cvs users through git-cvsserver. It's
not realistic to teach all people at the same time to use
git. We need some early adopters first. It is also likely
that we start migrating only parts of the repository and
keep some other parts in cvs. I plan to start with parts
for which the benefits of git's support for merging are
most obvious.
What's a reasonable workflow when some people use git and
other people use git-cvsserver simultaneously?
I can imaging that we try the typical git model with
developers who are using git. Developers would clone to
private repositories and ask upstream maintainers to merge.
I'm wondering how to integrate people that will not yet use
git but checkout and commit through git-cvsserver?
We could easily arrange a stable branch for cvs access that
should be accessed read-only. Work merged using git would
be published to this branch. I can also think of specific
topic branches that are created upon request by a git
expert and accessed from cvs through git-cvsserver. Merging
could be done by a git expert using git. An inconvenience
is that people must do a fresh checkout to switch to a
topic branch but can not use 'cvs up -r'. At least this is
my understanding of git-cvsserver's documentation.
I have no clear idea how to deal with the shared rest. We
typically share work in an unsorted way on a cvs branch,
which everyone commits to. I think we'll need a similar
possibility, at least for a transition period. We could
create such a shared branch for access from git-cvsserver.
What is a reasonable way to handle the unsorted commits
from a shared branch in a more git-ish way? I googled a bit
but didn't find a good explanation on the web.
Any ideas, any real-world experiences?
Steffen
^ permalink raw reply
* [RFC] describe: add option --dirty
From: Yasushi SHOJI @ 2007-07-23 6:35 UTC (permalink / raw)
To: git
when --dirty is given, git describe will check the working tree and
append "-dirty" to describe string if the tree is dirty.
---
I'm not sure this is good idea or the current way (using diff-index in
shell script) is more prefered.
one thing I found out is that we s/-/./g the out put of describe
before we append "-dirty". this patch doesn't take care that. so with
this patch what we get is either
v1.5.3-rc2-840-g1c0e2-dirty, or
v1.5.3.rc2.840.g1c0e2.dirty
if we don't put more complecated sed command in GIT-VERSION-GEN.
anyway, comments welcome.
ps. another thing I don't like about this patch is that it changed to
pass prefix down to describe() as the last argument because I was lazy
to call cmd_diff_index() in describe(). if there is better way to do
it, please let me know.
Documentation/git-describe.txt | 5 ++++-
builtin-describe.c | 29 ++++++++++++++++++++++-------
2 files changed, 26 insertions(+), 8 deletions(-)
diff --git a/Documentation/git-describe.txt b/Documentation/git-describe.txt
index f0bcb61..627c4d5 100644
--- a/Documentation/git-describe.txt
+++ b/Documentation/git-describe.txt
@@ -9,7 +9,7 @@ git-describe - Show the most recent tag that is reachable from a commit
SYNOPSIS
--------
'git-describe' [--all] [--tags] [--contains] [--abbrev=<n>]
- [--candidates=<n>] [--debug]
+ [--candidates=<n>] [--debug] [--dirty]
<committish>...
DESCRIPTION
@@ -53,6 +53,9 @@ OPTIONS
being employed to standard error. The tag name will still
be printed to standard out.
+--dirty::
+ Append "-dirty" to describe string if working tree is dirty.
+
EXAMPLES
--------
diff --git a/builtin-describe.c b/builtin-describe.c
index e94f867..bebc16b 100644
--- a/builtin-describe.c
+++ b/builtin-describe.c
@@ -9,11 +9,12 @@
#define MAX_TAGS (FLAG_BITS - 1)
static const char describe_usage[] =
-"git-describe [--all] [--tags] [--contains] [--abbrev=<n>] [--candidates] [--debug] <committish>*";
+"git-describe [--all] [--tags] [--contains] [--abbrev=<n>] [--candidates] [--debug] [--dirty] <committish>*";
static int debug; /* Display lots of verbose info */
static int all; /* Default to annotated tags only */
static int tags; /* But allow any tags if --tags is specified */
+static int check_dirty; /* Append "-dirty" to describe string if working tree is dirty */
static int abbrev = DEFAULT_ABBREV;
static int max_candidates = 10;
@@ -125,7 +126,7 @@ static unsigned long finish_depth_computation(
return seen_commits;
}
-static void describe(const char *arg, int last_one)
+static void describe(const char *arg, int last_one, const char *prefix)
{
unsigned char sha1[20];
struct commit *cmit, *gave_up_on = NULL;
@@ -135,6 +136,7 @@ static void describe(const char *arg, int last_one)
struct possible_tag all_matches[MAX_TAGS];
unsigned int match_cnt = 0, annotated_cnt = 0, cur_match;
unsigned long seen_commits = 0;
+ char *dirty_string = "";
if (get_sha1(arg, sha1))
die("Not a valid object name %s", arg);
@@ -229,12 +231,23 @@ static void describe(const char *arg, int last_one)
sha1_to_hex(gave_up_on->object.sha1));
}
}
+ if (check_dirty) {
+ const char **args = xmalloc(5 * sizeof(char*));
+ args[0] = "diff-index";
+ args[1] = "--quiet";
+ args[2] = "--name-only";
+ args[3] = "HEAD";
+ args[4] = NULL;
+ if (cmd_diff_index(4, args, prefix))
+ dirty_string = "-dirty";
+ }
if (abbrev == 0)
- printf("%s\n", all_matches[0].name->path );
+ printf("%s%s\n", all_matches[0].name->path, dirty_string);
else
- printf("%s-%d-g%s\n", all_matches[0].name->path,
+ printf("%s-%d-g%s%s\n", all_matches[0].name->path,
all_matches[0].depth,
- find_unique_abbrev(cmit->object.sha1, abbrev));
+ find_unique_abbrev(cmit->object.sha1, abbrev),
+ dirty_string);
if (!last_one)
clear_commit_marks(cmit, -1);
@@ -250,6 +263,8 @@ int cmd_describe(int argc, const char **argv, const char *prefix)
if (*arg != '-')
break;
+ else if (!strcmp(arg, "--dirty"))
+ check_dirty = 1;
else if (!strcmp(arg, "--contains"))
contains = 1;
else if (!strcmp(arg, "--debug"))
@@ -290,10 +305,10 @@ int cmd_describe(int argc, const char **argv, const char *prefix)
}
if (argc <= i)
- describe("HEAD", 1);
+ describe("HEAD", 1, prefix);
else
while (i < argc) {
- describe(argv[i], (i == argc - 1));
+ describe(argv[i], (i == argc - 1), prefix);
i++;
}
--
1.5.3.rc2.4.g726f9
^ permalink raw reply related
* [PATCH] describe: Add unlisted option
From: Yasushi SHOJI @ 2007-07-23 6:24 UTC (permalink / raw)
To: git
added unlisted options, --contains, --candidates and --debug, to usage
line. also, prints some info when --contains and --debug are given.
---
Documentation/git-describe.txt | 4 +++-
builtin-describe.c | 5 ++++-
2 files changed, 7 insertions(+), 2 deletions(-)
diff --git a/Documentation/git-describe.txt b/Documentation/git-describe.txt
index ac23e28..f0bcb61 100644
--- a/Documentation/git-describe.txt
+++ b/Documentation/git-describe.txt
@@ -8,7 +8,9 @@ git-describe - Show the most recent tag that is reachable from a commit
SYNOPSIS
--------
-'git-describe' [--all] [--tags] [--contains] [--abbrev=<n>] <committish>...
+'git-describe' [--all] [--tags] [--contains] [--abbrev=<n>]
+ [--candidates=<n>] [--debug]
+ <committish>...
DESCRIPTION
-----------
diff --git a/builtin-describe.c b/builtin-describe.c
index 669110c..e94f867 100644
--- a/builtin-describe.c
+++ b/builtin-describe.c
@@ -9,7 +9,7 @@
#define MAX_TAGS (FLAG_BITS - 1)
static const char describe_usage[] =
-"git-describe [--all] [--tags] [--abbrev=<n>] <committish>*";
+"git-describe [--all] [--tags] [--contains] [--abbrev=<n>] [--candidates] [--debug] <committish>*";
static int debug; /* Display lots of verbose info */
static int all; /* Default to annotated tags only */
@@ -283,6 +283,9 @@ int cmd_describe(int argc, const char **argv, const char *prefix)
args[2] = "--tags";
memcpy(args + 3, argv + i, (argc - i) * sizeof(char*));
args[3 + argc - i] = NULL;
+ if (debug)
+ fprintf(stderr, "redirecting to \"git name-rev\"; "
+ "no searching strategy will be printed\n");
return cmd_name_rev(3 + argc - i, args, prefix);
}
--
1.5.3.rc2.4.g726f9
^ permalink raw reply related
* Re: [RFC] describe: add option --dirty
From: Junio C Hamano @ 2007-07-23 6:56 UTC (permalink / raw)
To: Yasushi SHOJI; +Cc: git
In-Reply-To: <87odi3mxtl.wl@mail2.atmark-techno.com>
Yasushi SHOJI <yashi@atmark-techno.com> writes:
> when --dirty is given, git describe will check the working tree and
> append "-dirty" to describe string if the tree is dirty.
> ---
> I'm not sure this is good idea or the current way (using diff-index in
> shell script) is more prefered.
Hmph, this makes sense _ONLY_ for HEAD, doesn't it?
IOW, what should this output?
$ git checkout v1.5.0 ;# detached HEAD
$ git reset --hard ;# clean slate
$ echo >>Makefile ;# not anymore
$ git describe --dirty v1.4.0^1
Should it say "v1.4.0-rc2-156-g0a8f4f0-dirty"? The dirtiness
does not have anything to do with commit v1.4.0^1, so...
^ permalink raw reply
* Re: [RFC] describe: add option --dirty
From: Shawn O. Pearce @ 2007-07-23 6:59 UTC (permalink / raw)
To: Yasushi SHOJI; +Cc: git
In-Reply-To: <87odi3mxtl.wl@mail2.atmark-techno.com>
Yasushi SHOJI <yashi@atmark-techno.com> wrote:
> when --dirty is given, git describe will check the working tree and
> append "-dirty" to describe string if the tree is dirty.
> ---
> I'm not sure this is good idea or the current way (using diff-index in
> shell script) is more prefered.
Yea, I'm actually torn on this. A lot of people like the output of
git-describe for versions (where a lot is at least me!) and yet I
also always tack in the -dirty if the directory is dirty according
to diff-index. So having this built right into git-describe is
actually quite handy. It simplifies a little bit of build rule
logic.
> diff --git a/Documentation/git-describe.txt b/Documentation/git-describe.txt
> @@ -53,6 +53,9 @@ OPTIONS
> being employed to standard error. The tag name will still
> be printed to standard out.
>
> +--dirty::
> + Append "-dirty" to describe string if working tree is dirty.
> +
It requires a working directory. Running this in a bare repository
with --dirty won't work. You might want to discuss that in the
documentation.
> diff --git a/builtin-describe.c b/builtin-describe.c
> @@ -229,12 +231,23 @@ static void describe(const char *arg, int last_one)
> sha1_to_hex(gave_up_on->object.sha1));
> }
> }
> + if (check_dirty) {
> + const char **args = xmalloc(5 * sizeof(char*));
> + args[0] = "diff-index";
> + args[1] = "--quiet";
> + args[2] = "--name-only";
> + args[3] = "HEAD";
> + args[4] = NULL;
> + if (cmd_diff_index(4, args, prefix))
> + dirty_string = "-dirty";
> + }
So if I describe two different commits at once in the same working
tree you are going to run diff-index twice? That's not a great idea.
The outcome of diff-index won't change between those two commits.
Better to compute this up front before calling the describe()
function, and instead of passing in prefix pass in dirty_string.
Or just make it a global, like you did to the option flag.
> if (abbrev == 0)
> - printf("%s\n", all_matches[0].name->path );
> + printf("%s%s\n", all_matches[0].name->path, dirty_string);
> else
> - printf("%s-%d-g%s\n", all_matches[0].name->path,
> + printf("%s-%d-g%s%s\n", all_matches[0].name->path,
> all_matches[0].depth,
> - find_unique_abbrev(cmit->object.sha1, abbrev));
> + find_unique_abbrev(cmit->object.sha1, abbrev),
> + dirty_string);
>
> if (!last_one)
> clear_commit_marks(cmit, -1);
So if HEAD is exactly matching a tag you don't output the -dirty
suffix, even if the working tree is dirty? That's counter to the
documentation above. See l.150-154, we break out of the describe
function very quickly if there is a tag on the input commit.
--
Shawn.
^ permalink raw reply
* Re: [PATCH] describe: Add unlisted option
From: Shawn O. Pearce @ 2007-07-23 7:03 UTC (permalink / raw)
To: Yasushi SHOJI; +Cc: git
In-Reply-To: <87sl7fmyca.wl@mail2.atmark-techno.com>
Yasushi SHOJI <yashi@atmark-techno.com> wrote:
> added unlisted options, --contains, --candidates and --debug, to usage
> line. also, prints some info when --contains and --debug are given.
That makes sense. Especially telling the user why --debug --contains
doesn't actually print anything. ;-)
Originally I left out --candidates and --debug when I wrote the code
for them as I thought they were a tad too internal for casual use.
But maybe it makes sense to include them in the usage string.
Acked-by: Shawn O. Pearce <spearce@spearce.org>
--
Shawn.
^ permalink raw reply
* Re: [RFC] describe: add option --dirty
From: Shawn O. Pearce @ 2007-07-23 7:08 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Yasushi SHOJI, git
In-Reply-To: <7vsl7fmwud.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano <gitster@pobox.com> wrote:
> Yasushi SHOJI <yashi@atmark-techno.com> writes:
>
> > when --dirty is given, git describe will check the working tree and
> > append "-dirty" to describe string if the tree is dirty.
> > ---
> > I'm not sure this is good idea or the current way (using diff-index in
> > shell script) is more prefered.
>
> Hmph, this makes sense _ONLY_ for HEAD, doesn't it?
>
> IOW, what should this output?
>
> $ git checkout v1.5.0 ;# detached HEAD
> $ git reset --hard ;# clean slate
> $ echo >>Makefile ;# not anymore
> $ git describe --dirty v1.4.0^1
>
> Should it say "v1.4.0-rc2-156-g0a8f4f0-dirty"? The dirtiness
> does not have anything to do with commit v1.4.0^1, so...
Good catch. I had that in my mind when I was reading the patch,
but failed to mention it. I blame metze on #git, he interrupted
my train of thought. ;-)
I think the answer is the user passes either --dirty OR one or
more commit-ish. But not --dirty and a commit-ish. In other words
you can either describe the working directory state, or a commit,
but not both at once. Which also neatly solves my issue with
diff-index running more than once.
--
Shawn.
^ permalink raw reply
* [RFH] 3way still has D/F conflict problems...
From: Junio C Hamano @ 2007-07-23 7:22 UTC (permalink / raw)
To: git
The four commit series starting at 4c4caaf fixed a few D/F
conflict case in merge recursive.
4c4caaf... Treat D/F conflict entry more carefully in unpack-tree...
ac7f0f4... merge-recursive: do not barf on "to be removed" entries.
4d50895... merge-recursive: handle D/F conflict case more carefully.
885b981... t3030: merge-recursive backend test.
However this ended up regressed the following case (don't bother
bisecting, it will point at 4c4caaf).
The test case starts with a tree with a directory at D/,
one branch (master) modifies files in it, while the other branch
(side) makes a bunch of rename and has a blob at D.A, D, and D0C
Yes, this does not trigger if you change D.A to DxA (anything
that does not sort before D/ in the index).
Anybody interested in figuring out how to fix unpack-trees.c
without breaking the problem the above series fixed?
---
t/t3031-df-3way.sh | 58 ++++++++++++++++++++++++++++++++++++++++++++++++++++
1 files changed, 58 insertions(+), 0 deletions(-)
create mode 100755 t/t3031-df-3way.sh
diff --git a/t/t3031-df-3way.sh b/t/t3031-df-3way.sh
new file mode 100755
index 0000000..42548d2
--- /dev/null
+++ b/t/t3031-df-3way.sh
@@ -0,0 +1,58 @@
+#!/bin/sh
+
+test_description='D/F conflicting threeway merge'
+
+. ./test-lib.sh
+
+fill () {
+ cnt="$1"
+ shift
+ while test "$cnt" -ge 0
+ do
+ cnt=$(( $cnt - 1 ))
+ for line
+ do
+ echo "$line"
+ done
+ done
+}
+
+T=D
+
+test_expect_success 'setup' '
+
+ mkdir D &&
+ fill 50 "Tis true without lying, certain & most true." >D/A &&
+ fill 50 "The Sun is its father, the moon its mother," >D/B &&
+ fill 50 "the wind hath carried it in its belly, the earth its nourse." >D/C &&
+ git add D/A D/B D/C &&
+ test_tick &&
+ git commit -m "Initial" &&
+
+ git tag initial &&
+ git branch side &&
+
+ echo "It has the Sun for father and the Moon for mother:" >>D/B &&
+ test_tick &&
+ git commit -a -m "master changes in-place" &&
+
+ git checkout side &&
+ echo "Truth! Certainty! That in which there is no doubt!" >D.A &&
+ cat D/A >>D.A &&
+ echo "Its father is the Sun and its mother the Moon." >B &&
+ cat D/B >>B &&
+ mv D/C D0C &&
+ rm -rf D &&
+ mv B $T &&
+ git add D.A $T D0C &&
+ test_tick &&
+ git commit -a -m "side moves and makes changes"
+'
+
+test_expect_success 'threeway' '
+
+ git read-tree -m initial side master
+
+'
+
+test_done
^ permalink raw reply related
* Re: [PATCH] describe: Add unlisted option
From: Junio C Hamano @ 2007-07-23 7:41 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: Yasushi SHOJI, git
In-Reply-To: <20070723070308.GH32566@spearce.org>
"Shawn O. Pearce" <spearce@spearce.org> writes:
> Yasushi SHOJI <yashi@atmark-techno.com> wrote:
>> added unlisted options, --contains, --candidates and --debug, to usage
>> line. also, prints some info when --contains and --debug are given.
>
> That makes sense. Especially telling the user why --debug --contains
> doesn't actually print anything. ;-)
>
> Originally I left out --candidates and --debug when I wrote the code
> for them as I thought they were a tad too internal for casual use.
> But maybe it makes sense to include them in the usage string.
I was actually going to suggest removing these options, that
were primarily meant for debugging and tweaking while we figure
out what the optimum default should be. Do you think they are
worth keeping?
^ permalink raw reply
* Re: [RFC PATCH] Re: Empty directories...
From: David Kastrup @ 2007-07-23 7:45 UTC (permalink / raw)
To: git
In-Reply-To: <85ps2jeju9.fsf@lola.goethe.zz>
David Kastrup <dak@gnu.org> writes:
> Addition: I was thinking so much of my implementation and its
> semantics that I did not consider one possibility that you might mean
> here:
>
> When adding a/b, always also add a (and the whole hierarchy above it)
> automatically as sticky. Namely disallow unsticky directories in the
> repository at all. That would mean that
>
> git-add a/b;git-commit -m x;git-rm a/b;git-commit -m x
>
> might not be a noop if a was not in the repository previously: it
> would cause a to stay around sticky until removed. With all other
> schemes, however, it would cause a to be removed "on behalf of the
> user" even if the user intended it to stay around.
>
> Indeed, this scheme might by far be the easiest to understand.
> Having no autoremoval at all in levels higher than the deleted level
> is something that people might easily understand: delayed removal
> just does not happen anymore, and git never deletes a directory
> unless told to.
And of course, it would be a nuisance for people managing a
patch-based workflow. But those can actually easily set the
repository preferences differently, and even
find -type d -empty -delete
is not too hard to do. So it would even be feasible as default.
But I think that in practice, the "track only what has been added
recursively" approach is a good default. And since patches without
dir information never add anything recursively, it would mostly keep
the directories clean.
--
David Kastrup
^ permalink raw reply
* Re: [PATCH] describe: Add unlisted option
From: Shawn O. Pearce @ 2007-07-23 7:47 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Yasushi SHOJI, git
In-Reply-To: <7vabtnmusm.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano <gitster@pobox.com> wrote:
> "Shawn O. Pearce" <spearce@spearce.org> writes:
> > Originally I left out --candidates and --debug when I wrote the code
> > for them as I thought they were a tad too internal for casual use.
> > But maybe it makes sense to include them in the usage string.
>
> I was actually going to suggest removing these options, that
> were primarily meant for debugging and tweaking while we figure
> out what the optimum default should be. Do you think they are
> worth keeping?
Yea, I do. I'd like to keep them in the code as sometimes I do
look at their output. I'll even help maintain them, because they
change oh so often. ;-)
But if you really want them gone, I won't stop you.
--
Shawn.
^ permalink raw reply
* Re: [RFC] describe: add option --dirty
From: Yasushi SHOJI @ 2007-07-23 7:54 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: Junio C Hamano, git
In-Reply-To: <20070723070818.GI32566@spearce.org>
At Mon, 23 Jul 2007 03:08:18 -0400,
Shawn O. Pearce wrote:
>
> Junio C Hamano <gitster@pobox.com> wrote:
> > Yasushi SHOJI <yashi@atmark-techno.com> writes:
> >
> > > when --dirty is given, git describe will check the working tree and
> > > append "-dirty" to describe string if the tree is dirty.
> > > ---
> > > I'm not sure this is good idea or the current way (using diff-index in
> > > shell script) is more prefered.
> >
> > Hmph, this makes sense _ONLY_ for HEAD, doesn't it?
> >
> > IOW, what should this output?
> >
> > $ git checkout v1.5.0 ;# detached HEAD
> > $ git reset --hard ;# clean slate
> > $ echo >>Makefile ;# not anymore
> > $ git describe --dirty v1.4.0^1
> >
> > Should it say "v1.4.0-rc2-156-g0a8f4f0-dirty"? The dirtiness
> > does not have anything to do with commit v1.4.0^1, so...
>
> Good catch. I had that in my mind when I was reading the patch,
> but failed to mention it. I blame metze on #git, he interrupted
> my train of thought. ;-)
I knew the issue be failed to note about it. Thanks.
> I think the answer is the user passes either --dirty OR one or
> more commit-ish. But not --dirty and a commit-ish. In other words
> you can either describe the working directory state, or a commit,
> but not both at once. Which also neatly solves my issue with
> diff-index running more than once.
So the point is would it be worth implementing in usable form?
>From the comments I'd add an option "--workinig-tree" instead of
--dirty to describe the working tree. because that, the special case,
is what we want after all,
synopsis would be:
SYNOPSIS
--------
'git-describe' [--all] [--tags] [--contains] [--abbrev=<n>]
[--candidates=<n>] [--debug]
--working-tree | <committish>...
:
:
--working-tree::
Describe the working tree instead of committishes. if the
working tree is dirty, the describe string will have "-dirty"
appended.
As you can assume from the name, this option requires working
tree; running it on a bare repository will fail.
what do you think?
--
yashi
^ permalink raw reply
* git-apply versus git-am
From: Sean Kelley @ 2007-07-23 7:54 UTC (permalink / raw)
To: git
Why doesn't git-apply include an option for a signoff line like git-am?
git-applymbox /tmp/mbox ~/.signoff
Or am I missing something? (most likely the case!)
Sean
^ permalink raw reply
* Re: [PATCH] Add a 1-second sleep to git-cvsexportcommit test
From: Simon 'corecode' Schubert @ 2007-07-23 7:55 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Jason Sewall, git, raa.lkml
In-Reply-To: <7vd4yjoi2w.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano wrote:
> It may be that we may want to fix this inside cvsexportcommit
> itself, instead of working it around in the tests. If somebody
> tries to push more than one commit from git using two
> cvsexportcommit in a row, he would need to make sure that the
> second run happens one or more seconds after the first run,
> otherwise he will see the exact corruption in real life.
Ah, now I see the problem. The timestamp in the CVS/Entries is the same (because it only has second granularity), so cvs commit won't consider it as changed.
That's the reason why CVS usually waits until the second turns after a "update" (obviously not after a "commit"). So we could either turn back the timestamp in the Entries file (ugly) or simply wait until the second turns. Given the overall cvs performance, this won't be a big issue, I guess.
cheers
simon
--
Serve - BSD +++ RENT this banner advert +++ ASCII Ribbon /"\
Work - Mac +++ space for low €€€ NOW!1 +++ Campaign \ /
Party Enjoy Relax | http://dragonflybsd.org Against HTML \
Dude 2c 2 the max ! http://golden-apple.biz Mail + News / \
^ permalink raw reply
* Re: [RFC] describe: add option --dirty
From: Shawn O. Pearce @ 2007-07-23 7:58 UTC (permalink / raw)
To: Yasushi SHOJI; +Cc: Junio C Hamano, git
In-Reply-To: <87lkd7mu71.wl@mail2.atmark-techno.com>
Yasushi SHOJI <yashi@atmark-techno.com> wrote:
> From the comments I'd add an option "--workinig-tree" instead of
> --dirty to describe the working tree. because that, the special case,
> is what we want after all,
>
> synopsis would be:
>
> SYNOPSIS
> --------
> 'git-describe' [--all] [--tags] [--contains] [--abbrev=<n>]
> [--candidates=<n>] [--debug]
> --working-tree | <committish>...
> :
> :
> --working-tree::
> Describe the working tree instead of committishes. if the
> working tree is dirty, the describe string will have "-dirty"
> appended.
>
> As you can assume from the name, this option requires working
> tree; running it on a bare repository will fail.
>
> what do you think?
That's reasonable. It seems like a lot of work in core Git just
to avoid a small chunk of shell, but I think almost everyone has
that same small chunk of shell in their build scripts...
--
Shawn.
^ permalink raw reply
* Re: git-apply versus git-am
From: Alex Riesen @ 2007-07-23 8:31 UTC (permalink / raw)
To: Sean Kelley; +Cc: git
In-Reply-To: <a2e879e50707230054m60d45293ua1d57887367914c1@mail.gmail.com>
On 7/23/07, Sean Kelley <svk.sweng@gmail.com> wrote:
> Why doesn't git-apply include an option for a signoff line like git-am?
>
> git-applymbox /tmp/mbox ~/.signoff
>
> Or am I missing something? (most likely the case!)
>
git apply is just a safer patch(1). They serve different purpose.
^ permalink raw reply
* Re: [PATCH 3/3] Teach "git branch" about --new-workdir
From: Julian Phillips @ 2007-07-23 8:31 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git, gitster
In-Reply-To: <Pine.LNX.4.64.0707230000020.14781@racer.site>
On Mon, 23 Jul 2007, Johannes Schindelin wrote:
> Hi,
>
> On Sun, 22 Jul 2007, Julian Phillips wrote:
>
>> On Sun, 22 Jul 2007, Johannes Schindelin wrote:
>>
>>> Well, I am really not interested in shooting myself in the foot, and
>>> having that option in checkout would make that much more likely. So I
>>> really, really want to have this in git-branch.
>>
>> Fair enough. Your patch - so you get to choose. I don't have any
>> strong objections (and no power to express any if I did :P) - just
>> airing my POV ;)
>
> ;-)
>
> In related news, you got me convinced that my "solution" is not
> sufficient. So I guess this patch has to wait until after 1.5.3 _and_
> after we convinced Junio to put his BASE index extension in again.
>
> FWIW once git-checkout is builtin, I'll add "--new-workdir" for it. Deal?
Sounds good to me. Even gives me some motivation to see checkout a
builtin sooner rather than later ;)
--
Julian
---
Logic is the chastity belt of the mind!
^ permalink raw reply
* Re: [RFC] describe: add option --dirty
From: Yasushi SHOJI @ 2007-07-23 8:52 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: Junio C Hamano, git
In-Reply-To: <20070723075834.GK32566@spearce.org>
At Mon, 23 Jul 2007 03:58:34 -0400,
Shawn O. Pearce wrote:
>
> Yasushi SHOJI <yashi@atmark-techno.com> wrote:
> > From the comments I'd add an option "--workinig-tree" instead of
> > --dirty to describe the working tree. because that, the special case,
> > is what we want after all,
> >
> > synopsis would be:
> >
> > SYNOPSIS
> > --------
> > 'git-describe' [--all] [--tags] [--contains] [--abbrev=<n>]
> > [--candidates=<n>] [--debug]
> > --working-tree | <committish>...
> > :
> > :
> > --working-tree::
> > Describe the working tree instead of committishes. if the
> > working tree is dirty, the describe string will have "-dirty"
> > appended.
> >
> > As you can assume from the name, this option requires working
> > tree; running it on a bare repository will fail.
> >
> > what do you think?
>
> That's reasonable. It seems like a lot of work in core Git just
> to avoid a small chunk of shell, but I think almost everyone has
> that same small chunk of shell in their build scripts...
it's not that much. here it is. hope you like it.
>From 25acf0fad4866b87998b51f1e66f540f2bcc5f0d Mon Sep 17 00:00:00 2001
From: Yasushi SHOJI <yashi@atmark-techno.com>
Date: Mon, 23 Jul 2007 17:49:11 +0900
Subject: [PATCH] describe: add a new option --working-tree
Many people like to use git-describe for version number, and yet
people always tack in the -dirty if the directory is dirty according
to diff-index. So this patch tries to scratch the itchy.
With --working-tree, the command will describe the working tree
instead of committishes. If the working tree is dirty, the describe
string will have "-dirty" appended.
As you can assume from the name, this option requires working tree.
running it on a bare repository will fail.
Signed-off-by: Yasushi SHOJI <yashi@atmark-techno.com>
---
Documentation/git-describe.txt | 10 +++++++++-
builtin-describe.c | 38 +++++++++++++++++++++++++++++++-------
2 files changed, 40 insertions(+), 8 deletions(-)
diff --git a/Documentation/git-describe.txt b/Documentation/git-describe.txt
index f0bcb61..d9b1550 100644
--- a/Documentation/git-describe.txt
+++ b/Documentation/git-describe.txt
@@ -10,7 +10,7 @@ SYNOPSIS
--------
'git-describe' [--all] [--tags] [--contains] [--abbrev=<n>]
[--candidates=<n>] [--debug]
- <committish>...
+ --working-tree | <committish>...
DESCRIPTION
-----------
@@ -53,6 +53,14 @@ OPTIONS
being employed to standard error. The tag name will still
be printed to standard out.
+--working-tree::
+ Describe the working tree instead of committishes. if the
+ working tree is dirty, the describe string will have "-dirty"
+ appended.
+
+ As you can assume from the name, this option requires a
+ working tree. Running it on a bare repository will fail.
+
EXAMPLES
--------
diff --git a/builtin-describe.c b/builtin-describe.c
index e94f867..1c58480 100644
--- a/builtin-describe.c
+++ b/builtin-describe.c
@@ -9,11 +9,12 @@
#define MAX_TAGS (FLAG_BITS - 1)
static const char describe_usage[] =
-"git-describe [--all] [--tags] [--contains] [--abbrev=<n>] [--candidates] [--debug] <committish>*";
+"git-describe [--all] [--tags] [--contains] [--abbrev=<n>] [--candidates] [--debug] --working-tree | <committish>*";
static int debug; /* Display lots of verbose info */
static int all; /* Default to annotated tags only */
static int tags; /* But allow any tags if --tags is specified */
+static int working_tree;/* describe the working tree instead of committish */
static int abbrev = DEFAULT_ABBREV;
static int max_candidates = 10;
@@ -125,7 +126,7 @@ static unsigned long finish_depth_computation(
return seen_commits;
}
-static void describe(const char *arg, int last_one)
+static void describe(const char *arg, int last_one, int dirty)
{
unsigned char sha1[20];
struct commit *cmit, *gave_up_on = NULL;
@@ -135,6 +136,7 @@ static void describe(const char *arg, int last_one)
struct possible_tag all_matches[MAX_TAGS];
unsigned int match_cnt = 0, annotated_cnt = 0, cur_match;
unsigned long seen_commits = 0;
+ char *dirty_string = dirty ? "-dirty" : "";
if (get_sha1(arg, sha1))
die("Not a valid object name %s", arg);
@@ -230,11 +232,12 @@ static void describe(const char *arg, int last_one)
}
}
if (abbrev == 0)
- printf("%s\n", all_matches[0].name->path );
+ printf("%s%s\n", all_matches[0].name->path, dirty_string);
else
- printf("%s-%d-g%s\n", all_matches[0].name->path,
+ printf("%s-%d-g%s%s\n", all_matches[0].name->path,
all_matches[0].depth,
- find_unique_abbrev(cmit->object.sha1, abbrev));
+ find_unique_abbrev(cmit->object.sha1, abbrev),
+ dirty_string);
if (!last_one)
clear_commit_marks(cmit, -1);
@@ -244,12 +247,15 @@ int cmd_describe(int argc, const char **argv, const char *prefix)
{
int i;
int contains = 0;
+ int dirty = 0;
for (i = 1; i < argc; i++) {
const char *arg = argv[i];
if (*arg != '-')
break;
+ else if (!strcmp(arg, "--working-tree"))
+ working_tree = 1;
else if (!strcmp(arg, "--contains"))
contains = 1;
else if (!strcmp(arg, "--debug"))
@@ -276,6 +282,24 @@ int cmd_describe(int argc, const char **argv, const char *prefix)
save_commit_buffer = 0;
+ if (working_tree) {
+ const char **args;
+
+ if (!is_inside_work_tree() || is_inside_git_dir())
+ die("%s with --working-tree must be run in a working tree", argv[0]);
+ if (argc > i)
+ die("--working-tree doesn't take any committish\n");
+
+ args = xmalloc(5 * sizeof(char*));
+ args[0] = "diff-index";
+ args[1] = "--quiet";
+ args[2] = "--name-only";
+ args[3] = "HEAD";
+ args[4] = NULL;
+ if (cmd_diff_index(4, args, prefix))
+ dirty = 1;
+ }
+
if (contains) {
const char **args = xmalloc((4 + argc - i) * sizeof(char*));
args[0] = "name-rev";
@@ -290,10 +314,10 @@ int cmd_describe(int argc, const char **argv, const char *prefix)
}
if (argc <= i)
- describe("HEAD", 1);
+ describe("HEAD", 1, dirty);
else
while (i < argc) {
- describe(argv[i], (i == argc - 1));
+ describe(argv[i], (i == argc - 1), dirty);
i++;
}
--
1.5.3.rc2.4.g726f9
^ permalink raw reply related
* Re: [PATCH] describe: Add unlisted option
From: Junio C Hamano @ 2007-07-23 8:54 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: Yasushi SHOJI, git
In-Reply-To: <20070723074736.GJ32566@spearce.org>
"Shawn O. Pearce" <spearce@spearce.org> writes:
>> I was actually going to suggest removing these options, that
>> were primarily meant for debugging and tweaking while we figure
>> out what the optimum default should be. Do you think they are
>> worth keeping?
>
> Yea, I do. I'd like to keep them in the code as sometimes I do
> look at their output. I'll even help maintain them, because they
> change oh so often. ;-)
>
> But if you really want them gone, I won't stop you.
Nah, I already noticed your Ack and inferred that you would want
to keep them. Haven't applied the patches yet, though.
^ 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