* You have local changes; cannot switch branches error question
From: Eugene Sajine @ 2009-12-24 22:25 UTC (permalink / raw)
To: git; +Cc: Eugene Sajine
First of all Merry Christmas and Happy New Year to everybody! I wish
Git to move to global dominance during next year even faster then it
does now;)
My question is related to the fact that most of the time when i have
some local file changes Git is switching branches OK. But from time to
time in some repos I'm hitting this error and I cannot figure out why
it suddenly starts to complain about it?
For example in one of my repos I somehow got to a state when I have
three files modified, and when I'm trying to switch branches it
complains about one of them being changed locally, so it refuses to
switch branch
OTOH i have tried many different scenarios in another repo to leave
some uncommitted staged or not staged changes and switch branches and
same version of git does that just fine. (v 1.6.5.6).
So, what is correct behavior - do not switch or switch branches when
there are uncommitted changes?
Thanks,
Eugene
^ permalink raw reply
* Re: You have local changes; cannot switch branches error question
From: Nanako Shiraishi @ 2009-12-24 22:59 UTC (permalink / raw)
To: Eugene Sajine; +Cc: git
In-Reply-To: <76c5b8580912241425k741b24e9ie8ed92ca7cb8a659@mail.gmail.com>
Quoting Eugene Sajine <euguess@gmail.com>
> My question is related to the fact that most of the time when i have
> some local file changes Git is switching branches OK. But from time to
> time in some repos I'm hitting this error and I cannot figure out why
> it suddenly starts to complain about it?
The command is telling you that it refrained to overwrite
your local changes. It's not complaining. There is an
excellent summary of what switching branches with 'git
checkout' while you have local changes in your working tree.
http://thread.gmane.org/gmane.comp.version-control.git/77700/focus=77708
--
Nanako Shiraishi
http://ivory.ap.teacup.com/nanako3/
^ permalink raw reply
* Re: You have local changes; cannot switch branches error question
From: Junio C Hamano @ 2009-12-24 23:32 UTC (permalink / raw)
To: Eugene Sajine; +Cc: git
In-Reply-To: <76c5b8580912241425k741b24e9ie8ed92ca7cb8a659@mail.gmail.com>
Eugene Sajine <euguess@gmail.com> writes:
> For example in one of my repos I somehow got to a state when I have
> three files modified, and when I'm trying to switch branches it
> complains about one of them being changed locally, so it refuses to
> switch branch
Suppose you have a history like this:
o---B side
/
---o----o----A master
and both branches 'master' and 'side' have file, F and G. G is different
between commits A and B while F is the same between these two commits.
You have 'master' checked out, and modified both F and G. This table
shows the contents you have in each path:
path master work tree side
-----------------------------------------
F F1 F2 F1
G G1 G2 G3
In git, your local modification does _not_ belong to any branch. You need
to commit them if you want to make them part of the history of your
current branch. Checking out a different branch means you switch to the
branch and carry these changes along with you. But it is not necessarily
be possible to do so without modifying what is in your work tree.
For path F, your local change is (F2-F1), and switching to branch 'side'
means you would transplant that change on top of what that branch has,
which happens to be F1. That means the result is F2 (= F1 + (F2-F1)).
IOW, because F is identical between master and side, the file in your work
tree can stay the same.
Now, think what should happen to path G. The local change is (G2-G1), and
you need to transplant that change on top of G3, that is different from
G1. This computation will involve a merge, which you may or may not be
prepared to resolve.
If you are used to CVS/SVN workflow where you "update" to merge other's
changes to your work tree with your own local changes, you will know that
with such a merge, depending on the amount of change between G1 and G3,
you may end up losing quite a lot of work of your own (G2-G1), when the
merge is too complicated for you to handle. The message you saw is a
safety valve to prevent you from trashing your work that way.
There are two ways to deal with this situation, one safely, and another
quickly.
- You can "stash save" to first save the changes in your work tree,
"checkout" to switch to branch 'side', and then "stash pop" to attempt
the merge.
The last step of unstashing on the new branch _will_ give you the same
kind of conflict while computing G3 + (G2 - G1) to update file G, but
the approach has one huge advantage compared to CVS/SVN's "update", in
that you can "reset --hard" and "stash pop" to reset to a clean state
and attempt resolution if you failed resolve conflicts and end up
making a mess in your first try.
- If you _know_ that the changes between G1 and G3 do not conflict with
what you did between G1 and G2, you can "checkout -m" to instruct it to
act as if it were CVS/SVN's "update" command.
This can potentially make an unresolvable mess in your work tree, and
you can end up losing your changes G2-G1, but it is quicker than "stash
save"/"stash pop" pair.
^ permalink raw reply
* Branch shuffling after 1.6.6 release plans
From: Junio C Hamano @ 2009-12-25 0:25 UTC (permalink / raw)
To: git
In-Reply-To: <7vpr65kwnt.fsf@alter.siamese.dyndns.org>
Here is a list of short-term branch shuffling I plan to do.
- Kick a few topics back to 'pu'. They were merged to 'next' in the hope
of them either getting discussed to form a consensus or perfected, but
they ended up in limbo for a long time without progress (pre-release
freeze didn't have any impact on them),
This involves applying a few reverts directly on top of 'next', which
I've already done privately. People _could_ vote to bring them back by
working on perfecting them and/or discussing them to reach concensus.
* je/send-email-no-subject (2009-08-05) 1 commit
- send-email: confirm on empty mail subjects
The existing tests cover the positive case (i.e. as long as the user says
"yes" to the "do you really want to send this message that lacks subject",
the message is sent) of this feature, but the feature itself needs its own
test to verify the negative case (i.e. does it correctly stop if the user
says "no"?)
* tr/maint-merge-ours-clarification (2009-11-15) 1 commit
- rebase: refuse to rebase with -s ours
I do not think we reached a concensus for solving conflicts between "give
them rope" and "protect users from clearly meaningless combinations". The
author obviously is for the latter (and I am inclined to agree); Dscho
seems to think otherwise.
* tr/reset-checkout-patch (2009-11-19) 1 commit
- {checkout,reset} -p: make patch direction configurable
I do not particularly like a configuration like this that changes the
behaviour of a command in a drastic way---it will make helping others
much harder.
- Graduate the following topics to 'master':
* sr/vcs-helper (2009-12-07) 14 commits
* jc/1.7.0-send-email-no-thread-default (2009-08-22) 1 commit.
* jc/1.7.0-push-safety (2009-02-09) 2 commits.
* jc/1.7.0-diff-whitespace-only-status (2009-08-30) 4 commits.
* gb/1.7.0-diff-whitespace-only-output (2009-11-19) 1 commit
Also possibly:
* jk/1.7.0-status (2009-12-11) 16 commits
* jc/1.7.0-status (2009-09-05) 4 commits
For these topics, we would need to decide what to do with the
"submodule summary" stuff in the --porcelain format output, which we
promised will never change in the documentation. My current thinking
is to keep the current code and don't show anything; Porcelains can
choose to run "git log" inside submodule directories if they so desire.
- Rebuild 'next' on top of the updated 'master' with remaining topics.
I actually won't do this step before the new year, so that people who
based their topics on 'next' can still fast-forward, but with many
topics for 1.7.0 graduating this week to 'master' hopefully it would be
easier for them to rebase on top of 'master'.
^ permalink raw reply
* Re: [RFC PATCH 1/2] Report exec errors from run-command
From: Junio C Hamano @ 2009-12-25 7:35 UTC (permalink / raw)
To: Ilari Liusvaara; +Cc: git
In-Reply-To: <1261676971-3285-2-git-send-email-ilari.liusvaara@elisanet.fi>
Ilari Liusvaara <ilari.liusvaara@elisanet.fi> writes:
> Previously run-command was unable to report errors happening in exec
> call. Change it to pass errno from failed exec to errno value at
> return.
>
> The errno value passing can be done by opening close-on-exec pipe and
> piping the error code through in case of failure. In case of success,
> close-on-exec closes the pipe on successful exec and parent process
> gets end of file on read.
Thanks; I think overall this is a good idea, even though I have no clue
if WIN32 side wants a similar support.
- At first reading, the "while (close(fd) < 0 && errno != EBADF);"
pattern was a bit of eyesore. It might be worth factoring that out to
a small static helper function that a smart compiler would
automatically inline (or mark it as a static inline).
- Is it guaranteed that a failed pipe(2) never touches its int fildes[2]
parameter, or the values are undefined when it fails? The approach
would save one extra variable, compared to an alternative approach to
keep an explicit variable to record a pipe failure, but It feels iffy
that the code relies on them being left as their initial -1 values.
- Should we worry about partial write as well (you seem to warn when you
get a partial read)? Is it worth using xread() and friends found in
wrapper.c instead of goto read/write_again?
- Shouldn't any of these warning() be die() instead?
- The two extra file descriptors this patch uses are allocated after all
the existing pipe flipping is done, and all the dup's done in the child
process are to use dup2() to set up the known file descriptors at low
numbers, so I don't think we have to worry about this patch changing
the behaviour of the process pair by changing the assignment of file
descriptors (we had a bug or two in the past that made subprocess
misbehave under some funky condition, e.g. run with fd#0 closed).
^ permalink raw reply
* Re: [RFC PATCH 2/2] Improve transport helper exec failure reporting
From: Junio C Hamano @ 2009-12-25 7:44 UTC (permalink / raw)
To: Ilari Liusvaara; +Cc: git
In-Reply-To: <1261676971-3285-3-git-send-email-ilari.liusvaara@elisanet.fi>
Ilari Liusvaara <ilari.liusvaara@elisanet.fi> writes:
> Previously transport-helper exec failure error reporting was pretty
> much useless as it didn't report errors from execve, only from pipe
> and fork. Now that run-command passes errno from exec, use the
> improved support to actually print useful errors if execution fails.
>
> Signed-off-by: Ilari Liusvaara <ilari.liusvaara@elisanet.fi>
Looks pretty straightforward, except that I have this nagging feeling that
we should *not* be married to the idea of "'proc->git_cmd = 1' is merely a
way to save you from typing 'git-' prefix in start_command(proc)".
> diff --git a/transport-helper.c b/transport-helper.c
> index 5078c71..0965c9b 100644
> --- a/transport-helper.c
> +++ b/transport-helper.c
> @@ -31,13 +31,19 @@ static struct child_process *get_helper(struct transport *transport)
> helper->out = -1;
> helper->err = 0;
> helper->argv = xcalloc(4, sizeof(*helper->argv));
> - strbuf_addf(&buf, "remote-%s", data->name);
> + strbuf_addf(&buf, "git-remote-%s", data->name);
> helper->argv[0] = strbuf_detach(&buf, NULL);
> helper->argv[1] = transport->remote->name;
> helper->argv[2] = transport->url;
> - helper->git_cmd = 1;
> - if (start_command(helper))
> - die("Unable to run helper: git %s", helper->argv[0]);
> + helper->git_cmd = 0;
> + if (start_command(helper)) {
For example, we might later want to use different $PATH only when running
a git subcommand, and telling run_command() explicitly that we are running
a git thing would help if you don't add "git-" to the command line and
drop "proc->git_cmd = 1" in the caller like your patch does.
> + if (errno == ENOENT)
> + die("Unable to find remote helper for \"%s\"",
> + data->name);
> + else
> + die("Unable to run helper %s: %s", helper->argv[0],
> + strerror(errno));
> + }
> data->helper = helper;
>
> write_str_in_full(helper->in, "capabilities\n");
> --
> 1.6.6.3.gaa2e1
^ permalink raw reply
* Re: [RFC PATCH 1/2] Report exec errors from run-command
From: Junio C Hamano @ 2009-12-25 7:46 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Ilari Liusvaara, git
In-Reply-To: <7vr5qjecbb.fsf@alter.siamese.dyndns.org>
Junio C Hamano <gitster@pobox.com> writes:
> Ilari Liusvaara <ilari.liusvaara@elisanet.fi> writes:
>
>> Previously run-command was unable to report errors happening in exec
>> call. Change it to pass errno from failed exec to errno value at
>> return.
>>
>> The errno value passing can be done by opening close-on-exec pipe and
>> piping the error code through in case of failure. In case of success,
>> close-on-exec closes the pipe on successful exec and parent process
>> gets end of file on read.
>
> Thanks; I think overall this is a good idea, even though I have no clue
> if WIN32 side wants a similar support.
By the way, at least it should be pretty straightforward to add a test or
two for [1/2] if not [2/2].
^ permalink raw reply
* Re: [RFC PATCH 1/2] Report exec errors from run-command
From: Junio C Hamano @ 2009-12-25 8:40 UTC (permalink / raw)
To: Ilari Liusvaara; +Cc: git
In-Reply-To: <7vr5qjecbb.fsf@alter.siamese.dyndns.org>
Junio C Hamano <gitster@pobox.com> writes:
> - At first reading, the "while (close(fd) < 0 && errno != EBADF);"
> pattern was a bit of eyesore. It might be worth factoring that out to
> a small static helper function that a smart compiler would
> automatically inline (or mark it as a static inline).
This also is a minor style thing, but we prefer your
>>+ while(close(report_pipe[1]) < 0 && errno != EBADF);
formatted like this:
while (foobar)
; /* noop */
to
(1) have SP after syntactic keyword like while/if/switch to differentiate
from function calls; and
(2) make the no-op stand out for a bit more visibility.
^ permalink raw reply
* Re: [RFC PATCH 2/2] Improve transport helper exec failure reporting
From: Ilari Liusvaara @ 2009-12-25 9:32 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vljgrebv2.fsf@alter.siamese.dyndns.org>
On Thu, Dec 24, 2009 at 11:44:49PM -0800, Junio C Hamano wrote:
> Ilari Liusvaara <ilari.liusvaara@elisanet.fi> writes:
>
> Looks pretty straightforward, except that I have this nagging feeling that
> we should *not* be married to the idea of "'proc->git_cmd = 1' is merely a
> way to save you from typing 'git-' prefix in start_command(proc)".
That is already broken. If nothing previous broke it, then 1/2 of this
series did.
The immediate executable to run for 'git-foo' && git_cmd = 0: 'git-foo'.
The immediate executable to run for 'foo' && git_cmd = 1: 'git'(!).
And one wants exec status for 'git-remote-foo', NOT for 'git'. Thus,
git_cmd must be 0 (at least without additional flags or flag values).
> For example, we might later want to use different $PATH only when running
> a git subcommand, and telling run_command() explicitly that we are running
> a git thing would help if you don't add "git-" to the command line and
> drop "proc->git_cmd = 1" in the caller like your patch does.
Well, that would require new flag (or git_cmd field value) to mean do direct
exec with gitexecdir in $PATH. Otherwise, you would either break this piece
of code, or it would be already broken (depending on value of git_cmd).
-Ilari
^ permalink raw reply
* Re: [RFC PATCH 1/2] Report exec errors from run-command
From: Ilari Liusvaara @ 2009-12-25 9:51 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vr5qjecbb.fsf@alter.siamese.dyndns.org>
On Thu, Dec 24, 2009 at 11:35:04PM -0800, Junio C Hamano wrote:
> Ilari Liusvaara <ilari.liusvaara@elisanet.fi> writes:
>
> Thanks; I think overall this is a good idea, even though I have no clue
> if WIN32 side wants a similar support.
It would. But I have no clue about WIN32. But there are other people
on this list who have. :-)
> - At first reading, the "while (close(fd) < 0 && errno != EBADF);"
> pattern was a bit of eyesore. It might be worth factoring that out to
> a small static helper function that a smart compiler would
> automatically inline (or mark it as a static inline).
Done (with bit of reformatting to add space, line break and comment.
> - Is it guaranteed that a failed pipe(2) never touches its int fildes[2]
> parameter, or the values are undefined when it fails? The approach
> would save one extra variable, compared to an alternative approach to
> keep an explicit variable to record a pipe failure, but It feels iffy
> that the code relies on them being left as their initial -1 values.
I added explicit set to -1 on failure case (I think failed pipe doesn't touch
those, but you never know about what some oddball OS is going to do).
> - Should we worry about partial write as well (you seem to warn when you
> get a partial read)? Is it worth using xread() and friends found in
> wrapper.c instead of goto read/write_again?
That's hairy code. One really can't print any errors in write path, as those
errors would go to who knows where due to redirections (I took the error
warning out).
That partial read warning is more for detecting 'can't happen' situations
since pipe should be large enough to atomically transfer integer.
> - Shouldn't any of these warning() be die() instead?
If error reporting failures are fatal, all of them.
-Ilari
^ permalink raw reply
* Re: Branch shuffling after 1.6.6 release plans
From: Thomas Rast @ 2009-12-25 11:30 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vljgrgar9.fsf@alter.siamese.dyndns.org>
Thanks for 1.6.6!
Junio C Hamano wrote:
> * tr/maint-merge-ours-clarification (2009-11-15) 1 commit
> - rebase: refuse to rebase with -s ours
>
> I do not think we reached a concensus for solving conflicts between "give
> them rope" and "protect users from clearly meaningless combinations". The
> author obviously is for the latter (and I am inclined to agree); Dscho
> seems to think otherwise.
I can try hacking some internal option into the merge helpers, by
which they declare to be (in)compatible with rebasing. I think this
what Dscho or Sverre mentioned in the corresponding thread, but I
forgot about it when I noticed you had already promoted the above to
'next'.
> * tr/reset-checkout-patch (2009-11-19) 1 commit
> - {checkout,reset} -p: make patch direction configurable
>
> I do not particularly like a configuration like this that changes the
> behaviour of a command in a drastic way---it will make helping others
> much harder.
I think it's not quite as drastic as you make it sound ;-)
But I don't need this feature, and Peff mentioned something about
being happy except for the patch editing mode. Unfortunately the
above pretty much hits the limits of add--interactive's flexibility,
so an interactive direction toggling feature would need some rewiring.
--
Thomas Rast
trast@{inf,student}.ethz.ch
^ permalink raw reply
* Re: Branch shuffling after 1.6.6 release plans
From: Ilari Liusvaara @ 2009-12-25 12:28 UTC (permalink / raw)
To: Thomas Rast; +Cc: Junio C Hamano, git
In-Reply-To: <200912251230.48243.trast@student.ethz.ch>
On Fri, Dec 25, 2009 at 12:30:34PM +0100, Thomas Rast wrote:
>
> I can try hacking some internal option into the merge helpers, by
> which they declare to be (in)compatible with rebasing. I think this
> what Dscho or Sverre mentioned in the corresponding thread, but I
> forgot about it when I noticed you had already promoted the above to
> 'next'.
If you do that, maybe do all relevant flags (such as "no fast forwards"
and "no trivial merging") at the same time. That would allow external
strategies to use those flags.
-Ilari
^ permalink raw reply
* [PATCH] user-manual: use standarized quoting
From: Felipe Contreras @ 2009-12-25 13:05 UTC (permalink / raw)
To: git; +Cc: Felipe Contreras
Hi,
This is a big patch that was sent before, but now I'm explaining my rationale
for the quoting style I used. I noticed a few deviations on my own rules, so I
fixed them.
What do you think?
Felipe Contreras (1):
user-manual: general quoting improvements
Documentation/user-manual.txt | 884 ++++++++++++++++++++--------------------
1 files changed, 442 insertions(+), 442 deletions(-)
^ permalink raw reply
* Re: You have local changes; cannot switch branches error question
From: Matthieu Moy @ 2009-12-25 14:32 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Eugene Sajine, git
In-Reply-To: <7vhbrghrsn.fsf@alter.siamese.dyndns.org>
Junio C Hamano <gitster@pobox.com> writes:
> There are two ways to deal with this situation, one safely, and another
> quickly.
And a third one : commit, and then rebase onto the other branch. It's
safe, and nice when your local changes are ready to commit (then, you
can write the commit message before bothering about potential merge
conflicts).
--
Matthieu Moy
http://www-verimag.imag.fr/~moy/
^ permalink raw reply
* Re: [RFC PATCH 1/2] Report exec errors from run-command
From: Johannes Sixt @ 2009-12-25 14:39 UTC (permalink / raw)
To: Ilari Liusvaara; +Cc: git
In-Reply-To: <1261676971-3285-2-git-send-email-ilari.liusvaara@elisanet.fi>
On Donnerstag, 24. Dezember 2009, Ilari Liusvaara wrote:
> Previously run-command was unable to report errors happening in exec
> call. Change it to pass errno from failed exec to errno value at
> return.
>
> The errno value passing can be done by opening close-on-exec pipe and
> piping the error code through in case of failure. In case of success,
> close-on-exec closes the pipe on successful exec and parent process
> gets end of file on read.
The only really *important* errno of a failed exec is ENOENT. For this case,
wouldn't it be easier to do the PATH lookup manually in the parent (before
the fork()), and use execv() in the forked child rather than execvp()?
There is already a path lookup function in compat/mingw.c; it could certainly
need some improvement, but it is a starter.
That said, we don't need the stunt that you implemented on WIN32, because by
the time mingw_spawnvpe() returns, we have a running child process.
-- Hannes
^ permalink raw reply
* [PATCH 0/4] clone: use --progress to mean -v
From: Tay Ray Chuan @ 2009-12-25 17:12 UTC (permalink / raw)
To: git; +Cc: Miklos Vajna, Nicolas Pitre, Johannes Schindelin, Junio C Hamano
In-Reply-To: <18831.46833.862.196815@hungover.brentg.com>
This series makes git-clone follow the "argument convention" of
git-pack-objects, where the option --progress is used to force
reporting of reporting. This was previously done with -v/--verbose.
This in effect ensures a single consistent convention regarding
progress reporting for git commands. Having two conventions may
potentially confuse users.
On a related note, Brent wrote a patch a while back [1]. This series is
not as ambitious his and does not deal with the main git options. In
fact, only the last patch effects the titular change. If a consensus is
reached on this though, I don't rule out a separate patch/series to
set the convention at the main git level.
PS. If someone can enlighten me on the proper noun for the git
executable (I said "main git"), I would be very thankful.
PPS. Merry Christmas and happy holidays. :)
Tay Ray Chuan (4):
check stderr with isatty() instead of stdout when deciding to show
progress
git-clone.txt: reword description of progress behaviour
clone: set transport->verbose when -v/--verbose is used
clone: use --progress to force progress reporting
Documentation/git-clone.txt | 12 +++++++++---
builtin-clone.c | 6 ++++++
t/t5702-clone-options.sh | 3 ++-
transport-helper.c | 2 +-
transport.c | 2 +-
transport.h | 2 +-
6 files changed, 20 insertions(+), 7 deletions(-)
Footnotes:
[1] http://marc.info/?l=git&m=123415527432713
--
Cheers,
Ray Chuan
^ permalink raw reply
* [PATCH 1/4] check stderr with isatty() instead of stdout when deciding to show progress
From: Tay Ray Chuan @ 2009-12-25 17:12 UTC (permalink / raw)
To: git; +Cc: Miklos Vajna, Nicolas Pitre, Johannes Schindelin, Junio C Hamano
In-Reply-To: <1261761126-5784-1-git-send-email-rctay89@gmail.com>
Make transport code (viz. transport.c::fetch_refs_via_pack() and
transport-helper.c::standard_options()) that decides to show progress
check if stderr is a terminal, instead of stdout. After all, progress
reports (via the API in progress.[ch]) are sent to stderr.
Update the documentation for git-clone to say "standard error" as well.
Signed-off-by: Tay Ray Chuan <rctay89@gmail.com>
---
Documentation/git-clone.txt | 2 +-
transport-helper.c | 2 +-
transport.c | 2 +-
transport.h | 2 +-
4 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/Documentation/git-clone.txt b/Documentation/git-clone.txt
index 7ccd742..f298fdd 100644
--- a/Documentation/git-clone.txt
+++ b/Documentation/git-clone.txt
@@ -101,7 +101,7 @@ objects from the source repository into a pack in the cloned repository.
--verbose::
-v::
- Display the progress bar, even in case the standard output is not
+ Display the progress bar, even in case the standard error is not
a terminal.
--no-checkout::
diff --git a/transport-helper.c b/transport-helper.c
index 11f3d7e..b886985 100644
--- a/transport-helper.c
+++ b/transport-helper.c
@@ -169,7 +169,7 @@ static void standard_options(struct transport *t)
char buf[16];
int n;
int v = t->verbose;
- int no_progress = v < 0 || (!t->progress && !isatty(1));
+ int no_progress = v < 0 || (!t->progress && !isatty(2));
set_helper_option(t, "progress", !no_progress ? "true" : "false");
diff --git a/transport.c b/transport.c
index 3eea836..24c7f1d 100644
--- a/transport.c
+++ b/transport.c
@@ -476,7 +476,7 @@ static int fetch_refs_via_pack(struct transport *transport,
args.include_tag = data->followtags;
args.verbose = (transport->verbose > 0);
args.quiet = (transport->verbose < 0);
- args.no_progress = args.quiet || (!transport->progress && !isatty(1));
+ args.no_progress = args.quiet || (!transport->progress && !isatty(2));
args.depth = data->depth;
for (i = 0; i < nr_heads; i++)
diff --git a/transport.h b/transport.h
index 9e74406..68fda6a 100644
--- a/transport.h
+++ b/transport.h
@@ -63,7 +63,7 @@ struct transport {
int (*disconnect)(struct transport *connection);
char *pack_lockfile;
signed verbose : 3;
- /* Force progress even if the output is not a tty */
+ /* Force progress even if stderr is not a tty */
unsigned progress : 1;
};
--
1.6.6.278.g3f5f
^ permalink raw reply related
* [PATCH 2/4] git-clone.txt: reword description of progress behaviour
From: Tay Ray Chuan @ 2009-12-25 17:12 UTC (permalink / raw)
To: git; +Cc: Miklos Vajna, Nicolas Pitre, Johannes Schindelin, Junio C Hamano
In-Reply-To: <1261761126-5784-2-git-send-email-rctay89@gmail.com>
Mention progress reporting behaviour in the descriptions for -q/
--quiet and -v/--verbose options, in the style of git-pack-objects.txt.
Signed-off-by: Tay Ray Chuan <rctay89@gmail.com>
---
Documentation/git-clone.txt | 9 ++++++---
1 files changed, 6 insertions(+), 3 deletions(-)
diff --git a/Documentation/git-clone.txt b/Documentation/git-clone.txt
index f298fdd..e722e6c 100644
--- a/Documentation/git-clone.txt
+++ b/Documentation/git-clone.txt
@@ -96,13 +96,16 @@ objects from the source repository into a pack in the cloned repository.
--quiet::
-q::
- Operate quietly. This flag is also passed to the `rsync'
+ Operate quietly. Progress is not reported to the standard
+ error stream. This flag is also passed to the `rsync'
command when given.
--verbose::
-v::
- Display the progress bar, even in case the standard error is not
- a terminal.
+ Progress status is reported on the standard error stream
+ by default when it is attached to a terminal, unless -q
+ is specified. This flag forces progress status even if the
+ standard error stream is not directed to a terminal.
--no-checkout::
-n::
--
1.6.6.278.g3f5f
^ permalink raw reply related
* [PATCH 3/4] clone: set transport->verbose when -v/--verbose is used
From: Tay Ray Chuan @ 2009-12-25 17:12 UTC (permalink / raw)
To: git; +Cc: Miklos Vajna, Nicolas Pitre, Johannes Schindelin, Junio C Hamano
In-Reply-To: <1261761126-5784-3-git-send-email-rctay89@gmail.com>
Signed-off-by: Tay Ray Chuan <rctay89@gmail.com>
---
builtin-clone.c | 4 +++-
1 files changed, 3 insertions(+), 1 deletions(-)
diff --git a/builtin-clone.c b/builtin-clone.c
index 5df8b0f..463fbe4 100644
--- a/builtin-clone.c
+++ b/builtin-clone.c
@@ -525,8 +525,10 @@ int cmd_clone(int argc, const char **argv, const char *prefix)
if (option_quiet)
transport->verbose = -1;
- else if (option_verbose)
+ else if (option_verbose) {
+ transport->verbose = 1;
transport->progress = 1;
+ }
if (option_upload_pack)
transport_set_option(transport, TRANS_OPT_UPLOADPACK,
--
1.6.6.278.g3f5f
^ permalink raw reply related
* [PATCH 4/4] clone: use --progress to force progress reporting
From: Tay Ray Chuan @ 2009-12-25 17:12 UTC (permalink / raw)
To: git; +Cc: Miklos Vajna, Nicolas Pitre, Johannes Schindelin, Junio C Hamano
In-Reply-To: <1261761126-5784-4-git-send-email-rctay89@gmail.com>
Follow the argument convention of git-pack-objects, such that a
separate option (--preogress) is used to force progress reporting
instead of -v/--verbose.
-v/--verbose now does not force progress reporting. Make git-clone.txt
say so.
This should cover all the bases in 21188b1 (Implement git clone -v),
which implemented the option to force progress reporting.
Signed-off-by: Tay Ray Chuan <rctay89@gmail.com>
---
Documentation/git-clone.txt | 3 +++
builtin-clone.c | 8 ++++++--
t/t5702-clone-options.sh | 3 ++-
3 files changed, 11 insertions(+), 3 deletions(-)
diff --git a/Documentation/git-clone.txt b/Documentation/git-clone.txt
index e722e6c..f43c8b2 100644
--- a/Documentation/git-clone.txt
+++ b/Documentation/git-clone.txt
@@ -102,6 +102,9 @@ objects from the source repository into a pack in the cloned repository.
--verbose::
-v::
+ Run verbosely.
+
+--progress::
Progress status is reported on the standard error stream
by default when it is attached to a terminal, unless -q
is specified. This flag forces progress status even if the
diff --git a/builtin-clone.c b/builtin-clone.c
index 463fbe4..58bacbd 100644
--- a/builtin-clone.c
+++ b/builtin-clone.c
@@ -44,10 +44,13 @@ static char *option_origin = NULL;
static char *option_branch = NULL;
static char *option_upload_pack = "git-upload-pack";
static int option_verbose;
+static int option_progress;
static struct option builtin_clone_options[] = {
OPT__QUIET(&option_quiet),
OPT__VERBOSE(&option_verbose),
+ OPT_BOOLEAN(0, "progress", &option_progress,
+ "force progress reporting"),
OPT_BOOLEAN('n', "no-checkout", &option_no_checkout,
"don't create a checkout"),
OPT_BOOLEAN(0, "bare", &option_bare, "create a bare repository"),
@@ -525,10 +528,11 @@ int cmd_clone(int argc, const char **argv, const char *prefix)
if (option_quiet)
transport->verbose = -1;
- else if (option_verbose) {
+ else if (option_verbose)
transport->verbose = 1;
+
+ if (option_progress)
transport->progress = 1;
- }
if (option_upload_pack)
transport_set_option(transport, TRANS_OPT_UPLOADPACK,
diff --git a/t/t5702-clone-options.sh b/t/t5702-clone-options.sh
index 27825f5..02cb024 100755
--- a/t/t5702-clone-options.sh
+++ b/t/t5702-clone-options.sh
@@ -27,7 +27,8 @@ test_expect_success 'redirected clone' '
'
test_expect_success 'redirected clone -v' '
- git clone -v "file://$(pwd)/parent" clone-redirected-v >out 2>err &&
+ git clone --progress "file://$(pwd)/parent" clone-redirected-progress \
+ >out 2>err &&
test -s err
'
--
1.6.6.278.g3f5f
^ permalink raw reply related
* Re: [RFC PATCH 1/2] Report exec errors from run-command
From: Ilari Liusvaara @ 2009-12-25 17:15 UTC (permalink / raw)
To: Johannes Sixt; +Cc: git
In-Reply-To: <200912251539.35201.j6t@kdbg.org>
On Fri, Dec 25, 2009 at 03:39:34PM +0100, Johannes Sixt wrote:
>
> The only really *important* errno of a failed exec is ENOENT. For this case,
> wouldn't it be easier to do the PATH lookup manually in the parent (before
> the fork()), and use execv() in the forked child rather than execvp()?
In fact there is API for getting all valid commands on $PATH for given command
prefix. That would take care of ENOENT and most of EACCESS.
But OTOH, its nice to be able to report any error.
-Ilari
^ permalink raw reply
* Set the repository as it was on an earlier commit
From: Sergio Belkin @ 2009-12-25 23:09 UTC (permalink / raw)
To: git
Hi,
Firstly merry Christmas everyone.
I am somewhat new to git, and I've found great, but still I have some
doubts about it, let's say I have the following repo with:
A---B---C---D
Being A the first commit, B the second one an D the last one.
How I do to go back to let's say... B commit status, I mean somewhat as follows:
A---B---C---D---B'
B' would be the same as B. I am not asking to do something so:
A---B---C---D to A---B losing C and D commits,
I'd like to keep on history C and D commits, can git to do that?
Thanks in advance!
--
--
Open Kairos http://www.sergiobelkin.com
Watch More TV http://sebelk.blogspot.com
Sergio Belkin -
^ permalink raw reply
* Re: Set the repository as it was on an earlier commit
From: Steven Noonan @ 2009-12-25 23:24 UTC (permalink / raw)
To: Sergio Belkin; +Cc: git
In-Reply-To: <8c6f7f450912251509i67da4665t78be0bb79f2c40d6@mail.gmail.com>
On Fri, Dec 25, 2009 at 3:09 PM, Sergio Belkin <sebelk@gmail.com> wrote:
> Hi,
>
> Firstly merry Christmas everyone.
>
> I am somewhat new to git, and I've found great, but still I have some
> doubts about it, let's say I have the following repo with:
>
> A---B---C---D
>
> Being A the first commit, B the second one an D the last one.
>
> How I do to go back to let's say... B commit status, I mean somewhat as follows:
>
> A---B---C---D---B'
>
> B' would be the same as B. I am not asking to do something so:
>
> A---B---C---D to A---B losing C and D commits,
>
> I'd like to keep on history C and D commits, can git to do that?
>
> Thanks in advance!
>
git revert D
git revert C
Maybe? It would create two revert commits, but it would get you back
to the state of B.
- Steven
^ permalink raw reply
* Re: Set the repository as it was on an earlier commit
From: Santi Béjar @ 2009-12-25 23:36 UTC (permalink / raw)
To: Sergio Belkin; +Cc: git
In-Reply-To: <8c6f7f450912251509i67da4665t78be0bb79f2c40d6@mail.gmail.com>
On Sat, Dec 26, 2009 at 12:09 AM, Sergio Belkin <sebelk@gmail.com> wrote:
> Hi,
>
> Firstly merry Christmas everyone.
>
> I am somewhat new to git, and I've found great, but still I have some
> doubts about it, let's say I have the following repo with:
>
> A---B---C---D
>
> Being A the first commit, B the second one an D the last one.
>
> How I do to go back to let's say... B commit status, I mean somewhat as follows:
>
> A---B---C---D---B'
>
> B' would be the same as B. I am not asking to do something so:
>
> A---B---C---D to A---B losing C and D commits,
>
> I'd like to keep on history C and D commits, can git to do that?
I don't know if it is possible with porcelain commands, but with
plumbing you can:
# begin with a clean working dir
git read-tree B
git commit
git reset --hard
HTH,
Santi
^ permalink raw reply
* Re: Branch shuffling after 1.6.6 release plans
From: Jeff King @ 2009-12-26 8:01 UTC (permalink / raw)
To: Thomas Rast; +Cc: Junio C Hamano, git
In-Reply-To: <200912251230.48243.trast@student.ethz.ch>
On Fri, Dec 25, 2009 at 12:30:34PM +0100, Thomas Rast wrote:
> > * tr/reset-checkout-patch (2009-11-19) 1 commit
> > - {checkout,reset} -p: make patch direction configurable
> >
> > I do not particularly like a configuration like this that changes the
> > behaviour of a command in a drastic way---it will make helping others
> > much harder.
>
> I think it's not quite as drastic as you make it sound ;-)
>
> But I don't need this feature, and Peff mentioned something about
> being happy except for the patch editing mode. Unfortunately the
> above pretty much hits the limits of add--interactive's flexibility,
> so an interactive direction toggling feature would need some rewiring.
Let's drop it for now. I'm reasonably happy, and I don't want to waste
your time trying to do something more invasive. And I haven't seen any
evidence that anybody else is dissatisfied with what's in master.
-Peff
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox