* [PATCH, v2] tag: implement --[no-]strip option
From: Kirill A. Shutemov @ 2011-11-14 21:43 UTC (permalink / raw)
To: git; +Cc: Junio C Hamano, Kirill A. Shutemov
From: "Kirill A. Shutemov" <kirill@shutemov.name>
--strip::
Remove from tag message lines staring with '#', trailing spaces
from every line and empty lines from the beginning and end.
Enabled by default. Use --no-strip to overwrite the behaviour.
--no-strip is useful if you want to take a tag message as-is, without
any stripping.
Signed-off-by: Kirill A. Shutemov <kirill@shutemov.name>
---
Documentation/git-tag.txt | 5 +++++
builtin/tag.c | 41 ++++++++++++++++++++++++++++-------------
2 files changed, 33 insertions(+), 13 deletions(-)
diff --git a/Documentation/git-tag.txt b/Documentation/git-tag.txt
index c83cb13..dbb76a6 100644
--- a/Documentation/git-tag.txt
+++ b/Documentation/git-tag.txt
@@ -99,6 +99,11 @@ OPTIONS
Implies `-a` if none of `-a`, `-s`, or `-u <key-id>`
is given.
+--strip::
+ Remove from tag message lines staring with '#', trailing spaces
+ from every line and empty lines from the beginning and end.
+ Enabled by default. Use --no-strip to overwrite the behaviour.
+
<tagname>::
The name of the tag to create, delete, or describe.
The new tag name must pass all checks defined by
diff --git a/builtin/tag.c b/builtin/tag.c
index 9b6fd95..05a1fd4 100644
--- a/builtin/tag.c
+++ b/builtin/tag.c
@@ -319,8 +319,14 @@ static int build_tag_object(struct strbuf *buf, int sign, unsigned char *result)
return 0;
}
+struct create_tag_options {
+ unsigned int message;
+ unsigned int sign;
+ unsigned int strip;
+};
+
static void create_tag(const unsigned char *object, const char *tag,
- struct strbuf *buf, int message, int sign,
+ struct strbuf *buf, struct create_tag_options *opt,
unsigned char *prev, unsigned char *result)
{
enum object_type type;
@@ -345,7 +351,7 @@ static void create_tag(const unsigned char *object, const char *tag,
if (header_len > sizeof(header_buf) - 1)
die(_("tag header too big."));
- if (!message) {
+ if (!opt->message) {
int fd;
/* write the template message before editing: */
@@ -356,7 +362,7 @@ static void create_tag(const unsigned char *object, const char *tag,
if (!is_null_sha1(prev))
write_tag_body(fd, prev);
- else
+ else if (opt->strip)
write_or_die(fd, _(tag_template), strlen(_(tag_template)));
close(fd);
@@ -367,14 +373,15 @@ static void create_tag(const unsigned char *object, const char *tag,
}
}
- stripspace(buf, 1);
+ if (opt->strip)
+ stripspace(buf, 1);
- if (!message && !buf->len)
+ if (opt->message && !buf->len)
die(_("no tag message?"));
strbuf_insert(buf, 0, header_buf, header_len);
- if (build_tag_object(buf, sign, result) < 0) {
+ if (build_tag_object(buf, opt->sign, result) < 0) {
if (path)
fprintf(stderr, _("The tag message has been left in %s\n"),
path);
@@ -423,8 +430,13 @@ int cmd_tag(int argc, const char **argv, const char *prefix)
const char *object_ref, *tag;
struct ref_lock *lock;
- int annotate = 0, sign = 0, force = 0, lines = -1,
- list = 0, delete = 0, verify = 0;
+ struct create_tag_options opt = {
+ .sign = 0,
+ .strip = 1,
+ };
+
+ int annotate = 0, force = 0, lines = -1, list = 0,
+ delete = 0, verify = 0;
const char *msgfile = NULL, *keyid = NULL;
struct msg_arg msg = { 0, STRBUF_INIT };
struct commit_list *with_commit = NULL;
@@ -442,7 +454,9 @@ int cmd_tag(int argc, const char **argv, const char *prefix)
OPT_CALLBACK('m', "message", &msg, "message",
"tag message", parse_msg_arg),
OPT_FILENAME('F', "file", &msgfile, "read message from file"),
- OPT_BOOLEAN('s', "sign", &sign, "annotated and GPG-signed tag"),
+ OPT_BOOLEAN('s', "sign", &opt.sign, "annotated and GPG-signed tag"),
+ OPT_BOOLEAN(0, "strip", &opt.strip,
+ "turn off tag message stripping"),
OPT_STRING('u', "local-user", &keyid, "key-id",
"use another key to sign the tag"),
OPT__FORCE(&force, "replace the tag if exists"),
@@ -462,10 +476,10 @@ int cmd_tag(int argc, const char **argv, const char *prefix)
argc = parse_options(argc, argv, prefix, options, git_tag_usage, 0);
if (keyid) {
- sign = 1;
+ opt.sign = 1;
set_signingkey(keyid);
}
- if (sign)
+ if (opt.sign)
annotate = 1;
if (argc == 0 && !(delete || verify))
list = 1;
@@ -523,9 +537,10 @@ int cmd_tag(int argc, const char **argv, const char *prefix)
else if (!force)
die(_("tag '%s' already exists"), tag);
+ opt.message = msg.given || msgfile;
+
if (annotate)
- create_tag(object, tag, &buf, msg.given || msgfile,
- sign, prev, object);
+ create_tag(object, tag, &buf, &opt, prev, object);
lock = lock_any_ref_for_update(ref.buf, prev, 0);
if (!lock)
--
1.7.7.2
^ permalink raw reply related
* Re: Git: Unexpected behaviour?
From: Jakub Narebski @ 2011-11-14 21:33 UTC (permalink / raw)
To: Martin von Zweigbergk; +Cc: git, Junio C Hamano, J.V.
In-Reply-To: <CAOeW2eEUbvd0eJHjNfbvi9QnDiUO=mFA9rrKsjv8Yu0_QiPgSw@mail.gmail.com>
Martin von Zweigbergk <martin.von.zweigbergk@gmail.com> writes:
> On Sat, Nov 12, 2011 at 11:37 AM, Junio C Hamano <gitster@pobox.com> wrote:
> > "J.V." <jvsrvcs@gmail.com> writes:
> >
> > > OK so "work tree" is a new term for me. I thought we were in isolated
> > > sandboxes called "branches" and changes made in a branch would stay in
> > > that branch regardless.
That would be the default and only solution if each branch was checked
out to a separate working directory.
You can do that in git using git-new-worktree script from contrib.
> > Do not think of "branches" as isolated _sandboxes_.
> >
> > Rather, "branches" are where the independent states are to be _recorded_.
Branches are lines of development, and are about _comitted_ changes.
This means that when switching branches "in place", un-committed
changes are not on any branch.
> I think I was confused about this when learning Git too. I friend of
> mine made the following argument, which I agree with and which I haven
> seen on the list before:
>
> Either you want the modifications to stay on the branch, or you want
> them to carry over to the branch you are checking out. In the former
> case, you would want Git to fail if there are modifications (that you
> might have forgotten you made). In the latter case, you would want
> "git checkout -m". The current behavior is somewhere in between. It is
> not clear to me if there is a use case where the current behavior is
> better (from the user's point of view) than either failing or
> "checkout -m".
The "checkout -m" behavior is unsafe; you can land in a state where it
would be difficult to revert, and could lose your changes. The
default behavior of switching branches is to carry over changes if it
is safe to do so.
> It is obviously too late to change this now, though.
Well, we could in theory add knob that would stash changes when
switching to branch, and unstash when switching to branch.
--
Jakub Narębski
^ permalink raw reply
* Re: Git: Unexpected behaviour?
From: Junio C Hamano @ 2011-11-14 20:55 UTC (permalink / raw)
To: Martin von Zweigbergk; +Cc: git, J.V.
In-Reply-To: <CAOeW2eEUbvd0eJHjNfbvi9QnDiUO=mFA9rrKsjv8Yu0_QiPgSw@mail.gmail.com>
Martin von Zweigbergk <martin.von.zweigbergk@gmail.com> writes:
> Either you want the modifications to stay on the branch, or you want
> them to carry over to the branch you are checking out. In the former
> case, you would want Git to fail if there are modifications (that you
> might have forgotten you made). In the latter case, you would want
> "git checkout -m". The current behavior is somewhere in between. It is
> not clear to me if there is a use case where the current behavior is
> better (from the user's point of view) than either failing or
> "checkout -m".
Current behaviour is deliberately made safe because "checkout -m" may end
up forcing you to resolve a 3-way conflict you may not be prepared to do
correctly at your first attempt. Stopping and refusing to check out the
other branch gives you the choice to create a temporary stash-away commit
either on a current branch, or a temporary branch you create with "git
checkout -b temp && git commit" before switching to the target branch to
attempt to port the change over with "git cherry-pick @{-1}", which you
_can_ redo if you screw up conflict resolution and want to start over.
If you are confident that your local changes are trivial that you can
reproduce it even if you screw up your conflict resolution attempt, then
you can choose to run "checkout -m". If we made it the default, you will
lose this safety.
On the other hand, if you do *not* want to carry over the change when
checking out a different branch, you can easily stash-away the changes.
^ permalink raw reply
* Re: feature request: git annotate -w like git blame -w
From: Junio C Hamano @ 2011-11-14 20:49 UTC (permalink / raw)
To: Jakub Narebski; +Cc: Raoul Bhatia [IPAX], git
In-Reply-To: <m3sjlun4o9.fsf@localhost.localdomain>
Jakub Narebski <jnareb@gmail.com> writes:
> "Raoul Bhatia [IPAX]" <r.bhatia@ipax.at> writes:
>
>> is it possible to add a "git annotate -w" option like git blame has?
>
> Why not use "git blame -c -w"? `-c' turns on annotate-compatibile
> output.
>
> From git-annotate(1) manpage:
>
> The only difference between this command and git-blame(1) is that they use
> slightly different output formats, and this command exists only for back-
> ward compatibility to support existing scripts, and provide a more familiar
> command name for people coming from other SCM systems.
Somebody may want to compare git-blame.txt and git-annotate.txt in
Documentation/, notice that they share blame-options.txt and that the
former has accumulated option descriptions for a few more options that
should have been placed in blame-options.txt, and then prepare a patch to
improve the documentation? Hint, hint...
I *think* '-c', '-f', and '-n' are blame-only options but all others would
work with annotate (whoever is doing the patch needs to verify this,
though).
^ permalink raw reply
* Re: Compile warnings
From: Junio C Hamano @ 2011-11-14 20:36 UTC (permalink / raw)
To: Frans Klaver; +Cc: git@vger.kernel.org
In-Reply-To: <op.v4xyekju0aolir@keputer>
"Frans Klaver" <fransklaver@gmail.com> writes:
> Every now and then I see an 'unused result' warning come by during
> building. What is the general attitude towards these warnings? Remove
> them (by properly checking)? Or leave them be as a kind of
> documentation -- we know we're ignoring the info, but it's good to be
> reminded?
A callsite of a function whose return value is better checked should be
checked (e.g. not checking return from close(2) or write(2) in a non-error
codepath), but there is no strong mechanical "General attitude".
Sprinkling (void) that casts the return values all over the place makes
our code illegible, and we do not prefer it as a solution. A function
that returns a value that is useful for some callers but can be safely
ignored by others is sometimes an indication of a poor API, and for our
own code, we tend to prefer designing the API to pass optional pointer
to return value from callers that do want to use the return value (and
others that do not care about the return value pass NULL).
^ permalink raw reply
* Re: Git shouldn't allow to push a new branch called HEAD
From: Jeff King @ 2011-11-14 20:26 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Michael Haggerty, Daniele Segato, Git Mailing List
In-Reply-To: <7vbosejvx8.fsf@alter.siamese.dyndns.org>
On Mon, Nov 14, 2011 at 12:22:59PM -0800, Junio C Hamano wrote:
> Jeff King <peff@peff.net> writes:
>
> > So one solution is to block fetching of remote branches called HEAD
> > (which I would be OK with). But another is...
> > ... Obviously there's a lot more to it than just tweaking the default fetch
> > refspecs. The ref lookup rules need to be changed to take this into
> > account. There was some discussion about this over the summer (under the
> > subject of possible "1.8.0" changes), but I don't think any work has
> > been done.
>
> I would say discussing and ironing out the kinks of the design counts as
> work, but I agree nobody was seriously interested in laying out a sensible
> transition plan and discussion died out before anything concrete happened.
Yeah, I should have said "...has been done since then".
> Regardless of the layout chanage, which probably is a 2.X topic, I think a
> good first step would be to start forbidding anything that ends with _?HEAD
> as a branch or tag name, on top of Michael's "enforce the refname rules more
> vigorously when a ref is created" series.
Agreed. Changing the layout is a long-term fix, and I think disallowing
HEAD is a reasonable stop-gap measure.
-Peff
^ permalink raw reply
* Re: [PATCH] tag: implement --no-strip option
From: Junio C Hamano @ 2011-11-14 20:26 UTC (permalink / raw)
To: Kirill A. Shutemov; +Cc: git, Junio C Hamano
In-Reply-To: <1321268902-2170-1-git-send-email-kirill@shutemov.name>
"Kirill A. Shutemov" <kirill@shutemov.name> writes:
> +-S::
> +--no-strip::
> + Take tag message as-is. Do not strip any comments or empty lines.
Wrong naming convention. Just introduce a boolean --strip option which is
on by default, without adding -S; use of parse-options will allow the user
to negate it from the command line with --no-strip for free.
> diff --git a/builtin/tag.c b/builtin/tag.c
> index 9b6fd95..427d646 100644
> --- a/builtin/tag.c
> +++ b/builtin/tag.c
> @@ -320,7 +320,7 @@ static int build_tag_object(struct strbuf *buf, int sign, unsigned char *result)
> }
>
> static void create_tag(const unsigned char *object, const char *tag,
> - struct strbuf *buf, int message, int sign,
> + struct strbuf *buf, int message, int sign, int nostrip,
Again, wrong naming convention. "int strip" would be fine but I think at
this point "message, sign, strip" tuple should become fields of "struct
create_tag_option" that is passed to this funciton.
> unsigned char *prev, unsigned char *result)
> {
> enum object_type type;
> @@ -356,7 +356,7 @@ static void create_tag(const unsigned char *object, const char *tag,
>
> if (!is_null_sha1(prev))
> write_tag_body(fd, prev);
> - else
> + else if (!nostrip)
This double negation comes only because the argument is misnamed with negation.
^ permalink raw reply
* mergetool's test for rerere seems to be incorrect
From: Erik Carstensen @ 2011-11-14 20:26 UTC (permalink / raw)
To: git
Hi,
Occasionally when I use mergetool in a conflicted state ('git status'
says it's a conflict), nothing happens.
By bisection I found that bb0a484e985ef8d9bbbbeb172b1fcf4982634bef is
the offending commit.
I have rerere.enabled unset, but I did find an empty file MERGE_RR in
.git/, which explains my problem: mergetool chooses to use rerere
because it finds the MERGE_RR file, but rerere just exits silently
because it's not enabled.
Wouldn't it make sense to restrict mergetool's use of rerere to the
case when rerere.enabled is set?
I'm also a little confused about why the MERGE_RR file appeared there
in the first place. I can see that empty MERGE_RR files, with
different timestamps, have ended up in various other of my git
repositories as well. I never used rerere in these repos, and the only
non-git tools I have used for version control are stgit and kdiff3.
Erik
^ permalink raw reply
* [PATCH] svn: Create config options for common args
From: Ted Percival @ 2011-11-14 20:25 UTC (permalink / raw)
To: git; +Cc: Eric Wong, Ted Percival
These config options may be set to apply to all commands on the
repository in lieu of providing the command-line options each time:
svn.localtime: --localtime
svn.useLogAuthor: --use-log-author
svn.addAuthorFrom: --add-author-from
Since these flags apply to multiple operations, it's easier to set them
once rather than remembering to use them every time for every operation.
Signed-off-by: Ted Percival <ted.percival@quest.com>
---
Documentation/git-svn.txt | 10 ++++++++++
git-svn.perl | 3 +++
2 files changed, 13 insertions(+), 0 deletions(-)
diff --git a/Documentation/git-svn.txt b/Documentation/git-svn.txt
index 34ee785..20f8edd 100644
--- a/Documentation/git-svn.txt
+++ b/Documentation/git-svn.txt
@@ -113,6 +113,9 @@ repository you cloned from, but if you wish for your local Git
repository to be able to interoperate with someone else's local Git
repository, either don't use this option or you should both use it in
the same local timezone.
++
+[verse]
+config key: svn.localtime
--parent;;
Fetch only from the SVN parent of the current HEAD.
@@ -596,12 +599,19 @@ creating the branch or tag.
When retrieving svn commits into git (as part of 'fetch', 'rebase', or
'dcommit' operations), look for the first `From:` or `Signed-off-by:` line
in the log message and use that as the author string.
++
+[verse]
+config key: svn.useLogAuthor
+
--add-author-from::
When committing to svn from git (as part of 'commit-diff', 'set-tree' or 'dcommit'
operations), if the existing log message doesn't already have a
`From:` or `Signed-off-by:` line, append a `From:` line based on the
git commit's author string. If you use this, then `--use-log-author`
will retrieve a valid author string for all commits.
++
+[verse]
+config key: svn.addAuthorFrom
ADVANCED OPTIONS
diff --git a/git-svn.perl b/git-svn.perl
index e30df22..d69b0d7 100755
--- a/git-svn.perl
+++ b/git-svn.perl
@@ -21,6 +21,9 @@ $Git::SVN::default_repo_id = 'svn';
$Git::SVN::default_ref_id = $ENV{GIT_SVN_ID} || 'git-svn';
$Git::SVN::Ra::_log_window_size = 100;
$Git::SVN::_minimize_url = 'unset';
+$Git::SVN::_localtime = Git::config_bool('svn.localtime');
+$Git::SVN::_add_author_from = Git::config_bool('svn.addAuthorFrom');
+$Git::SVN::_use_log_author = Git::config_bool('svn.useLogAuthor');
if (! exists $ENV{SVN_SSH} && exists $ENV{GIT_SSH}) {
$ENV{SVN_SSH} = $ENV{GIT_SSH};
--
1.7.7.1
^ permalink raw reply related
* Re: [RFC] deprecating and eventually removing "git relink"?
From: Jeff King @ 2011-11-14 20:25 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Simon Brenner, git
In-Reply-To: <7vfwhqjw4u.fsf@alter.siamese.dyndns.org>
On Mon, Nov 14, 2011 at 12:18:25PM -0800, Junio C Hamano wrote:
> > Yes, I think that is sensible. I'm not sure there is even any core git
> > code to be written. I think a wrapper that does the following would
> > probably work:
>
> I agree with your outline, which I find is in line with what I had in mind
> in the message Miles responded.
>
> The approach is different from what Miles alluded to, which is to have
> "clients" create objects in the "central" place in the first place,
> though.
It seems to me that is simply an optimization that can come later. An
initial, no-C-code implementation would write to individual repos as
usual, and then occasionally migrate objects to the master shared repo
(and remove duplicates from individual repos). That's an easy to
implement low-risk experiment from which we can draw conclusions about
how well such a system works in practice.
And then if it seems like a good path, an obvious optimization[1] is to
write directly into the parent object store, skipping the migration.
This might involve git-core code, or maybe it just means setting up the
repos differently (e.g., symlinking the objects directory to the master
store).
-Peff
[1] Actually, I am slightly dubious that this optimization is worth
doing. It seems like it would save you from writing the data only to
copy it later. But in practice, we write loose objects, and you are
already rewriting the data to migrate it into packfiles. So the
migration already happens, and instead we would just be migrating to
packfiles in the central repo.
^ permalink raw reply
* Re: Git shouldn't allow to push a new branch called HEAD
From: Junio C Hamano @ 2011-11-14 20:22 UTC (permalink / raw)
To: Jeff King; +Cc: Michael Haggerty, Daniele Segato, Git Mailing List
In-Reply-To: <20111114111659.GC10847@sigill.intra.peff.net>
Jeff King <peff@peff.net> writes:
> So one solution is to block fetching of remote branches called HEAD
> (which I would be OK with). But another is...
> ... Obviously there's a lot more to it than just tweaking the default fetch
> refspecs. The ref lookup rules need to be changed to take this into
> account. There was some discussion about this over the summer (under the
> subject of possible "1.8.0" changes), but I don't think any work has
> been done.
I would say discussing and ironing out the kinks of the design counts as
work, but I agree nobody was seriously interested in laying out a sensible
transition plan and discussion died out before anything concrete happened.
Regardless of the layout chanage, which probably is a 2.X topic, I think a
good first step would be to start forbidding anything that ends with _?HEAD
as a branch or tag name, on top of Michael's "enforce the refname rules more
vigorously when a ref is created" series.
^ permalink raw reply
* Re: [RFC] deprecating and eventually removing "git relink"?
From: Junio C Hamano @ 2011-11-14 20:18 UTC (permalink / raw)
To: Jeff King; +Cc: Simon Brenner, git
In-Reply-To: <20111114103451.GA10847@sigill.intra.peff.net>
Jeff King <peff@peff.net> writes:
> On Mon, Nov 14, 2011 at 09:48:07AM +0100, Simon Brenner wrote:
>
>> On Mon, Nov 14, 2011 at 7:06 AM, Miles Bader <miles@gnu.org> wrote:
>> > It might be nice to have a mechanism where new objects would update
>> > the _alternate_ rather than the object-store in the tree where the
>> > command was run... then you could easily have a bunch of trees using a
>> > central object store without needing to update the central store
>> > occasionally by hand (and do gc in its "clients")...
>>
>> This sounds like a nice way forward: replace/extend the current
>> alternates system ...
>
> Yes, I think that is sensible. I'm not sure there is even any core git
> code to be written. I think a wrapper that does the following would
> probably work:
I agree with your outline, which I find is in line with what I had in mind
in the message Miles responded.
The approach is different from what Miles alluded to, which is to have
"clients" create objects in the "central" place in the first place,
though.
^ permalink raw reply
* Re: Repository data loss in fast-export with a merge of a deleted submodule
From: Jens Lehmann @ 2011-11-14 19:51 UTC (permalink / raw)
To: Joshua Jensen; +Cc: git@vger.kernel.org, Elijah Newren, Johannes Sixt
In-Reply-To: <4EC12E8B.3050909@workspacewhiz.com>
Am 14.11.2011 16:06, schrieb Joshua Jensen:
> ----- Original Message -----
> From: Joshua Jensen
> Date: 11/3/2011 10:05 AM
>> ----- Original Message -----
>> From: Joshua Jensen
>> Date: 10/27/2011 1:27 PM
>>> We had a submodule that we deleted and then added back into the repository at the same location as the former submodule. When running fast-export, the newly 'added' files for the merge commit are listed and then are followed with a:
>>>
>>> M ... path/to/submodule/file
>>> D path/to/submodule
>>>
>>> On fast-import, the resultant repository becomes corrupt due to the Delete instruction above occurring AFTER the file adds/modifications. The new repository does not match the old repository where the fast-export was performed.
>>>
>>> I am not familiar with the fast-export code. Can anyone help out?
>> Okay, I looked into this further, and I came up with a patch that works for me. Nevertheless, I do not understand exactly what is going on here, so I would like to defer to someone else's patch to fix the issue.
>>
> Hi.
>
> __This is a genuine data loss problem in Git.__
>
> I'm confused at the lack of response to this. I first posted about the issue **2-1/2 weeks ago**, and there have been no responses Does no one care?
Maybe no one cares, people didn't read the message (or forgot about it)
or they are too busy ... thanks for prodding us again.
While I'm interested in this issue because submodules are affected, I'm
very short on Git time these days and can't investigate this issue
further (and I have no clue about export/import either). I added the last
two people who touched depth_first() in builtin/fast-export.c to the CC,
maybe they can tell us more about your patch to solve this issue (found
in [2]).
> In case no one received the messages, you can find them at [1] and [2].
>
> -Josh
>
> [1] http://www.spinics.net/lists/git/msg168295.html
> [2] http://www.spinics.net/lists/git/msg168691.html
^ permalink raw reply
* Re: Git: Unexpected behaviour?
From: Martin von Zweigbergk @ 2011-11-14 17:20 UTC (permalink / raw)
To: git; +Cc: Junio C Hamano, J.V.
In-Reply-To: <7vlirlp1y6.fsf@alter.siamese.dyndns.org>
On Sat, Nov 12, 2011 at 11:37 AM, Junio C Hamano <gitster@pobox.com> wrote:
> "J.V." <jvsrvcs@gmail.com> writes:
>
>> OK so "work tree" is a new term for me. I thought we were in isolated
>> sandboxes called "branches" and changes made in a branch would stay in
>> that branch regardless.
>
> Do not think of "branches" as isolated _sandboxes_.
>
> Rather, "branches" are where the independent states are to be _recorded_.
I think I was confused about this when learning Git too. I friend of
mine made the following argument, which I agree with and which I haven
seen on the list before:
Either you want the modifications to stay on the branch, or you want
them to carry over to the branch you are checking out. In the former
case, you would want Git to fail if there are modifications (that you
might have forgotten you made). In the latter case, you would want
"git checkout -m". The current behavior is somewhere in between. It is
not clear to me if there is a use case where the current behavior is
better (from the user's point of view) than either failing or
"checkout -m".
It is obviously too late to change this now, though.
Martin
^ permalink raw reply
* Re: Compile warnings
From: Ævar Arnfjörð Bjarmason @ 2011-11-14 16:58 UTC (permalink / raw)
To: Frans Klaver; +Cc: git@vger.kernel.org
In-Reply-To: <op.v4xyekju0aolir@keputer>
On Mon, Nov 14, 2011 at 15:55, Frans Klaver <fransklaver@gmail.com> wrote:
> Every now and then I see an 'unused result' warning come by during building.
> What is the general attitude towards these warnings? Remove them (by
> properly checking)? Or leave them be as a kind of documentation -- we know
> we're ignoring the info, but it's good to be reminded?
Under what OS / version and compiler / version and what's the warning?
Paste the full warning(s) you get verbatim.
^ permalink raw reply
* Re: feature request: git annotate -w like git blame -w
From: Raoul Bhatia [IPAX] @ 2011-11-14 16:21 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git
In-Reply-To: <m3sjlun4o9.fsf@localhost.localdomain>
On 2011-11-11 14:57, Jakub Narebski wrote:
> "Raoul Bhatia [IPAX]"<r.bhatia@ipax.at> writes:
>
>> is it possible to add a "git annotate -w" option like git blame has?
>
> Why not use "git blame -c -w"? `-c' turns on annotate-compatibile
> output.
>
> From git-annotate(1) manpage:
>
> The only difference between this command and git-blame(1) is that they use
> slightly different output formats, and this command exists only for back-
> ward compatibility to support existing scripts, and provide a more familiar
> command name for people coming from other SCM systems.
thanks for this clarification. somehow, i missed this part while
scanning the man pages.
thank you and sorry for the noise!
raoul
--
____________________________________________________________________
DI (FH) Raoul Bhatia M.Sc. email. r.bhatia@ipax.at
Technischer Leiter
IPAX - Aloy Bhatia Hava OG web. http://www.ipax.at
Barawitzkagasse 10/2/2/11 email. office@ipax.at
1190 Wien tel. +43 1 3670030
FN 277995t HG Wien fax. +43 1 3670030 15
____________________________________________________________________
^ permalink raw reply
* Re: Repository data loss in fast-export with a merge of a deleted submodule
From: Joshua Jensen @ 2011-11-14 15:06 UTC (permalink / raw)
To: git@vger.kernel.org
In-Reply-To: <4EB2BBB5.3030908@workspacewhiz.com>
----- Original Message -----
From: Joshua Jensen
Date: 11/3/2011 10:05 AM
> ----- Original Message -----
> From: Joshua Jensen
> Date: 10/27/2011 1:27 PM
>> We had a submodule that we deleted and then added back into the
>> repository at the same location as the former submodule. When
>> running fast-export, the newly 'added' files for the merge commit are
>> listed and then are followed with a:
>>
>> M ... path/to/submodule/file
>> D path/to/submodule
>>
>> On fast-import, the resultant repository becomes corrupt due to the
>> Delete instruction above occurring AFTER the file
>> adds/modifications. The new repository does not match the old
>> repository where the fast-export was performed.
>>
>> I am not familiar with the fast-export code. Can anyone help out?
> Okay, I looked into this further, and I came up with a patch that
> works for me. Nevertheless, I do not understand exactly what is going
> on here, so I would like to defer to someone else's patch to fix the
> issue.
>
Hi.
__This is a genuine data loss problem in Git.__
I'm confused at the lack of response to this. I first posted about the
issue **2-1/2 weeks ago**, and there have been no responses Does no one
care?
In case no one received the messages, you can find them at [1] and [2].
-Josh
[1] http://www.spinics.net/lists/git/msg168295.html
[2] http://www.spinics.net/lists/git/msg168691.html
^ permalink raw reply
* Compile warnings
From: Frans Klaver @ 2011-11-14 14:55 UTC (permalink / raw)
To: git@vger.kernel.org
Hi,
Every now and then I see an 'unused result' warning come by during
building. What is the general attitude towards these warnings? Remove them
(by properly checking)? Or leave them be as a kind of documentation -- we
know we're ignoring the info, but it's good to be reminded?
Thanks,
Frans
^ permalink raw reply
* Re: input director not compatible with git right-click
From: Carlos Martín Nieto @ 2011-11-14 14:40 UTC (permalink / raw)
To: Eric; +Cc: git
In-Reply-To: <loom.20111113T173332-656@post.gmane.org>
[-- Attachment #1: Type: text/plain, Size: 514 bytes --]
On Sun, Nov 13, 2011 at 04:34:26PM +0000, Eric wrote:
> Hi,
>
> New in Git use, I use it do dev on window some administrative script. I use as
> well Input director to share keyboard and mouse on multiple computer.
Do you mean you're using it on the Windows OS?
>
> when I right-clicked on an item, it works when input director is disabled. If
Right-click on what? git doesn't have a graphical interface. If you're
using a graphical front-end to git, you should send them a bug report.
cmn
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 490 bytes --]
^ permalink raw reply
* Re: delete deprecated refs to release disk space
From: Peter Vereshagin @ 2011-11-14 14:25 UTC (permalink / raw)
To: ??var Arnfj??r?? Bjarmason; +Cc: Peter Vereshagin, git
In-Reply-To: <CACBZZX5kBqM1eye40_Vw0W=8qnNsUQBVCE0q9JrixYomGPuZbg@mail.gmail.com>
Hello.
2011/11/13 18:01:18 +0100 ??var Arnfj??r?? Bjarmason <avarab@gmail.com> => To Peter Vereshagin :
vArB> What you're looking for is git-filter-branch + the graft facility. I
vArB> can't remember the exact invocation, but you echo the sha1 of the
vArB> commit you want to be the oldest commit to .git/info/grafts, then run
vArB> git-filter-branch.
Seem to work for me ( with 'gc' and 'prune' thereafter ) but with these quirks:
*) the git-filter-branch(1) tells that there must be two ids:
echo "$commit-id $graft-id" >> .git/info/grafts
This works for me if only one is put there.
*) I'd like to have a command for this. Is this a '--parent-filter' to make
the same thing?
N commits ago is a fine setting for me as it's a cron job backup. Thanks?
--
Peter Vereshagin <peter@vereshagin.org> (http://vereshagin.org) pgp: A0E26627
^ permalink raw reply
* Re: [RFC/PATCH] remote: add new sync command
From: Felipe Contreras @ 2011-11-14 13:57 UTC (permalink / raw)
To: Jeff King; +Cc: git
In-Reply-To: <20111114122556.GB19746@sigill.intra.peff.net>
On Mon, Nov 14, 2011 at 2:25 PM, Jeff King <peff@peff.net> wrote:
> On Sun, Nov 13, 2011 at 12:07:19AM +0200, Felipe Contreras wrote:
>
>> > So in that sense, it is poorly named, and "--branches" (or "--heads")
>> > would be more accurate. At the same time, it is probably more likely
>> > what the user wants to do (you almost never want to push "refs/remotes",
>> > for example).
>>
>> But you do want to push tags, and --all --tags doesn't sound right; if
>> I'm pushing everything, why do I specify I want to push more stuff.
>> And then, why it --all --tags disallowed?
>
> I agree that "--all --tags" looks silly. I don't know why it's
> disallowed; from my reading, it should be a perfectly sensible
> operation. You might try digging in the history or the mailing list.
Yeah, I might do that.
>> > So I am a little hesitant to suggest changing it, even
>> > with a warning and deprecation period.
>>
>> It is confusing and wrong, what more reason do you need?
>
> Because I am worried that "--all" pushing refs/remotes will also be
> confusing; it's not what most people are going to want.
>
> If your suggestion is to deprecate the name "--all" and start calling it
> "--branches" or "--heads", then that is an improvement. But making
> "refs/*:refs/*" easier to accidentally use might not be.
That's what I meant; replace --all with --branches (remember heads is
a plumbing name).
>> > and then it really is just a special way of spelling "refs/heads/*". But
>> > then, I also think it's good for users to understand that the options
>> > are refspecs, and what that means. It's not a hard concept, and then
>> > when they inevitably say "how can I do BRANCHES, except put the result
>> > somewhere else in the remote namespace", it's a very natural extension
>> > to learn about the right-hand side o the refspec.
>> >
>> > Of course I also think BRANCHES looks ugly, and people should just learn
>> > "refs/heads/*".
>>
>> Look, I'm all in favor of people learning stuff, but I have been
>> involved in Git since basically day 1, and up to this day I was (am?)
>> not familiar with refspecs, I don't use them regularly, and never
>> really had a need to, and that's fine. People are already complaining
>> about the learning curve of git, and what you are suggesting is that:
>>
>> Instead of doing:
>> % git push remote --branches --tags
>>
>> They should do:
>> % git push remote 'refs/heads/*' 'refs/tags/*'
>
> Sorry, I should have been more clear with what I wrote. My "of
> course..." was more of a tangential "well, this is so far from what my
> gut tells me is reasonable that I'm not sure my definition of ugly is
> even relevant here".
>
> For me personally as a user, I prefer learning how a tool actually works
> at its core (in this case, refspecs), and then applying syntactic sugar
> to simplify usage. But I also respect that not everybody feels that way.
>
>> I'm not going to investigate the subtleties of these different setups,
>> I'm going to put my common user hat and ask; how do I fetch as a
>> mirror?
>
> The problem with that question is that you haven't defined mirror. Does
> that mean you just want pruning, or does it mean that you want your
> local ref namespace to match that of the remote?
Exactly, no mirror has been defined, because I don't want a mirror. A
mirror is supposed to have all the refs in sync all the time; that's
not what I want.
> Git should be able to do each of those cases. And I think it's fine to
> have a less cumbersome syntax to specify them. But it's also important
> that we don't over-simplify the terms so much that they get option A
> when they wanted B.
>
> BTW, right now there is "git remote add --mirror ...", which sets up the
> fetch refspec for you (in this case, mirror is "make your refs look like
> the remote's"). Perhaps rather than adding syntactic sugar to fetch, it
> would be best to channel users into configuring a remote that selects
> from one of a few common setups (including different types of mirrors).
But that assumes that they would want the same refspec operation *all
the time* which is not the case (at least for me). Sometimes I want to
update only existing branches, sometimes I want to fetch new branches
too, sometimes I want to prune local branches, sometimes not.
> It's not as flexible (I can't do a one-off mirrored push without using
> actual refspecs), but my guess is that most users would want to set up
> an actual remote, and picking from a set of configuration recipes would
> be the ideal interface for them.
I don't think so. I doubt users would like a refspec that will delete
their local branches *always*; sometimes they would want to prune the
remote tracking branches.
>> > And "--prune-local" doesn't seem like a fetch operation to me. Either
>> > you are mirroring, and --prune already handles it as above. Or you are
>> > interested in getting rid of branches whose upstream has gone away. But
>> > that's not a fetch operation; that's a branch operation.
>>
>> This would make things more confusing to the user.
>>
>> Say on one side I do this push?
>> % git push test --prune 'refs/heads/*' 'refs/tags/*'
>>
>> What do I do in the other side to synchronize the repo?
>> % git fetch test --prune-local 'refs/heads/*:refs/heads/*'
>> 'refs/tags/*:refs/tags/*'
>
> No, you would just do "--prune", because your refspecs are _already_
> indicating that you are writing into the local namespace, and anything
> you have locally would be deleted by the prune operation. I.e., there is
> no need for --prune-local in this scenario; --prune already does what we
> want.
That's very risky. The user might forget that this is a mirror repo,
and delete the local branches unintentionally. Plus, it would be then
impossible to prune remote tracking branches.
>> I would prefer this of course:
>> % git fetch test --all --prune-local
>>
>> But you are saying it should be:
>> % git fetch test 'refs/heads/*:refs/heads/*' 'refs/tags/*:refs/tags/*'
>> % git branch --prune-remote test
>>
>> That doesn't sound right to me; mixing branch operations with a specific remote?
>
> I was trying to outline a situation where "--prune" wouldn't be
> sufficient, which is:
>
> : we make some topic branch based on another branch
> $ git checkout -b topic-Y origin/topic-X
>
> : later, we (or someone else) deletes topic-X upstream
> $ git push origin :topic-X
>
> : now we fetch using the regular default refspecs, which put
> : everything in a separate remote. But we ask to prune, so that
> : deleted branches will go away.
> $ git fetch --prune origin
>
> Now origin/topic-X doesn't exist, even though it's configured as the
> upstream of topic-Y. Fetch doesn't enter into the picture, because it is
> configured to only touch items in refs/remotes/.
That's only by default.
> As a user, how do I resolve the situation? I might say topic-Y is
> obsolete and get rid of it. I might rebase it onto another branch. Or I
> might declare it to have no upstream. But all of those are branch
> operations, not fetch operations.
Yes, but that has nothing to do with the operation I want to achieve:
git remote sync. By which I mean synchronize the local branches with
the branches of a certain remote.
Note that in this sync operation, the upstream branch is irrelevant.
> So what I was trying to say was that either your fetch refspecs tell
> fetch to write into your local branch namespace, or not. If they do,
> then --prune is sufficient (with no -local variant required). If not,
> then touching your local branch namespace is outside the scope of fetch.
I don't want this to be a *permanent* configuration. I see this
similar to --force. You can achieve the same by adding a + at the
beginning of the refspec, but this is something that should be
activated on a per-command basis, thus the option. I think this should
be the same.
Cheers.
--
Felipe Contreras
^ permalink raw reply
* Re: git behaviour question regarding SHA-1 and commits
From: Jeff King @ 2011-11-14 13:04 UTC (permalink / raw)
To: Jonathan Nieder, vinassa vinassa, git,
Ævar Arnfjörð Bjarmason
In-Reply-To: <20111114124851.GB21854@victor>
On Mon, Nov 14, 2011 at 01:48:51PM +0100, Victor Engmark wrote:
> > Fortunately we have such a thing:
> >
> > http://article.gmane.org/gmane.comp.version-control.git/184243
> >
> > That one actually has 40 bits of hash entropy, so you'd expect to
> > generate 2^20 (about a million) commits before accidentally colliding.
> > If you want an easier experiment, you could truncate it even further.
>
> Would it be helpful to truncate this to something ludicrous like a
> single byte of entropy, to be able to write tests for the various tools
> and options?
That's probably too small. Obviously any implementation like this is not
going to be usable for interacting with existing repositories, but if
you have too many collisions, then you won't even be able to create a
few new commits for your test.
Something like 20 bits means you can brute-force a collision for a
particular blob, commit, tree, or whatever in a few seconds, but you
won't be having accidental ones all the time.
-Peff
^ permalink raw reply
* Re: git behaviour question regarding SHA-1 and commits
From: Victor Engmark @ 2011-11-14 12:48 UTC (permalink / raw)
To: Jeff King
Cc: Jonathan Nieder, vinassa vinassa, git,
Ævar Arnfjörð Bjarmason
In-Reply-To: <20111114113235.GE10847@sigill.intra.peff.net>
On Mon, Nov 14, 2011 at 06:32:35AM -0500, Jeff King wrote:
> On Sun, Nov 13, 2011 at 12:27:57PM -0600, Jonathan Nieder wrote:
>
> > Though I haven't tested. It would be nice to have an md5git (or even
> > truncated-sha1-git) program to test this kind of thing with.
>
> Fortunately we have such a thing:
>
> http://article.gmane.org/gmane.comp.version-control.git/184243
>
> That one actually has 40 bits of hash entropy, so you'd expect to
> generate 2^20 (about a million) commits before accidentally colliding.
> If you want an easier experiment, you could truncate it even further.
Would it be helpful to truncate this to something ludicrous like a
single byte of entropy, to be able to write tests for the various tools
and options?
Cheers,
V
--
terreActive AG
Kasinostrasse 30
CH-5001 Aarau
Tel: +41 62 834 00 55
Fax: +41 62 823 93 56
www.terreactive.ch
Wir sichern Ihren Erfolg - seit 15 Jahren
^ permalink raw reply
* Re: [RFC/PATCH] remote: add new sync command
From: Jeff King @ 2011-11-14 12:25 UTC (permalink / raw)
To: Felipe Contreras; +Cc: git
In-Reply-To: <CAMP44s06p+KyJAu4ddiCa8CFRq5eogbqxxJU16Z-SUb3GSp67Q@mail.gmail.com>
On Sun, Nov 13, 2011 at 12:07:19AM +0200, Felipe Contreras wrote:
> > So in that sense, it is poorly named, and "--branches" (or "--heads")
> > would be more accurate. At the same time, it is probably more likely
> > what the user wants to do (you almost never want to push "refs/remotes",
> > for example).
>
> But you do want to push tags, and --all --tags doesn't sound right; if
> I'm pushing everything, why do I specify I want to push more stuff.
> And then, why it --all --tags disallowed?
I agree that "--all --tags" looks silly. I don't know why it's
disallowed; from my reading, it should be a perfectly sensible
operation. You might try digging in the history or the mailing list.
> > So I am a little hesitant to suggest changing it, even
> > with a warning and deprecation period.
>
> It is confusing and wrong, what more reason do you need?
Because I am worried that "--all" pushing refs/remotes will also be
confusing; it's not what most people are going to want.
If your suggestion is to deprecate the name "--all" and start calling it
"--branches" or "--heads", then that is an improvement. But making
"refs/*:refs/*" easier to accidentally use might not be.
> > Right. It looks like that is just spelled "--mirror" (which gives you
> > pruning also), or "refs/*:refs/*" (without pruning). The latter is even
> > more flexible, as you could do "refs/*:refs/foo/*" to keep several
> > related backups in one upstream repo.
>
> So, we agree that --all is the same as 'refs/heads/*'. Therefore we
> already have this mixture of refspecs and options.
True. I wonder why there has been so much confusion over "--tags", and
so little over "--all".
> > and then it really is just a special way of spelling "refs/heads/*". But
> > then, I also think it's good for users to understand that the options
> > are refspecs, and what that means. It's not a hard concept, and then
> > when they inevitably say "how can I do BRANCHES, except put the result
> > somewhere else in the remote namespace", it's a very natural extension
> > to learn about the right-hand side o the refspec.
> >
> > Of course I also think BRANCHES looks ugly, and people should just learn
> > "refs/heads/*".
>
> Look, I'm all in favor of people learning stuff, but I have been
> involved in Git since basically day 1, and up to this day I was (am?)
> not familiar with refspecs, I don't use them regularly, and never
> really had a need to, and that's fine. People are already complaining
> about the learning curve of git, and what you are suggesting is that:
>
> Instead of doing:
> % git push remote --branches --tags
>
> They should do:
> % git push remote 'refs/heads/*' 'refs/tags/*'
Sorry, I should have been more clear with what I wrote. My "of
course..." was more of a tangential "well, this is so far from what my
gut tells me is reasonable that I'm not sure my definition of ugly is
even relevant here".
For me personally as a user, I prefer learning how a tool actually works
at its core (in this case, refspecs), and then applying syntactic sugar
to simplify usage. But I also respect that not everybody feels that way.
> I'm not going to investigate the subtleties of these different setups,
> I'm going to put my common user hat and ask; how do I fetch as a
> mirror?
The problem with that question is that you haven't defined mirror. Does
that mean you just want pruning, or does it mean that you want your
local ref namespace to match that of the remote?
Git should be able to do each of those cases. And I think it's fine to
have a less cumbersome syntax to specify them. But it's also important
that we don't over-simplify the terms so much that they get option A
when they wanted B.
BTW, right now there is "git remote add --mirror ...", which sets up the
fetch refspec for you (in this case, mirror is "make your refs look like
the remote's"). Perhaps rather than adding syntactic sugar to fetch, it
would be best to channel users into configuring a remote that selects
from one of a few common setups (including different types of mirrors).
It's not as flexible (I can't do a one-off mirrored push without using
actual refspecs), but my guess is that most users would want to set up
an actual remote, and picking from a set of configuration recipes would
be the ideal interface for them.
> > And "--prune-local" doesn't seem like a fetch operation to me. Either
> > you are mirroring, and --prune already handles it as above. Or you are
> > interested in getting rid of branches whose upstream has gone away. But
> > that's not a fetch operation; that's a branch operation.
>
> This would make things more confusing to the user.
>
> Say on one side I do this push?
> % git push test --prune 'refs/heads/*' 'refs/tags/*'
>
> What do I do in the other side to synchronize the repo?
> % git fetch test --prune-local 'refs/heads/*:refs/heads/*'
> 'refs/tags/*:refs/tags/*'
No, you would just do "--prune", because your refspecs are _already_
indicating that you are writing into the local namespace, and anything
you have locally would be deleted by the prune operation. I.e., there is
no need for --prune-local in this scenario; --prune already does what we
want.
> I would prefer this of course:
> % git fetch test --all --prune-local
>
> But you are saying it should be:
> % git fetch test 'refs/heads/*:refs/heads/*' 'refs/tags/*:refs/tags/*'
> % git branch --prune-remote test
>
> That doesn't sound right to me; mixing branch operations with a specific remote?
I was trying to outline a situation where "--prune" wouldn't be
sufficient, which is:
: we make some topic branch based on another branch
$ git checkout -b topic-Y origin/topic-X
: later, we (or someone else) deletes topic-X upstream
$ git push origin :topic-X
: now we fetch using the regular default refspecs, which put
: everything in a separate remote. But we ask to prune, so that
: deleted branches will go away.
$ git fetch --prune origin
Now origin/topic-X doesn't exist, even though it's configured as the
upstream of topic-Y. Fetch doesn't enter into the picture, because it is
configured to only touch items in refs/remotes/.
As a user, how do I resolve the situation? I might say topic-Y is
obsolete and get rid of it. I might rebase it onto another branch. Or I
might declare it to have no upstream. But all of those are branch
operations, not fetch operations.
So what I was trying to say was that either your fetch refspecs tell
fetch to write into your local branch namespace, or not. If they do,
then --prune is sufficient (with no -local variant required). If not,
then touching your local branch namespace is outside the scope of fetch.
-Peff
^ permalink raw reply
* Re: git behaviour question regarding SHA-1 and commits
From: Jeff King @ 2011-11-14 11:48 UTC (permalink / raw)
To: Junio C Hamano
Cc: Ævar Arnfjörð Bjarmason, vinassa vinassa, git
In-Reply-To: <7vwrb3l6v2.fsf@alter.siamese.dyndns.org>
On Sun, Nov 13, 2011 at 07:29:05PM -0800, Junio C Hamano wrote:
> If the collision is between commit objects, for example, we would write
> the (old) commit object name to the tip of the current branch. Most
> likely, the tree object recorded in the (old) commit would not match the
> tree object your "git commit" wanted to record (otherwise you have hit
> SHA-1 collision twice in a row ;-), which would mean "git status" would
> show that a whole bunch of paths have changed between the HEAD and the
> index. Also "git log" would show the history leading to the (old) commit
> that is likely to be very different from what you would expect immediately
> after committing the collided commit. Of course, you could recover from it
> with "git reset --soft" after finding out what the previous HEAD was from
> the reflog, but it won't be a pleasant experience.
>
> There can be other kinds of collisions (e.g. your latest commit might have
> collided with an existing blob or tree, in which case it is likely that
> almost nothing would work after finding a blob or tree in HEAD).
You are more likely to just have blobs collide, since we generate many
more blobs than commits (each commit should have at least one changed
blob, but typically has more).
And in that case, I expect git would silently lose that state. We would
fail to write the new blob to the object db, but "git diff" would report
nothing, as it would see that the index entry's sha1 is the same as what
is in HEAD, and that the file is up to date with respect to the stat
information in the index. So if you were to "git checkout", your content
would be lost forever. However, if you instead modify the file further,
the new content will be kept (and you will get a very confusing diff).
-Peff
^ 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