* Re: A Visual Git Reference
From: Daniel Barkalow @ 2010-02-08 21:57 UTC (permalink / raw)
To: Mark Lodato; +Cc: git list
In-Reply-To: <ca433831002081134m698f531bwa22f0474db0cdcb@mail.gmail.com>
On Mon, 8 Feb 2010, Mark Lodato wrote:
> All,
>
> I put together a "Visual Git Reference" containing visualizations of
> the most common git commands, for people who prefer to see images over
> text. It is designed as a reference, not a tutorial, so readers need
> to have some amount of experience before the page will become useful.
>
> URL: http://marklodato.github.com/visual-git-guide/
> Git repo: http://github.com/marklodato/visual-git-guide/
>
> If you have any feedback or suggestions, please let me know!
The "3-way merge" node should graphically distinguish the base from the
two sides, rather than having all three just go in. The "3-way merge"
operation is tricky to understand visually without some sort of "split and
rejoin, with specific points" thing.
Also, it would probably be worth showing the use of the index in the
process of a 3-way merge: all three versions go into the blue box, and a
combination (with conflict markers) goes into the pink box; the user
cleans up the pink box, and replaces the 3-part blue box content with the
cleaned-up single result content; then the commit gives the diagram you
have for "git merge other".
I think you should introduce the detached HEAD situation early; right
after "git checkout HEAD~ files", it would be worth showing "git checkout
HEAD~". It's pretty common for people in the "technical user" part of the
kernel community to use git to browse history and test different commits,
and never do a commit at all. This is a pretty common mode across many
version control systems (e.g., "cvs checkout -D yesterday"), and nothing
unexpected happens if you don't try to commit while doing it. In fact, you
could show tracking down a bug introduced between maint and master by
checking out c10b9 and then da985.
Then, later, you can bring up the fact that you can actually do commits in
that situation, and show how that works. That part is the part that's
novel and could potentially lead to people doing work and having it become
unreachable. Also, after commiting with a detached HEAD, the normal next
step is to create a new branch ("git checkout -b new-topic").
-Daniel
*This .sig left intentionally blank*
^ permalink raw reply
* Re: [PATCH v3 3/3] git-push: make git push --dry-run --porcelain exit with status 0 even if updates will be rejected
From: Larry D'Anna @ 2010-02-08 21:49 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vpr4figv3.fsf@alter.siamese.dyndns.org>
* Junio C Hamano (gitster@pobox.com) [100208 15:59]:
> Larry D'Anna <larry@elder-gods.org> writes:
>
> > The script calling git push --dry-run --porcelain can see clearly from the
> > output that the updates will be rejected. However, it will probably need to
> > distinguish this condition from the push failing for other reasons, such as the
> > remote not being reachable.
>
> I am not sure about this reasoning. If you are telling the script writers
> to decide what happened by reading from the output, shouldn't the program
> say "I fail because I cannot reach the other side" to its standard output
> so that the script can read it as well?
Wouldn't that just complicate life for the script writer? If you send such
messages to the standard output, the script would have to include logic to
distinguish error messages from the rest of the output. If you send them to the
standard error then the script knows exactly where to find them.
> Having said that, I don't think it matters either way. If a script wants
> to know if push would fully succeed or not, it will run without
> --porcelain (perhaps while discarding the standard error) and check the
> status. Even without this patch, if a script runs with --porcelain and
> gets non-zero status, it can inspect the output and if it got rejection,
> that is a sure sign that it at least reached the other end to get enough
> information to decide that it will be rejected, no?
Yes, it's a sure sign that it reached the other side, but how does the script
know nothing else went wrong? What if a malloc failed? OK that's a bit far
fetched, but it's really, really nice to be able to get an unambiguous status
bit out of a command so you know if the requested operation succeeded or not.
Without this patch, a script calling git push --porcelain --dry-run has no way
of distinguishing these two situations
1) "git push" would try to push a ref that would get rejected, but everything
else is fine.
2) "git push" would try to push a ref that would get rejected, and also some
unknown type of error occurred that this script has no idea how to handle.
--larry
^ permalink raw reply
* Re: [PATCH v3 2/3] git-push: clean up some of the output from git push --porcelain
From: Jeff King @ 2010-02-08 21:32 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Larry D'Anna, git
In-Reply-To: <7vvde7h1mn.fsf@alter.siamese.dyndns.org>
On Mon, Feb 08, 2010 at 01:13:36PM -0800, Junio C Hamano wrote:
> diff --git a/builtin-push.c b/builtin-push.c
> index 5633f0a..f5082d8 100644
> --- a/builtin-push.c
> +++ b/builtin-push.c
> @@ -226,6 +226,11 @@ int cmd_push(int argc, const char **argv, const char *prefix)
> git_config(git_default_config, NULL);
> argc = parse_options(argc, argv, prefix, options, push_usage, 0);
>
> + if (flags & TRANSPORT_PUSH_PORCELAIN) {
> + /* Do not give advice messages to Porcelain scripts */
> + advice_push_nonfastforward = 0;
> + }
I think this is sane.
> {
> if (!count)
> - fprintf(stderr, "To %s\n", dest);
> + fprintf(porcelain ? stdout : stderr, "To %s\n", dest);
But note here that you are changing the --porcelain format, as callers
which were keeping only the stdout (and letting stderr go to /dev/null,
or spew to the user) saw only the ref lines. So this may be breaking
such callers.
I think you argued elsewhere (and I agree) that with multiple push urls,
this information is useful. Which means that the original porcelain
format was perhaps not very well thought-out. :( So we have to choose
now whether to fix it and break compatibility, or leave it broken. If
the former, then we should make sure there are not other design issues
in need of fixing, so we can just break compatibility _once_.
> @@ -1071,7 +1071,8 @@ int transport_push(struct transport *transport,
> }
>
> if (!quiet && !ret && !refs_pushed(remote_refs))
> - fprintf(stderr, "Everything up-to-date\n");
> + fprintf(porcelain ? stdout : stderr,
> + "Everything up-to-date\n");
> return ret;
> }
This one, on the other hand, seems to me to be just noise. What does a
--porcelain caller learn by seeing "Everything up-to-date" that it did
not already know from seeing the list of refs?
-Peff
^ permalink raw reply
* Re: [PATCH] Support working directory located at root
From: Johannes Sixt @ 2010-02-08 21:29 UTC (permalink / raw)
To: Nguyễn Thái Ngọc Duy
Cc: git, João Carlos Mendes Luís, Junio C Hamano
In-Reply-To: <1265640810-6361-1-git-send-email-pclouds@gmail.com>
On Montag, 8. Februar 2010, Nguyễn Thái Ngọc Duy wrote:
> @@ -25,7 +25,7 @@ const char *prefix_path(const char *prefix, int len,
> const char *path) len = strlen(work_tree);
> total = strlen(sanitized) + 1;
> if (strncmp(sanitized, work_tree, len) ||
> - (sanitized[len] != '\0' && sanitized[len] != '/')) {
> + (len > 1 && sanitized[len] != '\0' && sanitized[len] != '/')) {
> error_out:
> die("'%s' is outside repository", orig);
> }
> @@ -403,7 +403,7 @@ const char *setup_git_directory_gently(int *nongit_ok)
> if (!work_tree_env)
> inside_work_tree = 0;
> if (offset != len) {
> - cwd[offset] = '\0';
> + cwd[offset ? offset : 1] = '\0';
> set_git_dir(cwd);
> } else
> set_git_dir(".");
> @@ -427,6 +427,8 @@ const char *setup_git_directory_gently(int *nongit_ok)
> inside_git_dir = 0;
> if (!work_tree_env)
> inside_work_tree = 1;
> + if (offset == 0) /* reached root, set worktree to '/' */
> + offset = 1;
> git_work_tree_cfg = xstrndup(cwd, offset);
> if (check_repository_format_gently(nongit_ok))
> return NULL;
Does not work:
etc@master:1028> ~/Src/git/git/git add resolv.conf
fatal: pathspec 'tc/resolv.conf' did not match any files
I wonder how this works on Windows where we do not want to strip the slash
from C:/ either.
-- Hannes
^ permalink raw reply
* Re: [PATCH v3 2/3] git-push: clean up some of the output from git push --porcelain
From: Junio C Hamano @ 2010-02-08 21:13 UTC (permalink / raw)
To: Larry D'Anna; +Cc: git
In-Reply-To: <7vtytrih7b.fsf@alter.siamese.dyndns.org>
I realize that I more-or-less repeated what I already said for the second
round, so let's try a different approach.
How about replacing the three patches with something like this?
-- >8 --
Subject: push --porcelain: usability updates
"git push --porcelain" is meant for Porcelain scripts to read from; there
is no reason to give advice messages meant for the user under that mode.
When reporting the update status, the name of the destination and
"Everything up-to-date" message were shown to the standard error stream,
but that is unfriendly when a Porcelain script is reading from us. Send
them to the standard output to make it easier for them.
---
builtin-push.c | 5 +++++
transport.c | 5 +++--
2 files changed, 8 insertions(+), 2 deletions(-)
diff --git a/builtin-push.c b/builtin-push.c
index 5633f0a..f5082d8 100644
--- a/builtin-push.c
+++ b/builtin-push.c
@@ -226,6 +226,11 @@ int cmd_push(int argc, const char **argv, const char *prefix)
git_config(git_default_config, NULL);
argc = parse_options(argc, argv, prefix, options, push_usage, 0);
+ if (flags & TRANSPORT_PUSH_PORCELAIN) {
+ /* Do not give advice messages to Porcelain scripts */
+ advice_push_nonfastforward = 0;
+ }
+
if (deleterefs && (tags || (flags & (TRANSPORT_PUSH_ALL | TRANSPORT_PUSH_MIRROR))))
die("--delete is incompatible with --all, --mirror and --tags");
if (deleterefs && argc < 2)
diff --git a/transport.c b/transport.c
index 3846aac..0492934 100644
--- a/transport.c
+++ b/transport.c
@@ -675,7 +675,7 @@ static void print_ok_ref_status(struct ref *ref, int porcelain)
static int print_one_push_status(struct ref *ref, const char *dest, int count, int porcelain)
{
if (!count)
- fprintf(stderr, "To %s\n", dest);
+ fprintf(porcelain ? stdout : stderr, "To %s\n", dest);
switch(ref->status) {
case REF_STATUS_NONE:
@@ -1071,7 +1071,8 @@ int transport_push(struct transport *transport,
}
if (!quiet && !ret && !refs_pushed(remote_refs))
- fprintf(stderr, "Everything up-to-date\n");
+ fprintf(porcelain ? stdout : stderr,
+ "Everything up-to-date\n");
return ret;
}
return 1;
^ permalink raw reply related
* Re: [PATCH v3 3/3] git-push: make git push --dry-run --porcelain exit with status 0 even if updates will be rejected
From: Junio C Hamano @ 2010-02-08 20:59 UTC (permalink / raw)
To: Larry D'Anna; +Cc: git
In-Reply-To: <032264a40d15cb9f4a86885947ffa23a603bfb0e.1265661033.git.larry@elder-gods.org>
Larry D'Anna <larry@elder-gods.org> writes:
> The script calling git push --dry-run --porcelain can see clearly from the
> output that the updates will be rejected. However, it will probably need to
> distinguish this condition from the push failing for other reasons, such as the
> remote not being reachable.
I am not sure about this reasoning. If you are telling the script writers
to decide what happened by reading from the output, shouldn't the program
say "I fail because I cannot reach the other side" to its standard output
so that the script can read it as well?
Having said that, I don't think it matters either way. If a script wants
to know if push would fully succeed or not, it will run without
--porcelain (perhaps while discarding the standard error) and check the
status. Even without this patch, if a script runs with --porcelain and
gets non-zero status, it can inspect the output and if it got rejection,
that is a sure sign that it at least reached the other end to get enough
information to decide that it will be rejected, no?
^ permalink raw reply
* Re: A Visual Git Reference
From: Mark Lodato @ 2010-02-08 20:57 UTC (permalink / raw)
To: Jon Seymour; +Cc: git list
In-Reply-To: <2cfc40321002081234t2e8585bxfbcae41b18804e70@mail.gmail.com>
On Mon, Feb 8, 2010 at 3:34 PM, Jon Seymour <jon.seymour@gmail.com> wrote:
> Nice diagrams. You might want to change the arrows on the diffs to be
> consistently in direction of the forward diff.
Thanks. You're right, the da985->b325c was the only one that made
sense - the rest were reversed. Is this what you meant? I just
pushed this change, so it should be fixed.
Mark
^ permalink raw reply
* Re: [PATCH v3 2/3] git-push: clean up some of the output from git push --porcelain
From: Junio C Hamano @ 2010-02-08 20:51 UTC (permalink / raw)
To: Larry D'Anna; +Cc: git
In-Reply-To: <a1b71c9f6566549e6117f5c98c2f1e60754a7334.1265661033.git.larry@elder-gods.org>
Larry D'Anna <larry@elder-gods.org> writes:
> * don't emit long explanatory message about non-fast-forward updates.
This makes sense as a goal, but at the same time as an implementation it
would be cleaner to flip "advice" off under --porcelain, instead of doing
"s/if (advice_blah)/if (advice_blah && !porcelain)/;".
This is doubly important if you consider longer term maintainability. I
do not want to see the next person who tries to add new advice messages to
copy and paste the long if() statement you added in this patch.
> * send "To dest" lines to standard out so whoever is reading standard
> out knows which ref updates went to which remotes.
Makes sense. s/standard out/the standard output/, and
s/reading .*knows/reading from the process knows/, perhaps.
> * only send the "Everything up-to-date" line if verbose.
Don't you want to send this also to stdout?
^ permalink raw reply
* Re: [PATCH v3 1/3] git-push: fix an error message so it goes to stderr
From: Junio C Hamano @ 2010-02-08 20:45 UTC (permalink / raw)
To: Larry D'Anna; +Cc: git
In-Reply-To: <214a0317f2e4707a866b2f5d10509296bc1479c1.1265661033.git.larry@elder-gods.org>
Larry D'Anna <larry@elder-gods.org> writes:
> Having it go to standard output interferes with git-push --porcelain.
Could you at least update this rationale?
You will be squelching this in [2/3] when --porcelain is used, so the
above is no longer a good justification. It won't interfere at all.
^ permalink raw reply
* Re: A Visual Git Reference
From: Jon Seymour @ 2010-02-08 20:34 UTC (permalink / raw)
To: Mark Lodato; +Cc: Peter Baumann, git list
In-Reply-To: <ca433831002081221o660ff882o703381c5f066512e@mail.gmail.com>
G'day Mark,
Nice diagrams. You might want to change the arrows on the diffs to be
consistently in direction of the forward diff.
jon.
On Tue, Feb 9, 2010 at 7:21 AM, Mark Lodato <lodatom@gmail.com> wrote:
> On Mon, Feb 8, 2010 at 2:51 PM, Peter Baumann <waste.manager@gmx.de> wrote:
>> I have only glanced over the page, but it seems you have made the time
>> flow from right to left. Is this intentional? I find it not very intuitive.
>
> Good call. I don't know why I did that. I just pushed a new version
> that goes left-to-right.
>
> Thanks,
> Mark
> --
> To unsubscribe from this list: send the line "unsubscribe git" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
^ permalink raw reply
* [PATCH v3 1/3] git-push: fix an error message so it goes to stderr
From: Larry D'Anna @ 2010-02-08 20:31 UTC (permalink / raw)
To: git; +Cc: Larry D'Anna
In-Reply-To: <20100208201956.GA7015@cthulhu>
Having it go to standard output interferes with git-push --porcelain.
Signed-off-by: Larry D'Anna <larry@elder-gods.org>
---
builtin-push.c | 6 +++---
1 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/builtin-push.c b/builtin-push.c
index 5633f0a..0a27072 100644
--- a/builtin-push.c
+++ b/builtin-push.c
@@ -124,9 +124,9 @@ static int push_with_options(struct transport *transport, int flags)
return 0;
if (nonfastforward && advice_push_nonfastforward) {
- printf("To prevent you from losing history, non-fast-forward updates were rejected\n"
- "Merge the remote changes before pushing again. See the 'Note about\n"
- "fast-forwards' section of 'git push --help' for details.\n");
+ fprintf(stderr, "To prevent you from losing history, non-fast-forward updates were rejected\n"
+ "Merge the remote changes before pushing again. See the 'Note about\n"
+ "fast-forwards' section of 'git push --help' for details.\n");
}
return 1;
--
1.7.0.rc1.33.g07cf0f.dirty
^ permalink raw reply related
* [PATCH v3 2/3] git-push: clean up some of the output from git push --porcelain
From: Larry D'Anna @ 2010-02-08 20:31 UTC (permalink / raw)
To: git; +Cc: Larry D'Anna
In-Reply-To: <20100208201956.GA7015@cthulhu>
* don't emit long explanatory message about non-fast-forward updates.
* send "To dest" lines to standard out so whoever is reading standard out knows
which ref updates went to which remotes.
* only send the "Everything up-to-date" line if verbose.
Signed-off-by: Larry D'Anna <larry@elder-gods.org>
---
builtin-push.c | 2 +-
transport.c | 4 ++--
2 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/builtin-push.c b/builtin-push.c
index 0a27072..ff0b1c6 100644
--- a/builtin-push.c
+++ b/builtin-push.c
@@ -123,7 +123,7 @@ static int push_with_options(struct transport *transport, int flags)
if (!err)
return 0;
- if (nonfastforward && advice_push_nonfastforward) {
+ if (!(flags & TRANSPORT_PUSH_PORCELAIN) && nonfastforward && advice_push_nonfastforward) {
fprintf(stderr, "To prevent you from losing history, non-fast-forward updates were rejected\n"
"Merge the remote changes before pushing again. See the 'Note about\n"
"fast-forwards' section of 'git push --help' for details.\n");
diff --git a/transport.c b/transport.c
index 3846aac..00d986c 100644
--- a/transport.c
+++ b/transport.c
@@ -675,7 +675,7 @@ static void print_ok_ref_status(struct ref *ref, int porcelain)
static int print_one_push_status(struct ref *ref, const char *dest, int count, int porcelain)
{
if (!count)
- fprintf(stderr, "To %s\n", dest);
+ fprintf(porcelain ? stdout : stderr, "To %s\n", dest);
switch(ref->status) {
case REF_STATUS_NONE:
@@ -1070,7 +1070,7 @@ int transport_push(struct transport *transport,
update_tracking_ref(transport->remote, ref, verbose);
}
- if (!quiet && !ret && !refs_pushed(remote_refs))
+ if (!quiet && (!porcelain || verbose) && !ret && !refs_pushed(remote_refs))
fprintf(stderr, "Everything up-to-date\n");
return ret;
}
--
1.7.0.rc1.33.g07cf0f.dirty
^ permalink raw reply related
* [PATCH v3 3/3] git-push: make git push --dry-run --porcelain exit with status 0 even if updates will be rejected
From: Larry D'Anna @ 2010-02-08 20:31 UTC (permalink / raw)
To: git; +Cc: Larry D'Anna
In-Reply-To: <20100208201956.GA7015@cthulhu>
The script calling git push --dry-run --porcelain can see clearly from the
output that the updates will be rejected. However, it will probably need to
distinguish this condition from the push failing for other reasons, such as the
remote not being reachable.
Signed-off-by: Larry D'Anna <larry@elder-gods.org>
---
builtin-send-pack.c | 4 ++++
send-pack.h | 1 +
transport.c | 3 ++-
3 files changed, 7 insertions(+), 1 deletions(-)
diff --git a/builtin-send-pack.c b/builtin-send-pack.c
index 76c7206..358f5e1 100644
--- a/builtin-send-pack.c
+++ b/builtin-send-pack.c
@@ -476,6 +476,10 @@ int send_pack(struct send_pack_args *args,
if (ret < 0)
return ret;
+
+ if (args->porcelain && args->dry_run)
+ return 0;
+
for (ref = remote_refs; ref; ref = ref->next) {
switch (ref->status) {
case REF_STATUS_NONE:
diff --git a/send-pack.h b/send-pack.h
index 28141ac..60b4ba6 100644
--- a/send-pack.h
+++ b/send-pack.h
@@ -4,6 +4,7 @@
struct send_pack_args {
unsigned verbose:1,
quiet:1,
+ porcelain:1,
send_mirror:1,
force_update:1,
use_thin_pack:1,
diff --git a/transport.c b/transport.c
index 00d986c..2b9e4be 100644
--- a/transport.c
+++ b/transport.c
@@ -791,6 +791,7 @@ static int git_transport_push(struct transport *transport, struct ref *remote_re
args.verbose = !!(flags & TRANSPORT_PUSH_VERBOSE);
args.quiet = !!(flags & TRANSPORT_PUSH_QUIET);
args.dry_run = !!(flags & TRANSPORT_PUSH_DRY_RUN);
+ args.porcelain = !!(flags & TRANSPORT_PUSH_PORCELAIN);
ret = send_pack(&args, data->fd, data->conn, remote_refs,
&data->extra_have);
@@ -1052,7 +1053,7 @@ int transport_push(struct transport *transport,
flags & TRANSPORT_PUSH_FORCE);
ret = transport->push_refs(transport, remote_refs, flags);
- err = push_had_errors(remote_refs);
+ err = (pretend && porcelain) ? 0 : push_had_errors(remote_refs);
ret |= err;
--
1.7.0.rc1.33.g07cf0f.dirty
^ permalink raw reply related
* Re: A Visual Git Reference
From: Mark Lodato @ 2010-02-08 20:21 UTC (permalink / raw)
To: Peter Baumann; +Cc: git list
In-Reply-To: <20100208195141.GF30877@m62s10.vlinux.de>
On Mon, Feb 8, 2010 at 2:51 PM, Peter Baumann <waste.manager@gmx.de> wrote:
> I have only glanced over the page, but it seems you have made the time
> flow from right to left. Is this intentional? I find it not very intuitive.
Good call. I don't know why I did that. I just pushed a new version
that goes left-to-right.
Thanks,
Mark
^ permalink raw reply
* Re: [PATCH v2 3/3] make git push --dry-run --porcelain exit with status 0 even if updates will be rejected
From: Larry D'Anna @ 2010-02-08 20:19 UTC (permalink / raw)
To: Tay Ray Chuan; +Cc: git
In-Reply-To: <20100206075025.c1fe6b5a.rctay89@gmail.com>
good idea.
--larry
^ permalink raw reply
* Re: [PATCH] Documentation: git-add: correct first example
From: Junio C Hamano @ 2010-02-08 20:08 UTC (permalink / raw)
To: Greg Bacon; +Cc: git
In-Reply-To: <7vsk9bmt1h.fsf@alter.siamese.dyndns.org>
Junio C Hamano <gitster@pobox.com> writes:
>> and its subdirectories:
>> +
>> ------------
>> -$ git add Documentation/\\*.txt
>
> This indeed results in double-backslash in the output.
>
>> +$ git add Documentation/\*.txt
>
> and this seems to fix it.
>
> Thanks.
To look for similar breakages, I ran
git grep -n -e '\\\\' -- 'Documentation/*.txt'
and found this in git-rm.txt:
EXAMPLES
--------
git rm Documentation/\\*.txt::
Removes all `\*.txt` files from the index that are under the
`Documentation` directory and any of its subdirectories.
What is intereseting is that this is rendered correctly. Quoting rule in
AsciiDoc is mysterious...
It turns out that the breakage in "git add" documentation was a
regression; the examples were written in a similar way to the one in "git
rm" documentation. When 921177f (Documentation: improve "add", "pull" and
"format-patch" examples, 2008-05-07) converted it to displayed text,
nobody noticed that the difference in the backslash quoting rule between
the enumeration header and displayed text.
^ permalink raw reply
* Re: A Visual Git Reference
From: Peter Baumann @ 2010-02-08 19:51 UTC (permalink / raw)
To: Mark Lodato; +Cc: git list
In-Reply-To: <ca433831002081134m698f531bwa22f0474db0cdcb@mail.gmail.com>
On Mon, Feb 08, 2010 at 02:34:21PM -0500, Mark Lodato wrote:
> All,
>
> I put together a "Visual Git Reference" containing visualizations of
> the most common git commands, for people who prefer to see images over
> text. It is designed as a reference, not a tutorial, so readers need
> to have some amount of experience before the page will become useful.
>
> URL: http://marklodato.github.com/visual-git-guide/
> Git repo: http://github.com/marklodato/visual-git-guide/
>
> If you have any feedback or suggestions, please let me know!
I have only glanced over the page, but it seems you have made the time
flow from right to left. Is this intentional? I find it not very intuitive.
^ permalink raw reply
* A Visual Git Reference
From: Mark Lodato @ 2010-02-08 19:34 UTC (permalink / raw)
To: git list
All,
I put together a "Visual Git Reference" containing visualizations of
the most common git commands, for people who prefer to see images over
text. It is designed as a reference, not a tutorial, so readers need
to have some amount of experience before the page will become useful.
URL: http://marklodato.github.com/visual-git-guide/
Git repo: http://github.com/marklodato/visual-git-guide/
If you have any feedback or suggestions, please let me know!
Cheers,
Mark
^ permalink raw reply
* Re: [PATCH] Documentation: git-add: correct first example
From: Junio C Hamano @ 2010-02-08 19:22 UTC (permalink / raw)
To: Greg Bacon; +Cc: git
In-Reply-To: <1265650551-32664-1-git-send-email-gbacon@dbresearch.net>
Greg Bacon <gbacon@dbresearch.net> writes:
> The first example for git-add covers recursive adding of patterns but
> contains an extra backslash.
Correct.
> Signed-off-by: Greg Bacon <gbacon@dbresearch.net>
> ---
> Documentation/git-add.txt | 5 +++--
> 1 files changed, 3 insertions(+), 2 deletions(-)
>
> diff --git a/Documentation/git-add.txt b/Documentation/git-add.txt
> index f74fcf3..93e8f57 100644
> --- a/Documentation/git-add.txt
> +++ b/Documentation/git-add.txt
> @@ -149,11 +149,12 @@ those in info/exclude. See linkgit:gitrepository-layout[5].
> EXAMPLES
> --------
>
> -* Adds content from all `\*.txt` files under `Documentation` directory
> +* Adds content from all `*.txt` files under `Documentation` directory
For this, both
http://www.kernel.org/pub/software/scm/git/docs/git-add.html
and output from
git help add
in my local build seem to be rendered correctly by AsciiDoc.
> and its subdirectories:
> +
> ------------
> -$ git add Documentation/\\*.txt
This indeed results in double-backslash in the output.
> +$ git add Documentation/\*.txt
and this seems to fix it.
Thanks.
^ permalink raw reply
* Re: git add -u nonexistent-file
From: Chris Packham @ 2010-02-08 19:12 UTC (permalink / raw)
To: SZEDER Gábor; +Cc: git
In-Reply-To: <20100208182929.GB14355@neumann>
2010/2/8 SZEDER Gábor <szeder@ira.uka.de>:
> Hi,
>
>
> $ git --version
> git version 1.7.0.rc1.84.g9879
> $ git add -u nonexistent-file
> $ echo $?
> 0
>
> No error message, no error in exit status.
>
> Is it OK this way? Why?
>
>
> Best,
> Gábor
>
Hi,
I see the same behaviour with git version 1.6.4.2.
From the man page of git-add
-u, --update
Update only files that git already knows about, staging
modified content for
commit and marking deleted files for removal.
So git will only look at files that are already in the repository.
It looks like in the case you've highlighted git is ignoring the extra
non-option parameters on the command line. I'll let other people argue
whether this is by design or omission.
'git add nonexistent-file' works as expected, exiting with an error
message and non-zero exit status.
^ permalink raw reply
* git add -u nonexistent-file
From: SZEDER Gábor @ 2010-02-08 18:29 UTC (permalink / raw)
To: git
Hi,
$ git --version
git version 1.7.0.rc1.84.g9879
$ git add -u nonexistent-file
$ echo $?
0
No error message, no error in exit status.
Is it OK this way? Why?
Best,
Gábor
^ permalink raw reply
* Re: [PATCH] Revert "pack-objects: fix pack generation when using pack_size_limit"
From: Nicolas Pitre @ 2010-02-08 18:11 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7v3a1bpqqq.fsf@alter.siamese.dyndns.org>
On Mon, 8 Feb 2010, Junio C Hamano wrote:
> Nicolas Pitre <nico@fluxnic.net> writes:
>
> > This reverts most of commit a2430dde8ceaaaabf05937438249397b883ca77a.
> >
> > That commit made the situation better for repositories with relatively
> > small number of objects. However with many objects and a small pack size
> > limit, the time required to complete the repack tends towards O(n^2),
> > or even much worse with long delta chains.
> >
> > Signed-off-by: Nicolas Pitre <nico@fluxnic.net>
> > ---
> >
> > Fixing this doesn't appear to be as trivial as I initially thought.
> > Although I do have some ideas, they're not appropriate so late in
> > the -rc period.
>
> Ok, so the idea is what a2430dd tried is an issue worth addressing but the
> particular execution wasn't good? We revert it for now, but we will try
> again after the release, perhaps doing it differently?
Exact. I did try a few things in the hope that the "fix" would have
been trivial enough to merge now but none of that worked satisfactorily.
> I agree with it if that is your intention, but "Most of" bugs me a bit.
It's not a straight revert in the sense that I left in some cleanups and
left out the redundant self consistency check. Only the significant
parts were reverted.
Nicolas
^ permalink raw reply
* [PATCH] Documentation: git-add: correct first example
From: Greg Bacon @ 2010-02-08 17:35 UTC (permalink / raw)
To: git; +Cc: gitster, Greg Bacon
The first example for git-add covers recursive adding of patterns but
contains an extra backslash. If copied verbatim, the command fails
with
fatal: pathspec 'Documentation/\*.txt' did not match any files
This patch corrects the problem and adds an equivalent invocation.
Signed-off-by: Greg Bacon <gbacon@dbresearch.net>
---
Documentation/git-add.txt | 5 +++--
1 files changed, 3 insertions(+), 2 deletions(-)
diff --git a/Documentation/git-add.txt b/Documentation/git-add.txt
index f74fcf3..93e8f57 100644
--- a/Documentation/git-add.txt
+++ b/Documentation/git-add.txt
@@ -149,11 +149,12 @@ those in info/exclude. See linkgit:gitrepository-layout[5].
EXAMPLES
--------
-* Adds content from all `\*.txt` files under `Documentation` directory
+* Adds content from all `*.txt` files under `Documentation` directory
and its subdirectories:
+
------------
-$ git add Documentation/\\*.txt
+$ git add Documentation/\*.txt
+$ git add 'Documentation/*.txt' # same thing
------------
+
Note that the asterisk `\*` is quoted from the shell in this
--
1.6.5.5
^ permalink raw reply related
* Re: [PATCH] Revert "pack-objects: fix pack generation when using pack_size_limit"
From: Junio C Hamano @ 2010-02-08 17:43 UTC (permalink / raw)
To: Nicolas Pitre; +Cc: git
In-Reply-To: <alpine.LFD.2.00.1002081032530.1681@xanadu.home>
Nicolas Pitre <nico@fluxnic.net> writes:
> This reverts most of commit a2430dde8ceaaaabf05937438249397b883ca77a.
>
> That commit made the situation better for repositories with relatively
> small number of objects. However with many objects and a small pack size
> limit, the time required to complete the repack tends towards O(n^2),
> or even much worse with long delta chains.
>
> Signed-off-by: Nicolas Pitre <nico@fluxnic.net>
> ---
>
> Fixing this doesn't appear to be as trivial as I initially thought.
> Although I do have some ideas, they're not appropriate so late in
> the -rc period.
Ok, so the idea is what a2430dd tried is an issue worth addressing but the
particular execution wasn't good? We revert it for now, but we will try
again after the release, perhaps doing it differently?
I agree with it if that is your intention, but "Most of" bugs me a bit.
^ permalink raw reply
* Re: [PATCH] Support working directory located at root
From: Junio C Hamano @ 2010-02-08 17:43 UTC (permalink / raw)
To: Nguyễn Thái Ngọc Duy
Cc: git, João Carlos Mendes Luís
In-Reply-To: <1265640810-6361-1-git-send-email-pclouds@gmail.com>
Nguyễn Thái Ngọc Duy <pclouds@gmail.com> writes:
> Git should work regardless where the working directory is located,
> even at root. This patch fixes two places where it assumes working
> directory always have parent directory.
>
> In setup_git_directory_gently(), when Git goes up to root and finds
> .git there, it happily sets worktree to "".
If you mean "instead set it to "/" and things will work much better."
I agree with the reasoning (not suggesting to reword---just trying to
make sure I understood what you meant).
> In prefix_path(), loosen the outside repo check a little bit. Usually
> when a path XXX is inside worktree /foo, it must be either "/foo", or
> "/foo/...". When worktree is simply "/", we can safely ignore the
> check: we have a slash at the beginning already.
The logic for the "are we inside?" check above sounds correct. When
work_tree is at root, have "/" in it, and len inside the "if orig is
absolute" block is 1, so memmove() strips out the leading '/' and makes
the result relative to the root level. Am I reading the code right?
> Not related to worktree, but also set gitdir correctly if a bare repo
> is placed (insanely?) at root.
Yuck, but looks correct.
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox