Re: [RFC/PATCH 3/3] push: add separate 'downstream' branch
Felipe Contreras writes: > ...for me > it's more important that 'git fetch' works sanely (patch #1), and I > don't like the proposed patch, but I can't think of anything better. I do not like that either, but I haven't formed a firm opinion on it yet. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC/PATCH 3/3] push: add separate 'downstream' branch
On Thu, May 16, 2013 at 12:36 AM, Junio C Hamano wrote: > Felipe Contreras writes: > >> It doesn't make sense to push to the upstream branch, so create new >> configurations for the notion of 'downstream' branch, which is basically >> the branch to push to by default. > > It doesn't? That depends. > > To people coming from (and people who are still using) central > shared repository workflow, pushing to anywhere other than the > upstream makes no sense. Semantics I guess; you can say they are pushing to the upstream, or that they are pushing downstream, which happens to be the same as the upstream. My rationale was that at some point in the future we might want to remove the code that pushes upstream, and only push downstream. And either way configure downstream when creating new branches with tracking. But I'm not sure that's a good idea. > If qualified with something like "When using a triangular workflow > to pull from one place and push to another place" in front, I can > see why having a separate upstream and downstream makes sense, and... > >> The upstream branch is remote+merge, the downstream branch is >> pushremote+push. > > ... this is a perfect explanation of what a downsream is. Cool. I haven't decided how best to set the downstream yet, but for me it's more important that 'git fetch' works sanely (patch #1), and I don't like the proposed patch, but I can't think of anything better. -- Felipe Contreras -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: English/German terminology, git.git's de.po, and pro-git
Hi, I think the discussion might work better via ML than GitHub. This is the full glossary of git's de.po as it would look like with (hopefully) all the changes included that have been discussed here. Still without any reasoning for decisions (except HEAD). Thanks for reading. +Basic repository objects: + +blob = Blob +tree = Baum, Baum-Objekt (bevorzugt), "Tree"-Objekt +submodule = Submodul +pack(noun) = Pack-Datei +pack(verb) = packen (ggf. Pack-Datei erstellen) +ancestor = Vorfahre, Vorgänger, Vorgänger-Commit (bevorzugt) + +Content in a repository: + +file(s)= Datei(en) +tracked file = beobachtete Datei +track file = beobachte Datei +untracked file = unbeobachtete Datei +directory = Verzeichnis + +Repositories / tracking concepts: + +clone (verb) = klonen +clone (noun) = der Klon +repository = Repository + +bare repository= bloßes Repository +working directory = Arbeitsverzeichnis + +remote branch = externer Zweig +remote tracking branch = externer Übernahmezweig +upstream branch= -||- +tracking branch= Übernahmezweig + +remote repository = externes Repository +remote(noun) = -||- +remote(adj)= extern + +Authorship: + +author= Autor +committer = Commit-Ersteller +tagger= Tag-Ersteller + +Commits, tags and other references: + +HEAD = HEAD + Konzept aus der Git-Welt, daher nicht zu übersetzen. +detached HEAD = losgelöster HEAD + +commit(noun) = Commit +commit(verb) = committen +commit the result = das Ergebnis committen +parent commit = Eltern-Commit +child commit = Kind-Commit +commit message= Commit-Beschreibung + +stash(noun) = der Stash +stash(verb) = "stashen", "stash" benutzen (bevorzugt) +unstash(verb) = "unstashen", "zurückladen", "aus 'stash' zurückladen" (bevorzugt) + +reference = Referenz +revision = Commit +branch = Zweig (or Branch) +tag(noun) = Tag +tag(verb) = taggen, Tag erstellen +annotated tag = annotierter Tag +tag message= Tag-Beschreibung + +orphan commit= +orphan reference = + +boundary commit = Grenz-Commit +root commit = Ursprungs-Commit, Wurzel-Commit + +stage/index (noun) = Staging-Area, Index +stage/index (verb) = (für einen | zum) Commit vormerken, zur Staging Area hinzufügen, dem Index hinzufügen +unstage (verb) = aus Staging Area entfernen/nehmen, aus Index entfernen/nehmen + +The DAG: + +commit graph = Commit-Graph +merge = Merge + +References in relation to other references: + +branches that have diverged = Zweige sind divergiert +diverging references= divergierte Referenzen +your branch is ahead= dein Zweig ist voraus +your branch is behind = dein Zweig ist hinterher + +Moving data around: + +fetch = anfordern +pull = zusammenführen +push = versenden + +fast-forward = vorspulen +non-fast-forward = nicht vorspulen + +Commands: + +log= Log +interactive commit = interaktiver Commit +cherry-pick= "cherry-pick" benutzen +rebase(verb) = "rebase" benutzen +rebase(noun) = "rebase" +archive= archivieren +revert = zurücknehmen +clean(verb)= +clean(noun)= +merge = mergen + +bundle(noun) = Paket +bundle(verb) = Paket erstellen +unbundle(verb) = Paket entpacken + +bisect = binäre Suche +bisecting = bei einer binären Suche sein, binäre Suche durchführen + +Diff/patch related: + +diff = Differenz +delta = Differenz (or Delta) +patch = Patch +apply = anwenden +diffstat = (leave it as it is) +hunk = Bereich +whitespace = Leerzeichen (FIXME?) (maybe "Leerraum") + +Still being worked out: + +prune = veraltete(n) Zweig(e) entfernen +checkout(verb) = auschecken + +git add = hinzufügen + +merge conflict = Merge-Konflikt +3-way merge= 3-Wege-Merge +paths = Pfade + +symbolic link = symbolische Verknüfung +path = Pfad +link = Verknüpfung + +reflog = Referenzprotokoll +partial commit = teilweise committen, partiell committen + +reset = neu setzen (maybe "umsetzen"?) + +register = in die Konfiguration eintragen +unregister = aus der Konfiguration austragen -- -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/4] resolve_ref: close race condition for packed refs
On 05/16/2013 05:47 AM, Jeff King wrote: >> I probably would have separated the rest of the patch, which is a pure >> refactoring, from this last chunk, which is a functional change. But >> that's just me. > > Yeah, I go back and forth on whether it is better to have strict > refactors followed by changes or not. Sometimes it is hard to understand > the motivation for the refactor without seeing the change, and you end > up explaining it twice. A pure refactoring doesn't need much justification. Something like "extract function foo()" plus maybe "this function will soon have multiple callers" is IMO usually adequate, especially if the function is well-named and documented in the patch itself. > My usual rule of thumb is: > > - If you are factoring out some code, and then are going to change > that code, make it two separate changes. That keeps the diffs > readable (the first one is pure movement and you do not need to look > closely, and the second shows a sane diff of the change). > > - If you are factoring out some code, and then adding more callers, > it's OK to do it together. The new caller provides the motivation > for the refactor. > > This is the latter case. But I'm open to arguments that the rule is not > a good one. :) Yes, I see how keeping the changes together makes the justification of the refactoring more obvious. On the other hand, splitting has the following benefits: 1. Reviewers have a single thing to check in each patch: "Did he transcribe the code correctly into a function and choose a good API?" vs. "Does it make sense to call the function from this new place?" The threads of feedback emails about each patch are similarly separated. On the other hand, of course these two changes are not completely independent, because having an idea what new callers want to do with the function affects what its API should be. 2. If the patch series needs to be revised, it is quite possible that the revisions affect only one patch or the other. Therefore, the unaffected patch can be carried along through interactive rebases etc. intact, or might serve as a building block for an alternative solution. 3. If there's a problem, bisect can figure out which half of the change was to blame. That being said, this case is very much in the gray area where it is a matter of personal preference and I don't mind at all if you leave it as a single patch. Michael -- Michael Haggerty mhag...@alum.mit.edu http://softwareswirl.blogspot.com/ -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC/PATCH 3/3] push: add separate 'downstream' branch
Felipe Contreras writes: > It doesn't make sense to push to the upstream branch, so create new > configurations for the notion of 'downstream' branch, which is basically > the branch to push to by default. It doesn't? That depends. To people coming from (and people who are still using) central shared repository workflow, pushing to anywhere other than the upstream makes no sense. If qualified with something like "When using a triangular workflow to pull from one place and push to another place" in front, I can see why having a separate upstream and downstream makes sense, and... > The upstream branch is remote+merge, the downstream branch is > pushremote+push. ... this is a perfect explanation of what a downsream is. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v6 2/2] imap-send: eliminate HMAC deprecation warnings on Mac OS X
David Aguilar writes: > On Wed, May 15, 2013 at 5:39 PM, Junio C Hamano wrote: >> David Aguilar writes: >> >>> Mac OS X 10.8 Mountain Lion warns that HMAC_Init() and friends >>> are deprecated. Detect the COMMON_CRYPTO_FOR_OPENSSL definition >> >> Ahh, I think you meant to use that name but forgot to adjust the >> symbol you use in the patch ;-) >> >> I'll queue with s/COMMON_DIGEST_FOR_OPENSSL/COMMON_CRYPTO_FOR_OPENSSL/; > > The symbol in Apple's header is COMMON_DIGEST_FOR_OPENSSL. Sigh. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/4] add a stat_validity struct
On Mon, May 13, 2013 at 04:29:34AM +0200, Michael Haggerty wrote: > > This patch introduces a "stat_validity" struct which > > encapsulates the concept of checking the stat-freshness of a > > file. It is implemented on top of "struct cache_entry" to > > reuse the logic about which stat entries to trust for a > > particular platform, but hides the complexity behind two > > simple functions: check and update. > > Given that "struct cache_entry" holds a lot of information that is > irrelevant to stat-freshness and that ce_match_stat_basic() has a lot of > logic that is geared towards cache_entries, it seems like there should > be some kind of "struct stat_data" that holds the portion of the stat > information that we use for checking whether a file might have been > changed between two accesses. cache_entry would contain a stat_data as > a member, and the functionality for checking that part of a cache_entry > validity would be moved to a separate function. > > Then your "struct validity_info" could hold a pointer to a stat_data > rather than to a cache_entry, and it wouldn't have to contain the > unrelated cache_entry stuff. Yes, I had the exact same thought, and came up with the exact same solution. I was just hesitant to do it because it meant touching all of the cache_entry users to adjust their struct accesses. But from your patches, it doesn't look too bad (and we can be sure we updated every spot, because it's easy for the compiler to enforce). I'm sorry to be so slow lately; I'm on vacation (and will be for a bit yet). I'm happy to rebuild my series on top of yours, and it looks like it is still only in pu (I haven't yet read "What's Cooking" to see the plans for it). I don't think there's a rush, as it is post-1.8.3 anyway (I _do_ think it's a serious bug, in that it can cause data loss, but in practice I doubt most people would hit it). -Peff -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/4] resolve_ref: close race condition for packed refs
On Mon, May 13, 2013 at 12:56:05AM +0200, Michael Haggerty wrote:
> > + * This should be called from resolve_ref_unsafe when a loose ref cannot be
> > + * accessed; err must represent the errno from the last attempt to access
> > the
> > + * loose ref, and the other options are forwarded from
> > resolve_safe_unsaefe.
>
> s/resolve_ref_unsaefe/resolve_ref_unsafe/
Oops, thanks.
> > - return NULL;
> > + return handle_loose_ref_failure(errno, refname, sha1,
> > + reading, flag);
>
> I probably would have separated the rest of the patch, which is a pure
> refactoring, from this last chunk, which is a functional change. But
> that's just me.
Yeah, I go back and forth on whether it is better to have strict
refactors followed by changes or not. Sometimes it is hard to understand
the motivation for the refactor without seeing the change, and you end
up explaining it twice.
My usual rule of thumb is:
- If you are factoring out some code, and then are going to change
that code, make it two separate changes. That keeps the diffs
readable (the first one is pure movement and you do not need to look
closely, and the second shows a sane diff of the change).
- If you are factoring out some code, and then adding more callers,
it's OK to do it together. The new caller provides the motivation
for the refactor.
This is the latter case. But I'm open to arguments that the rule is not
a good one. :)
> I suggest adding a comment here mentioning briefly the race condition
> that the call to handle_loose_ref_failure() is meant to address;
> otherwise somebody not thinking of race conditions might have the clever
> idea of "inlining" the call to "return NULL" because it seems redundant
> with the check of ENOENT following the lstat() call above.
Yeah, I thought I had mentioned that at the top of
handle_loose_ref_failure, but I see that I didn't. Probably something
like this squashed on top makes sense:
diff --git a/refs.c b/refs.c
index c127baf..1a7e4ef 100644
--- a/refs.c
+++ b/refs.c
@@ -,7 +,7 @@ static int get_packed_ref(const char *refname, unsigned
char *sha1)
/*
* This should be called from resolve_ref_unsafe when a loose ref cannot be
* accessed; err must represent the errno from the last attempt to access the
- * loose ref, and the other options are forwarded from resolve_safe_unsaefe.
+ * loose ref, and the other options are forwarded from resolve_safe_unsafe.
*/
static const char *handle_loose_ref_failure(int err,
const char *refname,
@@ -1200,9 +1200,16 @@ const char *resolve_ref_unsafe(const char *refname,
unsigned char *sha1, int rea
* a ref
*/
fd = open(path, O_RDONLY);
- if (fd < 0)
+ if (fd < 0) {
+ /*
+* We need to check again here for ENOENT and fall back
+* to the packed-refs file to avoid a race condition in
+* which the ref is packed and pruned between our
+* lstat() and open() calls.
+*/
return handle_loose_ref_failure(errno, refname, sha1,
reading, flag);
+ }
len = read_in_full(fd, buffer, sizeof(buffer)-1);
close(fd);
if (len < 0)
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] New kind of upstream branch: base branch
On Wed, May 15, 2013 at 5:22 PM, Philip Oakley wrote: > Sound a reasonable idea. On some patches I was working on I had to [chose > to] add a tag for the base which made it easier to rebase later. And was the 'upstream' branch somehow not appropriate for some reason? -- Felipe Contreras -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[RFC/PATCH 2/3] pull: trivial cleanups
Signed-off-by: Felipe Contreras
---
git-pull.sh | 6 ++
1 file changed, 2 insertions(+), 4 deletions(-)
diff --git a/git-pull.sh b/git-pull.sh
index 75297c7..b207df2 100755
--- a/git-pull.sh
+++ b/git-pull.sh
@@ -166,9 +166,7 @@ error_on_no_merge_candidates () {
op_prep=with
fi
- curr_branch=${curr_branch#refs/heads/}
- upstream=$(git config "branch.$curr_branch.merge")
- remote=$(git config "branch.$curr_branch.remote")
+ upstream=$(git config "branch.$curr_branch_short.merge")
if [ $# -gt 1 ]; then
if [ "$rebase" = true ]; then
@@ -183,7 +181,7 @@ error_on_no_merge_candidates () {
echo "You asked to pull from the remote '$1', but did not
specify"
echo "a branch. Because this is not the default configured
remote"
echo "for your current branch, you must specify a branch on the
command line."
- elif [ -z "$curr_branch" -o -z "$upstream" ]; then
+ elif [ -z "$curr_branch_short" -o -z "$upstream" ]; then
. git-parse-remote
error_on_missing_default_upstream "pull" $op_type $op_prep \
"git pull "
--
1.8.3.rc1.579.g184e698
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[RFC/PATCH 3/3] push: add separate 'downstream' branch
It doesn't make sense to push to the upstream branch, so create new
configurations for the notion of 'downstream' branch, which is basically
the branch to push to by default.
The upstream branch is remote+merge, the downstream branch is
pushremote+push.
[branch "master"]
remote = origin
merge = refs/heads/master
pushremote = github
push = refs/heads/master
Signed-off-by: Felipe Contreras
---
builtin/push.c | 65 --
remote.c | 8 ++--
remote.h | 3 +++
3 files changed, 50 insertions(+), 26 deletions(-)
diff --git a/builtin/push.c b/builtin/push.c
index 909c34d..c062fa5 100644
--- a/builtin/push.c
+++ b/builtin/push.c
@@ -76,21 +76,23 @@ static int push_url_of_remote(struct remote *remote, const
char ***url_p)
return remote->url_nr;
}
-static NORETURN int die_push_simple(struct branch *branch, struct remote
*remote) {
+static NORETURN int die_push_simple(struct branch *branch, struct remote
*remote,
+ const char *kind, const char *related)
+{
/*
* There's no point in using shorten_unambiguous_ref here,
* as the ambiguity would be on the remote side, not what
* we have locally. Plus, this is supposed to be the simple
* mode. If the user is doing something crazy like setting
-* upstream to a non-branch, we should probably be showing
+* upstream/downstream to a non-branch, we should probably be showing
* them the big ugly fully qualified ref.
*/
const char *advice_maybe = "";
- const char *short_upstream =
- skip_prefix(branch->merge[0]->src, "refs/heads/");
+ const char *short_upstream = skip_prefix(related, "refs/heads/");
if (!short_upstream)
- short_upstream = branch->merge[0]->src;
+ short_upstream = related;
+
/*
* Don't show advice for people who explicitely set
* push.default.
@@ -99,8 +101,8 @@ static NORETURN int die_push_simple(struct branch *branch,
struct remote *remote
advice_maybe = _("\n"
"To choose either option permanently, "
"see push.default in 'git help config'.");
- die(_("The upstream branch of your current branch does not match\n"
- "the name of your current branch. To push to the upstream
branch\n"
+ die(_("The %s branch of your current branch does not match\n"
+ "the name of your current branch. To push to the %s branch\n"
"on the remote, use\n"
"\n"
"git push %s HEAD:%s\n"
@@ -109,6 +111,7 @@ static NORETURN int die_push_simple(struct branch *branch,
struct remote *remote
"\n"
"git push %s %s\n"
"%s"),
+ kind, kind,
remote->name, short_upstream,
remote->name, branch->name, advice_maybe);
}
@@ -117,6 +120,8 @@ static void setup_push_upstream(struct remote *remote, int
simple)
{
struct strbuf refspec = STRBUF_INIT;
struct branch *branch = branch_get(NULL);
+ const char *related, *kind, *pushremote_name;
+
if (!branch)
die(_("You are not currently on a branch.\n"
"To push the history leading to the current (detached
HEAD)\n"
@@ -124,26 +129,38 @@ static void setup_push_upstream(struct remote *remote,
int simple)
"\n"
"git push %s HEAD:\n"),
remote->name);
- if (!branch->merge_nr || !branch->merge || !branch->remote_name)
- die(_("The current branch %s has no upstream branch.\n"
- "To push the current branch and set the remote as upstream,
use\n"
- "\n"
- "git push --set-upstream %s %s\n"),
- branch->name,
- remote->name,
- branch->name);
- if (branch->merge_nr != 1)
- die(_("The current branch %s has multiple upstream branches, "
- "refusing to push."), branch->name);
- if (strcmp(branch->remote_name, remote->name))
- die(_("You are pushing to remote '%s', which is not the
upstream of\n"
+
+ if (branch->push) {
+ kind = _("downstream");
+ related = branch->push;
+ pushremote_name = branch->pushremote_name;
+ } else {
+ if (!branch->merge_nr || !branch->merge || !branch->remote_name)
+ die(_("The current branch %s has no upstream branch.\n"
+ "To push the current branch and set the remote as
upstream, use\n"
+ "\n"
+ "git push --set-upstream %s %s\n"),
+ branch->name,
+ remote->name,
[RFC/PATCH 1/3] remote: don't override default if cur head remote is '.'
'git fetch .' makes no sense, so let's keep using the default ('origin')
when the current branch's remote is '.'.
Also update 'git pull' so that pulling works the same way as before.
Signed-off-by: Felipe Contreras
---
git-pull.sh | 9 -
remote.c| 2 +-
2 files changed, 9 insertions(+), 2 deletions(-)
diff --git a/git-pull.sh b/git-pull.sh
index 638aabb..75297c7 100755
--- a/git-pull.sh
+++ b/git-pull.sh
@@ -220,7 +220,14 @@ test true = "$rebase" && {
done
}
orig_head=$(git rev-parse -q --verify HEAD)
-git fetch $verbosity $progress $dry_run $recurse_submodules --update-head-ok
"$@" || exit 1
+# get the default remote
+remote="$(git config "branch.$curr_branch_short.remote")"
+if test $# == 0 && test -n "$remote"
+then
+ git fetch $verbosity $progress $dry_run $recurse_submodules
--update-head-ok "$remote" || exit 1
+else
+ git fetch $verbosity $progress $dry_run $recurse_submodules
--update-head-ok "$@" || exit 1
+fi
test -z "$dry_run" || exit 0
curr_head=$(git rev-parse -q --verify HEAD)
diff --git a/remote.c b/remote.c
index 68eb99b..322a1b6 100644
--- a/remote.c
+++ b/remote.c
@@ -360,7 +360,7 @@ static int handle_config(const char *key, const char
*value, void *cb)
if (!strcmp(subkey, ".remote")) {
if (git_config_string(&branch->remote_name, key, value))
return -1;
- if (branch == current_branch) {
+ if (branch == current_branch &&
strcmp(branch->remote_name, ".")) {
default_remote_name = branch->remote_name;
explicit_default_remote_name = 1;
}
--
1.8.3.rc1.579.g184e698
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[RFC/PATCH 0/3] New kind of upstream branch: downstream branch
Hi,
After thinking a bit more about, I think the current 'upstream' branch serves
most of the purposes; actually tracks an upstream branch; makes sense to rebase
onto that, makes sense to fetch from that remote, merge, and pull.
The only job it doesn't make sense to use the 'upstream' branch for is to push,
so here's a new notion of 'downstream' branch.
These patches are only exploratory, 'git branch -v' doesn't show these
branches, there's no @{downstream}, no documentation, and there isn't even a
way to set it.
If there's no downstream branch configured, nothing changes.
Felipe Contreras (3):
remote: don't override default if cur head remote is '.'
pull: trivial cleanups
push: add separate 'downstream' branch
builtin/push.c | 65 --
git-pull.sh| 15 +-
remote.c | 10 ++---
remote.h | 3 +++
4 files changed, 61 insertions(+), 32 deletions(-)
--
1.8.3.rc1.579.g184e698
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 4/4] fetch: opportunistically update tracking refs
On Sun, May 12, 2013 at 11:41:45AM +0200, Thomas Rast wrote: > >> We miss an opportunity to update "refs/remotes/origin/master" > >> (or whatever the user has configured). Some users find this > >> confusing, because they would want to do further comparisons > >> against the old state of the remote master, like: > >> > >> $ git pull origin master > >> $ git log HEAD...origin/master > > > > I agree with the patch, but I would use a different reasoning. Your > > example here is not even correct because the range in the second command > > would be empty unless the merge conflicted. > > Meh, I just read this again and saw that you actually had *three* dots. > Serves me right for writing a reply on the phone. > > So the quoted part is indeed correct. Yes, it's correct, but it is a bit subtle. A better example would probably be: $ git status # On branch foo # Your branch is ahead of 'origin/master' by 2 commits. $ git pull origin master [pull 10 new commits] $ git status # On branch foo # Your branch is ahead of 'origin/master' by 13 commits. That is technically true, but only because origin/master is now out of date. The more interesting number is 3: the two commits we had already, plus the new merge commit. And of course there are infinite variations where you pull on one branch, and then switch branches to compare on another. But they all boil down to having an out-of-date view of origin/master that does not reflect the most recent pull. -Peff -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCHv3 3/7] show: honor --textconv for blobs
On Mon, May 13, 2013 at 04:57:55PM +0200, Michael J Gruber wrote: > > I don't think that it is a property of the file itself. That is, you do > > not say "foo files are inherently uninteresting to git-show, and > > therefore we always convert them, whereas bar files do not have that > > property'. You say "in my workflows, I expect to see converted results > > from grep/show". And the latter points to using config, like either > > "diff.*.showConverted" (to allow per-type setting), or even > > "grep.useTextconv" and "show.textConv" (to allow setting it per-user for > > all types). > > I strongly disagree here. I have textconv filters for pdf, gpg, odf, > xls, doc, xoj... I know, ugly. At least some of them would benefit from > different filteres or different settings. OK. I was speaking mostly from intuition, and I suspect you have more real-world experience here. So I am willing to admit that my "you do not say..." above was a strawman. :) > The way I propose it, a user would just have to add "show=foo" to the > "diff=foo" lines without having to ad an extra filter, but with the > flexibility to do so. Yes, I think that would work OK. The only problem is that it is a bit weird to pointing "show=foo" to "diff.foo.*", especially when most of the driver options are ignored. But if we can accept that wrinkle in the UI, I think it would otherwise do what users want. > One may ask what a purely ui output oriented setting like "show" has to > do in .gitattributes, of course, but that applies to "diff" as well. > Separating the two (one in attributes, one in config) looks artificial > to me. I think the point is that the attribute says "a property of this path is that it has type X". And then the config says "when you see type X, do this thing with it". So arguably "diff=X" is wrong in the first place. It should be "type=X", and we should have "diff.X", "merge.X", etc in the config. And diff.*.textconv is potentially misplaced; it is not really about diffing at all, but rather about creating a human-readable presentation for the file. I don't think it is so bad that it is worth the pain of fixing it now, though. It is a historical weirdness that "diff=X" means "present the path according to the rules in X", but we can live with that. But if we think of it that way, then automatically respecting textconv for "git show" is a sensible thing to do. Hmph. Now I may have convinced myself that flipping the default is the right thing. :) So if it is not clear, I am pretty on the fence about how the defaults should be handled, or what would surprise users the least. Either way, though, it would probably make sense to have a configurable option. And with the reasoning above for the split between attributes/config, it would make sense to me for that option to be a boolean "diff.X.showtextconv". Which seems totally odd and broken (we are not doing a diff at all!), but that is where the textconv config lives, for historical reasons. -Peff -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v6 1/2] cache.h: eliminate SHA-1 deprecation warnings on Mac OS X
On Wed, May 15, 2013 at 5:36 PM, Junio C Hamano wrote: > David Aguilar writes: > >> Mac OS X 10.8 Mountain Lion prints warnings when building git: >> >> warning: 'SHA1_Init' is deprecated >> (declared at /usr/include/openssl/sha.h:121) >> >> Silence the warnings by using the CommonCrytpo SHA-1 >> functions for SHA1_Init(), SHA1_Update(), and SHA1_Final(). >> >> Add a NO_COMMON_DIGEST_FOR_OPENSSL option to the Makefile to allow >> users to opt out of using this library. When defined, Git will >> use OpenSSL instead. >> >> COMMON_DIGEST_FOR_OPENSSL is defined to enable the OpenSSL >> compatibility macros in CommonDigest.h. > > This symbol will also cover not just SHA but also HMAC, would it > make more sense to call it COMMON_CRYPTO_FOR_OPENSSL? After all, > that is what Apple calls this library, no? They call it COMMON_DIGEST_FOR_OPENSSL. weirdos, but I guess they mean it's for the digest functions. Thanks for catching the commit message typo. >> >> Helped-by: Eric Sunshine >> Helped-by: Torsten Bögershausen >> Signed-off-by: David Aguilar >> --- >> Changes since last time: >> >> Name the Makefile variable after the #define for consistency. >> >> Makefile | 13 + >> 1 file changed, 13 insertions(+) >> >> diff --git a/Makefile b/Makefile >> index f698c1a..b0eb949 100644 >> --- a/Makefile >> +++ b/Makefile >> @@ -137,6 +137,10 @@ all:: >> # specify your own (or DarwinPort's) include directories and >> # library directories by defining CFLAGS and LDFLAGS appropriately. >> # >> +# Define NO_COMMON_DIGEST_FOR_OPENSSL if you are building on Darwin/Mac OS X >> +# and do not want to use Apple's CommonCrypto library. This allows you to >> +# provide your own OpenSSL library, for example from MacPorts. >> +# >> # Define BLK_SHA1 environment variable to make use of the bundled >> # optimized C SHA1 routine. >> # >> @@ -1054,6 +1058,9 @@ ifeq ($(uname_S),Darwin) >> BASIC_LDFLAGS += -L/opt/local/lib >> endif >> endif >> + ifndef NO_COMMON_DIGEST_FOR_OPENSSL >> + COMMON_DIGEST_FOR_OPENSSL = YesPlease >> + endif >> NO_REGEX = YesPlease >> PTHREAD_LIBS = >> endif >> @@ -1389,10 +1396,16 @@ ifdef PPC_SHA1 >> LIB_OBJS += ppc/sha1.o ppc/sha1ppc.o >> LIB_H += ppc/sha1.h >> else >> +ifdef COMMON_DIGEST_FOR_OPENSSL >> + BASIC_CFLAGS += -DCOMMON_DIGEST_FOR_OPENSSL >> + SHA1_HEADER = >> +else >> SHA1_HEADER = >> EXTLIBS += $(LIB_4_CRYPTO) >> endif >> endif >> +endif >> + >> ifdef NO_PERL_MAKEMAKER >> export NO_PERL_MAKEMAKER >> endif -- David -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v6 2/2] imap-send: eliminate HMAC deprecation warnings on Mac OS X
On Wed, May 15, 2013 at 5:39 PM, Junio C Hamano wrote: > David Aguilar writes: > >> Mac OS X 10.8 Mountain Lion warns that HMAC_Init() and friends >> are deprecated. Detect the COMMON_CRYPTO_FOR_OPENSSL definition > > Ahh, I think you meant to use that name but forgot to adjust the > symbol you use in the patch ;-) > > I'll queue with s/COMMON_DIGEST_FOR_OPENSSL/COMMON_CRYPTO_FOR_OPENSSL/; The symbol in Apple's header is COMMON_DIGEST_FOR_OPENSSL. I rebased this patch for so many bikesheds I was bound to screw up the commit message ;-) >> diff --git a/imap-send.c b/imap-send.c >> index d9bcfb4..96012b1 100644 >> --- a/imap-send.c >> +++ b/imap-send.c >> @@ -29,8 +29,18 @@ >> #ifdef NO_OPENSSL >> typedef void *SSL; >> #else >> +#ifdef COMMON_DIGEST_FOR_OPENSSL Yup, the symbol is fine. >> +#include >> +#define HMAC_CTX CCHmacContext >> +#define HMAC_Init(hmac, key, len, algo) CCHmacInit(hmac, algo, key, len) >> +#define HMAC_Update CCHmacUpdate >> +#define HMAC_Final(hmac, hash, ptr) CCHmacFinal(hmac, hash) >> +#define HMAC_CTX_cleanup >> +#define EVP_md5() kCCHmacAlgMD5 >> +#else >> #include >> #include >> +#endif >> #include >> #endif -- David -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] strbuf_branchname(): do not double-expand @{-1}~22
On Wed, May 15, 2013 at 05:29:51PM -0700, Junio C Hamano wrote:
> If you were on 'frotz' branch before you checked out your current
> branch, "git merge @{-1}~22" means the same as "git merge frotz~22".
>
> The strbuf_branchname() function, when interpret_branch_name() gives
> up resolving "@{-1}~22" fully, returns "frotz" and tells the caller
> that it only resolved "@{-1}" part of the input, mistakes this as a
> total failure, and appends the whole thing to the result, yielding
> "frotz@{-1}~22", which does not make any sense.
>
> Inspect the return valud from interpret_branch_name() a bit more
> carefully. When it errored out without consuming anything, we will
> get -1 and we should return the whole thing. Otherwise, we should
> append the remainder (i.e. "~22" in the earlier example) to the
> partially resolved name (i.e. "frotz").
Thanks, I think your patch looks like the right solution.
Also, s/valud/value/ in the commit message.
> * The original code in a552de75eb01 (strbuf_branchname(): a wrapper
>for branch name shorthands, 2009-03-21) did not have this problem
>only because interpret_branch_name() did not return a partial
>success, but in today's code after d46a8301930a (fix parsing of
>@{-1}@{u} combination, 2010-01-28), it should pay attention to
>the condition.
A quick grep shows substitute_branch_name does not distinguish these
cases, either, but I think that is OK. It is used by dwim_ref and
dwim_log to convert a string into a refname, and a partial parse of
something like "@{u}~22" should be a failure (it does not return a ref,
but rather a commit).
It does look like substitute_branch_name may leak "buf" in such a case,
though.
-Peff
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Trouble with case insensitive filesystem
On 15 May 2013, at 15:32, Johannes Sixt wrote: > Am 5/15/2013 10:40, schrieb Luc Bourhis: >> I work on a case insensitive filesystem and I have core.ignorecase set to >> true. >> ... >> So I thought it was a job for git filter-branch, ... >> >> However because of those two blobs, I have: >> >> ~> git status >> #modified: .../fourCircles.py >> >> and git filter-branch therefore refuses to run. > > Make a commit that has neither file, run git filter-branch, then throw > away the commit with git reset --hard HEAD~. That did not work, i.e. fourCircles remained "unmodified". Eventually, I managed by successively removing the file with "C" and then the file with "c". Then filter-branch, and then reset --hard as you suggested. Then of course, all the sha's have changed and git cvsimport can't be used for incremental updates anymore, which I knew would happen, obviously. Thanks, Luc J. Bourhis -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v6 2/2] imap-send: eliminate HMAC deprecation warnings on Mac OS X
David Aguilar writes: > Mac OS X 10.8 Mountain Lion warns that HMAC_Init() and friends > are deprecated. Detect the COMMON_CRYPTO_FOR_OPENSSL definition Ahh, I think you meant to use that name but forgot to adjust the symbol you use in the patch ;-) I'll queue with s/COMMON_DIGEST_FOR_OPENSSL/COMMON_CRYPTO_FOR_OPENSSL/; > and use CommonCrypto's HMAC functions to eliminate the warnings. > > Signed-off-by: David Aguilar > --- > Changes since last time: None. > > imap-send.c | 10 ++ > 1 file changed, 10 insertions(+) > > diff --git a/imap-send.c b/imap-send.c > index d9bcfb4..96012b1 100644 > --- a/imap-send.c > +++ b/imap-send.c > @@ -29,8 +29,18 @@ > #ifdef NO_OPENSSL > typedef void *SSL; > #else > +#ifdef COMMON_DIGEST_FOR_OPENSSL > +#include > +#define HMAC_CTX CCHmacContext > +#define HMAC_Init(hmac, key, len, algo) CCHmacInit(hmac, algo, key, len) > +#define HMAC_Update CCHmacUpdate > +#define HMAC_Final(hmac, hash, ptr) CCHmacFinal(hmac, hash) > +#define HMAC_CTX_cleanup > +#define EVP_md5() kCCHmacAlgMD5 > +#else > #include > #include > +#endif > #include > #endif -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v6 1/2] cache.h: eliminate SHA-1 deprecation warnings on Mac OS X
David Aguilar writes: > Mac OS X 10.8 Mountain Lion prints warnings when building git: > > warning: 'SHA1_Init' is deprecated > (declared at /usr/include/openssl/sha.h:121) > > Silence the warnings by using the CommonCrytpo SHA-1 > functions for SHA1_Init(), SHA1_Update(), and SHA1_Final(). > > Add a NO_COMMON_DIGEST_FOR_OPENSSL option to the Makefile to allow > users to opt out of using this library. When defined, Git will > use OpenSSL instead. > > COMMON_DIGEST_FOR_OPENSSL is defined to enable the OpenSSL > compatibility macros in CommonDigest.h. This symbol will also cover not just SHA but also HMAC, would it make more sense to call it COMMON_CRYPTO_FOR_OPENSSL? After all, that is what Apple calls this library, no? > > Helped-by: Eric Sunshine > Helped-by: Torsten Bögershausen > Signed-off-by: David Aguilar > --- > Changes since last time: > > Name the Makefile variable after the #define for consistency. > > Makefile | 13 + > 1 file changed, 13 insertions(+) > > diff --git a/Makefile b/Makefile > index f698c1a..b0eb949 100644 > --- a/Makefile > +++ b/Makefile > @@ -137,6 +137,10 @@ all:: > # specify your own (or DarwinPort's) include directories and > # library directories by defining CFLAGS and LDFLAGS appropriately. > # > +# Define NO_COMMON_DIGEST_FOR_OPENSSL if you are building on Darwin/Mac OS X > +# and do not want to use Apple's CommonCrypto library. This allows you to > +# provide your own OpenSSL library, for example from MacPorts. > +# > # Define BLK_SHA1 environment variable to make use of the bundled > # optimized C SHA1 routine. > # > @@ -1054,6 +1058,9 @@ ifeq ($(uname_S),Darwin) > BASIC_LDFLAGS += -L/opt/local/lib > endif > endif > + ifndef NO_COMMON_DIGEST_FOR_OPENSSL > + COMMON_DIGEST_FOR_OPENSSL = YesPlease > + endif > NO_REGEX = YesPlease > PTHREAD_LIBS = > endif > @@ -1389,10 +1396,16 @@ ifdef PPC_SHA1 > LIB_OBJS += ppc/sha1.o ppc/sha1ppc.o > LIB_H += ppc/sha1.h > else > +ifdef COMMON_DIGEST_FOR_OPENSSL > + BASIC_CFLAGS += -DCOMMON_DIGEST_FOR_OPENSSL > + SHA1_HEADER = > +else > SHA1_HEADER = > EXTLIBS += $(LIB_4_CRYPTO) > endif > endif > +endif > + > ifdef NO_PERL_MAKEMAKER > export NO_PERL_MAKEMAKER > endif -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] strbuf_branchname(): do not double-expand @{-1}~22
If you were on 'frotz' branch before you checked out your current
branch, "git merge @{-1}~22" means the same as "git merge frotz~22".
The strbuf_branchname() function, when interpret_branch_name() gives
up resolving "@{-1}~22" fully, returns "frotz" and tells the caller
that it only resolved "@{-1}" part of the input, mistakes this as a
total failure, and appends the whole thing to the result, yielding
"frotz@{-1}~22", which does not make any sense.
Inspect the return valud from interpret_branch_name() a bit more
carefully. When it errored out without consuming anything, we will
get -1 and we should return the whole thing. Otherwise, we should
append the remainder (i.e. "~22" in the earlier example) to the
partially resolved name (i.e. "frotz").
The test suite adds enough number of checkout to make @{-12} in the
last test in t0100 that tried to check "we haven't flipped branches
that many times" error case; raise the number to a hundred.
Signed-off-by: Junio C Hamano
---
* The original code in a552de75eb01 (strbuf_branchname(): a wrapper
for branch name shorthands, 2009-03-21) did not have this problem
only because interpret_branch_name() did not return a partial
success, but in today's code after d46a8301930a (fix parsing of
@{-1}@{u} combination, 2010-01-28), it should pay attention to
the condition.
There might be other callers of interpret_branch_name() that
still assume there is no partial success; I didn't check.
sha1_name.c | 8 ++--
t/t0100-previous.sh | 15 +--
2 files changed, 19 insertions(+), 4 deletions(-)
diff --git a/sha1_name.c b/sha1_name.c
index 3820f28..371a49d 100644
--- a/sha1_name.c
+++ b/sha1_name.c
@@ -1055,9 +1055,13 @@ int interpret_branch_name(const char *name, struct
strbuf *buf)
int strbuf_branchname(struct strbuf *sb, const char *name)
{
int len = strlen(name);
- if (interpret_branch_name(name, sb) == len)
+ int used = interpret_branch_name(name, sb);
+
+ if (used == len)
return 0;
- strbuf_add(sb, name, len);
+ if (used < 0)
+ used = 0;
+ strbuf_add(sb, name + used, len - used);
return len;
}
diff --git a/t/t0100-previous.sh b/t/t0100-previous.sh
index 315b9b3..e0a6940 100755
--- a/t/t0100-previous.sh
+++ b/t/t0100-previous.sh
@@ -27,6 +27,7 @@ test_expect_success 'merge @{-1}' '
test_commit B &&
git checkout A &&
test_commit C &&
+ test_commit D &&
git branch -f master B &&
git branch -f other &&
git checkout other &&
@@ -35,14 +36,24 @@ test_expect_success 'merge @{-1}' '
git cat-file commit HEAD | grep "Merge branch '\''other'\''"
'
-test_expect_success 'merge @{-1} when there is not enough switches yet' '
+test_expect_success 'merge @{-1}~1' '
+ git checkout master &&
+ git reset --hard B &&
+ git checkout other &&
+ git checkout master &&
+ git merge @{-1}~1 &&
+ git cat-file commit HEAD >actual &&
+ grep "Merge branch '\''other'\''" actual
+'
+
+test_expect_success 'merge @{-100} before checking out that many branches yet'
'
git reflog expire --expire=now &&
git checkout -f master &&
git reset --hard B &&
git branch -f other C &&
git checkout other &&
git checkout master &&
- test_must_fail git merge @{-12}
+ test_must_fail git merge @{-100}
'
test_done
--
1.8.3-rc2-210-gbc3cf50
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: What's cooking in git.git (May 2013, #04; Wed, 15)
On Wed, May 15, 2013 at 4:42 PM, Junio C Hamano wrote: > Here are the topics that have been cooking. Commits prefixed with > '-' are only in 'pu' (proposed updates) while commits prefixed with > '+' are in 'next'. > > We are past -rc2 and haven't seen any regression reported since the > feature freeze started, which may be a good sign (the coming release > is perfect) or a bad sign (nobody is testing). We'll see soon when > we tag the 1.8.3 final sometime next week. We may see subsystem > (git-svn? gitk? git-gui?) and l10n updates before that happens. > > You can find the changes described here in the integration branches > of the repositories listed at > > http://git-blame.blogspot.com/p/git-public-repositories.html > > -- > [New Topics] > > * dw/asciidoc-sources-are-dot-txt-files (2013-05-10) 1 commit > - CodingGuidelines: Documentation/*.txt are the sources > > > * fc/doc-style (2013-05-09) 2 commits > - SQUASH??? more consistently update docs > - documentation: trivial style cleanups > > > * da/darwin (2013-05-15) 3 commits > - imap-send: eliminate HMAC deprecation warnings on Mac OS X > - cache.h: eliminate SHA-1 deprecation warnings on Mac OS X > - Makefile: fix default regex settings on Darwin > > Waiting for polishing discussion to finish. Thanks. imap-send and cache.h are now on their v6 patch which I just sent. That last few rounds have been cosmetic/superficial changes and I would like to consider this topic "done". We've painted this shed enough times ;-) I believe "fix default regex settings on Darwin" is uncontroversial and should be included in the upcoming release. It may even be maint-worthy. Without it we fail t0070-fundamental.sh. The two patches that follow it can wait and cook like normal. -- David -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v6 2/2] imap-send: eliminate HMAC deprecation warnings on Mac OS X
Mac OS X 10.8 Mountain Lion warns that HMAC_Init() and friends are deprecated. Detect the COMMON_CRYPTO_FOR_OPENSSL definition and use CommonCrypto's HMAC functions to eliminate the warnings. Signed-off-by: David Aguilar --- Changes since last time: None. imap-send.c | 10 ++ 1 file changed, 10 insertions(+) diff --git a/imap-send.c b/imap-send.c index d9bcfb4..96012b1 100644 --- a/imap-send.c +++ b/imap-send.c @@ -29,8 +29,18 @@ #ifdef NO_OPENSSL typedef void *SSL; #else +#ifdef COMMON_DIGEST_FOR_OPENSSL +#include +#define HMAC_CTX CCHmacContext +#define HMAC_Init(hmac, key, len, algo) CCHmacInit(hmac, algo, key, len) +#define HMAC_Update CCHmacUpdate +#define HMAC_Final(hmac, hash, ptr) CCHmacFinal(hmac, hash) +#define HMAC_CTX_cleanup +#define EVP_md5() kCCHmacAlgMD5 +#else #include #include +#endif #include #endif -- 1.8.3.rc2.3.g81576a6 -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v6 1/2] cache.h: eliminate SHA-1 deprecation warnings on Mac OS X
Mac OS X 10.8 Mountain Lion prints warnings when building git: warning: 'SHA1_Init' is deprecated (declared at /usr/include/openssl/sha.h:121) Silence the warnings by using the CommonCrytpo SHA-1 functions for SHA1_Init(), SHA1_Update(), and SHA1_Final(). Add a NO_COMMON_DIGEST_FOR_OPENSSL option to the Makefile to allow users to opt out of using this library. When defined, Git will use OpenSSL instead. COMMON_DIGEST_FOR_OPENSSL is defined to enable the OpenSSL compatibility macros in CommonDigest.h. Helped-by: Eric Sunshine Helped-by: Torsten Bögershausen Signed-off-by: David Aguilar --- Changes since last time: Name the Makefile variable after the #define for consistency. Makefile | 13 + 1 file changed, 13 insertions(+) diff --git a/Makefile b/Makefile index f698c1a..b0eb949 100644 --- a/Makefile +++ b/Makefile @@ -137,6 +137,10 @@ all:: # specify your own (or DarwinPort's) include directories and # library directories by defining CFLAGS and LDFLAGS appropriately. # +# Define NO_COMMON_DIGEST_FOR_OPENSSL if you are building on Darwin/Mac OS X +# and do not want to use Apple's CommonCrypto library. This allows you to +# provide your own OpenSSL library, for example from MacPorts. +# # Define BLK_SHA1 environment variable to make use of the bundled # optimized C SHA1 routine. # @@ -1054,6 +1058,9 @@ ifeq ($(uname_S),Darwin) BASIC_LDFLAGS += -L/opt/local/lib endif endif + ifndef NO_COMMON_DIGEST_FOR_OPENSSL + COMMON_DIGEST_FOR_OPENSSL = YesPlease + endif NO_REGEX = YesPlease PTHREAD_LIBS = endif @@ -1389,10 +1396,16 @@ ifdef PPC_SHA1 LIB_OBJS += ppc/sha1.o ppc/sha1ppc.o LIB_H += ppc/sha1.h else +ifdef COMMON_DIGEST_FOR_OPENSSL + BASIC_CFLAGS += -DCOMMON_DIGEST_FOR_OPENSSL + SHA1_HEADER = +else SHA1_HEADER = EXTLIBS += $(LIB_4_CRYPTO) endif endif +endif + ifdef NO_PERL_MAKEMAKER export NO_PERL_MAKEMAKER endif -- 1.8.3.rc2.3.g81576a6 -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
What's cooking in git.git (May 2013, #04; Wed, 15)
Here are the topics that have been cooking. Commits prefixed with '-' are only in 'pu' (proposed updates) while commits prefixed with '+' are in 'next'. We are past -rc2 and haven't seen any regression reported since the feature freeze started, which may be a good sign (the coming release is perfect) or a bad sign (nobody is testing). We'll see soon when we tag the 1.8.3 final sometime next week. We may see subsystem (git-svn? gitk? git-gui?) and l10n updates before that happens. You can find the changes described here in the integration branches of the repositories listed at http://git-blame.blogspot.com/p/git-public-repositories.html -- [New Topics] * dw/asciidoc-sources-are-dot-txt-files (2013-05-10) 1 commit - CodingGuidelines: Documentation/*.txt are the sources * fc/doc-style (2013-05-09) 2 commits - SQUASH??? more consistently update docs - documentation: trivial style cleanups * da/darwin (2013-05-15) 3 commits - imap-send: eliminate HMAC deprecation warnings on Mac OS X - cache.h: eliminate SHA-1 deprecation warnings on Mac OS X - Makefile: fix default regex settings on Darwin Waiting for polishing discussion to finish. * fc/macos-x-clipped-write (2013-05-10) 2 commits - SQUASH??? - compate/clipped-write.c: large write(2) fails on Mac OS X/XNU The tip needs to be squashed, as it was reported to have tested OK. * fc/remote-hg (2013-05-15) 39 commits - remote-hg: remove files before modifications - remote-hg: improve lightweight tag author - remote-hg: use remote 'default' not local one - remote-hg: improve branch listing - remote-hg: simplify branch_tip() - remote-hg: check diverged bookmarks - remote-hg: pass around revision refs - remote-hg: implement custom checkheads() - remote-hg: implement custom push() - remote-hg: only update necessary revisions - remote-hg: force remote bookmark push selectively - remote-hg: reorganize bookmark handling - remote-hg: add test for failed double push - remote-hg: add test for big push - remote-hg: add test for new bookmark special - remote-hg: add test for bookmark diverge - remote-hg: add test for diverged push - remote-hg: add test to push new bookmark - remote-hg: add remote tests - remote-hg: add check_bookmark() test helper - remote-bzr: simplify test checks - remote-hg: always point HEAD to master - remote-hg: improve progress calculation - remote-hg: trivial cleanups - remote-hg: ensure remote rebasing works - remote-hg: upgrade version 1 marks - remote-hg: switch from revisions to SHA-1 noteids - remote-hg: add version checks to the marks - remote-hg: improve node traversing - remote-hg: shuffle some code - remote-hg: use a shared repository store - remote-hg: load all extensions - remote-hg: test: simplify previous branch checkout - remote-helpers: test: simplify remote URLs - remote-helpers: tests: general improvements - remote-helpers: test: cleanup style - remote-helpers: test: cleanup white-spaces - remote-hg: trivial reorganization - remote-hg: test: be a little more quiet Probably will be one of the early topics to graduate post 1.8.3. * hv/config-from-blob (2013-05-12) 5 commits - do not die when error in config parsing of buf occurs - teach config --blob option to parse config from database - config: make parsing stack struct independent from actual data source - config: drop cf validity check in get_next_char() - config: factor out config file stack management * jc/t5551-posix-sed-bre (2013-05-12) 1 commit - t5551: do not use unportable sed '\+' Not a regression fix and not urgent. * jk/fetch-always-update-tracking (2013-05-12) 4 commits - fetch: opportunistically update tracking refs - refactor "ref->merge" flag - fetch/pull doc: untangle meaning of bare - t5510: start tracking-ref tests from a known state "git fetch origin master" unlike "git fetch origin" or "git fetch" does not update "refs/remotes/origin/master" and it was an early design decision to keep the update of remote tracking branches predictable, but in practice it turns out that people find it more convenient to opportunisticly update them whenever we have a chance, and we have been updating them when we run "git push" which already breaks the original "predictability" anyway. * nd/clone-connectivity-shortcut (2013-05-11) 4 commits - clone: open a shortcut for connectivity check - index-pack: remove dead code (it should never happen) - fetch-pack: prepare updated shallow file before fetching the pack - clone: let the user know when check_everything_connected is run * rr/rebase-autostash (2013-05-12) 7 commits - rebase: implement --[no-]autostash and rebase.autostash - rebase --merge: return control to caller, for housekeeping - rebase -i: return control to caller, for housekeeping - am: return control to caller, for housekeeping - rebase: prepare to do generic housekeeping - rebase -i: don't error out if $state_dir a
Re: [RFC] New kind of upstream branch: base branch
On Wed, May 15, 2013 at 6:14 PM, Junio C Hamano wrote: > Felipe Contreras writes: > >> Exactly the same as 'git pull' does right now. > > You set > > [branch 'foobar'] > base = refs/heads/master > > then 'git pull [--rebase]' will go to 'origin' due to the default, > but then what branch from the 'origin' are you integrating with? The same as if you didn't have 'branch.foobar.base': none. You get an error because there's no upstream. > Do you mean you are also setting both remote and upstream, perhaps > like this, for all of your branches? > > [remote "origin"] > url = github.com:maintainer/hisproject > fetch = +refs/heads/*:refs/remotes/origin/* > > [remote "github"] > url = github.com:felipec/myproject > fetch = +refs/heads/*:refs/remotes/github/* > > [branch 'foobar'] > base = refs/heads/master > remote = github ;# or is it origin??? > upstream = refs/heads/foobar > > Then your 'git pull' will fetch from remote 'origin' and integrate > with its 'foobar' and 'push' may go to update 'foobar' at 'github'. > > Perhaps that is what you meant. That's what I described in my example. >> 'base' has absolutely nothing to do with pulling or pushing. > > I agree it shouldn't have anything to do with pushing, but given > that 'git pull [--rebase]' is a way to do a 'merge' or 'rebase' with > what you 'git fetch', introducing something that 'merge' or 'rebase' > pays attention to that does not have anything to do with 'pull' > sounds like it breaks existing end user expectation. But it's already broken. 'git pull' is not the same as 'git fetch'+'git merge'. That *only* works when merge.defaulttoupstream is set. > But that does not mean it is a bad idea. The behaviour changes only > when you have branch.$name.base, so I suspect that we do not need to > worry about "what if the user has both?" case you mentioned in your > first message. Indeed. It wouldn't be an intrusive change; it would only affect 'git rebase', and nothing more. But I'm wondering if the behavior of 'git fecth' should change as well. And in fact it should be the other way around. > I think I misunderstood what you meant. If it is the norm to have > both base and upstream/remote in branch.$name (as opposed to "have > only branch.$name.base and not branch.$name.remote to force fetch to > go to the default 'origin'), then 'git pull' will not break and I > can see how many things would work naturally (admittedly I can only > say 'many things', not 'everything', at this point, as I haven't > thought things through). But I think the norm would be to have only 'base', because a lot of people don't manually set an upstream branch. In the end it all boils down to; which is the upstream 'origin/master', or 'github/master'? Well, it is 'origin/master', so 'upstream' should point there, but I don't want to push to the 'upstream', I want to push somewhere else by default. -- Felipe Contreras -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] New kind of upstream branch: base branch
On Wed, May 15, 2013 at 5:50 PM, Junio C Hamano wrote:
> Junio C Hamano writes:
>
>> I however am not yet convinced if that direction is what you really
>> want go in, though. What should your 'git pull' on that branch do,
>> for example?
>>
>> When you are on foobar and want to integrate with the branch you
>> based your work on (i.e. local 'master'), you can do one of these:
>>
>> $ git pull
>> $ git pull --rebase
>>
>> to "fetch the upstream branch and integrate with it", without having
>> to even care if that upstream branch is from the remote, or happens
>> to be truly local. By making 'git fetch' to go to the remote origin
>> site, what will you be merging (or rebasing on) when you do the
>> above two?
>>
>> Incidentally, I suspect you can do exactly the same thing without
>> introducing a new concept "base" and instead special casing a remote
>> whose URL is "."; you essentially declare that "The upstream of this
>> branch whose branch.$name.remote is set to '.' lives locally", which
>> is not all that different from saying "The upstream of this branch
>> whose branch.$name.base exists lives locally", which is what you
>> seem to be proposing. One of the things this alternative approach
>> would "special case" such remote is probably to cause "git fetch" to
>> ignore such a branch.$name.remote setting and instead go fetch from
>> 'origin', just like your "if there is branch.$name.base, but no
>> branch.$name.remote, fetch will go to 'origin'" does.
>>
>> But it has exactly the same "what happens when you do 'git pull'"
>> problem, so even though it is conceptually a lot simpler, it has the
>> same brokenness.
>
> I do not think of a good way to fix the 'git pull' confusion; the
> desire to 'fetch from the overall upstream repository regardless of
> which branch I am on' is a valid and understandable one, but that
> does not mesh well with "'git pull' is 'git fetch' followed by
> either merge or rebase to integrate the result"
But that is not true. It's only true when merge.defaulttoupstream=true.
> and "git merge or
> git rebase pays attention to the other branch that is specified to
> integrate with". The best we could do might be to simply forbid
> "git pull" if your current branch is marked with branch.$name.base
> but still allow "git fetch".
Why forbid it? Why not leave it as it is?
> The changes that are involved are:
>
> * Do not change anything to @{upstream}'s definition, that is,
>"checkout -t -b A localbranch" will set branch.A.remote to '.',
>and "git log A@{u}..A" will stand for "git log localbranch..A".
Yes, but in addition it would set 'branch.A.base'.
> * Current 'git fetch' pays attention to branch.A.remote when you
>are on branch A, and tries to fetch from there. Stop doing that
>when branch.A.remote is set to '.' (the current repository) and
>let other rules in the current implementation decide what remote
>to fetch from. Also teach it to error out when branch.A.remote is
>set to '.' when a new --forbid-local option is passed.
I don't see the point of --forbid-local, but otherwise yeah.
> Ah, alternatively, instead of adding --forbid-local, we could modify
> the changes for 'git fetch' and 'git pull' to read like this:
>
> * Current 'git fetch' pays attention to branch.A.remote when you
>are on branch A, and tries to fetch from there. Stop doing that
>when branch.A.remote is set to '.' (the current repository) and
>let other rules in the current implementation decide what remote
>to fetch from, unless a new --allow-fetch-from-local option is
>passed.
>
> * Teach 'git pull' to pass --allow-fetch-from-local to 'git fetch'.
Perhaps.
> If we did this, we can keep the "git pull [--rebase]" as a way to
> integrate with what you specified as your upstream, which is a
> common expectation, without forcing you to say "git fetch origin".
I'm starting to change my mind. Perhaps instead of aiming to change
the behavior 'git rebase', it would make more sense to change the
behavior of 'git push'. So that 'git rebase', 'git fetch' and 'git
pull' all use 'upstream' as is currently the case, but 'git push'
would use something different. That would solve my 'origin/master' vs.
'github/master' distinction. But I would like 'git checkout -b foo
master' to automatically setup 'upstream', and 'git checkout -t -b foo
master' to in addition set this other kind that only affects 'git
push'. This would be a much more intrusive change though.
So, 'branch.A.merge' would become 'branch.A.upstream' and have the
full tracking branch (e.g. 'refs/remotes/github/master'), and
'branch.A.remote' would only affect 'git push'.
--
Felipe Contreras
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] New kind of upstream branch: base branch
Felipe Contreras writes: > Exactly the same as 'git pull' does right now. You set [branch 'foobar'] base = refs/heads/master then 'git pull [--rebase]' will go to 'origin' due to the default, but then what branch from the 'origin' are you integrating with? Do you mean you are also setting both remote and upstream, perhaps like this, for all of your branches? [remote "origin"] url = github.com:maintainer/hisproject fetch = +refs/heads/*:refs/remotes/origin/* [remote "github"] url = github.com:felipec/myproject fetch = +refs/heads/*:refs/remotes/github/* [branch 'foobar'] base = refs/heads/master remote = github ;# or is it origin??? upstream = refs/heads/foobar Then your 'git pull' will fetch from remote 'origin' and integrate with its 'foobar' and 'push' may go to update 'foobar' at 'github'. Perhaps that is what you meant. > 'base' has absolutely nothing to do with pulling or pushing. I agree it shouldn't have anything to do with pushing, but given that 'git pull [--rebase]' is a way to do a 'merge' or 'rebase' with what you 'git fetch', introducing something that 'merge' or 'rebase' pays attention to that does not have anything to do with 'pull' sounds like it breaks existing end user expectation. But that does not mean it is a bad idea. The behaviour changes only when you have branch.$name.base, so I suspect that we do not need to worry about "what if the user has both?" case you mentioned in your first message. I think I misunderstood what you meant. If it is the norm to have both base and upstream/remote in branch.$name (as opposed to "have only branch.$name.base and not branch.$name.remote to force fetch to go to the default 'origin'), then 'git pull' will not break and I can see how many things would work naturally (admittedly I can only say 'many things', not 'everything', at this point, as I haven't thought things through). -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] New kind of upstream branch: base branch
On Wed, May 15, 2013 at 5:20 PM, Junio C Hamano wrote:
> Felipe Contreras writes:
>
>> The 'base' branch will be set each time you create a branch from another;
>> 'git checkout -b foobar master' sets 'master' as the 'base' of 'foobar'.
>
> "git checkout -t -b foobar mastee" would instead set 'upstream' of
> 'foobar' to the branch 'master' of remote '.' (the current one).
Yeah, but I don't to set an upstream, because 'master' is not the
upstream of 'foobar'.
> This 'base' is a new mechanism to explicitly say "The upstream of
> this branch lives locally" by not setting "branch.foobar.remote".
No, 'base' can point to a remote tracking branch.
>> Then you can do 'git rebase foobar@{base}' or simply 'git rebase', and Git
>> will
>> pick the right branch to rebase unto, even if you have no 'upstream'
>> configured.
>
> Surely you can teach rebase to pay attention to 'base' and achieve
> that. But you can already do so with upstream, so this is not an
> advertisement of a 'plus', but rather a lack of 'minus' (which is
> not a bad thing at all).
Only if there's an upstream configured, which many times is not the
case, and many times causes side-effects the user doesn't want to.
The purpose of 'upstream' is completely different.
>> This way 'git fetch' will keep picking 'origin', and other commands that make
>> use of 'upstrem' would be undisturbed.
>
> And this is the true plus, because 'git fetch' with the current
> "setting a local base using the same upstream mechanism to point at
> a branch of _this_ repository, indirectly setting the upstream
> _repository_ for this branch to the current repository" will end up
> making you fetch from yourself, which is not very interesting.
>
> So I think I understand your itch and I agree that it is a valid
> one.
>
> I however am not yet convinced if that direction is what you really
> want go in, though. What should your 'git pull' on that branch do,
> for example?
Exactly the same as 'git pull' does right now.
'base' has absolutely nothing to do with pulling or pushing.
> When you are on foobar and want to integrate with the branch you
> based your work on (i.e. local 'master'), you can do one of these:
>
> $ git pull
> $ git pull --rebase
>
> to "fetch the upstream branch and integrate with it", without having
> to even care if that upstream branch is from the remote, or happens
> to be truly local. By making 'git fetch' to go to the remote origin
> site, what will you be merging (or rebasing on) when you do the
> above two?
The same as we do now.
> Incidentally, I suspect you can do exactly the same thing without
> introducing a new concept "base" and instead special casing a remote
> whose URL is "."; you essentially declare that "The upstream of this
> branch whose branch.$name.remote is set to '.' lives locally", which
> is not all that different from saying "The upstream of this branch
> whose branch.$name.base exists lives locally", which is what you
> seem to be proposing.
That would be good, but it doesn't have the same benefits:
If I have set an 'upstream' branch, say 'github/master', and I have
'base' branch, say 'origin/master'. I would expect 'git rebase' to
rebase onto 'origin/master'. When I do 'git push', I expect to push to
'github/master'. Moreover, I would expect 'git fetch' to fetch from
'origin', but that can be discussed later.
Right now I'm forced to choose a single branch and set it to
'upstream'. If I choose 'origin/master' (which is not really the
upstream), the rebase would do what I want, but not the push, unless I
have configured a remote.pushdefault, but that would only work if I
the real upstream is the common one. If I choose 'github/master', then
rebase would not do what I want (and neither would fetch).
> One of the things this alternative approach
> would "special case" such remote is probably to cause "git fetch" to
> ignore such a branch.$name.remote setting and instead go fetch from
> 'origin', just like your "if there is branch.$name.base, but no
> branch.$name.remote, fetch will go to 'origin'" does.
>
> But it has exactly the same "what happens when you do 'git pull'"
> problem, so even though it is conceptually a lot simpler, it has the
> same brokenness.
There is no brokenness; 'git pull' does different things depending on
the configuration. With my proposal nothing would change.
--
Felipe Contreras
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] New kind of upstream branch: base branch
Junio C Hamano writes:
> I however am not yet convinced if that direction is what you really
> want go in, though. What should your 'git pull' on that branch do,
> for example?
>
> When you are on foobar and want to integrate with the branch you
> based your work on (i.e. local 'master'), you can do one of these:
>
> $ git pull
> $ git pull --rebase
>
> to "fetch the upstream branch and integrate with it", without having
> to even care if that upstream branch is from the remote, or happens
> to be truly local. By making 'git fetch' to go to the remote origin
> site, what will you be merging (or rebasing on) when you do the
> above two?
>
> Incidentally, I suspect you can do exactly the same thing without
> introducing a new concept "base" and instead special casing a remote
> whose URL is "."; you essentially declare that "The upstream of this
> branch whose branch.$name.remote is set to '.' lives locally", which
> is not all that different from saying "The upstream of this branch
> whose branch.$name.base exists lives locally", which is what you
> seem to be proposing. One of the things this alternative approach
> would "special case" such remote is probably to cause "git fetch" to
> ignore such a branch.$name.remote setting and instead go fetch from
> 'origin', just like your "if there is branch.$name.base, but no
> branch.$name.remote, fetch will go to 'origin'" does.
>
> But it has exactly the same "what happens when you do 'git pull'"
> problem, so even though it is conceptually a lot simpler, it has the
> same brokenness.
I do not think of a good way to fix the 'git pull' confusion; the
desire to 'fetch from the overall upstream repository regardless of
which branch I am on' is a valid and understandable one, but that
does not mesh well with "'git pull' is 'git fetch' followed by
either merge or rebase to integrate the result" and "git merge or
git rebase pays attention to the other branch that is specified to
integrate with". The best we could do might be to simply forbid
"git pull" if your current branch is marked with branch.$name.base
but still allow "git fetch".
The changes that are involved are:
* Do not change anything to @{upstream}'s definition, that is,
"checkout -t -b A localbranch" will set branch.A.remote to '.',
and "git log A@{u}..A" will stand for "git log localbranch..A".
* Current 'git fetch' pays attention to branch.A.remote when you
are on branch A, and tries to fetch from there. Stop doing that
when branch.A.remote is set to '.' (the current repository) and
let other rules in the current implementation decide what remote
to fetch from. Also teach it to error out when branch.A.remote is
set to '.' when a new --forbid-local option is passed.
* Teach 'git pull' to pass --forbid-local option to 'git fetch',
and let an error return fail the whole thing.
Ah, alternatively, instead of adding --forbid-local, we could modify
the changes for 'git fetch' and 'git pull' to read like this:
* Current 'git fetch' pays attention to branch.A.remote when you
are on branch A, and tries to fetch from there. Stop doing that
when branch.A.remote is set to '.' (the current repository) and
let other rules in the current implementation decide what remote
to fetch from, unless a new --allow-fetch-from-local option is
passed.
* Teach 'git pull' to pass --allow-fetch-from-local to 'git fetch'.
If we did this, we can keep the "git pull [--rebase]" as a way to
integrate with what you specified as your upstream, which is a
common expectation, without forcing you to say "git fetch origin".
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCHv2] git-submodule.txt: Clarify 'init' and 'add' subcommands.
Describe how 'add' sets the submodule's logical name, which is used in
the configuration entry names.
Clarify that 'init' only sets up the configuration entries for
submodules that have already been added elsewhere. Describe that
arguments limit the submodules that are configured.
Signed-off-by: Dale Worley
---
This patch seems to have all the features that we have discussed:
- Describes how 'add' selects the submodule logical name, including
the effect of --name. (My first patch was on a version of Git that
did not support --name, so I didn't know of it.)
- Corrects description of 'init' to clarify that its behavior is
driven by the gitlinks recorded in the index, rather than implying
it is driven by the contents of .gitmodules.
- Describes 'init' behavior to be driven by the index, rather than my
previous incorrect use of "file tree". (Of course, gitlinks aren't
visible in the file tree.)
- Updated text for 'init' is shorter and less technical than my
previous patch.
- Since "(which were added and committed elsewhere)" is stated in the
first sentence, I've removed the later sentence explaining that
submodules must be added before they can be inited.
- Explains the effect of arguments to 'init' subcommand.
Documentation/git-submodule.txt |8 ++--
1 files changed, 6 insertions(+), 2 deletions(-)
diff --git a/Documentation/git-submodule.txt b/Documentation/git-submodule.txt
index c99d795..83235c0 100644
--- a/Documentation/git-submodule.txt
+++ b/Documentation/git-submodule.txt
@@ -76,6 +76,8 @@ argument is the relative location for the cloned
submodule
to exist in the superproject. If is not given, the
"humanish" part of the source repository is used ("repo" for
"/path/to/repo.git" and "foo" for "host.xz:foo/.git").
+The is also used as the submodule's logical name in its
+configuration entries unless `--name` is used to specify a logical name.
+
is the URL of the new submodule's origin repository.
This may be either an absolute URL, or (if it begins with ./
@@ -123,8 +125,10 @@ linkgit:git-status[1] and linkgit:git-diff[1] will provide
that information
too (and can also report changes to a submodule's work tree).
init::
- Initialize the submodules, i.e. register each submodule name
- and url found in .gitmodules into .git/config.
+ Initialize the submodules recorded in the index (which were
+ added and committed elsewhere) by copying submodule
+ names and urls from .gitmodules to .git/config.
+ Optional arguments limit which submodules will be initialized.
It will also copy the value of `submodule.$name.update` into
.git/config.
The key used in .git/config is `submodule.$name.url`.
--
1.7.7.6
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] New kind of upstream branch: base branch
From: "Felipe Contreras"
Sent: Wednesday, May 15, 2013 9:34 PM
Hi,
I've been using Git from the start, but only lately have I forced
myself to configure upstream branches for all my branches, and I've
found a few things more convenient, but others completely contrary to
what I expected.
Inconvenient:
Before, I used to do 'git fetch' to simply fetch from 'origin', but
now, it depends on where 'upstream' is set to.
Convinient:
Now, I can just do 'git rebase --interactive' and I don't have to
specify the starting point, which is particularily useful when there's
a lot of branches one depending on another.
I think I'm using 'upstream' for something it was not intended to, and
I think the current 'upstream' behavior should be split into
'upstream' and 'base'.
== base ==
The 'base' branch will be set each time you create a branch from
another;
'git checkout -b foobar master' sets 'master' as the 'base' of
'foobar'.
Then you can do 'git rebase foobar@{base}' or simply 'git rebase', and
Git will pick the right branch to rebase unto, even if you have no
'upstream'
configured.
This way 'git fetch' will keep picking 'origin', and other commands
that make use of 'upstream' would be undisturbed.
If both 'base' and 'upstream' are defined, I think 'git rebase' should
use 'base', but since that would break old behavior, perhaps there
should be a configuration variable to enable a different behavior.
I already started writting the patches, and although tedious, I think
they they'll be rather straightforward, but I thought it would be best
to hear some opinions first.
What do you think?
--
Felipe Contreras
---
Sound a reasonable idea. On some patches I was working on I had to
[chose to] add a tag for the base which made it easier to rebase later.
The other point is that I had already noted that the glossary doesn't
include the many "base" terms in use that aren't always well understood.
Philip Oakley
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] New kind of upstream branch: base branch
Felipe Contreras writes:
> The 'base' branch will be set each time you create a branch from another;
> 'git checkout -b foobar master' sets 'master' as the 'base' of 'foobar'.
"git checkout -t -b foobar mastee" would instead set 'upstream' of
'foobar' to the branch 'master' of remote '.' (the current one).
This 'base' is a new mechanism to explicitly say "The upstream of
this branch lives locally" by not setting "branch.foobar.remote".
> Then you can do 'git rebase foobar@{base}' or simply 'git rebase', and Git
> will
> pick the right branch to rebase unto, even if you have no 'upstream'
> configured.
Surely you can teach rebase to pay attention to 'base' and achieve
that. But you can already do so with upstream, so this is not an
advertisement of a 'plus', but rather a lack of 'minus' (which is
not a bad thing at all).
> This way 'git fetch' will keep picking 'origin', and other commands that make
> use of 'upstrem' would be undisturbed.
And this is the true plus, because 'git fetch' with the current
"setting a local base using the same upstream mechanism to point at
a branch of _this_ repository, indirectly setting the upstream
_repository_ for this branch to the current repository" will end up
making you fetch from yourself, which is not very interesting.
So I think I understand your itch and I agree that it is a valid
one.
I however am not yet convinced if that direction is what you really
want go in, though. What should your 'git pull' on that branch do,
for example?
When you are on foobar and want to integrate with the branch you
based your work on (i.e. local 'master'), you can do one of these:
$ git pull
$ git pull --rebase
to "fetch the upstream branch and integrate with it", without having
to even care if that upstream branch is from the remote, or happens
to be truly local. By making 'git fetch' to go to the remote origin
site, what will you be merging (or rebasing on) when you do the
above two?
Incidentally, I suspect you can do exactly the same thing without
introducing a new concept "base" and instead special casing a remote
whose URL is "."; you essentially declare that "The upstream of this
branch whose branch.$name.remote is set to '.' lives locally", which
is not all that different from saying "The upstream of this branch
whose branch.$name.base exists lives locally", which is what you
seem to be proposing. One of the things this alternative approach
would "special case" such remote is probably to cause "git fetch" to
ignore such a branch.$name.remote setting and instead go fetch from
'origin', just like your "if there is branch.$name.base, but no
branch.$name.remote, fetch will go to 'origin'" does.
But it has exactly the same "what happens when you do 'git pull'"
problem, so even though it is conceptually a lot simpler, it has the
same brokenness.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[RFC] New kind of upstream branch: base branch
Hi,
I've been using Git from the start, but only lately have I forced
myself to configure upstream branches for all my branches, and I've
found a few things more convenient, but others completely contrary to
what I expected.
Inconvenient:
Before, I used to do 'git fetch' to simply fetch from 'origin', but
now, it depends on where 'upstream' is set to.
Convinient:
Now, I can just do 'git rebase --interactive' and I don't have to
specify the starting point, which is particularily useful when there's
a lot of branches one depending on another.
I think I'm using 'upstream' for something it was not intended to, and
I think the current 'upstream' behavior should be split into
'upstream' and 'base'.
== base ==
The 'base' branch will be set each time you create a branch from another;
'git checkout -b foobar master' sets 'master' as the 'base' of 'foobar'.
Then you can do 'git rebase foobar@{base}' or simply 'git rebase', and
Git will pick the right branch to rebase unto, even if you have no
'upstream'
configured.
This way 'git fetch' will keep picking 'origin', and other commands
that make use of 'upstream' would be undisturbed.
If both 'base' and 'upstream' are defined, I think 'git rebase' should
use 'base', but since that would break old behavior, perhaps there
should be a configuration variable to enable a different behavior.
I already started writting the patches, and although tedious, I think
they they'll be rather straightforward, but I thought it would be best
to hear some opinions first.
What do you think?
--
Felipe Contreras
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[RFC] New kind of upstream branch: base branch
Hi,
I've been using Git from the start, but only lately have I forced myself to
configure upstream branches for all my branches, and I've found a few things
more convenient, but others completely contrary to what I expected.
Inconvenient:
Before, I used to do 'git fetch' to simply fetch from 'origin', but now, it
depends on where 'upstream' is set to.
Convinient:
Now, I can just do 'git rebase --interactive' and I don't have to specify the
starting point, which is particularily useful when there's a lot of branches
one depending on another.
I think I'm using 'upstream' for something it was not intended to, and I think
the current 'upstream' behavior should be split into 'upstream' and 'base'.
== base ==
The 'base' branch will be set each time you create a branch from another;
'git checkout -b foobar master' sets 'master' as the 'base' of 'foobar'.
Then you can do 'git rebase foobar@{base}' or simply 'git rebase', and Git will
pick the right branch to rebase unto, even if you have no 'upstream'
configured.
This way 'git fetch' will keep picking 'origin', and other commands that make
use of 'upstrem' would be undisturbed.
If both 'base' and 'upstream' are defined, I think 'git rebase' should use
'base', but since that would break old behavior, perhaps there should be a
configuration variable to enable a different behavior.
I already started writting the patches, and although tedious, I think they
they'll be rather straightforward, but I thought it would be best to hear some
opinions first.
What do you think?
Cheers.
--
Felipe Contreras
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2] git-svn: introduce --parents parameter for commands branch and tag
This parameter is equivalent to the parameter --parents on svn cp commands
and is useful for non-standard repository layouts.
Signed-off-by: Tobias Schulte
---
Documentation/git-svn.txt|5
git-svn.perl | 19 +++-
t/t9167-git-svn-cmd-branch-subproject.sh | 48 ++
3 files changed, 71 insertions(+), 1 deletion(-)
create mode 100755 t/t9167-git-svn-cmd-branch-subproject.sh
diff --git a/Documentation/git-svn.txt b/Documentation/git-svn.txt
index 58b6d54..842ff83 100644
--- a/Documentation/git-svn.txt
+++ b/Documentation/git-svn.txt
@@ -298,6 +298,11 @@ where is the name of the SVN repository as
specified by the -R option to
git config --get-all svn-remote..commiturl
+
+--parents;;
+ Create parent folders. This parameter is equivalent to the parameter
+ --parents on svn cp commands and is useful for non-standard repository
+ layouts.
+
'tag'::
Create a tag in the SVN repository. This is a shorthand for
'branch -t'.
diff --git a/git-svn.perl b/git-svn.perl
index ccabe06..d070de0 100755
--- a/git-svn.perl
+++ b/git-svn.perl
@@ -113,7 +113,7 @@ my ($_stdin, $_help, $_edit,
$_template, $_shared,
$_version, $_fetch_all, $_no_rebase, $_fetch_parent,
$_before, $_after,
- $_merge, $_strategy, $_preserve_merges, $_dry_run, $_local,
+ $_merge, $_strategy, $_preserve_merges, $_dry_run, $_parents, $_local,
$_prefix, $_no_checkout, $_url, $_verbose,
$_commit_url, $_tag, $_merge_info, $_interactive);
@@ -203,6 +203,7 @@ my %cmd = (
{ 'message|m=s' => \$_message,
'destination|d=s' => \$_branch_dest,
'dry-run|n' => \$_dry_run,
+ 'parents' => \$_parents,
'tag|t' => \$_tag,
'username=s' => \$Git::SVN::Prompt::_username,
'commit-url=s' => \$_commit_url } ],
@@ -211,6 +212,7 @@ my %cmd = (
{ 'message|m=s' => \$_message,
'destination|d=s' => \$_branch_dest,
'dry-run|n' => \$_dry_run,
+ 'parents' => \$_parents,
'username=s' => \$Git::SVN::Prompt::_username,
'commit-url=s' => \$_commit_url } ],
'set-tree' => [ \&cmd_set_tree,
@@ -1172,6 +1174,10 @@ sub cmd_branch {
$ctx->ls($dst, 'HEAD', 0);
} and die "branch ${branch_name} already exists\n";
+ if ($_parents) {
+ mk_parent_dirs($ctx, $dst);
+ }
+
print "Copying ${src} at r${rev} to ${dst}...\n";
$ctx->copy($src, $rev, $dst)
unless $_dry_run;
@@ -1179,6 +1185,17 @@ sub cmd_branch {
$gs->fetch_all;
}
+sub mk_parent_dirs {
+ my ($ctx, $parent) = @_;
+ $parent =~ s{/[^/]*$}{};
+
+ if (!eval{$ctx->ls($parent, 'HEAD', 0)}) {
+ mk_parent_dirs($ctx, $parent);
+ print "Creating parent folder ${parent} ...\n";
+ $ctx->mkdir($parent) unless $_dry_run;
+ }
+}
+
sub cmd_find_rev {
my $revision_or_hash = shift or die "SVN or git revision required ",
"as a command-line argument\n";
diff --git a/t/t9167-git-svn-cmd-branch-subproject.sh
b/t/t9167-git-svn-cmd-branch-subproject.sh
new file mode 100755
index 000..53def87
--- /dev/null
+++ b/t/t9167-git-svn-cmd-branch-subproject.sh
@@ -0,0 +1,48 @@
+#!/bin/sh
+#
+# Copyright (c) 2013 Tobias Schulte
+#
+
+test_description='git svn branch for subproject clones'
+. ./lib-git-svn.sh
+
+test_expect_success 'initialize svnrepo' '
+ mkdir import &&
+ (
+ cd import &&
+ mkdir -p trunk/project branches tags &&
+ (
+ cd trunk/project &&
+ echo foo > foo
+ ) &&
+ svn_cmd import -m "import for git-svn" . "$svnrepo" >/dev/null
+ ) &&
+ rm -rf import &&
+ svn_cmd co "$svnrepo"/trunk/project trunk/project &&
+ (
+ cd trunk/project &&
+ echo bar >> foo &&
+ svn_cmd ci -m "updated trunk"
+ ) &&
+ rm -rf trunk
+'
+
+test_expect_success 'import into git' '
+ git svn init --trunk=trunk/project --branches=branches/*/project \
+ --tags=tags/*/project "$svnrepo" &&
+ git svn fetch &&
+ git checkout remotes/trunk
+'
+
+test_expect_success 'git svn branch tests' '
+ test_must_fail git svn branch a &&
+ git svn branch --parents a &&
+ test_must_fail git svn branch -t tag1 &&
+ git svn branch --parents -t tag1 &&
+ test_must_fail git svn branch --tag tag2 &&
+ git svn branch --parents --tag tag2 &&
+ test_must_fail git svn tag tag3 &&
+ git svn tag --parents tag3
+'
+
+test_done
--
1.7.9.5
--
To unsubscribe from this list: send
Re: [PATCH] git-svn: introduce --parents parameter for commands branch and tag
On 15.05.2013 04:35, Eric Wong wrote:
>> +if (!eval{$ctx->ls($parent, 'HEAD', 0)}) {
>> +mk_parent_dirs($ctx, $parent);
>> +print "Creating parent folder ${parent} ...\n";
>> +$ctx->mkdir($parent)
>> +unless $_dry_run;
>
> The newline is confusing, I prefer:
>
> $ctx->mkdir($parent) unless $_dry_run;
In fact, this was a copy/paste from a few lines above
print "Copying ${src} at r${rev} to ${dst}...\n";
$ctx->copy($src, $rev, $dst)
unless $_dry_run;
> Howeve :
>
> if (!$_dry_run) {
> $ctx->mkdir($parent);
> }
>
> May be preferred, too (especially for the non-Perl-fluent)
I am a non-Perl-fluent, as I come from the Java world with some
knowledge of C and C++. But to be able to create the patch I had to
gather some Perl knowledge, and by doing this, I learned enough to
understand, that there is more than one way, ... Especially the
constructs if (condition) foo(); vs foo() if (condition); and the same
for unless. And since the dry_run is the exception in this case, I think
unless is a valid choice -- and is used often in git-svn.perl. So I will
stick to it, but remove the newline.
>
>> +++ b/t/t9167-git-svn-cmd-branch-subproject.sh
>
>> +test_expect_success 'initialize svnrepo' '
>> +mkdir import &&
>> +(
>> +(cd import &&
>> +mkdir -p trunk/project branches tags &&
>> +(cd trunk/project &&
>> +echo foo > foo
>> +) &&
>
> Tabs for all indentation, and indent consistently for subshells:
>
> mkdir import &&
> (
> cd import &&
> mkdir .. &&
> (
> cd .. &&
> ..
> )
> )
>
> We use subshells + cd like this so it's easier to read/maintain.
Again, this was a copy/paste from t9128-git-svn-cmd-branch.sh. So this
file needs some cosmetics, too. And t9127... as well...
>
> Thanks again, looking forward to applying v2.
>
I will send v2 soon.
Tobias
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCHv2 03/10] refs.c: Refactor code for mapping between shorthand names and full refnames
Johan Herland wrote: > Unfortunately, using "refs/remotes/%1/%*" instead of "refs/remotes/%*" > breaks a number of git-svn tests which puts refs directly within > refs/remotes/, and then does things like "git reset --hard trunk" > (expecting trunk -> refs/remotes/trunk, which the refs/remotes/%1/%* > doesn't match). > > I don't know if putting refs directly within refs/remotes/ is > something that git-svn does by default (which would prevent us from > changing "refs/remotes/%*" to "refs/remotes/%1/%*"), or whether it is > specific to the tests (in which case we should fix the tests). Yes, git-svn uses refs/remotes/%* by default. This was a design mistake on my part. I think it's too late to change, now, as existing users will encounter breakage and/or out-of-date documentation (which is even more confusing, as git-svn is often the first introduction to git for SVN users). -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 05/10] remote-hg: fix new branch creation
On Wed, May 15, 2013 at 2:40 PM, Junio C Hamano wrote: > Felipe Contreras writes: > >> Felipe Contreras wrote: >>> When force_push is disabled, we need to turn the argument to True. > > With your follow-up clarification, here is what ended up in the log > message: > > remote-hg: fix new branch creation > > When a user creates a new branch with git: > > $ git checkout -b branches/devel > > and then pushes this branch > > $ git push origin branches/devel > > which is the way to push new mercurial branches, I don't like this part. This is not documentation, this is a commit message. You don't explain how git works in every commit message. It's not relevant how to create Mercurial branches, it could be done through a totally different way and it wouldn't affect this patch. The only thing that is relevant is that a new Mercurial branch is created somehow. But since you never, *ever*, agree that a piece of information in the commit message is not useful, I realize this is wasted breath. > we do want to > create a branch, but the command would fail without newbranch=True. > > This only matters when force_push=False, but setting newbranch=True > unconditionally does not hurt. > > The only part that I came up with on my own is "but ... does not > hurt" at the end. If that is incorrect, please supply an update. It's correct. -- Felipe Contreras -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] make color.ui default to 'auto'
On Wed, May 15, 2013 at 1:32 PM, Junio C Hamano wrote: > Matthieu Moy writes: > >>> We should be honest and say what we are doing: "it will make things >>> easier for majority while making it less convenient for minority". >> >> I thought this was what I did, but your first complain was I was >> mentionning the majority, and you are now suggesting something about >> majority/minority, so I'm lost. > > Not really. My main complaint is that you were making it sound as > if the inconvenience for the "majority" is very severe with "many > not discover", "live with", and such phrases, while making the > inconveience you are placing on the "minority" trivial with "easily > set" and "already tells them". That sounds a lot more like making a > lame excuse than doing a balanced analysis of pros and cons of the > change. I could barely parse this, but I've found that many colleagues didn't know about this configuration. And I don't see why anybody would not want this. The minority that don't want this can search the interwebs to find out how to disable the unwanted behavior, so the majority that do want this don't have to enable it all the time (*if* they know about it). -- Felipe Contreras -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 05/10] remote-hg: fix new branch creation
Felipe Contreras writes: > Felipe Contreras wrote: >> When force_push is disabled, we need to turn the argument to True. With your follow-up clarification, here is what ended up in the log message: remote-hg: fix new branch creation When a user creates a new branch with git: $ git checkout -b branches/devel and then pushes this branch $ git push origin branches/devel which is the way to push new mercurial branches, we do want to create a branch, but the command would fail without newbranch=True. This only matters when force_push=False, but setting newbranch=True unconditionally does not hurt. The only part that I came up with on my own is "but ... does not hurt" at the end. If that is incorrect, please supply an update. Thanks. >> Signed-off-by: Felipe Contreras >> --- >> contrib/remote-helpers/git-remote-hg | 2 +- >> 1 file changed, 1 insertion(+), 1 deletion(-) >> >> diff --git a/contrib/remote-helpers/git-remote-hg >> b/contrib/remote-helpers/git-remote-hg >> index 4a5c72f..3cf9b4c 100755 >> --- a/contrib/remote-helpers/git-remote-hg >> +++ b/contrib/remote-helpers/git-remote-hg >> @@ -856,7 +856,7 @@ def do_export(parser): >> continue >> >> if peer: >> -parser.repo.push(peer, force=force_push) >> +parser.repo.push(peer, force=force_push, newbranch=True) >> >> # handle bookmarks >> for bmark, node in p_bmarks: >> -- >> 1.8.3.rc1.579.g184e698 -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Lines missing from git diff-tree -p -c output?
Matthijs Kooijman writes: >> Could you explain why you think it hides the real problem, and what >> kind of future enhancement may break it? > I think the differences is mostly in the locality of the fix. In my > proposed patch, the no_pre_delete flag is never set on an interesting > line because it is checked in the line before it. In your patch, it > never happens because the control flow guarantees the "context" lines > before each change must be uninteresting. > > The net effect is of course identical, but I'm arguing that depending on > the control flow and some code a doze lines down is easier to break than > depending on a previous line. Yeah, that sounds like a reasonable reasoning. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] make color.ui default to 'auto'
Matthieu Moy writes: >> We should be honest and say what we are doing: "it will make things >> easier for majority while making it less convenient for minority". > > I thought this was what I did, but your first complain was I was > mentionning the majority, and you are now suggesting something about > majority/minority, so I'm lost. Not really. My main complaint is that you were making it sound as if the inconvenience for the "majority" is very severe with "many not discover", "live with", and such phrases, while making the inconveience you are placing on the "minority" trivial with "easily set" and "already tells them". That sounds a lot more like making a lame excuse than doing a balanced analysis of pros and cons of the change. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC 0/2] refactor relative_path in path.c
Jiang Xin writes: > These two patches enhance relative_path() in path.c, so that function > relative_path() will return real relative path, not a path strip off > the prefix. > > The 2nd patch is a bit aggressive, it refactor all related functions, > remove unnecessary arguments: len and/or prefix_len. I did not particularly find the second one "aggressive"; it would have been much more pleasant to review if the "drop unused 'len'" part were made into a separate patch [3/2] as a follow-up, though. It is a bit sad that relative_path() in [1/2] uses a single static and fixed sized buffer. How is the new implementation making sure the expanded result does not overflow the buf[]? -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] make color.ui default to 'auto'
Junio C Hamano writes: > Now, realize that after switching the default, these "few people" > have to live with distracting (or unreadable) output. Because these > people are minority, their websearch "disable colors in git" will by > definition have smaller number of hits than "enable colors in git" > the above claims people "may not discover it by themselves". As my message says, "disable colors in git" already gives you the answer, today (1st hit in Google). I'm not worried about the difficulty to find the information in the future. > We should be honest and say what we are doing: "it will make things > easier for majority while making it less convenient for minority". I thought this was what I did, but your first complain was I was mentionning the majority, and you are now suggesting something about majority/minority, so I'm lost. In any case, feel free to change the commit message, what's really important is the actual change, and it does not seem controversial. -- Matthieu Moy http://www-verimag.imag.fr/~moy/ -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Lines missing from git diff-tree -p -c output?
Hi Junio,
> Could you explain why you think it hides the real problem, and what
> kind of future enhancement may break it?
I think the differences is mostly in the locality of the fix. In my
proposed patch, the no_pre_delete flag is never set on an interesting
line because it is checked in the line before it. In your patch, it
never happens because the control flow guarantees the "context" lines
before each change must be uninteresting.
The net effect is of course identical, but I'm arguing that depending on
the control flow and some code a doze lines down is easier to break than
depending on a previous line.
Having said that: I'm not sure if the difference is significant enough
to convince me in either direction.
However, thinking about this a bit more (and getting sidetracked on a
completely separate issue/question), I wonder why the coalescing-hunks
code is there in the first place? e.g., why not leave out these lines?
if (k < j + context) {
/* k is interesting and [j,k) are not, but
* paint them interesting because the gap is small.
*/
while (j < k)
sline[j++].flag |= mark;
i = k;
goto again;
}
If the "context" lines before and after each group of changes are
painted interesting, then these lines in between will also be painted
interesting. Of course, this could cause some lines to be painted as
interesting twice and it needs my fix for the no_pre_delete thing, but
it would work just as well?
However, I can imagine that this code is present to prevent painting
lines twice, which would of course be a bit of a performance loss. But
if this really was the motivation, why is the first if not something
like:
if (k <= j + 2 * context) {
Since IIUC, the current code can still paint a few context lines twice
when they are exacly "context" lines apart, once by the "paint before"
and one by the "paint after" code (which is also what happens in my bug
example, I think). The above should "fix" that as well (the first part
of the test suite hasn't complained so far).
Gr.
Matthijs
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Fwd: git cvsimport implications
Hi My primary goal was to understand better what are the real problems that we might have with the way we use git cvsimport, so I was not asking about the guarantee of the cvsimport to import things correctly, but if there is a guarantee the import will result in completely broken history. IF there is a situation when cvsimport can do things right and when it definitely going to fail? Anyway, thanks a lot for the info. I do know that cvs2git is an option. If the cvsimport is that broken - is there any plan to fix it? Thanks, Eugene On Wed, May 15, 2013 at 2:24 AM, Michael Haggerty wrote: > On 05/15/2013 12:19 AM, Junio C Hamano wrote: >> Eugene Sajine writes: >> >>> What if there are a lot of branches in the CVS repo? Is it guaranteed >>> to be broken after import? >> >> Even though CVS repository can record branches in individual ,v >> files, reconstructing per branch history and where the branch >> happened in each "changeset" cannot be determined with any >> certainty. The best you can get is a heuristic result. >> >> I do not think anybody can give such a guarantee. The best you can >> do is to convert it and validate if the result matches what you >> think has happened in the CVS history. > > Junio, you are correct that there is no 100% reliable way of inferring > the changesets that were made in CVS. CVS doesn't record which file > revisions were committed at the same time, unambiguous branch points, > etc. The best a tool can do is use heuristics. > > But it *is* possible for a conversion tool to make some more elementary > guarantees regarding aspects of the history that are recorded > unambiguously in CVS, for example: > > * That if you check the tip of same branch out of CVS and out of Git, > you get the same contents. > > * That CVS file revisions are committed to Git in the correct order > relative to each other; e.g., that the changes made in CVS revision > 1.4.2.2 in a particular file precede those made in revision 1.4.2.3 of > the same file. > > git-cvsimport fails to ensure even this minimal level of correctness. > Such errors are demonstrated in its own test suite. > > cvs2git, on the other hand, gets the basics 100% correct (if you find a > discrepancy, please file a bug!), in addition to having great heuristics > for inferring the details of the history. > > There is no reason ever to use git-cvsimport for one-time conversions > from CVS to Git. The only reason ever to use it is if you absolutely > require an incremental bridge between CVS and Git, and even then please > use it with great caution. > > Michael > the cvs2svn/cvs2git maintainer > > -- > Michael Haggerty > mhag...@alum.mit.edu > http://softwareswirl.blogspot.com/ -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] make color.ui default to 'auto'
Matthieu Moy writes:
> Junio C Hamano writes:
>
>> I think you are missing the entire point, which is not "is anyone
>> harmed?"
>
> Again, it is. If the new default is really harmful for too many people,
> then documentations will have to mention how to fix it.
>
> And really, I do not forsee any newbie-oriented starting with "here's
> how to disable colors in case you need it", because of the reasons
> mentionned in the message.
>
>> Our recommendation has been "use color=auto"
>
> Not really. Neither Documentation/gittutorial.txt nor
> Documentation/user-manual.txt mention colors. Pro Git mentions it, but
> more as a possibility than as a recommandation. This is the
> recommandation of the rest of the world, not "ours".
Do you mean the git users who learn and use Git without being in the
circle of people who updates Documentation/ hierarchy "the rest of
the world"?
I think that is a flawed mentality. They are part of "us".
> It's not "either we update the docs or we update the code", it's "follow
> what the rest of the world is doing", and "rest of the world" has to
> imply a notion of majority (not all tutorials talk about color.ui).
Yes, exactly.
Read the statement you made again, with the assumption that
everybody ("the rest of the world") already knows (and/or agreed to)
colouring is a good thing.
> ... Other beginners do not know about
> color.ui=auto, and may not discover it by themselves, hence live with
> black&white outputs while they may have prefered colors.
>
> A few people (e.g. color-blind) prefer having no colors, but they can
> easily set color.ui=never for this (and googling "disable colors in git"
> already tells them how to do so).
Now, realize that after switching the default, these "few people"
have to live with distracting (or unreadable) output. Because these
people are minority, their websearch "disable colors in git" will by
definition have smaller number of hits than "enable colors in git"
the above claims people "may not discover it by themselves". In a
way, you are making things even harder because these minority do not
have many similar others to ask help for.
That is the honest way to express what you said in the second
paragraph.
If we really want to justify the changing of the default, we should
not try to weasel out by using asymmetric wording from the fact that
we are making things less convenient for one kind of people. We
should be honest and say what we are doing: "it will make things
easier for majority while making it less convenient for minority".
I am however saying that in this case, we are better off not even
trying to come up with such a lame excuse for us to hurt color-blind
people in order to make things easier for majority. Just saying
"the rest of the world prefer automatic color and that is what we
recommend, so make the code match" should be sufficient.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] combine-diff.c: Fix output when changes are exactly 3 lines apart
When a deletion is followed by exactly 3 (or whatever the number of
context lines) unchanged lines, followed by another change, the combined
diff output would hide the first deletion, resulting in a malformed
diff.
This happened because the 3 lines before each change are painted
interesting, but also marked as no_pre_delete to prevent showing deletes
that were previously marked as uninteresting. This behaviour was
introduced in c86fbe53 (diff -c/--cc: do not include uninteresting
deletion before leading context). However, as a side effect, this could
also mark deletes that were already interesting as no_pre_delete. This
would happen only if the delete was exactly 3 lines away from the next
change, since lines farther away would not be touched by the "paint
three lines before the change" code and lines closer would be painted
by the "merge two adjacent hunks" code instead, which does not set the
no_pre_delete flag.
This commit fixes this problem by only setting the no_pre_delete flag
for changes that were previously uninteresting.
Signed-off-by: Matthijs Kooijman
---
combine-diff.c | 7 +--
t/t4038-diff-combined.sh | 47 +++
2 files changed, 52 insertions(+), 2 deletions(-)
diff --git a/combine-diff.c b/combine-diff.c
index 77d7872..3e8bb17 100644
--- a/combine-diff.c
+++ b/combine-diff.c
@@ -518,8 +518,11 @@ static int give_context(struct sline *sline, unsigned long
cnt, int num_parent)
unsigned long k;
/* Paint a few lines before the first interesting line. */
- while (j < i)
- sline[j++].flag |= mark | no_pre_delete;
+ while (j < i) {
+ if (!(sline[j].flag & mark))
+ sline[j].flag |= no_pre_delete;
+ sline[j++].flag |= mark;
+ }
again:
/* we know up to i is to be included. where does the
diff --git a/t/t4038-diff-combined.sh b/t/t4038-diff-combined.sh
index 1261dbb..a23ca7e 100755
--- a/t/t4038-diff-combined.sh
+++ b/t/t4038-diff-combined.sh
@@ -353,4 +353,51 @@ test_expect_failure 'combine diff coalesce three parents' '
compare_diff_patch expected actual
'
+# Test for a bug reported at
+# http://thread.gmane.org/gmane.comp.version-control.git/224410
+# where a delete lines were missing from combined diff output when they
+# occurred exactly before the context lines of a later change.
+test_expect_success 'combine diff missing delete bug' '
+ git commit -m initial --allow-empty &&
+ cat <<-\EOF >test &&
+ 1
+ 2
+ 3
+ 4
+ EOF
+ git add test
+ git commit -a -m side1 &&
+ git checkout -B side1 &&
+ git checkout HEAD^ &&
+ cat <<-\EOF >test &&
+ 0
+ 1
+ 2
+ 3
+ 4modified
+ EOF
+ git commit -a -m side2 &&
+ git branch -f side2 &&
+ test_must_fail git merge --no-commit side1 &&
+ cat <<-\EOF >test &&
+ 1
+ 2
+ 3
+ 4modified
+ EOF
+ git add test &&
+ git commit -a -m merge &&
+ git diff-tree -c -p HEAD >actual.tmp &&
+ sed -e "1,/^@@@/d" < actual.tmp >actual &&
+ tr -d Q <<-\EOF >expected &&
+ - 0
+ 1
+ 2
+ 3
+-4
++4modified
+ EOF
+ compare_diff_patch expected actual
+'
+
test_done
--
1.8.3.rc1
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] make color.ui default to 'auto'
Junio C Hamano writes: > I think you are missing the entire point, which is not "is anyone > harmed?" Again, it is. If the new default is really harmful for too many people, then documentations will have to mention how to fix it. And really, I do not forsee any newbie-oriented starting with "here's how to disable colors in case you need it", because of the reasons mentionned in the message. > Our recommendation has been "use color=auto" Not really. Neither Documentation/gittutorial.txt nor Documentation/user-manual.txt mention colors. Pro Git mentions it, but more as a possibility than as a recommandation. This is the recommandation of the rest of the world, not "ours". It's not "either we update the docs or we update the code", it's "follow what the rest of the world is doing", and "rest of the world" has to imply a notion of majority (not all tutorials talk about color.ui). -- Matthieu Moy http://www-verimag.imag.fr/~moy/ -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v5 1/2] cache.h: eliminate SHA-1 deprecation warnings on Mac OS X
On 2013-05-15 09.11, David Aguilar wrote: > Mac OS X 10.8 Mountain Lion prints warnings when building git: > > warning: 'SHA1_Init' is deprecated > (declared at /usr/include/openssl/sha.h:121) > > Silence the warnings by using the CommonCrytpo SHA-1 > functions for SHA1_Init(), SHA1_Update(), and SHA1_Final(). > > COMMON_DIGEST_FOR_OPENSSL is defined to enable the OpenSSL > compatibility macros in CommonDigest.h. > > Add a NO_APPLE_COMMON_CRYPTO option to the Makefile to allow > users to opt out of using this library. When defined, Git will > use OpenSSL instead. > > Helped-by: Eric Sunshine > Signed-off-by: David Aguilar > --- > Both of these are replacement patches "pu". > > Changes from last time: > > It now uses a single APPLE_COMMON_CRYPTO definition. > Users can now opt-out by setting NO_APPLE_COMMON_CRYPTO. > > Makefile | 13 + > 1 file changed, 13 insertions(+) > > diff --git a/Makefile b/Makefile > index f698c1a..8309c41 100644 > --- a/Makefile > +++ b/Makefile > @@ -137,6 +137,10 @@ all:: > # specify your own (or DarwinPort's) include directories and > # library directories by defining CFLAGS and LDFLAGS appropriately. > # > +# Define NO_APPLE_COMMON_CRYPTO if you are building on Darwin/Mac OS X > +# and do not want to use Apple's CommonCrypto library. This allows you > +# to provide your own OpenSSL library, for example from MacPorts. > +# > # Define BLK_SHA1 environment variable to make use of the bundled > # optimized C SHA1 routine. > # > @@ -1054,6 +1058,9 @@ ifeq ($(uname_S),Darwin) > BASIC_LDFLAGS += -L/opt/local/lib > endif > endif > + ifndef NO_APPLE_COMMON_CRYPTO > + APPLE_COMMON_CRYPTO = YesPlease > + endif > NO_REGEX = YesPlease > PTHREAD_LIBS = > endif > @@ -1389,10 +1396,16 @@ ifdef PPC_SHA1 > LIB_OBJS += ppc/sha1.o ppc/sha1ppc.o > LIB_H += ppc/sha1.h > else > +ifdef APPLE_COMMON_CRYPTO > + BASIC_CFLAGS += -DCOMMON_DIGEST_FOR_OPENSSL > + SHA1_HEADER = Would it make sense to replace APPLE_COMMON_CRYPTO with COMMON_DIGEST_FOR_OPENSSL ? In the spirit of other Makefile-defines becoming Compiler defines, a random picked example: ifdef NO_STRTOULL COMPAT_CFLAGS += -DNO_STRTOULL endif /Torsten -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Lines missing from git diff-tree -p -c output?
Matthijs Kooijman writes: > Hi Junio, > >> I think the coalescing of two adjacent hunks into one is painting >> leading lines "interesting to show context but not worth showing >> deletion before it" incorrectly. > Yup, that seems to be the case. > >> Does this patch fix the issue? > > Yes, it fixes the issue. However, I think that this patch actually hides > the real problem (in a way that will always work with the current code, > though). Could you explain why you think it hides the real problem, and what kind of future enhancement may break it? This is *not* my usual rhetorical question "Please explain yourself, because I think you are wrong", but is "I do not understand the reasoning behind your statement, and I (and the reasoning behind my patch) must be missing something important, so please enlighten me by pointing out where I am wrong, so that I won't stick to my flawed patch". The painting with no_pre_delete is applied when we extend the common context back to lines we _know_ otherwise not worth showing (because there is no difference) only because we want to show them as the context lines and we do not need to show deletions that come before these common context. By forcing (k == j + context) case, that is, there are exactly "context" number of lines between the end of the current hunk and the next hunk, which the old code would have showed "context" lines at the beginning of the next hunk, to go back to the "again" label, we are coalescing the two hunks that _should_ have been shown together anyway, without painting the context lines incorrectly with "before this line, do not show deletion" mark. > I had come up with a different fix myself (similar to the one I sent to > the list as a followup, but that one still had a bug), which I think > might be better. In any case, it includes a testcase for this bug which > seems good to include. > > I'll send my patch as a followup in a minute, feel free to use it > entirely or only partially. > > Gr. > > Matthijs -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] make color.ui default to 'auto'
Matthieu Moy writes: >> The above two paragraphs do not make a good justification [*1*]. >> The former can just as easily websearch for "enable colours in git" > > I disagree: I do not know anyone who would be really harmed by colors > ... I actually am one of them (light cyan or green on white background with small font is very hard to read for me), but I think you are missing the entire point, which is not "is anyone harmed?" This patch is not even about deciding if colored output should be the default. That has already been decided by documentation for us long time ago; the patch does not have to (and should not) argue for and justify why color is good. Our recommendation has been "use color=auto", and change of the in-code default is merely to make the default in line with that recommendation. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Lines missing from git diff-tree -p -c output?
Hi Junio, > I think the coalescing of two adjacent hunks into one is painting > leading lines "interesting to show context but not worth showing > deletion before it" incorrectly. Yup, that seems to be the case. > Does this patch fix the issue? Yes, it fixes the issue. However, I think that this patch actually hides the real problem (in a way that will always work with the current code, though). I had come up with a different fix myself (similar to the one I sent to the list as a followup, but that one still had a bug), which I think might be better. In any case, it includes a testcase for this bug which seems good to include. I'll send my patch as a followup in a minute, feel free to use it entirely or only partially. Gr. Matthijs -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2] make color.ui default to 'auto'
Matthieu Moy writes: > Junio C Hamano writes: > >> Matthieu Moy writes: >> >>> diff --git a/builtin/config.c b/builtin/config.c >>> index 000d27c..ecfceca 100644 >>> --- a/builtin/config.c >>> +++ b/builtin/config.c >>> @@ -316,7 +316,7 @@ static void get_color(const char *def_color) >>> >>> static int get_colorbool_found; >>> static int get_diff_color_found; >>> -static int get_color_ui_found; >>> +static int get_color_ui_found = GIT_COLOR_AUTO; >> >> It is curious to notice that we have these three and only one is >> initialized to the new default value, while the other two get -1 >> at the beginning of get_colorbool(). > > Right. The meaning of the _found suffix is clear for the first two, but > not the last. > >> I wonder if it would be cleaner to statically initialize all three >> to -1 here, drop the assignment of -1 to two of them from the >> beginning of get_colorbool(), and then have a final fallback inside >> the want_color() call itself, i.e. > > I've left the assignments within the function (I like the initialisation > right before usage, I don't have to worry about how many times the > function is called then), but I've added a patch that initializes > get_color_ui_found to -1 like the others, and does essentially this: > >> get_colorbool_found = want_color(get_colorbool_found < 0 >> ? GIT_COLOR_AUTO >> : get_colorbool_found); > > Except I've made it a separate if statement. Then PATCH 2/2 is really > crystal clear. Yeah, sounds good. > Reroll comming, with an improved commit message that should adress the > points in the other message. Hmm, I don't see much improvement in the message, though. It seems to talk about "may not discover", "live with", "a few people", and "they can easily", none of which should be there. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: English/German terminology, git.git's de.po, and pro-git
On Wednesday 2013-05-15 17:31, Holger Hellmuth (IKS) wrote: >>> >>> I actually had the '-' in there too until I tried to look up "Zip-Datei" >>> in the Duden. While I don't get the leading '.' (I cannot remember having >>> seen that anywhere, AFAIK the file extensions are always used without the >>> dot), I'm not a grammar expert and will be fine either way. >> >> In UNIX-land, extension seemed to always include the dot. >> In DOS-land, it's without (inherited from VMS too, perhaps?) >> As such, either way to write it is acceptable. > > Even in unix-land no one adds a dot because usually the extension is named > after the data format, only that the file extension is used as the common > abbreviation (at least that is my interpretation). Compare with jpeg. You > often > write jpeg-Datei instead of jpg-Datei because the data format is called jpeg. That too is correct, and actually a third way of describing files. For example, .doc/.xls-Datei in speech is very seldom, if at all; MS Office output has had generally been called Word-Datei, Excel-Tabelle/-Datei and so on. What I meant however is that the extension is ".jpg" (or .jpeg) from a programming aspect (like, when naïvely trying to figure out the filetype) as in ($name, $ext) = (/^[^\.]+(\..+)?/) -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Lines missing from git diff-tree -p -c output?
Matthijs Kooijman writes:
> $ git diff-tree -p -c HEAD
> d945a51b6ca22e6e8e550c53980d026f11b05158
> diff --combined file
> index 3404f54,0eab113..e8c8c18
> --- a/file
> +++ b/file
> @@@ -1,7 -1,5 +1,6 @@@
> +LEFT
> BASE2
> BASE3
> BASE4
> - BASE5
> + BASE5MODIFIED
> BASE6
>
> Here, the header claims that the first head has 7 lines, but there really are
> only 6 (5 lines of context and one delete line). The numbers for the others
> heads are incorrect. In the original diff, the difference was bigger
> (first head was stated to have 28 lines, while the output was similar to
> the above).
The count and the output does look inconsistent. The hunk header
claims that it is showing:
- range 1,7 for the first parent but it should be 1,5 (2, 3, 4, 5 and 6)
to match the output.
- range 1,5 for the second parent (left, 2, 3, 4, 5mod, and 6 -- correct)
- range 1,6 for the result (left, 2, 3, 4, 5mod and 6 -- correct)
If we resurrect the loss of "BASE1" from the output, then the
output should have shown:
+LEFT
- BASE1
BASE2
BASE3
BASE4
- BASE5
+ BASE5MODIFIED
BASE6
which means the numbers shown for the first parent (1, 2, 3, 4, 5
and 6) should be 1,6.
> Note that to trigger this behaviour, the number of context lines between the
> BASE1 and BASE5 must be _exactly_ 3, more or less prevents this bug from
> occuring.
I think the coalescing of two adjacent hunks into one is painting
leading lines "interesting to show context but not worth showing
deletion before it" incorrectly.
Does this patch fix the issue?
combine-diff.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/combine-diff.c b/combine-diff.c
index 77d7872..7359b84 100644
--- a/combine-diff.c
+++ b/combine-diff.c
@@ -533,7 +533,7 @@ static int give_context(struct sline *sline, unsigned long
cnt, int num_parent)
k = find_next(sline, mark, j, cnt, 0);
j = adjust_hunk_tail(sline, all_mask, i, j);
- if (k < j + context) {
+ if (k <= j + context) {
/* k is interesting and [j,k) are not, but
* paint them interesting because the gap is small.
*/
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/2] config: refactor management of color.ui's default value
The meaning of get_colorbool_found and get_diff_color_found is "the
config value if found, and -1 otherwise", but get_color_ui_found had a
slightly different meaning, as it has the value 0 (which corresponds to
the default value from the user point of view) when color.ui is unset.
Make get_color_ui_found default to -1, and make it explicit that 0 is the
default value when nothing else is found.
Signed-off-by: Matthieu Moy
---
So, this is new, as suggested by Junio.
builtin/config.c | 5 +
1 file changed, 5 insertions(+)
diff --git a/builtin/config.c b/builtin/config.c
index 000d27c..171bad7 100644
--- a/builtin/config.c
+++ b/builtin/config.c
@@ -333,6 +333,7 @@ static int get_colorbool(int print)
{
get_colorbool_found = -1;
get_diff_color_found = -1;
+ get_color_ui_found = -1;
git_config_with_options(git_get_colorbool_config, NULL,
given_config_file, given_config_blob,
respect_includes);
@@ -344,6 +345,10 @@ static int get_colorbool(int print)
get_colorbool_found = get_color_ui_found;
}
+ if (get_colorbool_found < 0)
+ /* default value if none found in config */
+ get_colorbool_found = 0;
+
get_colorbool_found = want_color(get_colorbool_found);
if (print) {
--
1.8.3.rc1.315.g4602f33
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 2/2 v4] make color.ui default to 'auto'
Most users seem to like having colors enabled, and colors can help beginners to understand the output of some commands (e.g. notice immediately the boundary between commits in the output of "git log"). Many tutorials tell the users to set color.ui=auto as a very first step, which tend to indicate that color.ui=none is not the recommanded value, hence should not be the default. These tutorials would benefit from skipping this step and starting the real Git manipulations earlier. Other beginners do not know about color.ui=auto, and may not discover it by themselves, hence live with black&white outputs while they may have preferred colors. A few people (e.g. color-blind) prefer having no colors, but they can easily set color.ui=never for this (and googling "disable colors in git" already tells them how to do so), but this needs not occupy space in beginner-oriented documentations. A transition period with Git emitting a warning when color.ui is unset would be possible, but the discomfort of having the warning seems superior to the benefit: users may be surprised by the change, but not harmed by it. The default value is changed, and the documentation is reworded to mention "color.ui=false" first, since the primary use of color.ui after this change is to disable colors, not to enable it. Signed-off-by: Matthieu Moy --- Adapted after PATCH 1/2, and commit message updated. Documentation/config.txt | 11 ++- builtin/config.c | 2 +- color.c | 2 +- 3 files changed, 8 insertions(+), 7 deletions(-) diff --git a/Documentation/config.txt b/Documentation/config.txt index 1009bfc..97550be 100644 --- a/Documentation/config.txt +++ b/Documentation/config.txt @@ -913,11 +913,12 @@ color.ui:: as `color.diff` and `color.grep` that control the use of color per command family. Its scope will expand as more commands learn configuration to set a default for the `--color` option. Set it - to `always` if you want all output not intended for machine - consumption to use color, to `true` or `auto` if you want such - output to use color when written to the terminal, or to `false` or - `never` if you prefer Git commands not to use color unless enabled - explicitly with some other configuration or the `--color` option. + to `false` or `never` if you prefer Git commands not to use + color unless enabled explicitly with some other configuration + or the `--color` option. Set it to `always` if you want all + output not intended for machine consumption to use color, to + `true` or `auto` (this is the default since Git 2.0) if you + want such output to use color when written to the terminal. column.ui:: Specify whether supported commands should output in columns. diff --git a/builtin/config.c b/builtin/config.c index 171bad7..4010c43 100644 --- a/builtin/config.c +++ b/builtin/config.c @@ -347,7 +347,7 @@ static int get_colorbool(int print) if (get_colorbool_found < 0) /* default value if none found in config */ - get_colorbool_found = 0; + get_colorbool_found = GIT_COLOR_AUTO; get_colorbool_found = want_color(get_colorbool_found); diff --git a/color.c b/color.c index e8e2681..f672885 100644 --- a/color.c +++ b/color.c @@ -1,7 +1,7 @@ #include "cache.h" #include "color.h" -static int git_use_color_default = 0; +static int git_use_color_default = GIT_COLOR_AUTO; int color_stdout_is_tty = -1; /* -- 1.8.3.rc1.315.g4602f33 -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2] make color.ui default to 'auto'
Junio C Hamano writes: > Matthieu Moy writes: > >> diff --git a/builtin/config.c b/builtin/config.c >> index 000d27c..ecfceca 100644 >> --- a/builtin/config.c >> +++ b/builtin/config.c >> @@ -316,7 +316,7 @@ static void get_color(const char *def_color) >> >> static int get_colorbool_found; >> static int get_diff_color_found; >> -static int get_color_ui_found; >> +static int get_color_ui_found = GIT_COLOR_AUTO; > > It is curious to notice that we have these three and only one is > initialized to the new default value, while the other two get -1 > at the beginning of get_colorbool(). Right. The meaning of the _found suffix is clear for the first two, but not the last. > I wonder if it would be cleaner to statically initialize all three > to -1 here, drop the assignment of -1 to two of them from the > beginning of get_colorbool(), and then have a final fallback inside > the want_color() call itself, i.e. I've left the assignments within the function (I like the initialisation right before usage, I don't have to worry about how many times the function is called then), but I've added a patch that initializes get_color_ui_found to -1 like the others, and does essentially this: > get_colorbool_found = want_color(get_colorbool_found < 0 > ? GIT_COLOR_AUTO > : get_colorbool_found); Except I've made it a separate if statement. Then PATCH 2/2 is really crystal clear. Reroll comming, with an improved commit message that should adress the points in the other message. -- Matthieu Moy http://www-verimag.imag.fr/~moy/ -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] make color.ui default to 'auto'
On Wed, May 15, 2013 at 08:42:39AM -0700, Junio C Hamano wrote:
> Matthieu Moy writes:
>
> > Many tutorials tell the users to set color.ui=auto as a very first step.
> > These tutorials would benefit from skiping this step and starting the
> > real Git manipualtions earlier. Other beginners do not know about
> > color.ui=auto, and may not discover it by themselves, hence live with
> > black&white outputs while they may have prefered colors.
> >
> > A few people (e.g. color-blind) prefer having no colors, but they can
> > easily set color.ui=never for this (and googling "disable colors in git"
> > already tells them how to do so).
>
> The above two paragraphs do not make a good justification [*1*].
> The former can just as easily websearch for "enable colours in git"
> as the latter would for "disable" in order to avoid having to live
> with distraction while they may have preferred monochrome.
>
> The train of thought that is a sufficient justification for this
> change is "Our document and third-party tutorials often start with
> setting color.ui=auto configuration." leading to "Our recommendation
> is to enable colour on terminals." which in turn leading to "Why is
> our default monochrome, against our own recommendation?". Saying
> anything more, like who are the majority or how easily the default
> can be overridden, is unnecessary, I think [*2*].
>
> As this is purely a UI thing, and since daa0c3d97176 (color: delay
> auto-color decision until point of use, 2011-08-17), the logic to
> decide when "auto colouring" is triggered is centrary controlled
> (hence it is much less likely than before that color.ui=auto could
> misfire when it shouldn't), I agree that this does not even deserve
> a warning. You could even sell it as a pure bugfix ("we recommend
> users to use auto colouring but we did not set it up for users").
>
> > The default value is changed, and the documentation is reworded to
> > mention "color.ui=false" first, since the primary use of color.ui after
> > this change is to disable colors, not to enable it.
>
> Good.
>
> > I'm starting to wonder why we didn't do this earlier ;-).
> >
> > Documentation/config.txt | 11 ++-
> > color.c | 2 +-
> > 2 files changed, 7 insertions(+), 6 deletions(-)
> >
> > diff --git a/Documentation/config.txt b/Documentation/config.txt
> > index 1009bfc..97550be 100644
> > --- a/Documentation/config.txt
> > +++ b/Documentation/config.txt
> > @@ -913,11 +913,12 @@ color.ui::
> > as `color.diff` and `color.grep` that control the use of color
> > per command family. Its scope will expand as more commands learn
> > configuration to set a default for the `--color` option. Set it
> > + to `false` or `never` if you prefer Git commands not to use
> > + color unless enabled explicitly with some other configuration
> > + or the `--color` option. Set it to `always` if you want all
> > + output not intended for machine consumption to use color, to
> > + `true` or `auto` (this is the default since Git 2.0) if you
> > + want such output to use color when written to the terminal.
>
> OK, so this is planned for 2.0?
I would vote for just considering this a bugfix as you say above and
therefore not worthy of any special treatment, so it should end up in
whatever the next release is after it hits master.
The changes that are being held back for 2.0 change how commands operate
and we don't provide any overrides for those; this is just a cosmetic
change to the default output format.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] make color.ui default to 'auto'
Junio C Hamano writes: > Matthieu Moy writes: > >> Many tutorials tell the users to set color.ui=auto as a very first step. >> These tutorials would benefit from skiping this step and starting the >> real Git manipualtions earlier. Other beginners do not know about >> color.ui=auto, and may not discover it by themselves, hence live with >> black&white outputs while they may have prefered colors. >> >> A few people (e.g. color-blind) prefer having no colors, but they can >> easily set color.ui=never for this (and googling "disable colors in git" >> already tells them how to do so). > > The above two paragraphs do not make a good justification [*1*]. > The former can just as easily websearch for "enable colours in git" I disagree: I do not know anyone who would be really harmed by colors (and such users would most likely have a terminal configured without colors I guess), so although I can imagine some people feeling less comfortable, disabling colors can be deferred to much later in the learning process. When I teach Git to students (a relatively short tutorial), I currently ask them to type a ~/.gitconfig containing color.ui=auto before anything else. If this was the default, I would skip this completely from the beginner-oriented doc, and I would mention color.ui=never only to people complaining about colors. It's really about _skipping_ the color-related stuff from the newbie docs, not about reverting them. Also, as my message points out, with "disabled by default", many people do not know that it is possible to have it, hence won't google for anything related to colors. There's no symmetry either here: with colors enabled by default, people will know that Git can use colors. >> diff --git a/Documentation/config.txt b/Documentation/config.txt >> index 1009bfc..97550be 100644 >> --- a/Documentation/config.txt >> +++ b/Documentation/config.txt >> @@ -913,11 +913,12 @@ color.ui:: >> as `color.diff` and `color.grep` that control the use of color >> per command family. Its scope will expand as more commands learn >> configuration to set a default for the `--color` option. Set it >> +to `false` or `never` if you prefer Git commands not to use >> +color unless enabled explicitly with some other configuration >> +or the `--color` option. Set it to `always` if you want all >> +output not intended for machine consumption to use color, to >> +`true` or `auto` (this is the default since Git 2.0) if you >> +want such output to use color when written to the terminal. > > OK, so this is planned for 2.0? We've lived without this for years, so I'd say it can wait untill Git 2.0. It may give a "Wow" effect to some users when upgrading ;-). -- Matthieu Moy http://www-verimag.imag.fr/~moy/ -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2] make color.ui default to 'auto'
Matthieu Moy writes: > diff --git a/builtin/config.c b/builtin/config.c > index 000d27c..ecfceca 100644 > --- a/builtin/config.c > +++ b/builtin/config.c > @@ -316,7 +316,7 @@ static void get_color(const char *def_color) > > static int get_colorbool_found; > static int get_diff_color_found; > -static int get_color_ui_found; > +static int get_color_ui_found = GIT_COLOR_AUTO; It is curious to notice that we have these three and only one is initialized to the new default value, while the other two get -1 at the beginning of get_colorbool(). I wonder if it would be cleaner to statically initialize all three to -1 here, drop the assignment of -1 to two of them from the beginning of get_colorbool(), and then have a final fallback inside the want_color() call itself, i.e. get_colorbool_found = want_color(get_colorbool_found < 0 ? GIT_COLOR_AUTO : get_colorbool_found); so that it is clear that -1 consistently mean "We haven't read any value from the configuration file for this variable", instead of making get_color_ui_found mean slightly different thing (the value read from the configuration; GIT_COLOR_AUTO means we cannot tell if we saw this variable or the user specified auto) from the other two (the value read from the configuration; -1 means we did not find any). -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Lines missing from git diff-tree -p -c output?
Hi folks,
> $ git diff-tree -p -c HEAD
> d945a51b6ca22e6e8e550c53980d026f11b05158
> diff --combined file
> index 3404f54,0eab113..e8c8c18
> --- a/file
> +++ b/file
> @@@ -1,7 -1,5 +1,6 @@@
> +LEFT
> BASE2
> BASE3
> BASE4
> - BASE5
> + BASE5MODIFIED
> BASE6
I found the spot in the code where this is going wrong, there is an
incorrectly set "no_pre_delete" flag for the context lines before each
hunk. Since a patch says more than a thousand words, here's what I think
will fix this problem:
diff --git a/combine-diff.c b/combine-diff.c
index 77d7872..d36bfcf 100644
--- a/combine-diff.c
+++ b/combine-diff.c
@@ -518,8 +518,11 @@ static int give_context(struct sline *sline, unsigned long
cnt, int num_parent)
unsigned long k;
/* Paint a few lines before the first interesting line. */
- while (j < i)
- sline[j++].flag |= mark | no_pre_delete;
+ while (j < i) {
+ if (!(sline[j++].flag & mark))
+ sline[j++].flag |= no_pre_delete;
+ sline[j++].flag |= mark;
+ }
again:
/* we know up to i is to be included. where does the
I'll see if I can write up a testcase and then submit this as a proper
patch, but I wanted to at least send this over now lest someone wastes
time coming to the same conclusion as I did.
Gr.
Matthijs
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] make color.ui default to 'auto'
Matthieu Moy writes:
> Many tutorials tell the users to set color.ui=auto as a very first step.
> These tutorials would benefit from skiping this step and starting the
> real Git manipualtions earlier. Other beginners do not know about
> color.ui=auto, and may not discover it by themselves, hence live with
> black&white outputs while they may have prefered colors.
>
> A few people (e.g. color-blind) prefer having no colors, but they can
> easily set color.ui=never for this (and googling "disable colors in git"
> already tells them how to do so).
The above two paragraphs do not make a good justification [*1*].
The former can just as easily websearch for "enable colours in git"
as the latter would for "disable" in order to avoid having to live
with distraction while they may have preferred monochrome.
The train of thought that is a sufficient justification for this
change is "Our document and third-party tutorials often start with
setting color.ui=auto configuration." leading to "Our recommendation
is to enable colour on terminals." which in turn leading to "Why is
our default monochrome, against our own recommendation?". Saying
anything more, like who are the majority or how easily the default
can be overridden, is unnecessary, I think [*2*].
As this is purely a UI thing, and since daa0c3d97176 (color: delay
auto-color decision until point of use, 2011-08-17), the logic to
decide when "auto colouring" is triggered is centrary controlled
(hence it is much less likely than before that color.ui=auto could
misfire when it shouldn't), I agree that this does not even deserve
a warning. You could even sell it as a pure bugfix ("we recommend
users to use auto colouring but we did not set it up for users").
> The default value is changed, and the documentation is reworded to
> mention "color.ui=false" first, since the primary use of color.ui after
> this change is to disable colors, not to enable it.
Good.
> I'm starting to wonder why we didn't do this earlier ;-).
>
> Documentation/config.txt | 11 ++-
> color.c | 2 +-
> 2 files changed, 7 insertions(+), 6 deletions(-)
>
> diff --git a/Documentation/config.txt b/Documentation/config.txt
> index 1009bfc..97550be 100644
> --- a/Documentation/config.txt
> +++ b/Documentation/config.txt
> @@ -913,11 +913,12 @@ color.ui::
> as `color.diff` and `color.grep` that control the use of color
> per command family. Its scope will expand as more commands learn
> configuration to set a default for the `--color` option. Set it
> + to `false` or `never` if you prefer Git commands not to use
> + color unless enabled explicitly with some other configuration
> + or the `--color` option. Set it to `always` if you want all
> + output not intended for machine consumption to use color, to
> + `true` or `auto` (this is the default since Git 2.0) if you
> + want such output to use color when written to the terminal.
OK, so this is planned for 2.0?
[Footnote]
*1* Unless you have some statistical fact to demonstrate that
beginners who prefer colours are of lessor intelligence than
those who do not, that is.
*2* It unnecessarily muddies the water to bring up "which is
majority?". A poll might reveal more people prefer monochrome, but
in that case, either we keep the default monochrome *and* fix the
tutorial not to suggest auto, or we stick to the recommendation to
use auto colouring. In other words, I see this change as merely
making the code in line with the spirit of the documentation.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: English/German terminology, git.git's de.po, and pro-git
Am 15.05.2013 15:14, schrieb Jan Engelhardt: On Wednesday 2013-05-15 14:27, Jens Lehmann wrote: While it's spoken Packdatei, the way to actually write it is .pack-Datei or ".pack"-Datei. I actually had the '-' in there too until I tried to look up "Zip-Datei" in the Duden. While I don't get the leading '.' (I cannot remember having seen that anywhere, AFAIK the file extensions are always used without the dot), I'm not a grammar expert and will be fine either way. In UNIX-land, extension seemed to always include the dot. In DOS-land, it's without (inherited from VMS too, perhaps?) As such, either way to write it is acceptable. Even in unix-land no one adds a dot because usually the extension is named after the data format, only that the file extension is used as the common abbreviation (at least that is my interpretation). Compare with jpeg. You often write jpeg-Datei instead of jpg-Datei because the data format is called jpeg. This is why I don't think the dot has any reason to be there. I can't remember ever seeing anyone writing .jpg-Datei (or .doc-Datei, .rar-Datei) except to ask what a .xyz Datei contains (i.e. when he doesn't know what the data format is) -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[RFC 2/2] quote.c: remove path_relative, use relative_path instead
Since there is a enhanced version of relative_path() in path.c,
remove duplicate counterpart path_relative() in quote.c.
Also refactor related functions, remove unnecessary arguments:
len and/or prefix_len.
Signed-off-by: Jiang Xin
---
builtin/clean.c| 18 +++---
builtin/grep.c | 4 +--
builtin/ls-files.c | 13 +-
quote.c| 71 --
quote.h| 7 +++---
wt-status.c| 17 ++---
6 files changed, 33 insertions(+), 97 deletions(-)
diff --git a/builtin/clean.c b/builtin/clean.c
index 04e39..a93c3 100644
--- a/builtin/clean.c
+++ b/builtin/clean.c
@@ -56,7 +56,7 @@ static int remove_dirs(struct strbuf *path, const char
*prefix, int force_flag,
if ((force_flag & REMOVE_DIR_KEEP_NESTED_GIT) &&
!resolve_gitlink_ref(path->buf, "HEAD",
submodule_head)) {
if (!quiet) {
- quote_path_relative(path->buf, strlen(path->buf),
"ed, prefix);
+ quote_path_relative(path->buf, "ed, prefix);
printf(dry_run ? _(msg_would_skip_git_dir) :
_(msg_skip_git_dir),
quoted.buf);
}
@@ -70,7 +70,7 @@ static int remove_dirs(struct strbuf *path, const char
*prefix, int force_flag,
/* an empty dir could be removed even if it is unreadble */
res = dry_run ? 0 : rmdir(path->buf);
if (res) {
- quote_path_relative(path->buf, strlen(path->buf),
"ed, prefix);
+ quote_path_relative(path->buf, "ed, prefix);
warning(_(msg_warn_remove_failed), quoted.buf);
*dir_gone = 0;
}
@@ -94,7 +94,7 @@ static int remove_dirs(struct strbuf *path, const char
*prefix, int force_flag,
if (remove_dirs(path, prefix, force_flag, dry_run,
quiet, &gone))
ret = 1;
if (gone) {
- quote_path_relative(path->buf,
strlen(path->buf), "ed, prefix);
+ quote_path_relative(path->buf, "ed, prefix);
string_list_append(&dels, quoted.buf);
} else
*dir_gone = 0;
@@ -102,10 +102,10 @@ static int remove_dirs(struct strbuf *path, const char
*prefix, int force_flag,
} else {
res = dry_run ? 0 : unlink(path->buf);
if (!res) {
- quote_path_relative(path->buf,
strlen(path->buf), "ed, prefix);
+ quote_path_relative(path->buf, "ed, prefix);
string_list_append(&dels, quoted.buf);
} else {
- quote_path_relative(path->buf,
strlen(path->buf), "ed, prefix);
+ quote_path_relative(path->buf, "ed, prefix);
warning(_(msg_warn_remove_failed), quoted.buf);
*dir_gone = 0;
ret = 1;
@@ -127,7 +127,7 @@ static int remove_dirs(struct strbuf *path, const char
*prefix, int force_flag,
if (!res)
*dir_gone = 1;
else {
- quote_path_relative(path->buf, strlen(path->buf),
"ed, prefix);
+ quote_path_relative(path->buf, "ed, prefix);
warning(_(msg_warn_remove_failed), quoted.buf);
*dir_gone = 0;
ret = 1;
@@ -262,7 +262,7 @@ int cmd_clean(int argc, const char **argv, const char
*prefix)
if (remove_dirs(&directory, prefix, rm_flags,
dry_run, quiet, &gone))
errors++;
if (gone && !quiet) {
- qname =
quote_path_relative(directory.buf, directory.len, &buf, prefix);
+ qname =
quote_path_relative(directory.buf, &buf, prefix);
printf(dry_run ? _(msg_would_remove) :
_(msg_remove), qname);
}
}
@@ -272,11 +272,11 @@ int cmd_clean(int argc, const char **argv, const char
*prefix)
continue;
res = dry_run ? 0 : unlink(ent->name);
if (res) {
- qname = quote_path_relative(ent->name, -1,
&buf, prefix);
+ qname = quote_path_relative(ent->name, &buf,
prefix);
warning(_(msg_warn_remove_failed), qname);
errors++;
} else if (!quiet) {
- qname =
[RFC 1/2] path.c: refactor relative_path(), not only strip prefix
Original design of relative_path() is simple, just strip the prefix
(*base) from the abosolute path (*abs). In most cases, we need a real
relative path, such as: ../foo, ../../bar. That's why there is another
reimplementation (path_relative()) in quote.c.
Refactor relative_path() in path.c to return real relative path, so
that user can reuse this function without reimplement his/her own.
I will use this method for interactive git-clean later. Some of the
implementations are borrowed from path_relative() in quote.c.
Different results for relative_path() before and after this refactor:
base path abs path relative (orignal) relative (refactor)
= == ===
/a/b /a/b/c/ c/ c/
//a///b/ /a/b//c/ c/ c/
/a/b /a/b/ . ./
/a/b/ /a/a ../
/a/b/ / / ../../
/a/b/ /a/c /a/c../c
Signed-off-by: Jiang Xin
---
path.c | 94 --
1 file changed, 74 insertions(+), 20 deletions(-)
diff --git a/path.c b/path.c
index 04ff..4dafa8 100644
--- a/path.c
+++ b/path.c
@@ -444,38 +444,92 @@ int adjust_shared_perm(const char *path)
const char *relative_path(const char *abs, const char *base)
{
static char buf[PATH_MAX + 1];
- int i = 0, j = 0;
+ int abs_off, base_off, i, j;
+ int abs_len, base_len;
if (!base || !base[0])
return abs;
- while (base[i]) {
+
+ abs_len = strlen(abs);
+ base_len = strlen(base);
+
+ abs_off = 0;
+ base_off = 0;
+ i = 0;
+ j = 0;
+ while (i < base_len && j < abs_len && base[i] == abs[j]) {
if (is_dir_sep(base[i])) {
- if (!is_dir_sep(abs[j]))
- return abs;
while (is_dir_sep(base[i]))
i++;
while (is_dir_sep(abs[j]))
j++;
- continue;
- } else if (abs[j] != base[i]) {
+ base_off = i;
+ abs_off = j;
+ } else {
+ i++;
+ j++;
+ }
+ }
+ if (
+ /* base seems like prefix of abs */
+ i >= base_len &&
+ /*
+* but "/foo" is not a prefix of "/foobar"
+* (i.e. base not end with '/')
+*/
+ base_off < base_len) {
+ if (j >= abs_len) {
+ /* abs="/a/b", base="/a/b" */
+ abs_off = abs_len;
+ } else if (is_dir_sep(abs[j])) {
+ /* abs="/a/b/c", base="/a/b" */
+ while (is_dir_sep(abs[j]))
+ j++;
+ abs_off = j;
+ } else {
+ /* abs="/a/bbb/c", base="/a/b" */
+ i = base_off;
+ }
+ } else if (
+ /* abs is short than base (prefix of base) */
+ j >= abs_len &&
+ /* abs not end with '/' */
+ abs_off < abs_len) {
+ if (is_dir_sep(base[i])) {
+ /* abs="/a/b", base="/a/b/c/" */
+ while (is_dir_sep(base[i]))
+ i++;
+ abs_off = abs_len;
+ }
+ }
+ abs += abs_off;
+ abs_len -= abs_off;
+
+ /* base is prefix of abs */
+ if (i >= base_len) {
+ if (*abs == '\0') {
+ strcpy(buf, "./");
+ return buf;
+ } else {
return abs;
}
+ }
+
+ buf[0] = '\0';
+ while (i < base_len) {
+ if (is_dir_sep(base[i])) {
+ strcat(buf, "../");
+ while (is_dir_sep(base[i]))
+ i++;
+ continue;
+ }
i++;
- j++;
}
- if (
- /* "/foo" is a prefix of "/foo" */
- abs[j] &&
- /* "/foo" is not a prefix of "/foobar" */
- !is_dir_sep(base[i-1]) && !is_dir_sep(abs[j])
- )
- return abs;
- while (is_dir_sep(abs[j]))
- j++;
- if (!abs[j])
- strcpy(buf, ".");
- else
- strcpy(buf, abs + j);
+ if (!is_dir_sep(base[base_len - 1]))
+ strcat(buf, "../");
+
+ strcat(buf, abs);
+
return buf;
}
--
1.8.3.rc1.404.ga32c147
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.
[RFC 0/2] refactor relative_path in path.c
2013/5/15 Junio C Hamano :
> Jiang Xin writes:
>
>> +/*
>> + * Give path as relative to prefix.
>> + *
>> + * This function is a combination of path_relative (in quote.c) and
>> + * relative_path (in path.c)
>> + */
>> +static const char *path_relative(const char *in, const char *prefix)
>> +{
>> +...
>
> Hmph. Is it possible to reuse the public one (in path.c) here and
> in quote.c, perhaps after enhancing it a bit to serve needs of the
> callers of two existing ones and the new callers of this one?
>
These two patches enhance relative_path() in path.c, so that function
relative_path() will return real relative path, not a path strip off
the prefix.
The 2nd patch is a bit aggressive, it refactor all related functions,
remove unnecessary arguments: len and/or prefix_len.
Please review them. They will be prerequisites for the interactive
git-clean patch series.
Jiang Xin (2):
path.c: refactor relative_path(), not only strip prefix
quote.c: remove path_relative, use relative_path instead
builtin/clean.c| 18 +--
builtin/grep.c | 4 +--
builtin/ls-files.c | 13
path.c | 94 ++
quote.c| 71 +++--
quote.h| 7 ++--
wt-status.c| 17 +-
7 files changed, 107 insertions(+), 117 deletions(-)
--
1.8.3.rc1.404.ga32c147
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCHv2 03/10] refs.c: Refactor code for mapping between shorthand names and full refnames
Johan Herland writes: > On Wed, May 15, 2013 at 9:39 AM, Johan Herland wrote: >> On Wed, May 15, 2013 at 8:45 AM, Michael Haggerty >> wrote: >>> "refs/remotes/%1/%2" (or "refs/remotes/%1/%*") might be a nice way to >>> imply that the rule should only be attempted if the input has at least >>> two components, whereas something like "refs/heads/%*" would be applied >>> even for inputs with no slashes. >> >> /me likes, at least for "refs/remotes/%1/%*". > > Unfortunately, using "refs/remotes/%1/%*" instead of "refs/remotes/%*" > breaks a number of git-svn tests which puts refs directly within > refs/remotes/, and then does things like "git reset --hard trunk" > (expecting trunk -> refs/remotes/trunk, which the refs/remotes/%1/%* > doesn't match). Oh, I never thought refs/remotes/%1/%* was a suggestion for a serious "improvement", but was merely a thought experiment "if all the remotes were at least two level names, we could express it like this to stress that fact". We already allow 'origin' to refer to refs/remotes/origin/HEAD, so it is clear refs/remotes/%1/%* alone will not be able to replace what we have; we need refs/remotes/%* and refs/remotes/%*/HEAD anyway. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v9 1/9] git-clean: refactor git-clean into two phases
2013/5/15 Junio C Hamano :
> Jiang Xin writes:
>
>> 2013/5/15 Junio C Hamano :
@@ -242,11 +287,6 @@ int cmd_clean(int argc, const char **argv, const char
*prefix)
continue; /* Yup, this one exists unmerged */
}
- /*
- * we might have removed this as part of earlier
- * recursive directory removal, so lstat() here could
- * fail with ENOENT.
- */
if (lstat(ent->name, &st))
continue;
>>>
>>> I am guessing that the reason why you removed the comment is because
>>> during this phase there is no way we "might have removed". But if
>>> that is the case, does it still make sense to run lstat() and ignore
>>> errors from the call?
>>>
>>
>> Run lstat() here is necessary, because we need to check whether
>> ent->name points to a file or a directory. If ent points to a directory,
>> only add to del_list when user provides '-x' option to git-clean.
>
> Sorry, but that was not the question; we can see st is used
> immediately below so somebody needs to fill it.
>
> I was pointing out that the "lstat() is expected to fail with ENOENT
> but it is not an error worth reporting" justification the original
> code had to silently ignore an error, because you no longer remove
> anything immediately in this part of the code. Is "if () continue"
> still valid thing to do here, not "if () die()"?
I'm clear, it could be:
if (lstat(ent->name, &st))
die_errno("Cannot lstat '%s'", ent->name);
--
Jiang Xin
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v9 1/9] git-clean: refactor git-clean into two phases
Jiang Xin writes: > 2013/5/15 Junio C Hamano : >>> @@ -242,11 +287,6 @@ int cmd_clean(int argc, const char **argv, const char >>> *prefix) >>> continue; /* Yup, this one exists unmerged */ >>> } >>> >>> - /* >>> - * we might have removed this as part of earlier >>> - * recursive directory removal, so lstat() here could >>> - * fail with ENOENT. >>> - */ >>> if (lstat(ent->name, &st)) >>> continue; >> >> I am guessing that the reason why you removed the comment is because >> during this phase there is no way we "might have removed". But if >> that is the case, does it still make sense to run lstat() and ignore >> errors from the call? >> > > Run lstat() here is necessary, because we need to check whether > ent->name points to a file or a directory. If ent points to a directory, > only add to del_list when user provides '-x' option to git-clean. Sorry, but that was not the question; we can see st is used immediately below so somebody needs to fill it. I was pointing out that the "lstat() is expected to fail with ENOENT but it is not an error worth reporting" justification the original code had to silently ignore an error, because you no longer remove anything immediately in this part of the code. Is "if () continue" still valid thing to do here, not "if () die()"? -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Lines missing from git diff-tree -p -c output?
Hi folks, while trying to parse git diff-tree output, I found out that in some cases it appears to generate an incorrect diff (AFAICT). I orginally found this in a 5-way merge commit in the Linux kernel, but managed to reduce this to something a lot more managable (an ordinary 2-way merge on a 6-line file). To start with the wrong-ness, this is the diff generated: $ git diff-tree -p -c HEAD d945a51b6ca22e6e8e550c53980d026f11b05158 diff --combined file index 3404f54,0eab113..e8c8c18 --- a/file +++ b/file @@@ -1,7 -1,5 +1,6 @@@ +LEFT BASE2 BASE3 BASE4 - BASE5 + BASE5MODIFIED BASE6 Here, the header claims that the first head has 7 lines, but there really are only 6 (5 lines of context and one delete line). The numbers for the others heads are incorrect. In the original diff, the difference was bigger (first head was stated to have 28 lines, while the output was similar to the above). To find out what's going on, we can look at the -m output, which is correct (or look at the original file contents at the end of this mail). $ git diff-tree -m -p HEAD d945a51b6ca22e6e8e550c53980d026f11b05158 diff --git a/file b/file index 3404f54..e8c8c18 100644 --- a/file +++ b/file @@ -1,7 +1,6 @@ LEFT -BASE1 BASE2 BASE3 BASE4 -BASE5 +BASE5MODIFIED BASE6 d945a51b6ca22e6e8e550c53980d026f11b05158 diff --git a/file b/file index 0eab113..e8c8c18 100644 --- a/file +++ b/file @@ -1,3 +1,4 @@ +LEFT BASE2 BASE3 BASE4 As you can see here, first head added "LEFT", and the second head removed "BASE1" and modified "BASE5". In the -c diff-tree output above, this removal of "BASE1" is not shown, but it is counted in the number of lines, causing this breakage. Note that to trigger this behaviour, the number of context lines between the BASE1 and BASE5 must be _exactly_ 3, more or less prevents this bug from occuring. Also, the "LEFT" line introduced does not seem to be essential, but there needed to be some change from both sides in order to generate a diff at all. I haven't looked into the code, though I might give that a go later. Anyone got any clue why this is happening? Is this really a bug, or am I misunderstanding here? To recreate the above situation, you can use the following commands: git init cat > file < file < file < file
[PATCH v3] make color.ui default to 'auto'
Most users seem to like having colors enabled, and colors can help
beginners to understand the output of some commands (e.g. notice
immediately the boundary between commits in the output of "git log").
Many tutorials tell the users to set color.ui=auto as a very first step.
These tutorials would benefit from skipping this step and starting the
real Git manipulations earlier. Other beginners do not know about
color.ui=auto, and may not discover it by themselves, hence live with
black&white outputs while they may have preferred colors.
A few people (e.g. color-blind) prefer having no colors, but they can
easily set color.ui=never for this (and googling "disable colors in git"
already tells them how to do so).
A transition period with Git emitting a warning when color.ui is unset
would be possible, but the discomfort of having the warning seems
superior to the benefit: users may be surprised by the change, but not
harmed by it.
The default value is changed, and the documentation is reworded to
mention "color.ui=false" first, since the primary use of color.ui after
this change is to disable colors, not to enable it.
Signed-off-by: Matthieu Moy
---
v2 crossed Stefano's email with typos. v3 just fixes these typos in
the commit message.
Documentation/config.txt | 11 ++-
builtin/config.c | 2 +-
color.c | 2 +-
3 files changed, 8 insertions(+), 7 deletions(-)
diff --git a/Documentation/config.txt b/Documentation/config.txt
index 1009bfc..97550be 100644
--- a/Documentation/config.txt
+++ b/Documentation/config.txt
@@ -913,11 +913,12 @@ color.ui::
as `color.diff` and `color.grep` that control the use of color
per command family. Its scope will expand as more commands learn
configuration to set a default for the `--color` option. Set it
- to `always` if you want all output not intended for machine
- consumption to use color, to `true` or `auto` if you want such
- output to use color when written to the terminal, or to `false` or
- `never` if you prefer Git commands not to use color unless enabled
- explicitly with some other configuration or the `--color` option.
+ to `false` or `never` if you prefer Git commands not to use
+ color unless enabled explicitly with some other configuration
+ or the `--color` option. Set it to `always` if you want all
+ output not intended for machine consumption to use color, to
+ `true` or `auto` (this is the default since Git 2.0) if you
+ want such output to use color when written to the terminal.
column.ui::
Specify whether supported commands should output in columns.
diff --git a/builtin/config.c b/builtin/config.c
index 000d27c..ecfceca 100644
--- a/builtin/config.c
+++ b/builtin/config.c
@@ -316,7 +316,7 @@ static void get_color(const char *def_color)
static int get_colorbool_found;
static int get_diff_color_found;
-static int get_color_ui_found;
+static int get_color_ui_found = GIT_COLOR_AUTO;
static int git_get_colorbool_config(const char *var, const char *value,
void *cb)
{
diff --git a/color.c b/color.c
index e8e2681..f672885 100644
--- a/color.c
+++ b/color.c
@@ -1,7 +1,7 @@
#include "cache.h"
#include "color.h"
-static int git_use_color_default = 0;
+static int git_use_color_default = GIT_COLOR_AUTO;
int color_stdout_is_tty = -1;
/*
--
1.8.3.rc1.314.g2261e40.dirty
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCHv2 03/10] refs.c: Refactor code for mapping between shorthand names and full refnames
On Wed, May 15, 2013 at 9:39 AM, Johan Herland wrote: > On Wed, May 15, 2013 at 8:45 AM, Michael Haggerty > wrote: >> "refs/remotes/%1/%2" (or "refs/remotes/%1/%*") might be a nice way to >> imply that the rule should only be attempted if the input has at least >> two components, whereas something like "refs/heads/%*" would be applied >> even for inputs with no slashes. > > /me likes, at least for "refs/remotes/%1/%*". Unfortunately, using "refs/remotes/%1/%*" instead of "refs/remotes/%*" breaks a number of git-svn tests which puts refs directly within refs/remotes/, and then does things like "git reset --hard trunk" (expecting trunk -> refs/remotes/trunk, which the refs/remotes/%1/%* doesn't match). I don't know if putting refs directly within refs/remotes/ is something that git-svn does by default (which would prevent us from changing "refs/remotes/%*" to "refs/remotes/%1/%*"), or whether it is specific to the tests (in which case we should fix the tests). Also, there might be too many other users of refs directly within refs/remotes/ that expect "foo_without_slash" to expand to "refs/remotes/foo_without_slash", which would prevent us from doing this change. ...Johan -- Johan Herland, www.herland.net -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Trouble with case insensitive filesystem
Am 5/15/2013 10:40, schrieb Luc Bourhis: > I work on a case insensitive filesystem and I have core.ignorecase set to > true. > ... > So I thought it was a job for git filter-branch, ... > > However because of those two blobs, I have: > > ~> git status > # modified: .../fourCircles.py > > and git filter-branch therefore refuses to run. Make a commit that has neither file, run git filter-branch, then throw away the commit with git reset --hard HEAD~. -- Hannes -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2] make color.ui default to 'auto'
Most users seem to like having colors enabled, and colors can help
beginners to understand the output of some commands (e.g. notice
immediately the boundary between commits in the output of "git log").
Many tutorials tell the users to set color.ui=auto as a very first step.
These tutorials would benefit from skiping this step and starting the
real Git manipualtions earlier. Other beginners do not know about
color.ui=auto, and may not discover it by themselves, hence live with
black&white outputs while they may have prefered colors.
A few people (e.g. color-blind) prefer having no colors, but they can
easily set color.ui=never for this (and googling "disable colors in git"
already tells them how to do so).
A transition period with Git emitting a warning when color.ui is unset
would be possible, but the discomfort of having the warning seems
superior to the benefit: users may be surprised by the change, but not
harmed by it.
The default value is changed, and the documentation is reworded to
mention "color.ui=false" first, since the primary use of color.ui after
this change is to disable colors, not to enable it.
Signed-off-by: Matthieu Moy
---
> Reviewed and supported-by: Johan Herland
Apparently not well enough ;-).
In v1, "git config --get-colorbool" was not affected, hence "git add
-p" wasn't colored. v2 fixes this.
Documentation/config.txt | 11 ++-
builtin/config.c | 2 +-
color.c | 2 +-
3 files changed, 8 insertions(+), 7 deletions(-)
diff --git a/Documentation/config.txt b/Documentation/config.txt
index 1009bfc..97550be 100644
--- a/Documentation/config.txt
+++ b/Documentation/config.txt
@@ -913,11 +913,12 @@ color.ui::
as `color.diff` and `color.grep` that control the use of color
per command family. Its scope will expand as more commands learn
configuration to set a default for the `--color` option. Set it
- to `always` if you want all output not intended for machine
- consumption to use color, to `true` or `auto` if you want such
- output to use color when written to the terminal, or to `false` or
- `never` if you prefer Git commands not to use color unless enabled
- explicitly with some other configuration or the `--color` option.
+ to `false` or `never` if you prefer Git commands not to use
+ color unless enabled explicitly with some other configuration
+ or the `--color` option. Set it to `always` if you want all
+ output not intended for machine consumption to use color, to
+ `true` or `auto` (this is the default since Git 2.0) if you
+ want such output to use color when written to the terminal.
column.ui::
Specify whether supported commands should output in columns.
diff --git a/builtin/config.c b/builtin/config.c
index 000d27c..ecfceca 100644
--- a/builtin/config.c
+++ b/builtin/config.c
@@ -316,7 +316,7 @@ static void get_color(const char *def_color)
static int get_colorbool_found;
static int get_diff_color_found;
-static int get_color_ui_found;
+static int get_color_ui_found = GIT_COLOR_AUTO;
static int git_get_colorbool_config(const char *var, const char *value,
void *cb)
{
diff --git a/color.c b/color.c
index e8e2681..f672885 100644
--- a/color.c
+++ b/color.c
@@ -1,7 +1,7 @@
#include "cache.h"
#include "color.h"
-static int git_use_color_default = 0;
+static int git_use_color_default = GIT_COLOR_AUTO;
int color_stdout_is_tty = -1;
/*
--
1.8.3.rc1.314.g2261e40.dirty
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] make color.ui default to 'auto'
On 05/15/2013 02:09 PM, Matthieu Moy wrote: > Most users seem to like having colors enabled, and colors can help > beginners to understand the output of some commands (e.g. notice > immediately the boundary between commits in the output of "git log"). > > Many tutorials tell the users to set color.ui=auto as a very first step. > These tutorials would benefit from skiping > s/skiping/skipping/ > this step and starting the > real Git manipualtions earlier. > s/manipualtions/manipulations/ > Other beginners do not know about > color.ui=auto, and may not discover it by themselves, hence live with > black&white outputs while they may have prefered colors. > s/prefered/preferred/ > A few people (e.g. color-blind) prefer having no colors, but they can > easily set color.ui=never for this (and googling "disable colors in git" > already tells them how to do so). > > A transition period with Git emitting a warning when color.ui is unset > would be possible, but the discomfort of having the warning seems > superior to the benefit: users may be surprised by the change, but not > harmed by it. > > The default value is changed, and the documentation is reworded to > mention "color.ui=false" first, since the primary use of color.ui after > this change is to disable colors, not to enable it. > > Signed-off-by: Matthieu Moy > --- >>> I'd love to see this by default, yes. Maybe a 2.0 change? >>> >>> If people agree that this is a good change, would we need a transition >>> plan? I'd say no, as there is no real backward incompatibility involved. >>> People who dislike colors can already set color.ui=false, and seeing >>> colors can hardly harm them, just temporarily reduce the comfort for >>> them. >> >> I vote for this. It's the first thing I do in any setup, even the ones >> that are note mine. I've also seen it in basically all the tutorials, >> even before setting user.name/email. >> >> I also don't see the point of a transition plan. > > OK, then let's try turning the discussion into code. > > I'm starting to wonder why we didn't do this earlier ;-). > > Documentation/config.txt | 11 ++- > color.c | 2 +- > 2 files changed, 7 insertions(+), 6 deletions(-) > > diff --git a/Documentation/config.txt b/Documentation/config.txt > index 1009bfc..97550be 100644 > --- a/Documentation/config.txt > +++ b/Documentation/config.txt > @@ -913,11 +913,12 @@ color.ui:: > as `color.diff` and `color.grep` that control the use of color > per command family. Its scope will expand as more commands learn > configuration to set a default for the `--color` option. Set it > - to `always` if you want all output not intended for machine > - consumption to use color, to `true` or `auto` if you want such > - output to use color when written to the terminal, or to `false` or > - `never` if you prefer Git commands not to use color unless enabled > - explicitly with some other configuration or the `--color` option. > + to `false` or `never` if you prefer Git commands not to use > + color unless enabled explicitly with some other configuration > + or the `--color` option. Set it to `always` if you want all > + output not intended for machine consumption to use color, to > + `true` or `auto` (this is the default since Git 2.0) if you > + want such output to use color when written to the terminal. > > column.ui:: > Specify whether supported commands should output in columns. > diff --git a/color.c b/color.c > index e8e2681..f672885 100644 > --- a/color.c > +++ b/color.c > @@ -1,7 +1,7 @@ > #include "cache.h" > #include "color.h" > > -static int git_use_color_default = 0; > +static int git_use_color_default = GIT_COLOR_AUTO; > int color_stdout_is_tty = -1; > > /* > With the typos above fixed: Reviewed and supported-by: Stefano Lattarini Thanks, Stefano -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: English/German terminology, git.git's de.po, and pro-git
On Wednesday 2013-05-15 14:27, Jens Lehmann wrote: >> >> While it's spoken Packdatei, the way to actually write it is >> .pack-Datei or ".pack"-Datei. > >I actually had the '-' in there too until I tried to look up "Zip-Datei" >in the Duden. While I don't get the leading '.' (I cannot remember having >seen that anywhere, AFAIK the file extensions are always used without the >dot), I'm not a grammar expert and will be fine either way. In UNIX-land, extension seemed to always include the dot. In DOS-land, it's without (inherited from VMS too, perhaps?) As such, either way to write it is acceptable. >>> extension ".zip" is a "Zipdatei" (known by the Duden) >> >> If that's how Duden specifies it, it's time to call wrong upon Duden. > >Go ahead: http://www.duden.de/rechtschreibung/Zipdatei ;-) (There seems to be no way to send corrections. Sucks not to be a wiki.) Ah well that explains their cluelessness: nach englisch zip file, zu: to zip = (mit dem Reißverschluss) schließen und file = Datei "ZIP-Datei" kommt daher, weil die Erweiterung ZIP/.zip ist, nicht weil da ein symbolischer Reißverschluss zugezogen wird oder ein Programmicon selbiges suggerieren will. Wir haben ja schließlich auch RAR-Dateien, die deswegen so heißen, weil sie eben .rar als Endung tragen und nicht, weil sie wertvolle Mangelware sind. ;-) >> Not so strange. We have other words with -tet. >> bitten -> erbittete -> habe erbittet. > >That example was not the best, what about "wenn Du das mergest(?)" (if Konjugation wie merken, nur Aussprache mit [dʒ] statt [k]-Laut. merge/mergst/mergt/mergen/mergt/mergen/mergte/(habe,hatte) (ge)mergt. Ich sehe da keine Komplikationen. >you merge that), I cannot really say how to write that correctly (as in >German we would want to drop the last 'e', right?) -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] make color.ui default to 'auto'
On Wed, May 15, 2013 at 2:09 PM, Matthieu Moy wrote: > Signed-off-by: Matthieu Moy Reviewed and supported-by: Johan Herland ...Johan -- Johan Herland, www.herland.net -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC/PATCH] branch: show me the hot branches
On Tue, May 14, 2013 at 7:34 PM, Junio C Hamano wrote: > Phil Hord writes: > >> I imagine it with --date-order and whatnot. > > Perhaps modeled after this one. > > git for-each-ref \ > --format='%(refname:short) %(subject)' > --sort='-committerdate' refs/heads/ > Nice. I had no idea about for-each-ref. I knew it was out there, but not what it could do. Another tool in the swiss army knife that is git. I think Duy was right about his patch's merits. Phil -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: English/German terminology, git.git's de.po, and pro-git
Am 15.05.2013 13:56, schrieb Jan Engelhardt: > On Wednesday 2013-05-15 13:26, Jens Lehmann wrote: >> but I believe "Packdatei" would be a much better translation (especially as >> the translation of "pack(verb)" is "packen"). I find it natural that a file >> with the extension ".pack" is named Packdatei > > While it's spoken Packdatei, the way to actually write it is > .pack-Datei or ".pack"-Datei. I actually had the '-' in there too until I tried to look up "Zip-Datei" in the Duden. While I don't get the leading '.' (I cannot remember having seen that anywhere, AFAIK the file extensions are always used without the dot), I'm not a grammar expert and will be fine either way. >> extension ".zip" is a "Zipdatei" (known by the Duden) > > If that's how Duden specifies it, it's time to call wrong upon Duden. Go ahead: http://www.duden.de/rechtschreibung/Zipdatei ;-) >> Yup, im my experience "committen" (to commit), "einchecken" (to check in), >> "auschecken" (to check out) und "taggen" (to tag) made it into our daily >> German language use. To avoid e.g. having past tenses look strange (like >> "committet") > > Not so strange. We have other words with -tet. > bitten -> erbittete -> habe erbittet. That example was not the best, what about "wenn Du das mergest(?)" (if you merge that), I cannot really say how to write that correctly (as in German we would want to drop the last 'e', right?). All that goes away when we use "Merge" as a noun: "wenn Du den Merge machst". But again, somebody else might come up with a grammatically correct solution for that I'm missing. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] make color.ui default to 'auto'
Most users seem to like having colors enabled, and colors can help beginners to understand the output of some commands (e.g. notice immediately the boundary between commits in the output of "git log"). Many tutorials tell the users to set color.ui=auto as a very first step. These tutorials would benefit from skiping this step and starting the real Git manipualtions earlier. Other beginners do not know about color.ui=auto, and may not discover it by themselves, hence live with black&white outputs while they may have prefered colors. A few people (e.g. color-blind) prefer having no colors, but they can easily set color.ui=never for this (and googling "disable colors in git" already tells them how to do so). A transition period with Git emitting a warning when color.ui is unset would be possible, but the discomfort of having the warning seems superior to the benefit: users may be surprised by the change, but not harmed by it. The default value is changed, and the documentation is reworded to mention "color.ui=false" first, since the primary use of color.ui after this change is to disable colors, not to enable it. Signed-off-by: Matthieu Moy --- > > I'd love to see this by default, yes. Maybe a 2.0 change? > > > > If people agree that this is a good change, would we need a transition > > plan? I'd say no, as there is no real backward incompatibility involved. > > People who dislike colors can already set color.ui=false, and seeing > > colors can hardly harm them, just temporarily reduce the comfort for > > them. > > I vote for this. It's the first thing I do in any setup, even the ones > that are note mine. I've also seen it in basically all the tutorials, > even before setting user.name/email. > > I also don't see the point of a transition plan. OK, then let's try turning the discussion into code. I'm starting to wonder why we didn't do this earlier ;-). Documentation/config.txt | 11 ++- color.c | 2 +- 2 files changed, 7 insertions(+), 6 deletions(-) diff --git a/Documentation/config.txt b/Documentation/config.txt index 1009bfc..97550be 100644 --- a/Documentation/config.txt +++ b/Documentation/config.txt @@ -913,11 +913,12 @@ color.ui:: as `color.diff` and `color.grep` that control the use of color per command family. Its scope will expand as more commands learn configuration to set a default for the `--color` option. Set it - to `always` if you want all output not intended for machine - consumption to use color, to `true` or `auto` if you want such - output to use color when written to the terminal, or to `false` or - `never` if you prefer Git commands not to use color unless enabled - explicitly with some other configuration or the `--color` option. + to `false` or `never` if you prefer Git commands not to use + color unless enabled explicitly with some other configuration + or the `--color` option. Set it to `always` if you want all + output not intended for machine consumption to use color, to + `true` or `auto` (this is the default since Git 2.0) if you + want such output to use color when written to the terminal. column.ui:: Specify whether supported commands should output in columns. diff --git a/color.c b/color.c index e8e2681..f672885 100644 --- a/color.c +++ b/color.c @@ -1,7 +1,7 @@ #include "cache.h" #include "color.h" -static int git_use_color_default = 0; +static int git_use_color_default = GIT_COLOR_AUTO; int color_stdout_is_tty = -1; /* -- 1.8.3.rc1.313.geb32591.dirty -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: English/German terminology, git.git's de.po, and pro-git
On Wednesday 2013-05-15 13:26, Jens Lehmann wrote:
>
>Hmm, I rather tend towards using "Repository" instead of "Archiv" too, as
>"Archiv" can mean anything from a tar-file to a git repository
It's exactly the reasoning I made in my git-glossary.txt sample
(of which the reasoning apparently has not made it into ralfth's
latest wiki, but that's the most essential part of a glossary IMHO).
>but I believe "Packdatei" would be a much better translation (especially as
>the translation of "pack(verb)" is "packen"). I find it natural that a file
>with the extension ".pack" is named Packdatei
While it's spoken Packdatei, the way to actually write it is
.pack-Datei or ".pack"-Datei.
>extension ".zip" is a "Zipdatei" (known by the Duden)
If that's how Duden specifies it, it's time to call wrong upon Duden.
It's ZIP-Datei, of course, and follows the same origin (".zip"-Datei).
The history of "ZIP-Datei" can be explained by way of MSDOS showing
the filename in the DIR command without the dot - which is also
why we do not pronounce the dot in ".zip"- or ".pack"-Datei.
>Yup, im my experience "committen" (to commit), "einchecken" (to check in),
>"auschecken" (to check out) und "taggen" (to tag) made it into our daily
>German language use. To avoid e.g. having past tenses look strange (like
>"committet")
Not so strange. We have other words with -tet.
bitten -> erbittete -> habe erbittet.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: English/German terminology, git.git's de.po, and pro-git
Am 15.05.2013 12:23, schrieb Holger Hellmuth (IKS):
> Am 14.05.2013 19:51, schrieb Ralf Thielow:
>> - repository = Projektarchiv
>> - bare repository = bloßes Projektarchiv
>> + repository = Projektarchiv, (or just Repository?)
>> + bare repository = bloßes Projektarchiv (-||-), (reines, pures Repository)
>
> I would vote for Repository or if it needs to be translated, simply Archiv.
> Neither Projektarchiv nor Archiv is commonly used by me but Archiv is shorter
> and not everything in a repository is a project.
Hmm, I rather tend towards using "Repository" instead of "Archiv" too, as
"Archiv" can mean anything from a tar-file to a git repository, while we are
talking about something very specific here (and a German might be surprised
what the command "git archive" is about if we use "Archiv" here ;-). So if
it has to be translated, I like "Projektarchiv" better than "Archiv" for
those reasons. We can also think about using "Repo" as an abbreviated form,
we often use that when talking about repositories in German. That would be a
new term without ambiguity and will be pronounced pretty much correctly by
all Germans too. But this remains one of the tougher questions.
And then "pack" is currently translated as "Archiv":
pack(noun) = Archiv
but I believe "Packdatei" would be a much better translation (especially as
the translation of "pack(verb)" is "packen"). I find it natural that a file
with the extension ".pack" is named Packdatei, just like a file with the
extension ".zip" is a "Zipdatei" (known by the Duden) in German. And the
Duden already knows "Pack" as an assembly of smaller parts, so we should be
safe here.
>> I'm not sure about using "Repository". I think "Projektarchiv" is
>> actually good enough.
>>
>> - committer = Eintragender
>> - tagger = Markierer
>> + committer = Eintragender (or Committer, Commit-Ersteller)
>> + tagger = Markierer (or Tagger, Tag-Ersteller)
>> ...[each usage of commit and tag]...
>
> Both "commit" and "tag" are used in commands so with the exception of the
> place where they are defined the english words should be used. I think
> Commit-/Tag-Ersteller actually sounds fine and german enough so no one
> notices there is an english word in there ;-)
Yup, im my experience "committen" (to commit), "einchecken" (to check in),
"auschecken" (to check out) und "taggen" (to tag) made it into our daily
German language use. To avoid e.g. having past tenses look strange (like
"committet") the combined Form ("Commit erstellt") could solve that problem.
>> + branch = Zweig (or Branch)
>>
>> I think "Zweig" is already fine.
>
> Same reason, branch is used as a command and should not be translated. But
> "Zweig" is a really natural and together with "Baum" fitting translation, so
> I'm conflicted here.
Yes, Baum, Wurzel and Zweig are obviously equivalent to tree, root and branch,
so I don't care much if we translate that or not.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: is this a bug of git-diff?
On Wed, May 15, 2013 at 10:50:25AM +0100, John Keeping wrote: > On Wed, May 15, 2013 at 11:34:41AM +0200, Matthieu Moy wrote: > > Antoine's answer is correct. In addition, I'd say that you may want to > > enable color in the output to make it clearer (the @@ ... @@ part would > > be colored, but not the function name): > > > > git config --global color.ui auto > > I wonder if that should be the default. I've advised a lot of people to > turn it on and it seems to me that a user is much more likely to go > looking for a "turn color off" option than realise that color is an > option at all. +1. My settings have been there for so long that I thought it was the default. Mike -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: English/German terminology, git.git's de.po, and pro-git
Am 14.05.2013 19:51, schrieb Ralf Thielow: - repository = Projektarchiv - bare repository = bloßes Projektarchiv + repository = Projektarchiv, (or just Repository?) + bare repository = bloßes Projektarchiv (-||-), (reines, pures Repository) I would vote for Repository or if it needs to be translated, simply Archiv. Neither Projektarchiv nor Archiv is commonly used by me but Archiv is shorter and not everything in a repository is a project. I'm not sure about using "Repository". I think "Projektarchiv" is actually good enough. - committer = Eintragender - tagger = Markierer + committer = Eintragender (or Committer, Commit-Ersteller) + tagger = Markierer (or Tagger, Tag-Ersteller) ...[each usage of commit and tag]... Both "commit" and "tag" are used in commands so with the exception of the place where they are defined the english words should be used. I think Commit-/Tag-Ersteller actually sounds fine and german enough so no one notices there is an english word in there ;-) + branch = Zweig (or Branch) I think "Zweig" is already fine. Same reason, branch is used as a command and should not be translated. But "Zweig" is a really natural and together with "Baum" fitting translation, so I'm conflicted here. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Default for color.ui (was Re: is this a bug of git-diff?)
On Wed, May 15, 2013 at 5:03 AM, Matthieu Moy wrote: > John Keeping writes: > >> I wonder if that should be the default. I've advised a lot of people to >> turn it on and it seems to me that a user is much more likely to go >> looking for a "turn color off" option than realise that color is an >> option at all. > > I'd love to see this by default, yes. Maybe a 2.0 change? > > If people agree that this is a good change, would we need a transition > plan? I'd say no, as there is no real backward incompatibility involved. > People who dislike colors can already set color.ui=false, and seeing > colors can hardly harm them, just temporarily reduce the comfort for > them. I vote for this. It's the first thing I do in any setup, even the ones that are note mine. I've also seen it in basically all the tutorials, even before setting user.name/email. I also don't see the point of a transition plan. -- Felipe Contreras -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Default for color.ui (was Re: is this a bug of git-diff?)
John Keeping writes: > I wonder if that should be the default. I've advised a lot of people to > turn it on and it seems to me that a user is much more likely to go > looking for a "turn color off" option than realise that color is an > option at all. I'd love to see this by default, yes. Maybe a 2.0 change? If people agree that this is a good change, would we need a transition plan? I'd say no, as there is no real backward incompatibility involved. People who dislike colors can already set color.ui=false, and seeing colors can hardly harm them, just temporarily reduce the comfort for them. -- Matthieu Moy http://www-verimag.imag.fr/~moy/ -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: is this a bug of git-diff?
On Wed, May 15, 2013 at 11:34:41AM +0200, Matthieu Moy wrote: > Antoine's answer is correct. In addition, I'd say that you may want to > enable color in the output to make it clearer (the @@ ... @@ part would > be colored, but not the function name): > > git config --global color.ui auto I wonder if that should be the default. I've advised a lot of people to turn it on and it seems to me that a user is much more likely to go looking for a "turn color off" option than realise that color is an option at all. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Trouble with case insensitive filesystem
Hi, I work on a case insensitive filesystem and I have core.ignorecase set to true. I have a series of troublesome commits and here is what git cat-file -p shows me: ... 100644 blob 99... fourCircles.py 100644 blob 97... fourcircles.py ... The content of those slightly differ: --- a/99... +++ b/97... -__version__='$Header: .../fourCircles.py, ...$' +__version__='$Header: .../fourcircle.py, ...$' As you can guess this git repo started its life with CVS (it was converted with git cvsimport). So I thought it was a job for git filter-branch, specifically I propose to do: git filter-branch --index-filter 'git rm --cached --ignore-unmatch .../fourCircles.py' However because of those two blobs, I have: ~> git status # modified: .../fourCircles.py and git filter-branch therefore refuses to run. I tried to use checkout, reset, even to commit that fluke of a change but whatever I do, that file is still marked as modified. I am sure I am missing a tiny detail that would get me out of those dire straights but it has eluded me so far. I run git 1.8.2.2 on MacOS 10.7.5 (installed with MacPorts if that matters). Best wishes, Luc J. Bourhis -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: is this a bug of git-diff?
Antoine Pelisse writes: > On Wed, May 15, 2013 at 8:52 AM, eric liou wrote: >> Thank you for the quick reply. >> But this line is not correct: "@@ -4,5 +4,6 @@ int a = 1;" Antoine's answer is correct. In addition, I'd say that you may want to enable color in the output to make it clearer (the @@ ... @@ part would be colored, but not the function name): git config --global color.ui auto -- Matthieu Moy http://www-verimag.imag.fr/~moy/ -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCHv2 03/10] refs.c: Refactor code for mapping between shorthand names and full refnames
On Wed, May 15, 2013 at 8:45 AM, Michael Haggerty wrote: > On 05/14/2013 04:24 PM, Johan Herland wrote: >> I am not sure why we would want "refs/remotes/%1/%2" instead of >> "refs/remote/%*". Maybe I've been staring at this for too long, but I >> find the latter shorter and more descriptive and the "%1/%2" notation >> needlessly cumbersome, especially if it's also supposed to match >> "foo/bar/baz" > > "refs/remotes/%1/%2" (or "refs/remotes/%1/%*") might be a nice way to > imply that the rule should only be attempted if the input has at least > two components, whereas something like "refs/heads/%*" would be applied > even for inputs with no slashes. /me likes, at least for "refs/remotes/%1/%*". ...Johan -- Johan Herland, www.herland.net -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: is this a bug of git-diff?
On Wed, May 15, 2013 at 8:52 AM, eric liou wrote:
> Thank you for the quick reply.
> But this line is not correct: "@@ -4,5 +4,6 @@ int a = 1;"
Oh OK, I see.
Git tries to name the function where the changes take place. This is
purely informative.
In your example, you don't have any function so of course the
information is not very helpful.
Typically it will look like the following, helping the reader by
giving the function name:
@@ -591,6 +609,14 @@ int cmd_grep(int argc, const char **argv, const
char *prefix)
paths[1] = NULL;
}
+ if (!use_index) {
+ if (cached)
+ die("--cached cannot be used with --no-index.");
+ if (list.nr)
+ die("--no-index cannot be used with revs.");
+ return !grep_directory(&opt, paths);
+ }
+
if (!list.nr) {
if (!cached)
setup_work_tree();
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v5 2/2] imap-send: eliminate HMAC deprecation warnings on Mac OS X
Mac OS X 10.8 Mountain Lion warns that HMAC_Init() and friends are deprecated. Detect the COMMON_CRYPTO_FOR_OPENSSL definition and use CommonCrypto's HMAC functions to eliminate the warnings. Signed-off-by: David Aguilar --- Changes since last time: This version re-uses the existing COMMON_CRYPTO_FOR_OPENSSL define instead of tweaking the Makefile to add a new one, so it's simpler. My previous patch had Jonathan's reviewed-by tag, but he hasn't reviewed this exact patch, so I removed it. The C macros are unchanged. imap-send.c | 10 ++ 1 file changed, 10 insertions(+) diff --git a/imap-send.c b/imap-send.c index d9bcfb4..96012b1 100644 --- a/imap-send.c +++ b/imap-send.c @@ -29,8 +29,18 @@ #ifdef NO_OPENSSL typedef void *SSL; #else +#ifdef COMMON_DIGEST_FOR_OPENSSL +#include +#define HMAC_CTX CCHmacContext +#define HMAC_Init(hmac, key, len, algo) CCHmacInit(hmac, algo, key, len) +#define HMAC_Update CCHmacUpdate +#define HMAC_Final(hmac, hash, ptr) CCHmacFinal(hmac, hash) +#define HMAC_CTX_cleanup +#define EVP_md5() kCCHmacAlgMD5 +#else #include #include +#endif #include #endif -- 1.8.3.rc2.2.gbc955d1 -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v5 1/2] cache.h: eliminate SHA-1 deprecation warnings on Mac OS X
Mac OS X 10.8 Mountain Lion prints warnings when building git: warning: 'SHA1_Init' is deprecated (declared at /usr/include/openssl/sha.h:121) Silence the warnings by using the CommonCrytpo SHA-1 functions for SHA1_Init(), SHA1_Update(), and SHA1_Final(). COMMON_DIGEST_FOR_OPENSSL is defined to enable the OpenSSL compatibility macros in CommonDigest.h. Add a NO_APPLE_COMMON_CRYPTO option to the Makefile to allow users to opt out of using this library. When defined, Git will use OpenSSL instead. Helped-by: Eric Sunshine Signed-off-by: David Aguilar --- Both of these are replacement patches "pu". Changes from last time: It now uses a single APPLE_COMMON_CRYPTO definition. Users can now opt-out by setting NO_APPLE_COMMON_CRYPTO. Makefile | 13 + 1 file changed, 13 insertions(+) diff --git a/Makefile b/Makefile index f698c1a..8309c41 100644 --- a/Makefile +++ b/Makefile @@ -137,6 +137,10 @@ all:: # specify your own (or DarwinPort's) include directories and # library directories by defining CFLAGS and LDFLAGS appropriately. # +# Define NO_APPLE_COMMON_CRYPTO if you are building on Darwin/Mac OS X +# and do not want to use Apple's CommonCrypto library. This allows you +# to provide your own OpenSSL library, for example from MacPorts. +# # Define BLK_SHA1 environment variable to make use of the bundled # optimized C SHA1 routine. # @@ -1054,6 +1058,9 @@ ifeq ($(uname_S),Darwin) BASIC_LDFLAGS += -L/opt/local/lib endif endif + ifndef NO_APPLE_COMMON_CRYPTO + APPLE_COMMON_CRYPTO = YesPlease + endif NO_REGEX = YesPlease PTHREAD_LIBS = endif @@ -1389,10 +1396,16 @@ ifdef PPC_SHA1 LIB_OBJS += ppc/sha1.o ppc/sha1ppc.o LIB_H += ppc/sha1.h else +ifdef APPLE_COMMON_CRYPTO + BASIC_CFLAGS += -DCOMMON_DIGEST_FOR_OPENSSL + SHA1_HEADER = +else SHA1_HEADER = EXTLIBS += $(LIB_4_CRYPTO) endif endif +endif + ifdef NO_PERL_MAKEMAKER export NO_PERL_MAKEMAKER endif -- 1.8.3.rc2.2.gbc955d1 -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
