* Re: [RFC] Questions for "Git User's Survey 2011"
From: David Aguilar @ 2011-09-03 23:41 UTC (permalink / raw)
To: Jakub Narebski; +Cc: Phil Hord, git@vger.kernel.org
In-Reply-To: <201109031100.54775.jnareb@gmail.com>
On Sep 3, 2011, at 2:00 AM, Jakub Narebski <jnareb@gmail.com> wrote:
> On Sat, 3 Sep 2011, David Aguilar wrote:
>> On Mon, Jul 25, 2011 at 05:58:32PM -0400, Phil Hord wrote:
>>> On 07/25/2011 04:33 PM, Jakub Narebski wrote:
>>>> === 11. What Git interfaces, implementations and frontends do you use? ===
>>>> (multiple choice, with other)
> [...]
>
>>> Looking at the 2010 results, I would add these GUIs to the main list:
>>> git-gui (core)
>>> gitk (core)
>>> gitX
>>> gitg
>>> git-cola
>>> TortoiseGit
>>> SmartGit
>>> Git Extensions
>>> Giggle
>>
>> This is a better list ;-)
>
> Because of huge number of Git GUIs and tools instead of providing a long
> list of tools to choose from, I went for free-form question:
okay, that makes sense.
nevertheless, we are advertising cogito (deprecated) and pyrite (never made it past pre-alpha in 2008). why? these should be removed. if you need a replacement, might I suggest git-cola? ;-)I think removing (and thus not advertising) dead tools is more important than coming up with replacements. this is on page 4/10 on the survs.com link you sent elsewhere in this thread.
> === 13. List git tools that you use (optional) ===
> (free form, essay)
>
> Description:
> ~~~~~~~~~~~~
> Please include only frontends, interfaces and tools that have support
> for Git (so e.g. EGit applies, but Eclipse doesn't).
>
> Please either use comma separated list of tools, or put each tool in a
> separate line. That would make analysis of answers simpler. Thanks
> in advance.
>
> Even though it is free-form question, it shouldn't be hard to analyse,
> though it wouldn't be completely automatical.
> --
> Jakub Narebski
> Poland
^ permalink raw reply
* Lost association between TAGS and COMMITs when rebased a git(1) repository
From: John S. Urban @ 2011-09-04 1:32 UTC (permalink / raw)
To: git
With my first use of git(1) I created a small project with about 200
"commits". When this was complete, I needed to label each commit with
information pointing it to a section of a document. I used tags for this. So
far, everything was fine. I was then asked to merge two commits
into one. I then did a "rebase" (for the first time). I then appear to have
lost all association between the tags and the effected commits; as all
commits after
the ones I modified no longer see "their" tags. Was there a way to have kept
the tags associated with the original commits as they were "rebased"?
Also, I have some commits with multiple tags pointing to them. It has come
to my attention that might not be an intentional feature. I could find
nothing in the documentation explicitly stating multiple tags were allowed
to point to a commit; but the tags seem to be unique "objects" so I
see no reason this should not be an expected feature?
Thanks for any insights. Other than loosing association between the tags and
the commits with rebase (which I was hesitant to use; and am now
doubly so) I found git(1) to be the first version control system better than
"be careful and make tar-balls of major releases"; although I am just
starting to get an idea of how the pieces work.
^ permalink raw reply
* Re: [PATCH 10/10] want_color: automatically fallback to color.ui
From: Martin von Zweigbergk @ 2011-09-04 2:36 UTC (permalink / raw)
To: Jeff King; +Cc: git, Junio C Hamano, Steffen Daode Nurpmeso, Ingo Brückl
In-Reply-To: <20110818050533.GJ2889@sigill.intra.peff.net>
Hi Jeff,
This patch makes format-patch output color escape codes to file when
run with color.ui=always. Before the patch it did not do that. The
documentation for color.ui says "Set it to always if you want all
output not intended for machine consumption to use color". Is
format-patch "intended for machine consumption" or not?
I'm not sure why I had the parameter set to "always" instead of
"true/auto" and maybe I should change it, but since this patch changes
the behavior, I thought I should let you know (it was not mentioned in
the commit message, so I'm not sure it was intentional).
Martin
^ permalink raw reply
* git push output goes into stderr
From: Lynn Lin @ 2011-09-04 9:26 UTC (permalink / raw)
To: git
Hi all,
When I create a local branch and then push it to remote. I find that
the output without error goes into stderr, is this expected?
Lynn
^ permalink raw reply
* Re: Lost association between TAGS and COMMITs when rebased a git(1) repository
From: PJ Weisberg @ 2011-09-04 10:02 UTC (permalink / raw)
To: John S. Urban; +Cc: git
In-Reply-To: <FF0364F3D5244CA4987EDDCFE7244BF3@urbanjsPC>
On Sat, Sep 3, 2011 at 6:32 PM, John S. Urban <urbanjost@comcast.net> wrote:
> With my first use of git(1) I created a small project with about 200
> "commits". When this was complete, I needed to label each commit with
> information pointing it to a section of a document. I used tags for this. So
> far, everything was fine. I was then asked to merge two commits
> into one. I then did a "rebase" (for the first time). I then appear to have
> lost all association between the tags and the effected commits; as all
> commits after
> the ones I modified no longer see "their" tags. Was there a way to have kept
> the tags associated with the original commits as they were "rebased"?
When Old Biff Tannen traveled back to the year 1955 and gave his
younger self a copy of Grays Sports Almanac, which listed the outcomes
of every major sporting event from the years 1950-2000, the timeline
skewed, creating an alternate reality in which he had won enough money
through gambling to take over the town of Hill Valley. If Marty McFly
had kept a reflog, like Git does, he could have backtracked in his
personal history and just not left the almanac and the time machine
where Biff could find them. Instead, he had to go back to 1955 and
steal the almanac from young Biff after old Biff had given it to him.
But this metaphor is getting silly, and alienating anyone who wasn't
watching American movies in the late 1980s.
My point is that the tags are still there, and they still point to the
same commits they always pointed to. It's just that those commits are
part of the original history, not the alternate history created by the
rebase. People say that Git can "rewrite" history, but really it
creates a new history for the branch. The old history is still around
as long as there are references to it, until the garbage collector
picks it up.
Once a tag points to a commit, it isn't meant to be easy to make it
point to a different commit. For the same reason that you wouldn't
release version 1.8.3 of some software, and then later make a new
release also called 1.8.3.
> Also, I have some commits with multiple tags pointing to them. It has come
> to my attention that might not be an intentional feature. I could find
> nothing in the documentation explicitly stating multiple tags were allowed
> to point to a commit; but the tags seem to be unique "objects" so I
> see no reason this should not be an expected feature?
There's no reason you can't have multiple tags pointing to the same commit.
> Thanks for any insights. Other than loosing association between the tags and
> the commits with rebase (which I was hesitant to use; and am now
> doubly so) I found git(1) to be the first version control system better than
> "be careful and make tar-balls of major releases"; although I am just
> starting to get an idea of how the pieces work.
It's generally accepted that rebasing commits that other people have
had access to is a bad idea. :-)
-PJ
^ permalink raw reply
* [PATCH 1/3] remove prefix argument from pathspec_prefix
From: Clemens Buchacher @ 2011-09-04 10:41 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <1315132921-26949-1-git-send-email-drizzd@aon.at>
Passing a prefix to a function that is supposed to find the prefix
is strange. And it's really only used if the pathspec is NULL. Make
the callers handle this case instead.
Signed-off-by: Clemens Buchacher <drizzd@aon.at>
---
builtin/commit.c | 5 +++--
builtin/ls-files.c | 2 +-
cache.h | 2 +-
setup.c | 4 ++--
4 files changed, 7 insertions(+), 6 deletions(-)
diff --git a/builtin/commit.c b/builtin/commit.c
index cbc9613..64fe501 100644
--- a/builtin/commit.c
+++ b/builtin/commit.c
@@ -255,8 +255,9 @@ static int list_paths(struct string_list *list, const char *with_tree,
m = xcalloc(1, i);
if (with_tree) {
- const char *max_prefix = pathspec_prefix(prefix, pattern);
- overlay_tree_on_cache(with_tree, max_prefix);
+ char *max_prefix = pathspec_prefix(pattern);
+ overlay_tree_on_cache(with_tree, max_prefix ? max_prefix : prefix);
+ free(max_prefix);
}
for (i = 0; i < active_nr; i++) {
diff --git a/builtin/ls-files.c b/builtin/ls-files.c
index e8a800d..a54c2a2 100644
--- a/builtin/ls-files.c
+++ b/builtin/ls-files.c
@@ -545,7 +545,7 @@ int cmd_ls_files(int argc, const char **argv, const char *cmd_prefix)
strip_trailing_slash_from_submodules();
/* Find common prefix for all pathspec's */
- max_prefix = pathspec_prefix(prefix, pathspec);
+ max_prefix = pathspec_prefix(pathspec);
max_prefix_len = max_prefix ? strlen(max_prefix) : 0;
/* Treat unmatching pathspec elements as errors */
diff --git a/cache.h b/cache.h
index 607c2ea..0ccc84d 100644
--- a/cache.h
+++ b/cache.h
@@ -444,7 +444,7 @@ extern void set_git_work_tree(const char *tree);
#define ALTERNATE_DB_ENVIRONMENT "GIT_ALTERNATE_OBJECT_DIRECTORIES"
extern const char **get_pathspec(const char *prefix, const char **pathspec);
-extern const char *pathspec_prefix(const char *prefix, const char **pathspec);
+extern char *pathspec_prefix(const char **pathspec);
extern void setup_work_tree(void);
extern const char *setup_git_directory_gently(int *);
extern const char *setup_git_directory(void);
diff --git a/setup.c b/setup.c
index 27c1d47..0906790 100644
--- a/setup.c
+++ b/setup.c
@@ -236,13 +236,13 @@ const char **get_pathspec(const char *prefix, const char **pathspec)
return pathspec;
}
-const char *pathspec_prefix(const char *prefix, const char **pathspec)
+char *pathspec_prefix(const char **pathspec)
{
const char **p, *n, *prev;
unsigned long max;
if (!pathspec)
- return prefix ? xmemdupz(prefix, strlen(prefix)) : NULL;
+ return NULL;
prev = NULL;
max = PATH_MAX;
--
1.7.6.1
^ permalink raw reply related
* renaming pathspec_prefix (was: Re: [PATCH v2] commit: allow partial commits with relative paths)
From: Clemens Buchacher @ 2011-09-04 10:41 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vbow7ebzw.fsf@alter.siamese.dyndns.org>
On Tue, Aug 02, 2011 at 02:31:47PM -0700, Junio C Hamano wrote:
> Clemens Buchacher <drizzd@aon.at> writes:
>
> > diff --git a/setup.c b/setup.c
> > index 5ea5502..2c51a9a 100644
> > --- a/setup.c
> > +++ b/setup.c
> > @@ -264,6 +264,38 @@ const char **get_pathspec(const char *prefix, const char **pathspec)
> > return pathspec;
> > }
> >
> > +const char *pathspec_prefix(const char *prefix, const char **pathspec)
> > +{
>
> As a public function, this sorely needs a comment that describes what it
> does. More importantly, when I tried to come up with an example
> description, it became very clear that this neither prefixes anything to
> pathspec, nor prefixes pathspec to anything else.
>
> As an internal helper in ls-files implementation it was perfectly
> fine that the function was slightly misnamed, but if you are making it
> into a public API, we should get its name right.
>
> Perhaps "common_prefix()"?
>
> Don't you also want to consolidate dir.c:common_prefix() with this?
Yes. This should do it:
[PATCH 1/3] remove prefix argument from pathspec_prefix
[PATCH 2/3] consolidate pathspec_prefix and common_prefix
[PATCH 3/3] rename pathspec_prefix -> common_prefix and move to
> What happens when pathspec has the recently introduced magic elements,
> e.g. ':/' that widens the match to the whole tree?
If I understand correctly that is resolved in get_pathspec. And
pathspec_prefix (now common_prefix) is called later.
Clemens
^ permalink raw reply
* [PATCH 2/3] consolidate pathspec_prefix and common_prefix
From: Clemens Buchacher @ 2011-09-04 10:42 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <1315132921-26949-1-git-send-email-drizzd@aon.at>
The implementation from pathspec_prefix (slightly modified)
replaces the current common_prefix, because it also respects glob
characters.
Signed-off-by: Clemens Buchacher <drizzd@aon.at>
---
I wonder if PATH_MAX is needed and respected everywhere. Do we have
any previous experience with very long paths?
Clemens
dir.c | 52 ++++++++++++++++++++++++++--------------------------
dir.h | 1 +
setup.c | 29 ++---------------------------
3 files changed, 29 insertions(+), 53 deletions(-)
diff --git a/dir.c b/dir.c
index 08281d2..7099fb3 100644
--- a/dir.c
+++ b/dir.c
@@ -34,37 +34,37 @@ int fnmatch_icase(const char *pattern, const char *string, int flags)
return fnmatch(pattern, string, flags | (ignore_case ? FNM_CASEFOLD : 0));
}
-static int common_prefix(const char **pathspec)
+unsigned long common_prefix_len(const char **pathspec)
{
- const char *path, *slash, *next;
- int prefix;
+ const char *n, *first;
+ unsigned long max;
if (!pathspec)
return 0;
- path = *pathspec;
- slash = strrchr(path, '/');
- if (!slash)
- return 0;
-
- /*
- * The first 'prefix' characters of 'path' are common leading
- * path components among the pathspecs we have seen so far,
- * including the trailing slash.
- */
- prefix = slash - path + 1;
- while ((next = *++pathspec) != NULL) {
- int len, last_matching_slash = -1;
- for (len = 0; len < prefix && next[len] == path[len]; len++)
- if (next[len] == '/')
- last_matching_slash = len;
- if (len == prefix)
- continue;
- if (last_matching_slash < 0)
- return 0;
- prefix = last_matching_slash + 1;
+ first = *pathspec;
+ max = PATH_MAX;
+ while ((n = *pathspec++)) {
+ int i, len = 0;
+ for (i = 0; i < max; i++) {
+ char c = n[i];
+ if (!c || c != first[i] || is_glob_special(c))
+ break;
+ if (c == '/')
+ len = i+1;
+ }
+ if (len < max) {
+ max = len;
+ if (!max)
+ break;
+ }
}
- return prefix;
+
+ /* Nothing in the first PATH_MAX characters? */
+ if (max > 0 && first[max-1] != '/')
+ max = 0;
+
+ return max;
}
int fill_directory(struct dir_struct *dir, const char **pathspec)
@@ -76,7 +76,7 @@ int fill_directory(struct dir_struct *dir, const char **pathspec)
* Calculate common prefix for the pathspec, and
* use that to optimize the directory walk
*/
- len = common_prefix(pathspec);
+ len = common_prefix_len(pathspec);
path = "";
if (len)
diff --git a/dir.h b/dir.h
index 433b5b4..0e55b71 100644
--- a/dir.h
+++ b/dir.h
@@ -64,6 +64,7 @@ struct dir_struct {
#define MATCHED_RECURSIVELY 1
#define MATCHED_FNMATCH 2
#define MATCHED_EXACTLY 3
+extern unsigned long common_prefix_len(const char **pathspec);
extern int match_pathspec(const char **pathspec, const char *name, int namelen, int prefix, char *seen);
extern int match_pathspec_depth(const struct pathspec *pathspec,
const char *name, int namelen,
diff --git a/setup.c b/setup.c
index 0906790..0c60dbd 100644
--- a/setup.c
+++ b/setup.c
@@ -238,34 +238,9 @@ const char **get_pathspec(const char *prefix, const char **pathspec)
char *pathspec_prefix(const char **pathspec)
{
- const char **p, *n, *prev;
- unsigned long max;
+ unsigned long len = common_prefix_len(pathspec);
- if (!pathspec)
- return NULL;
-
- prev = NULL;
- max = PATH_MAX;
- for (p = pathspec; (n = *p) != NULL; p++) {
- int i, len = 0;
- for (i = 0; i < max; i++) {
- char c = n[i];
- if (prev && prev[i] != c)
- break;
- if (!c || c == '*' || c == '?')
- break;
- if (c == '/')
- len = i+1;
- }
- prev = n;
- if (len < max) {
- max = len;
- if (!max)
- break;
- }
- }
-
- return max ? xmemdupz(prev, max) : NULL;
+ return len ? xmemdupz(prefix, len) : NULL;
}
/*
--
1.7.6.1
^ permalink raw reply related
* [PATCH 3/3] rename pathspec_prefix -> common_prefix and move to dir.[ch]
From: Clemens Buchacher @ 2011-09-04 10:42 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <1315132921-26949-1-git-send-email-drizzd@aon.at>
Signed-off-by: Clemens Buchacher <drizzd@aon.at>
---
builtin/commit.c | 2 +-
builtin/ls-files.c | 2 +-
cache.h | 1 -
dir.c | 11 +++++++++++
dir.h | 1 +
setup.c | 7 -------
6 files changed, 14 insertions(+), 10 deletions(-)
diff --git a/builtin/commit.c b/builtin/commit.c
index 64fe501..b9ab5ef 100644
--- a/builtin/commit.c
+++ b/builtin/commit.c
@@ -255,7 +255,7 @@ static int list_paths(struct string_list *list, const char *with_tree,
m = xcalloc(1, i);
if (with_tree) {
- char *max_prefix = pathspec_prefix(pattern);
+ char *max_prefix = common_prefix(pattern);
overlay_tree_on_cache(with_tree, max_prefix ? max_prefix : prefix);
free(max_prefix);
}
diff --git a/builtin/ls-files.c b/builtin/ls-files.c
index a54c2a2..7cff175 100644
--- a/builtin/ls-files.c
+++ b/builtin/ls-files.c
@@ -545,7 +545,7 @@ int cmd_ls_files(int argc, const char **argv, const char *cmd_prefix)
strip_trailing_slash_from_submodules();
/* Find common prefix for all pathspec's */
- max_prefix = pathspec_prefix(pathspec);
+ max_prefix = common_prefix(pathspec);
max_prefix_len = max_prefix ? strlen(max_prefix) : 0;
/* Treat unmatching pathspec elements as errors */
diff --git a/cache.h b/cache.h
index 0ccc84d..586b987 100644
--- a/cache.h
+++ b/cache.h
@@ -444,7 +444,6 @@ extern void set_git_work_tree(const char *tree);
#define ALTERNATE_DB_ENVIRONMENT "GIT_ALTERNATE_OBJECT_DIRECTORIES"
extern const char **get_pathspec(const char *prefix, const char **pathspec);
-extern char *pathspec_prefix(const char **pathspec);
extern void setup_work_tree(void);
extern const char *setup_git_directory_gently(int *);
extern const char *setup_git_directory(void);
diff --git a/dir.c b/dir.c
index 7099fb3..f606da9 100644
--- a/dir.c
+++ b/dir.c
@@ -67,6 +67,17 @@ unsigned long common_prefix_len(const char **pathspec)
return max;
}
+/*
+ * Returns a copy of the longest leading path common among all
+ * pathspecs.
+ */
+char *common_prefix(const char **pathspec)
+{
+ unsigned long len = common_prefix_len(pathspec);
+
+ return len ? xmemdupz(*pathspec, len) : NULL;
+}
+
int fill_directory(struct dir_struct *dir, const char **pathspec)
{
const char *path;
diff --git a/dir.h b/dir.h
index 0e55b71..9a33d23 100644
--- a/dir.h
+++ b/dir.h
@@ -65,6 +65,7 @@ struct dir_struct {
#define MATCHED_FNMATCH 2
#define MATCHED_EXACTLY 3
extern unsigned long common_prefix_len(const char **pathspec);
+extern char *common_prefix(const char **pathspec);
extern int match_pathspec(const char **pathspec, const char *name, int namelen, int prefix, char *seen);
extern int match_pathspec_depth(const struct pathspec *pathspec,
const char *name, int namelen,
diff --git a/setup.c b/setup.c
index 0c60dbd..52bbb70 100644
--- a/setup.c
+++ b/setup.c
@@ -236,13 +236,6 @@ const char **get_pathspec(const char *prefix, const char **pathspec)
return pathspec;
}
-char *pathspec_prefix(const char **pathspec)
-{
- unsigned long len = common_prefix_len(pathspec);
-
- return len ? xmemdupz(prefix, len) : NULL;
-}
-
/*
* Test if it looks like we're at a git directory.
* We want to see:
--
1.7.6.1
^ permalink raw reply related
* Re: [BUG] git push --quiet fails with older versions
From: Tobias Ulmer @ 2011-09-04 12:08 UTC (permalink / raw)
To: Clemens Buchacher; +Cc: git, Junio C Hamano
In-Reply-To: <1315067656-2846-1-git-send-email-drizzd@aon.at>
On Sat, Sep 03, 2011 at 06:34:13PM +0200, Clemens Buchacher wrote:
> Hello Tobias,
>
> On Sat, Sep 03, 2011 at 12:57:23PM +0200, Tobias Ulmer wrote:
> >
> > my distro updated git to 1.7.6.1. Now git push --quiet, used in various
> > scripts, blows up against 1.7.6. I don't know how backwards compatible
> > git tries to be, but in my opinion that seems like a regression for a
> > patchlevel release.
>
> Yes, that's a good point. I did not consider that.
>
> > The problem seems to be that the remote git receive-pack does not
> > understand --quiet. Maybe it is possible to check for the remote version
> > before sending incompatible commandline parameters?
>
> Indeed, that's what we must do. I am sending three patches in reply
> to this email:
>
> [PATCH 1/3] tests for push --quiet
> [PATCH 2/3] fix push --quiet via http
> [PATCH 3/3] push: old receive-pack does not understand --quiet
>
> The third one fixes this issue on the client side. It does not
> depend on the first two. It applies to v1.7.6.1, maint, and master.
> Would be great if you could test.
Hi Clemens,
I've just gotten round to test patch 3/3 and it works perfectly against
1.7.6 as well as 1.7.6.1. It suppresses the output if the remote git
version is 1.7.6.1, like it should.
Thanks for your quick response,
Tobias
>
> Thanks,
> Clemens
^ permalink raw reply
* Re: [PATCH 10/10] want_color: automatically fallback to color.ui
From: Jeff King @ 2011-09-04 12:53 UTC (permalink / raw)
To: Martin von Zweigbergk
Cc: git, Junio C Hamano, Steffen Daode Nurpmeso, Ingo Brückl
In-Reply-To: <alpine.DEB.2.00.1109032212310.12564@debian>
On Sat, Sep 03, 2011 at 10:36:01PM -0400, Martin von Zweigbergk wrote:
> This patch makes format-patch output color escape codes to file when
> run with color.ui=always. Before the patch it did not do that. The
> documentation for color.ui says "Set it to always if you want all
> output not intended for machine consumption to use color". Is
> format-patch "intended for machine consumption" or not?
Sorry, this is a regression. The old behavior was that commands had to
copy color.ui's value manually into diff_use_color_default. With my
patch, the value is picked up automatically, and it is up to commands to
load or not load the specified config.
For diff plumbing versus porcelain, we have separate config code paths
(diff_basic versus diff_ui). I forgot that format-patch versus log has
the same situation, and needs the same split.
It's a long weekend here in the US, but I'll try to get a patch out on
Tuesday (and also check for any other similar regressions).
> I'm not sure why I had the parameter set to "always" instead of
> "true/auto" and maybe I should change it, but since this patch changes
> the behavior, I thought I should let you know (it was not mentioned in
> the commit message, so I'm not sure it was intentional).
Yeah, I don't think setting color.ui to "always" is all that useful. But
this behavior change was definitely not intentional. Thanks for
noticing.
-Peff
^ permalink raw reply
* Re: Lost association between TAGS and COMMITs when rebased a git(1) repository
From: Michael Witten @ 2011-09-04 13:40 UTC (permalink / raw)
To: PJ Weisberg; +Cc: John S. Urban, git
In-Reply-To: <CAJsNXTmJo6UXYS4AXygSLq2+T8MV0Sp0KhUt_mvgMqxC_k27ig@mail.gmail.com>
On Sun, Sep 4, 2011 at 10:02, PJ Weisberg <pj@irregularexpressions.net> wrote:
> On Sat, Sep 3, 2011 at 6:32 PM, John S. Urban <urbanjost@comcast.net> wrote:
>> With my first use of git(1) I created a small project with about 200
>> "commits". When this was complete, I needed to label each commit with
>> information pointing it to a section of a document. I used tags for this. So
>> far, everything was fine. I was then asked to merge two commits
>> into one. I then did a "rebase" (for the first time). I then appear to have
>> lost all association between the tags and the effected commits; as all
>> commits after
>> the ones I modified no longer see "their" tags. Was there a way to have kept
>> the tags associated with the original commits as they were "rebased"?
>
> ...
>
> My point is that the tags are still there, and they still point to the
> same commits they always pointed to. It's just that those commits are
> part of the original history, not the alternate history created by the
> rebase. People say that Git can "rewrite" history, but really it
> creates a new history for the branch. The old history is still around
> as long as there are references to it, until the garbage collector
> picks it up.
>
> Once a tag points to a commit, it isn't meant to be easy to make it
> point to a different commit. For the same reason that you wouldn't
> release version 1.8.3 of some software, and then later make a new
> release also called 1.8.3.
Perhaps `git rebase' should accept a `--tags' flag to tell it to
rewrite tags (or should I say `recreate' in the case of tag objects).
Git should not get in the way of people who know what they are doing.
^ permalink raw reply
* Lost association between TAGS and COMMITs when rebased a git(1) repository
From: Michael Witten @ 2011-09-04 14:03 UTC (permalink / raw)
To: John S. Urban; +Cc: git
In-Reply-To: <FF0364F3D5244CA4987EDDCFE7244BF3@urbanjsPC>
On Sat, 3 Sep 2011 21:32:03 -0400, John S. Urban wrote:
> With my first use of git(1) I created a small project with about 200
> "commits". When this was complete, I needed to label each commit with
> information pointing it to a section of a document.
What exactly does that mean?
> I used tags for this.
It sounds like `git notes' or rewritten commit messages would be what is
appropriate.
> So far, everything was fine. I was then asked to merge two commits
> into one. I then did a "rebase" (for the first time).
You mean `squash'; the term `merge' has a specific meaning in git
nomenclature.
> Also, I have some commits with multiple tags pointing to them. It has come
> to my attention that might not be an intentional feature. I could find
> nothing in the documentation explicitly stating multiple tags were allowed
> to point to a commit; but the tags seem to be unique "objects" so I
> see no reason this should not be an expected feature?
Well, everybody, it sounds like John's confusion is a good example for
why `tag' is another TERRIBLE choice of terminology.
See here:
http://article.gmane.org/gmane.comp.version-control.git/179609
Message-ID: <CAMOZ1Btmk86vmp1gRuCfG7yRuc6fD3_oYBvtq2VKK9Ywu8ay0A@mail.gmail.com>
http://article.gmane.org/gmane.comp.version-control.git/179942
Message-ID: <CAMOZ1Bti3ZtAEOtLiUYSkWE+rO_VQd09NAn58Cn4hZBu8f-aFQ@mail.gmail.com>
^ permalink raw reply
* Re: Lost association between TAGS and COMMITs when rebased a git(1) repository
From: knittl @ 2011-09-04 14:30 UTC (permalink / raw)
To: John S. Urban; +Cc: git
In-Reply-To: <FF0364F3D5244CA4987EDDCFE7244BF3@urbanjsPC>
On Sun, Sep 4, 2011 at 3:32 AM, John S. Urban <urbanjost@comcast.net> wrote:
> With my first use of git(1) I created a small project with about 200
> "commits". When this was complete, I needed to label each commit with
> information pointing it to a section of a document. I used tags for this.
Use git notes[1] to attach additional info to existing commits. Git
notes will by default be copied when using git rebase or git commit
--amend (cf. notes.rewrite.<command> config)
> So far, everything was fine. I was then asked to merge two commits
> into one. I then did a "rebase" (for the first time). I then appear to have
> lost all association between the tags and the effected commits; as all
> commits after
> the ones I modified no longer see "their" tags. Was there a way to have kept
> the tags associated with the original commits as they were "rebased"?
"Rebase" takes commits and creates new commits from those. The new
commits are not the same as the old, although they might have
associated the same tree or changeset.
> Also, I have some commits with multiple tags pointing to them. It has come
> to my attention that might not be an intentional feature. I could find
> nothing in the documentation explicitly stating multiple tags were allowed
> to point to a commit; but the tags seem to be unique "objects" so I
> see no reason this should not be an expected feature?
Tags can point to any git object (commits, trees, blobs, notes, even
to other annotated tags). There's nothing wrong with that.
[1]: http://www.kernel.org/pub/software/scm/git/docs/git-notes.html
--
typed with http://neo-layout.org
myFtPhp -- visit http://myftphp.sf.net -- v. 0.4.7 released!
^ permalink raw reply
* Re: Lost association between TAGS and COMMITs when rebased a git(1) repository
From: Michael Witten @ 2011-09-04 14:43 UTC (permalink / raw)
To: knittl; +Cc: John S. Urban, git
In-Reply-To: <CACx-yZ3tav1sJnLtJOn_YugQOsM9ERi7Cc7SowunyobxxX5YdA@mail.gmail.com>
On Sun, Sep 4, 2011 at 14:30, knittl <knittl89@googlemail.com> wrote:
> "Rebase" takes commits and creates new commits from those. The new
> commits are not the same as the old, although they might have
> associated the same tree or changeset.
According to `git help glossary':
changeset
BitKeeper/cvsps speak for "commit".
Since git does not store changes, but states,
it really does not make sense to use the term
"changesets" with git.
Git's erroneous nomenclature is bad enough as it is, so please try
not to explain things using such spurious terminology.
^ permalink raw reply
* Re: Lost association between TAGS and COMMITs when rebased a git(1) repository
From: Michael Witten @ 2011-09-04 14:38 UTC (permalink / raw)
To: Brandon Casey; +Cc: git, John S. Urban, PJ Weisberg
In-Reply-To: <CA+sFfMcMgPDyCi6SCS=Sc4XFrug_Ee7vbmBBkmkwfwwpXg8yCg@mail.gmail.com>
On Sun, Sep 4, 2011 at 14:16, Brandon Casey <drafnel@gmail.com> wrote:
> That's true, but git is also a tool with a purpose and tags are intended to
> be permanent.
Tag *objects* are intended to be permanent (like commit objects);
however, don't forget about `lightweight' tags.
> A valid workflow would need to be demonstrated before such a
> high-level operation as rebase made it so trivial to rewrite tags methinks.
How is it any different than doing the same with commits?
Let's say I have a private repository with an appreciable graph of
commits and collection of tags, and that I want to clean up the
history a bit before publishing it publicly. Well, it might save me
a lot of trouble if I could use `rebase' to create an alternative
history without also having to dicker around with creating the
associated tags.
^ permalink raw reply
* Re: Lost association between TAGS and COMMITs when rebased a git(1) repository
From: Jakub Narebski @ 2011-09-04 15:39 UTC (permalink / raw)
To: Michael Witten; +Cc: knittl, John S. Urban, git
In-Reply-To: <CAMOZ1BtxZ5C+pH_eEBu8=oqOyY6JkP8wiFmauyqcSOeijvgA+g@mail.gmail.com>
Michael Witten <mfwitten@gmail.com> writes:
> On Sun, Sep 4, 2011 at 14:30, knittl <knittl89@googlemail.com> wrote:
>
> > "Rebase" takes commits and creates new commits from those. The new
> > commits are not the same as the old, although they might have
> > associated the same tree or changeset.
>
> According to `git help glossary':
>
> changeset
> BitKeeper/cvsps speak for "commit".
> Since git does not store changes, but states,
> it really does not make sense to use the term
> "changesets" with git.
>
> Git's erroneous nomenclature is bad enough as it is, so please try
> not to explain things using such spurious terminology.
Actually "changeset", at least in the original meaning as the set of
changes (the difference between two snapshots), is perfectly in place
here: rebase operation preserves changes which means that it copies
changesets, at least if there are no conflicts.
--
Jakub Narębski
^ permalink raw reply
* Re: Retrieving logs matching pattern for all time.
From: Thomas Rast @ 2011-09-04 16:13 UTC (permalink / raw)
To: Jeremy Nickurak; +Cc: git
In-Reply-To: <CA+eQo_0gZpbz399GN1b+0mq8OY3Xoo+kij=UGSjwbJcNreYBvw@mail.gmail.com>
Jeremy Nickurak wrote:
> > user@host:~/something$ git log -- 'hel*'
> > user@host:~/something$
>
> IE, git doesn't seem to interpret globs itself in patterns.
It does for me:
thomas@thomas:~/g(next u+59)$ g log --oneline --name-status -- "REA*"
f73b3af README: git lives at http://git-scm.com these days
M README
etc.
Which git version are you using?
--
Thomas Rast
trast@{inf,student}.ethz.ch
^ permalink raw reply
* Re: Lost association between TAGS and COMMITs when rebased a git(1) repository
From: John S. Urban @ 2011-09-04 16:40 UTC (permalink / raw)
To: git
In-Reply-To: <CACx-yZ1Ce3x=ZSdm5iY3JqYjVGVs5uPnb12-tMJP7zWsGuMK_Q@mail.gmail.com>
Thanks to all for the replies. Perhaps the tutorials should mention notes
more often. I used several introductory
manuals; all of which mentioned tags and none of which mentioned notes. The
tags seem (in retrospect) useful when
I want additional sign-off capabilities. If the tags are seen only as a
sign-off mechanism I understand why they do not
retain their associations when you "rewrite history"; but I really would
like to see a --tags option on the rebase option
that lets tags keep their associations when they are not signed, as one
reply suggested.
Notes are definitely more appropriate for my purpose than tags, however. I
haven't tried them yet but will shortly.
I hope to see that
they show up in gitk(1) as nicely as the tags do. I've been using the line
mode but the reviewers are very happy with
gitk(1) as an efficient way to review and sign changes (especially simple
ones).
Now that I've used the basics enough to find git(1) useful I guess it's time
to read the complete manual before I shoot
myself in the foot again (yeehh, like that will happen!).
Much appreciated!
----- Original Message -----
From: "knittl" <knittl89@googlemail.com>
To: "John S. Urban" <urbanjost@comcast.net>
Sent: Sunday, September 04, 2011 3:55 AM
Subject: Re: Lost association between TAGS and COMMITs when rebased a git(1)
repository
On Sun, Sep 4, 2011 at 3:32 AM, John S. Urban <urbanjost@comcast.net> wrote:
> With my first use of git(1) I created a small project with about 200
> "commits". When this was complete, I needed to label each commit with
> information pointing it to a section of a document. I used tags for this.
Use git notes[1] to attach additional info to existing commits. Git
notes will by default be copied when using git rebase or git commit
--amend (cf. notes.rewrite.<command> config)
> So far, everything was fine. I was then asked to merge two commits
> into one. I then did a "rebase" (for the first time). I then appear to
> have
> lost all association between the tags and the effected commits; as all
> commits after
> the ones I modified no longer see "their" tags. Was there a way to have
> kept
> the tags associated with the original commits as they were "rebased"?
"Rebase" takes commits and creates new commits from those. The new
commits are not the same as the old, although they might have
associated the same tree or changeset.
> Also, I have some commits with multiple tags pointing to them. It has come
> to my attention that might not be an intentional feature. I could find
> nothing in the documentation explicitly stating multiple tags were allowed
> to point to a commit; but the tags seem to be unique "objects" so I
> see no reason this should not be an expected feature?
Tags can point to any git object (commits, trees, blobs, notes, even
to other annotated tags). There's nothing wrong with that.
[1]: http://www.kernel.org/pub/software/scm/git/docs/git-notes.html
--
typed with http://neo-layout.org
myFtPhp -- visit http://myftphp.sf.net -- v. 0.4.7 released!
^ permalink raw reply
* Re: Lost association between TAGS and COMMITs when rebased a git(1) repository
From: Philip Oakley @ 2011-09-04 17:20 UTC (permalink / raw)
To: Michael Witten, John S. Urban; +Cc: git
In-Reply-To: <3c10d6593152436c9dd3a5b5773e3c79-mfwitten@gmail.com>
From: "Michael Witten" <mfwitten@gmail.com>
> On Sat, 3 Sep 2011 21:32:03 -0400, John S. Urban wrote:
>> Also, I have some commits with multiple tags pointing to them. It has
>> come
>> to my attention that might not be an intentional feature. I could find
>> nothing in the documentation explicitly stating multiple tags were
>> allowed
>> to point to a commit; but the tags seem to be unique "objects" so I
>> see no reason this should not be an expected feature?
>
> Well, everybody, it sounds like John's confusion is a good example for
> why `tag' is another TERRIBLE choice of terminology.
>
> See here:
>
> http://article.gmane.org/gmane.comp.version-control.git/179609
> Message-ID:
> <CAMOZ1Btmk86vmp1gRuCfG7yRuc6fD3_oYBvtq2VKK9Ywu8ay0A@mail.gmail.com>
>
> http://article.gmane.org/gmane.comp.version-control.git/179942
> Message-ID:
> <CAMOZ1Bti3ZtAEOtLiUYSkWE+rO_VQd09NAn58Cn4hZBu8f-aFQ@mail.gmail.com>
> --
In terms of things understood and misunderstood, I found that Branches and
Tags were reasonable terms for use within Git at the time I read about them
(I'm still getting to grips with git in a hostile Windows environment).
There were other areas of confusing (to me) terminology, such as heads,
tips, and refs, which are 'the same' within particular contexts. In the same
way the Index/Staging area can be confusing without a good visualisation.
The fact that Git has both Trees, and Branches but relating to different
parts of the architecture can be a bit confusing, but wasn't too much of a
hassle.
The fact that git does merging with relative ease is one reason that brings
on the 'branch' problem. If merging is a major activity that is kept
independent of the SCM, as it often is, then branches take on a bigger
meaning as being proper sub-projects with all the attention that comes from
there. If they are simple, lightweight, easy to use, and 'discard' then the
concerns should reduce, unless that is, local customs keep worrying the
issue. Most SCM systems are built on archaic principles that pre-date
computers, so a new methodology has an uphill battle.
In terms of Figure 0 in Sourceforge, It doesn't fully represent the
information that Git would have, because the order of parentage would be
available, though Git doesn't mandate that branch names are remembered (but
is normally within merge commit messages). This means that some folks would
feel unhappy about the bundle of diverge/merge links in the DAG that don't
have Names, which is a very human concern.
Overall, I'm not too unhappy with the terminology, and yes I would like
filter-branch to be able to copy across tags when creating a publishable
history - it probably just need me to understnd the right --tag-name-filter
<command>.
Philip
^ permalink raw reply
* Re: Lost association between TAGS and COMMITs when rebased a git(1) repository
From: knittl @ 2011-09-04 18:15 UTC (permalink / raw)
To: Philip Oakley; +Cc: Michael Witten, John S. Urban, git
In-Reply-To: <1B5C619E91F7437EA844D1D3DD3E6798@PhilipOakley>
On Sun, Sep 4, 2011 at 7:20 PM, Philip Oakley <philipoakley@iee.org> wrote:
> Overall, I'm not too unhappy with the terminology, and yes I would like
> filter-branch to be able to copy across tags when creating a publishable
> history - it probably just need me to understand the right --tag-name-filter
> <command>.
filter-branch --tag-name-filter 'cat' ;) – it's even mentioned in the
manpage of filter-branch:
> The original tags are not deleted, but can be overwritten; use
> "--tag-name-filter cat" to simply update the tags. In this case, be
> very careful and make sure you have the old tags backed up in case
> the conversion has run afoul.
unless you meant rebase with filter-branch?
--
typed with http://neo-layout.org
myFtPhp -- visit http://myftphp.sf.net -- v. 0.4.7 released!
^ permalink raw reply
* Re: Lost association between TAGS and COMMITs when rebased a git(1) repository
From: Tor Arntsen @ 2011-09-04 18:16 UTC (permalink / raw)
To: knittl; +Cc: John S. Urban, git
In-Reply-To: <CACx-yZ3tav1sJnLtJOn_YugQOsM9ERi7Cc7SowunyobxxX5YdA@mail.gmail.com>
On Sun, Sep 4, 2011 at 4:30 PM, knittl <knittl89@googlemail.com> wrote:
>
> On Sun, Sep 4, 2011 at 3:32 AM, John S. Urban <urbanjost@comcast.net> wrote:
> > With my first use of git(1) I created a small project with about 200
> > "commits". When this was complete, I needed to label each commit with
> > information pointing it to a section of a document. I used tags for this.
>
> Use git notes[1] to attach additional info to existing commits. Git
> notes will by default be copied when using git rebase or git commit
> --amend (cf. notes.rewrite.<command> config)
Is that true? I've always lost the notes when rebasing. I just tried
that again now (1.7.5.4), and after a rebase the notes attached to any
commit that was rebased just disappeared. I've always had to hunt down
and re-create the notes. It would indeed be much more convenient if
the notes would tag along.
-Tor
^ permalink raw reply
* Re: Lost association between TAGS and COMMITs when rebased a git(1) repository
From: Thomas Rast @ 2011-09-04 18:43 UTC (permalink / raw)
To: Tor Arntsen; +Cc: knittl, John S. Urban, git
In-Reply-To: <CABNEGjyXLnSvjhBewNDsjW=rthRh0HY+KgC05vPNPu5QCaAgXQ@mail.gmail.com>
Tor Arntsen wrote:
> On Sun, Sep 4, 2011 at 4:30 PM, knittl <knittl89@googlemail.com> wrote:
> >
> > On Sun, Sep 4, 2011 at 3:32 AM, John S. Urban <urbanjost@comcast.net> wrote:
> > > With my first use of git(1) I created a small project with about 200
> > > "commits". When this was complete, I needed to label each commit with
> > > information pointing it to a section of a document. I used tags for this.
> >
> > Use git notes[1] to attach additional info to existing commits. Git
> > notes will by default be copied when using git rebase or git commit
> > --amend (cf. notes.rewrite.<command> config)
>
> Is that true? I've always lost the notes when rebasing. I just tried
> that again now (1.7.5.4), and after a rebase the notes attached to any
> commit that was rebased just disappeared. I've always had to hunt down
> and re-create the notes. It would indeed be much more convenient if
> the notes would tag along.
Yes, that support has been present since 1.7.1, but it's not enabled
by default: you need to configure notes.rewriteRef.
--
Thomas Rast
trast@{inf,student}.ethz.ch
^ permalink raw reply
* Re: Retrieving logs matching pattern for all time.
From: Junio C Hamano @ 2011-09-04 18:59 UTC (permalink / raw)
To: Thomas Rast; +Cc: Jeremy Nickurak, git
In-Reply-To: <201109041813.24418.trast@student.ethz.ch>
Thomas Rast <trast@student.ethz.ch> writes:
> Jeremy Nickurak wrote:
>> > user@host:~/something$ git log -- 'hel*'
>> > user@host:~/something$
>>
>> IE, git doesn't seem to interpret globs itself in patterns.
>
> It does for me:
>
> thomas@thomas:~/g(next u+59)$ g log --oneline --name-status -- "REA*"
> f73b3af README: git lives at http://git-scm.com these days
> M README
>
> etc.
The "git log" family learned globbing pathspecs in 1.7.5 if I believe the
Release Notes.
^ permalink raw reply
* Re: [BUG] git push --quiet fails with older versions
From: Junio C Hamano @ 2011-09-04 19:02 UTC (permalink / raw)
To: Tobias Ulmer; +Cc: git, Clemens Buchacher
In-Reply-To: <20110903105723.GA16304@tin.tmux.org>
Tobias Ulmer <tobiasu@tmux.org> writes:
> my distro updated git to 1.7.6.1. Now git push --quiet, used in various
> scripts, blows up against 1.7.6.
This kind of regression is not acceptable not just for point maintenance
release, but for feature releases. 1.7.7 client must work with 1.7.6
server just fine without such a breakage. I should have been more careful
when reviewing.
Thanks for a report, Tobias, and thanks for a quick fix, Clemens.
^ 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