* Re: Disappearing change on pull rebase
From: Philippe Vaucher @ 2011-11-11 10:08 UTC (permalink / raw)
To: Johannes Sixt; +Cc: Pitucha, Stanislaw Izaak, git@vger.kernel.org
In-Reply-To: <4EBCF34A.3090908@viscovery.net>
>> Doesn't this create a problem if you pull, resolve a conflit but do NOT
>> push, then pull --rebase some more commits later on? As I understand
>> it, the conflict resolution commit will be a merge commit and will be
>> thrown away by the git pull --rebase.
>
> You are correct, but it is not a problem: During the rebase, the same
> conflicts will arise as during the merge, and you will be forced to
> resolve them before you can complete the rebase. Therefore, nothing will
> be lost.
Doing the same conflict resolution twice is kinda irritating... but
ok, fair enough.
I guess when you resolve a conflict you're supposed to push to avoid this :)
Philippe
^ permalink raw reply
* Re: [RFC/PATCH] i18n: add infrastructure for translating Git with gettext
From: Jakub Narebski @ 2011-11-11 10:27 UTC (permalink / raw)
To: Ævar Arnfjörð Bjarmason; +Cc: git
In-Reply-To: <1320970164-31694-2-git-send-email-avarab@gmail.com>
Ævar Arnfjörð Bjarmason <avarab@gmail.com> writes:
> = Perl
>
> Perl code that wants to be localized should use the new Git::I18n
> module. It imports a __ function into the caller's package by
> default.
>
> Instead of using the high level Locale::TextDomain interface I've
> opted to use the low-level (equivalent to the C interface)
> Locale::Messages module, which Locale::TextDomain itself uses.
Nice of you using libintl-perl instead of old Locale::MakeText
(with gettext compatibility layer).
> See <AANLkTilYD_NyIZMyj9dHtVk-ylVBfvyxpCC7982LWnVd@mail.gmail.com> for
> a further elaboration on this topic.
http://thread.gmane.org/gmane.comp.version-control.git/148446/focus=148478
> = Shell
>
> Shell code that's to be localized should use the git-sh-i18n
> library. It's basically just a wrapper for the system's gettext.sh.
>
> If gettext.sh isn't available we'll fall back on gettext(1) if it's
> available. The latter is available without the former on Solaris,
> which has its own non-GNU gettext implementation. We also need to
> emulate eval_gettext() there.
>
> If neither are present we'll use a dumb printf(1) fall-through
> wrapper.
>
> I originally tried to detect if the system supported `echo -n' but
> I found this to be a waste of time. My benchmarks on Linux, Solaris
> and FreeBSD reveal that printf(1) is fast enough, especially since
> we aren't calling gettext() from within any tight loops, and
> unlikely to ever do so.
Didn't we decide that the only sane way to handle eval_gettext
is to provide minimal implemetation in the form of external command?
Thanks for working on this.
--
Jakub Narębski
^ permalink raw reply
* Re: [RFC/PATCH] i18n: add infrastructure for translating Git with gettext
From: Ævar Arnfjörð Bjarmason @ 2011-11-11 10:34 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git
In-Reply-To: <m31utfnedi.fsf@localhost.localdomain>
On Fri, Nov 11, 2011 at 11:27, Jakub Narebski <jnareb@gmail.com> wrote:
>> I originally tried to detect if the system supported `echo -n' but
>> I found this to be a waste of time. My benchmarks on Linux, Solaris
>> and FreeBSD reveal that printf(1) is fast enough, especially since
>> we aren't calling gettext() from within any tight loops, and
>> unlikely to ever do so.
>
> Didn't we decide that the only sane way to handle eval_gettext
> is to provide minimal implemetation in the form of external command?
This comment is a bit out of date and probably shouldn't be in the
commit message. But it doesn't have to do with eval_gettext. I mean at
one point I tried to change the fall-through wrapper from:
gettext () {
printf "%s" "$1"
}
to:
gettext () {
echo -n $1
}
But found it to bee too troublesome with various echo implementations
and just not worth it for the complexity.
But yeah, for eval_gettext() we need an external program, which we
already have in git.git as git-sh-i18n--envsubst.
^ permalink raw reply
* Re: [RFC/PATCH] remote: add new sync command
From: Jakub Narebski @ 2011-11-11 10:35 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Felipe Contreras, Jeff King, git
In-Reply-To: <7vobwmvuei.fsf@alter.siamese.dyndns.org>
Junio C Hamano <gitster@pobox.com> writes:
> Felipe Contreras <felipe.contreras@gmail.com> writes:
>
> > Perhaps these 'git remote' commands should be removed in 1.8 then.
>
> It is true that it was a long-term goal to deprecate many parts of the
> "git remote" script that started as a hack to scratch itches "git fetch"
> in the older days did not directly scratch for people, e.g. fetching from
> multiple remotes in one go.
>
> I do not think 1.7.X series to 1.8 is a big enough jump to remove
> duplicated features, though.
I am using "git remote update" to fetch a _subset_ of remotes;
does "git fetch" offers such feature already?
--
Jakub Narębski
^ permalink raw reply
* Re: [RFC/PATCH] remote: add new sync command
From: Felipe Contreras @ 2011-11-11 12:30 UTC (permalink / raw)
To: Jeff King; +Cc: git
In-Reply-To: <20111108181442.GA17317@sigill.intra.peff.net>
On Tue, Nov 8, 2011 at 8:14 PM, Jeff King <peff@peff.net> wrote:
> On Tue, Nov 08, 2011 at 07:31:09PM +0200, Felipe Contreras wrote:
>
>> > 1. git push --prune <remote> :
>> >
>> > I.e., use the "matching" refspec to not push new things, but turn
>> > on pruning.
>>
>> I guess so, but ":" seems a bit obscure.
>
> Yeah, it is. It's also the default, so you could just do:
>
> git push --prune <remote>
That would work only if not configured otherwise; remote.<foo>.push,
push.default
> Although some people have argued for changing the default in future
> versions. I don't know what the status of that is.
IMO the default doesn't matter, it should be easy for everyone.
>> > 2. git push <remote> refs/heads/*
>> >
>> > Turn off pruning, but use an explicit refspec, not just "matching",
>> > which will push all local branches.
>>
>> Isn't refs/heads/* the same as --all? BTW. I think --all is confusing,
>> should be --branches, or something.
>
> Doesn't --all mean all refs, including tags and branches?
Nope, only branches, try it. I also found it strange. And what is
more, you can't use --all and --tags at the same time. Totally
strange.
Also, --all doesn't push other refs (say refs/foobar/test)
I think this area has been neglected.
> I thought that was the thing you were avoiding.
--all + --tags is not the same as --mirror (refs/foobar/* is pushed
only by --mirror).
And yes, in this particular use-case that's what I am trying to avoid,
but in other use-cases (like creating a new repo and pushing
*everything*), a *true* --all would be nice.
> We could add syntactic sugar to make
> --branches mean "refs/heads/*". But I do worry that pseudo-options like
> that just end up creating more confusion (I seem to recall there being a
> lot of confusion about "--tags", which is more or less the same thing).
But it's not, that could explain part of the confusion. I think these
would be totally intuitive.
--branches
--tags
--other
--all
--update
--prune
But what about 'git fetch'? You didn't comment anything. I think we
should try to be consistent in these imaginary future options, maybe
to devise a transition, or at least to identify good names for the new
options.
Cheers.
--
Felipe Contreras
^ permalink raw reply
* Re: Thoughts on gitk's memory footprint over linux-2.6.git
From: Felipe Contreras @ 2011-11-11 12:44 UTC (permalink / raw)
To: Martin Langhoff; +Cc: Git Mailing List
In-Reply-To: <CACPiFC+T1EZ1CSakQxsYZhsnHc-ZsN1-=tpoi-NaQSdpU5Yxkg@mail.gmail.com>
On Mon, Sep 26, 2011 at 10:38 PM, Martin Langhoff
<martin.langhoff@gmail.com> wrote:
> However, I find it extremely annoying over the kernel tree, due to its
> memory footprint. It is not the only thing I am running, (Chrome
> Browser, Gnome3, Firefox, many gnome Terminal windows, emacs), and
> given that I am looking at "just a couple of commits" I don't feel
> opening a few gitk instances should be problematic... except that it
> is.
Sometimes I do this:
% gitk master..branch_1 master..branch_2 ...
But as I visualize more branches, it becomes tedious.
It would be nice to have --base option, and show only the commits
<base>..<branch>.
Cheers.
--
Felipe Contreras
^ permalink raw reply
* feature request: git annotate -w like git blame -w
From: Raoul Bhatia [IPAX] @ 2011-11-11 13:02 UTC (permalink / raw)
To: git
hi!
is it possible to add a "git annotate -w" option like git blame has?
thanks,
raoul
ps. please reply to me in cc as i'm not subscribed to this list.
--
____________________________________________________________________
DI (FH) Raoul Bhatia M.Sc. email. r.bhatia@ipax.at
Technischer Leiter
IPAX - Aloy Bhatia Hava OG web. http://www.ipax.at
Barawitzkagasse 10/2/2/11 email. office@ipax.at
1190 Wien tel. +43 1 3670030
FN 277995t HG Wien fax. +43 1 3670030 15
____________________________________________________________________
^ permalink raw reply
* Re: [PATCH 0/14] resumable network bundles
From: David Michael Barr @ 2011-11-11 13:13 UTC (permalink / raw)
To: Jeff King; +Cc: git
In-Reply-To: <20111110074330.GA27925@sigill.intra.peff.net>
On Thu, Nov 10, 2011 at 6:43 PM, Jeff King <peff@peff.net> wrote:
> One possible option for resumable clones that has been discussed is
> letting the server point the client by http to a static bundle
> containing most of history, followed by a fetch from the actual git repo
> (which should be much cheaper now that we have all of the bundled
> history). This series implements "step 0" of this plan: just letting
> bundles be fetched across the network in the first place.
>
> Shawn raised some issues about using bundles for this (as opposed to
> accessing the packfiles themselves); specifically, this raises the I/O
> footprint of a repository that has to serve both the bundled version of
> the pack and the regular packfile.
>
> So it may be that we don't follow this plan all the way through.
> However, even if we don't, fetching bundles over http is still a useful
> thing to be able to do. Which makes this first step worth doing either
> way.
>
> [01/14]: t/lib-httpd: check for NO_CURL
> [02/14]: http: turn off curl signals
> [03/14]: http: refactor http_request function
> [04/14]: http: add a public function for arbitrary-callback request
> [05/14]: remote-curl: use http callback for requesting refs
> [06/14]: transport: factor out bundle to ref list conversion
> [07/14]: bundle: add is_bundle_buf helper
> [08/14]: remote-curl: free "discovery" object
> [09/14]: remote-curl: auto-detect bundles when fetching refs
> [10/14]: remote-curl: try base $URL after $URL/info/refs
> [11/14]: progress: allow pure-throughput progress meters
> [12/14]: remote-curl: show progress for bundle downloads
> [13/14]: remote-curl: resume interrupted bundle transfers
> [14/14]: clone: give advice on how to resume a failed clone
>
> -Peff
> --
> 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
>
I just want to say thank you for doing this.--David Barr
^ permalink raw reply
* Re: feature request: git annotate -w like git blame -w
From: Jakub Narebski @ 2011-11-11 13:57 UTC (permalink / raw)
To: Raoul Bhatia [IPAX]; +Cc: git
In-Reply-To: <4EBD1CF4.7040002@ipax.at>
"Raoul Bhatia [IPAX]" <r.bhatia@ipax.at> writes:
> is it possible to add a "git annotate -w" option like git blame has?
Why not use "git blame -c -w"? `-c' turns on annotate-compatibile
output.
From git-annotate(1) manpage:
The only difference between this command and git-blame(1) is that they use
slightly different output formats, and this command exists only for back-
ward compatibility to support existing scripts, and provide a more familiar
command name for people coming from other SCM systems.
> ps. please reply to me in cc as i'm not subscribed to this list.
This is usual behavior on this list.
--
Jakub Narębski
^ permalink raw reply
* Re: reset reports file as modified when it's in fact deleted
From: Carlos Martín Nieto @ 2011-11-11 14:08 UTC (permalink / raw)
To: Jeff King; +Cc: git
In-Reply-To: <20111107162642.GA27055@sigill.intra.peff.net>
[-- Attachment #1: Type: text/plain, Size: 5184 bytes --]
On Mon, Nov 07, 2011 at 11:26:42AM -0500, Jeff King wrote:
> On Mon, Nov 07, 2011 at 10:43:30AM +0100, Carlos Martín Nieto wrote:
>
> > When I delete a file (git rm) and then reset so it exists in the index
> > again, the message tells me 'M file.txt' even though the file doesn't
> > exist in the worktree anymore. Running git status afterwards does give
> > the correct output. So, here's the minimal steps to reproduce:
> >
> > $ git init
> > Initialized empty Git repository in /home/carlos/test/reset-err/.git/
> > $ touch file.txt
> > $ git add file.txt
> > $ git ci file.txt -m initial
> > [master (root-commit) a536393] initial
> > 0 files changed, 0 insertions(+), 0 deletions(-)
> > create mode 100644 file.txt
> > $ git rm file.txt
> > rm 'file.txt'
> > $ git reset -- file.txt
> > Unstaged changes after reset:
> > M file.txt
> > $ git status -b -s
> > ## master
> > D file.txt
>
> You can simplify this even further by not touching the index at all:
>
> git init -q &&
> >file && git add file && git commit -q -m initial &&
> rm file &&
> git reset
>
> produces:
>
> Unstaged changes after reset:
> M file
Ah, I see. I got the previous sequence because that's what we have in
an instruction manual and where we saw it.
>
> > I'd expect the output after "Unstaged changes after reset" to tell me
> > file.txt has been deleted instead of modified. This happens with
> > 1.7.8-rc0, 1.7.7 and 1.7.4.1 and I expect with many more that I don't
> > have here.
> >
> > I thought the index diff code might have been checking the index at the
> > wrong time, but I can run 'git reset HEAD -- file.txt' as many times
> > as I want, and it will still say 'M', so now I'm not sure.
>
> The index diff code isn't running at all. Those messages are produced by
> refresh_index, which outputs only two flags: modified or unmerged. I
> think the reason for this is somewhat historical. You would run
> "update-index --refresh", and it would helpfully say "by the way, when
> refreshing this entry, I noticed that it is in need of being updated in
> the index". The text was "file.txt: needs update".
>
> Later, many porcelain commands started to refresh the index themselves,
> and the "needs update" message was very confusing. So it was switched to
> the more familiar "M file.txt" (though you can still see the original
> plumbing message if you run update-index yourself).
>
> I think it is a little more friendly to distinguish deletion from just
> modification. And there's shouldn't be any compatibility questions, as
> these are explicitly porcelain output (plumbing will still say "needs
> update").
>
> There are a few other cases users might expect to see. We'll never show
> copies or renames, of course, because we aren't actually doing a diff
> with copy detection. We won't see an "A"dded file, because such a file
> would be in the working tree but not the index, meaning it is not
> tracked.
>
> We could see a "T"ypechange, but the distinction between that and a
> modified file is lost by the time we get to refresh_index. We could pass
> it up, but I wonder if it's really worth it.
That's probably overkill. The issue with reporting 'M' for a deleted
file is that it conflicts with what the status output would say, even
though it's in the same format.
>
> The patch to do "D"eleted is pretty simple:
>
> diff --git a/read-cache.c b/read-cache.c
> index dea7cd8..cc1ebdf 100644
> --- a/read-cache.c
> +++ b/read-cache.c
> @@ -1103,9 +1103,11 @@ int refresh_index(struct index_state *istate, unsigned int flags, const char **p
> int in_porcelain = (flags & REFRESH_IN_PORCELAIN);
> unsigned int options = really ? CE_MATCH_IGNORE_VALID : 0;
> const char *needs_update_fmt;
> + const char *needs_rm_fmt;
> const char *needs_merge_fmt;
>
> needs_update_fmt = (in_porcelain ? "M\t%s\n" : "%s: needs update\n");
> + needs_rm_fmt = (in_porcelain ? "D\t%s\n" : "%s: needs update\n");
> needs_merge_fmt = (in_porcelain ? "U\t%s\n" : "%s: needs merge\n");
While the name fits in with the rest of the variables, it's kind of
the wrong way around, isn't it? It doesn't need an 'rm', it /was/
rm'd. Other than that stupid thing, the patch works great, thanks. Can
we get it into git?
> for (i = 0; i < istate->cache_nr; i++) {
> struct cache_entry *ce, *new;
> @@ -1145,7 +1147,10 @@ int refresh_index(struct index_state *istate, unsigned int flags, const char **p
> }
> if (quiet)
> continue;
> - show_file(needs_update_fmt, ce->name, in_porcelain, &first, header_msg);
> + if (cache_errno == ENOENT)
> + show_file(needs_rm_fmt, ce->name, in_porcelain, &first, header_msg);
> + else
> + show_file(needs_update_fmt, ce->name, in_porcelain, &first, header_msg);
> has_errors = 1;
> continue;
> }
> --
> 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
>
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 490 bytes --]
^ permalink raw reply
* Re: Thoughts on gitk's memory footprint over linux-2.6.git
From: Johannes Sixt @ 2011-11-11 14:19 UTC (permalink / raw)
To: Felipe Contreras; +Cc: Martin Langhoff, Git Mailing List
In-Reply-To: <CAMP44s1cZc5OZ0L0zG-Wu+QVpu7xv4-JtWTBtPvnjO7sUFeM9w@mail.gmail.com>
Am 11/11/2011 13:44, schrieb Felipe Contreras:
> On Mon, Sep 26, 2011 at 10:38 PM, Martin Langhoff
> <martin.langhoff@gmail.com> wrote:
>> However, I find it extremely annoying over the kernel tree, due to its
>> memory footprint. It is not the only thing I am running, (Chrome
>> Browser, Gnome3, Firefox, many gnome Terminal windows, emacs), and
>> given that I am looking at "just a couple of commits" I don't feel
>> opening a few gitk instances should be problematic... except that it
>> is.
>
> Sometimes I do this:
> % gitk master..branch_1 master..branch_2 ...
>
> But as I visualize more branches, it becomes tedious.
>
> It would be nice to have --base option, and show only the commits
> <base>..<branch>.
What's wrong with
gitk master..branch_1 branch_2 branch_3 branch_4 branch_5
or
gitk --branches --not master
? (I do that all the time.) Recall that 'master..branch_1' is short for
'^master branch_1'. It is sufficient to specify the negative ref, ^master,
only once.
-- Hannes
^ permalink raw reply
* Re: Thoughts on gitk's memory footprint over linux-2.6.git
From: Felipe Contreras @ 2011-11-11 16:04 UTC (permalink / raw)
To: Johannes Sixt; +Cc: Martin Langhoff, Git Mailing List
In-Reply-To: <4EBD2EFF.1010000@viscovery.net>
On Fri, Nov 11, 2011 at 4:19 PM, Johannes Sixt <j.sixt@viscovery.net> wrote:
> Am 11/11/2011 13:44, schrieb Felipe Contreras:
>> It would be nice to have --base option, and show only the commits
>> <base>..<branch>.
>
> What's wrong with
>
> gitk master..branch_1 branch_2 branch_3 branch_4 branch_5
> or
> gitk --branches --not master
>
> ? (I do that all the time.) Recall that 'master..branch_1' is short for
> '^master branch_1'. It is sufficient to specify the negative ref, ^master,
> only once.
Ah, nice! Thanks a lot :)
--
Felipe Contreras
^ permalink raw reply
* Re: Disappearing change on pull rebase
From: Junio C Hamano @ 2011-11-11 16:31 UTC (permalink / raw)
To: Johannes Sixt; +Cc: Pitucha, Stanislaw Izaak, git@vger.kernel.org
In-Reply-To: <4EBCC71D.6000505@viscovery.net>
Johannes Sixt <j.sixt@viscovery.net> writes:
> Am 11/10/2011 14:35, schrieb Pitucha, Stanislaw Izaak:
>> As mentioned in the original mail - the merge commit did have changes.
>> Here's the log of reproducing it. The line containing "2" in changelog
>> is gone from master after pull --rebase.
>> ...
>> disappearing_commit$ git merge --no-ff --no-commit some-branch
>> Automatic merge went well; stopped before committing as requested
>> disappearing_commit$ echo 2 >> changelog
>> disappearing_commit$ git add changelog
>> disappearing_commit$ git commit
>> [master e41e4c9] Merge branch 'some-branch'
>
> This is by design. Rebase does not rebase merge commits because it is
> assumed that merge commits only do what their name implies - to merge
> branches of a forked history. As such, they do not introduce their own
> changes. Follow this rule, i.e., make your change in a separate non-merge
> commit, and you are fine.
While that may be technically correct, I wonder if we can be a bit more
helpful to the users in such a case (upfront I admit that I have a strong
suspicion that this is a hard problem in general). One typical use of
"rebase" is to linearize a history that has unfortunate merges that did
not have to be there, so refusing "git rebase A..B" when there is a merge
in "git rev-list --merges A..B" is not a solution. But would it help if we
warned about the merges when we find that there is something _interesting_
going on in them, e.g. an evil merge that adds material that did not exist
in any of the parents [*1*]? The warning message may diagnose "you asked
me to linearize the history by picking commits on the non-merge segments
and replaying them, but there may be changes made in this merge commit,
and it does this interesting thing: $(git show -c $that_merge_commit)" and
may further suggest "if you do not want to linearize but just transplant
the history, perhaps you want to run the command with the '-m' option?".
[Footnote]
*1* This is a hard problem and not just the matter of looking at "show -c"
output. A "-s ours" merge would appear empty in "show -c" but it _is_ an
interesting event that makes the result of linearizing non-merge segments
vastly different from the original. Also material that did not exist in
any of the parents is not necessarily evil (e.g. the side branch may have
added one parameter to a function and updated its call sites, while our
branch may have added a different parameter to the same function. The
update to the call sites in the merge result should pass two more parameters
from the common ancestor, and different from either of the parents).
^ permalink raw reply
* Re: [RFC/PATCH] remote: add new sync command
From: Junio C Hamano @ 2011-11-11 16:38 UTC (permalink / raw)
To: Jakub Narebski; +Cc: Felipe Contreras, Jeff King, git
In-Reply-To: <m3wrb7lzg8.fsf@localhost.localdomain>
Jakub Narebski <jnareb@gmail.com> writes:
> Junio C Hamano <gitster@pobox.com> writes:
>> Felipe Contreras <felipe.contreras@gmail.com> writes:
>>
>> > Perhaps these 'git remote' commands should be removed in 1.8 then.
>>
>> It is true that it was a long-term goal to deprecate many parts of the
>> "git remote" script that started as a hack to scratch itches "git fetch"
>> in the older days did not directly scratch for people, e.g. fetching from
>> multiple remotes in one go.
>>
>> I do not think 1.7.X series to 1.8 is a big enough jump to remove
>> duplicated features, though.
>
> I am using "git remote update" to fetch a _subset_ of remotes;
> does "git fetch" offers such feature already?
Heh, look at builtin/remote.c::update() and report what you see. It just
calls into "git fetch" and let the command fetch either from a single
repository or from a remote group. "git remote update" is not even aware
of the remote groups; the expansion is done by "git fetch".
Whoever added "multiple repositories" feature to "git fetch" in order to
support "remote update <group>" apparently under-documented it.
^ permalink raw reply
* Re: reset reports file as modified when it's in fact deleted
From: Junio C Hamano @ 2011-11-11 16:43 UTC (permalink / raw)
To: Carlos Martín Nieto; +Cc: Jeff King, git
In-Reply-To: <20111111140834.GA10025@beez.lab.cmartin.tk>
Carlos Martín Nieto <cmn@elego.de> writes:
> On Mon, Nov 07, 2011 at 11:26:42AM -0500, Jeff King wrote:
> ...
>> The patch to do "D"eleted is pretty simple:
>>
>> diff --git a/read-cache.c b/read-cache.c
>> index dea7cd8..cc1ebdf 100644
>> --- a/read-cache.c
>> +++ b/read-cache.c
>> @@ -1103,9 +1103,11 @@ int refresh_index(struct index_state *istate, unsigned int flags, const char **p
>> int in_porcelain = (flags & REFRESH_IN_PORCELAIN);
>> unsigned int options = really ? CE_MATCH_IGNORE_VALID : 0;
>> const char *needs_update_fmt;
>> + const char *needs_rm_fmt;
>> const char *needs_merge_fmt;
>>
>> needs_update_fmt = (in_porcelain ? "M\t%s\n" : "%s: needs update\n");
>> + needs_rm_fmt = (in_porcelain ? "D\t%s\n" : "%s: needs update\n");
>> needs_merge_fmt = (in_porcelain ? "U\t%s\n" : "%s: needs merge\n");
>
> While the name fits in with the rest of the variables, it's kind of
> the wrong way around, isn't it? It doesn't need an 'rm', it /was/
> rm'd.
The variable names were chosen to mean "In a situation where the plumbing
traditionally would have said X, use this format to describe it". This is
the first topic to separate a single situation (from the plumbing's point
of view) into two and say different things at Porcelain, and the variable
naming no longer works.
An obvious solution would be to rename all of them to be based on "what
happened to the path". E.g. "modified_fmt" would be set to either "M" or
"needs update", and "removed_fmt" would be set to either "D" or "needs
update", etc.
^ permalink raw reply
* Re: [RFC/PATCH] remote: add new sync command
From: Jeff King @ 2011-11-11 18:13 UTC (permalink / raw)
To: Felipe Contreras; +Cc: git
In-Reply-To: <CAMP44s2RjcFtdO2jft0Hg9RtqK-DRK47gX8By-dBFSBcSA+yFA@mail.gmail.com>
On Fri, Nov 11, 2011 at 02:30:48PM +0200, Felipe Contreras wrote:
> > Doesn't --all mean all refs, including tags and branches?
>
> Nope, only branches, try it. I also found it strange. And what is
> more, you can't use --all and --tags at the same time. Totally
> strange.
Yeah, you're right. Sorry for my confusion.
So in that sense, it is poorly named, and "--branches" (or "--heads")
would be more accurate. At the same time, it is probably more likely
what the user wants to do (you almost never want to push "refs/remotes",
for example). So I am a little hesitant to suggest changing it, even
with a warning and deprecation period.
> And yes, in this particular use-case that's what I am trying to avoid,
> but in other use-cases (like creating a new repo and pushing
> *everything*), a *true* --all would be nice.
Right. It looks like that is just spelled "--mirror" (which gives you
pruning also), or "refs/*:refs/*" (without pruning). The latter is even
more flexible, as you could do "refs/*:refs/foo/*" to keep several
related backups in one upstream repo.
Just to get back to the original patch for a second: are we in agreement
that what you want to do with "sync" is almost possible now (modulo a
separate --prune option), and that there is a separate issue of making
friendlier syntax for a few common refspecs?
> > We could add syntactic sugar to make
> > --branches mean "refs/heads/*". But I do worry that pseudo-options like
> > that just end up creating more confusion (I seem to recall there being a
> > lot of confusion about "--tags", which is more or less the same thing).
>
> But it's not, that could explain part of the confusion. I think these
> would be totally intuitive.
>
> --branches
> --tags
> --other
> --all
> --update
> --prune
My problem with them syntactically is that you have option-looking
things that are really not flags, but rather syntactic placeholders for
refspecs. So you have:
git push --prune remote --branches
which looks wrong from the perspective of usual option-parsing rules.
And does:
git push remote --prune --branches
work? Or:
git push --prune --branches remote
?
I think we could make them all work if we want. But somehow the syntaxes
just look wrong to me. Using a non-dashed placeholder for special
refspecs makes more sense to me like:
git push --prune remote BRANCHES
and then it really is just a special way of spelling "refs/heads/*". But
then, I also think it's good for users to understand that the options
are refspecs, and what that means. It's not a hard concept, and then
when they inevitably say "how can I do BRANCHES, except put the result
somewhere else in the remote namespace", it's a very natural extension
to learn about the right-hand side o the refspec.
Of course I also think BRANCHES looks ugly, and people should just learn
"refs/heads/*".
I dunno. Maybe my brain is fried from knowing too much about how git
works. I don't have much of an "ordinary user" perspective anymore.
> But what about 'git fetch'? You didn't comment anything. I think we
> should try to be consistent in these imaginary future options, maybe
> to devise a transition, or at least to identify good names for the new
> options.
Yeah, fetch makes it harder because the options may have subtly
different meanings. Using non-option placeholders would work around
that. You would still have options for pruning, which to me is not
really a refspec, but an option that acts on the refspecs.
>From the list in your previous email, you wrote:
> --prune -> rename to --prune-tracking?
> --prune-local (new; prune local branches that don't exist on the remote)
I think --prune wouldn't need renaming. If you fetch into tracking
branches, then pruning would prune tracking branches. If you fetch as a
mirror (refs/*:refs/*), then you would prune everything.
And "--prune-local" doesn't seem like a fetch operation to me. Either
you are mirroring, and --prune already handles it as above. Or you are
interested in getting rid of branches whose upstream has gone away. But
that's not a fetch operation; that's a branch operation.
-Peff
^ permalink raw reply
* Re: reset reports file as modified when it's in fact deleted
From: Jeff King @ 2011-11-11 18:21 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Carlos Martín Nieto, git
In-Reply-To: <7vr51er4nd.fsf@alter.siamese.dyndns.org>
On Fri, Nov 11, 2011 at 08:43:34AM -0800, Junio C Hamano wrote:
> Carlos Martín Nieto <cmn@elego.de> writes:
>
> > On Mon, Nov 07, 2011 at 11:26:42AM -0500, Jeff King wrote:
> > ...
> >> The patch to do "D"eleted is pretty simple:
> >>
> >> diff --git a/read-cache.c b/read-cache.c
> >> index dea7cd8..cc1ebdf 100644
> >> --- a/read-cache.c
> >> +++ b/read-cache.c
> >> @@ -1103,9 +1103,11 @@ int refresh_index(struct index_state *istate, unsigned int flags, const char **p
> >> int in_porcelain = (flags & REFRESH_IN_PORCELAIN);
> >> unsigned int options = really ? CE_MATCH_IGNORE_VALID : 0;
> >> const char *needs_update_fmt;
> >> + const char *needs_rm_fmt;
> >> const char *needs_merge_fmt;
> >>
> >> needs_update_fmt = (in_porcelain ? "M\t%s\n" : "%s: needs update\n");
> >> + needs_rm_fmt = (in_porcelain ? "D\t%s\n" : "%s: needs update\n");
> >> needs_merge_fmt = (in_porcelain ? "U\t%s\n" : "%s: needs merge\n");
> >
> > While the name fits in with the rest of the variables, it's kind of
> > the wrong way around, isn't it? It doesn't need an 'rm', it /was/
> > rm'd.
>
> The variable names were chosen to mean "In a situation where the plumbing
> traditionally would have said X, use this format to describe it". This is
> the first topic to separate a single situation (from the plumbing's point
> of view) into two and say different things at Porcelain, and the variable
> naming no longer works.
I agree the naming is awkward (but then, I think the "needs update"
message is awkward ;) ). But my interpretation was: if you want the
index to be in sync with the working tree, you must do this. Hence:
$EDITOR file ;# triggers needs_update
git update-index file ;# and do update in index
rm file ;# triggers needs rm
git rm --cached file ;# and do rm in index
So that was my attempt to follow the same scheme, and I think it does
work. But I agree it's awkward, and since we're not changing the
plumbing message (nor do I think we should; most users won't see it, and
we would only be breaking scripts that do), it's not a big deal just to
change the variable names.
> An obvious solution would be to rename all of them to be based on "what
> happened to the path". E.g. "modified_fmt" would be set to either "M" or
> "needs update", and "removed_fmt" would be set to either "D" or "needs
> update", etc.
I'm happy to make that change. What do you think of the feature overall?
And should typechanges also be handled here (it's no extra work for git
to detect them; we just have to pass the TYPE_CHANGED flag back up the
stack)?
-Peff
^ permalink raw reply
* Re: [PATCH] git-web--browser: avoid errors in terminal when running Firefox on Windows
From: Jeff King @ 2011-11-11 18:35 UTC (permalink / raw)
To: Alexey Shumkin; +Cc: git, Chris Packham
In-Reply-To: <1321028283-17307-1-git-send-email-Alex.Crezoff@gmail.com>
On Fri, Nov 11, 2011 at 08:18:03PM +0400, Alexey Shumkin wrote:
> Firefox on Windows by default is placed in "C:\Program Files\Mozilla Firefox"
> folder, i.e. its path contains spaces. Before running this browser "git-web--browse"
> tests version of Firefox to decide whether to use "-new-tab" option or not.
>
> Quote browser path to avoid error during this test.
Thanks. I even noticed this bug early on in the previous discussion:
http://article.gmane.org/gmane.comp.version-control.git/181600
but forgot about it by the time the final patch rolled around. Your fix
looks correct, but:
> test_expect_success \
> + 'Firefox below v2.0 paths are properly quoted' '
> + echo fake: http://example.com/foo >expect &&
> + cat >"fake browser" <<-\EOF &&
> + #!/bin/sh
> +
> + if [ "$1" == "-version" ]; then
Using "==" is a bashism. Just use "=".
Also, a style nit, but we usually spell this "test" and not "[". I admit
I don't care much, though.
> + # Firefox (in contrast to w3m) is run in background (with &)
> + # so redirect output to "actual"
> + echo fake: "$@" > actual
> + fi
> + EOF
> + chmod +x "fake browser" &&
> + git config browser.firefox.path "`pwd`/fake browser" &&
> + git web--browse --browser=firefox \
> + http://example.com/foo &&
> + test_cmp expect actual
Hmm. So we are running the fake browser in the background, but then
check that it has written something as soon as web--browse exits. Isn't
that a race condition? I.e., we could run "test_cmp" before the browser
has actually written anything?
I'm not sure there's a good way to do it. You would need either to wait
some pre-determined "it could not possibly take it longer than N seconds
to run" sleep, or we need some kind of synchronization point. We can't
wait call "wait" on the child PID (if we even have it, because it's not
our child).
-Peff
^ permalink raw reply
* Re: [PATCH] git-web--browser: avoid errors in terminal when running Firefox on Windows
From: Alexey Shumkin @ 2011-11-11 19:48 UTC (permalink / raw)
To: Jeff King; +Cc: git, Chris Packham
In-Reply-To: <20111111183555.GC16055@sigill.intra.peff.net>
> > test_expect_success \
> > + 'Firefox below v2.0 paths are properly quoted' '
> > + echo fake: http://example.com/foo >expect &&
> > + cat >"fake browser" <<-\EOF &&
> > + #!/bin/sh
> > +
> > + if [ "$1" == "-version" ]; then
>
> Using "==" is a bashism. Just use "=".
Thanks (I have no skills enough in this area)
>
> Also, a style nit, but we usually spell this "test" and not "[". I
> admit I don't care much, though.
Oh, I see
>
> > + # Firefox (in contrast to w3m) is run in
> > background (with &)
> > + # so redirect output to "actual"
> > + echo fake: "$@" > actual
> > + fi
> > + EOF
> > + chmod +x "fake browser" &&
> > + git config browser.firefox.path "`pwd`/fake browser" &&
> > + git web--browse --browser=firefox \
> > + http://example.com/foo &&
> > + test_cmp expect actual
>
> Hmm. So we are running the fake browser in the background, but then
> check that it has written something as soon as web--browse exits.
> Isn't that a race condition? I.e., we could run "test_cmp" before the
> browser has actually written anything?
eeehh... you're right...
but even on slow Windows Cygwin it is passed )
> I'm not sure there's a good way to do it. You would need either to
> wait some pre-determined "it could not possibly take it longer than N
> seconds to run" sleep, or we need some kind of synchronization point.
> We can't wait call "wait" on the child PID (if we even have it,
> because it's not our child).
hmm... we can delete "actual" file and wait its appearance (with
some timeout), no ? but I didn't see in tests anything like this
> -Peff
^ permalink raw reply
* Re: [PATCH] git-web--browser: avoid errors in terminal when running Firefox on Windows
From: Jeff King @ 2011-11-11 20:26 UTC (permalink / raw)
To: Alexey Shumkin; +Cc: git, Chris Packham
In-Reply-To: <20111111234830.32dccd87@zappedws>
On Fri, Nov 11, 2011 at 11:48:30PM +0400, Alexey Shumkin wrote:
> > I'm not sure there's a good way to do it. You would need either to
> > wait some pre-determined "it could not possibly take it longer than N
> > seconds to run" sleep, or we need some kind of synchronization point.
> > We can't wait call "wait" on the child PID (if we even have it,
> > because it's not our child).
> hmm... we can delete "actual" file and wait its appearance (with
> some timeout), no ? but I didn't see in tests anything like this
Even that's not foolproof, as the open and write are not atomic (so you
could see it's there, but read an empty file). But in this case, we
really just care that the thing ran, not that it writes any specific
output. So you could probably get away with something like:
cat >fake-browser <<\EOF &&
#!/bin/sh
>fake-browser-ran
EOF
git web--browse ... &&
{
for timeout in 1 2 3 4 5; do
test -f fake-browser-ran && break
sleep 1
done
test "$timeout" -ne 5
}
which would note success as soon as possible (to within a one second
margin), but would eventually give up after 5 seconds. So you'd get a
false positive on a _very_ loaded system, but that's kind of unlikely.
I dunno. Maybe this hackery is OK, or maybe it just isn't worth it, and
we should declare this as something that's too hard to test to make it
into our test suite.
-Peff
^ permalink raw reply
* Re: [PATCH 14/14] clone: give advice on how to resume a failed clone
From: Jeff King @ 2011-11-11 20:52 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vvcqrsmfx.fsf@alter.siamese.dyndns.org>
On Thu, Nov 10, 2011 at 01:21:38PM -0800, Junio C Hamano wrote:
> Jeff King <peff@peff.net> writes:
>
> > We could make "git clone ..." automatically resume, but I'm a little
> > nervous about that. I wrote a patch that did so, and it did work, but
> > there are a lot of little hiccups as we violate the assumption that the
> > directory didn't already exist (e.g., it writes multiple fetch refspec
> > lines to the config).
>
> Sorry, but I do not think the worry is quite justified.
>
> The "assumption that directory didn't already exist" becomes an issue only
> if you implement your "git clone" that automatically resumes as a thin
> wrapper around the current "git clone" in the form of
>
> until git clone ...
> do
> echo retrying...
> done
That was sort of what my patch looked like. It didn't do the wrapper
bit; you would have to run "git clone" again to resume. I.e.:
$ git clone http://...
Downloading bundle: ...
^C
$ git clone http://...
Resuming bundle: ...
and the implementation was very minimal. Basically, instead of checking
that the directory exists and dying, it said "the directory exists, but
there is a resumable bundle in it, so let's keep going anyway".
You _could_ do that right, with clone saying "I got to the fetch stage",
and picking up there. But that means picking apart clone into its
various stages, and not repeating earlier stages (or making sure they're
idempotent). And making sure that internally, later stages don't depend
on in-memory actions from the earlier stages.
And then what happens when you have different parameters? If I say "git
clone foo", and then resume with "git clone --mirror foo", what should
happen?
None of these problems are insurmountable. But it means looking over the
clone code carefully, figuring out what should happen, and then probably
breaking apart the various stages to see where we can resume from.
I wanted to start simply, and just tell the user "this is approximately
what clone would have done from here". And then the fancier automatic
bits can come later.
> Stepping back a bit, I think there are two different situations where
> resumable clone is beneficial. The "git clone" process died either by the
> machine crashing or the user hitting a \C-c, or the connection between the
> server and the "git clone" got severed for some reason.
>
> Right now, the "got disconnected" case results in "git clone" voluntarily
> dying and as the result of this, the symptom appears the same. But it
> does not have to be that way. If we know the underlying transport is
> resumable, e.g. when you are fetching a prepared bundle over the wire.
>
> I have this suspicion that in practice the "got disconnected" case is the
> majority. If "git clone" does not die upon disconnect while fetching a
> bundle, but instead the fetching of the bundle is resumed internally by
> reconnecting to the server and requesting a range transfer, there is no
> risk of "writes multiple fetch refspec lines" etc, no?
I don't think it is the majority. And there are even variants of "git
disconnected" that don't work. Here are just a few cases it wouldn't
handle that I think are common:
1. the client machine crashes or loses power; you'd like to resume
after rebooting.
2. the network or server goes out, but is not immediately available.
The followup attempt to fetch fails, but you could succeed if you
restarted the fetch a few minutes (or hours, or days) later.
3. the user hits ^C not because they want to abort the clone entirely,
but because they know they cannot complete the clone right now
(e.g., they are taking their laptop off the network, or it is
consuming too much bandwidth, or they would rather wait until later
when they are on a faster network).
All of those mean we have to have some on-disk state that shows how far
we got, and that a totally separate process can figure out from the
state where to resume.
> Of course, it is _also_ beneficial if we made "git clone" resumable after
> you purposefully kill it (maybe you thought it will clone within minutes,
> but it turns out that it may take hours and you have to turn off the
> machine in the next five minutes before leaving the work, or something).
> A solution for that case _could_ be used for the "got disconnected" case
> by letting it voluntarily die as we currently do, but I do not think that
> is an optimal solution to the "got disconnected" case.
I see the "got disconnected, and we can immediately resume" as a
minority subset of the larger problem. If we really want to, we can
implement that while waiting for a larger solution, but I don't think it
will serve most people's needs, and then will eventually become obsolete
anyway.
-Peff
^ permalink raw reply
* Re: [PATCH 02/14] http: turn off curl signals
From: Jeff King @ 2011-11-11 20:54 UTC (permalink / raw)
To: Daniel Stenberg; +Cc: git
In-Reply-To: <alpine.DEB.2.00.1111100941380.27581@tvnag.unkk.fr>
On Thu, Nov 10, 2011 at 09:43:40AM +0100, Daniel Stenberg wrote:
> >I'm a little iffy on this one. If I understand correctly, depending
> >on the build and configuration, curl may not be able to timeout
> >during DNS lookups. But I'm not sure if it does, anyway, since we
> >don't set any timeouts.
>
> Right, without a timeout set libcurl won't try to timeout name resolves.
>
> To clarify: when libcurl is built to use the standard synchronous
> name resolver functions it can only abort them after a specified time
> by using signals (on posix systems).
OK, that matches with my understanding. I think this patch is a fine
thing to do for us, then. If we ever do start caring about timing out on
name lookups, we can rework it.
Thanks.
-Peff
^ permalink raw reply
* Git: Unexpected behaviour?
From: Jvsrvcs @ 2011-11-11 20:55 UTC (permalink / raw)
To: git
Unexpected git behaviour
---
# First create a local git repo
$mkdir gitexample
$git config --global user.name "my name"
$git config --global user.email "me@me.com"
$git init
$git add .
$git commit -m 'initial commit'
# Create/Edit an empty file
$vi readme.txt
# add a single line: "this was added in the master branch."
$git commit -a
# create and checkout a new branch (from master)
$git branch test
$git checkout test
# edit the readme.txt file and do not commit
# add the text: "this was added in the test branch.", save and exit
$vi readme.txt
#now switch back to master
$git checkout master
$cat readme.txt
#You will see both lines in the master.
Question #1:
Why was this line added in the *master branch?
--- even further surprising
In the master branch, now do a commit
$git commit -a
cat readme.txt ( you will see the line in the master now that was added in
the test branch )
Question #2:
Why did this happen?
# Now switch back to the test branch
$git checkout test
$cat readme.txt
You will only see the one line: "This was added in the master branch"
Question #3:
Why did this happen?
and NOT the line added in that branch: "this was added in the test branch"
<= this line is gone
What is the reason for this?
1) Why do I see uncommitted changes in the branches made off master in the
master branch?
2) Why, if I commit them in the master, do the disappear in the branch in
which they were made?
This is confusing, I would think the * master branch would be left
untouched. This would solve issue #2.
--
View this message in context: http://git.661346.n2.nabble.com/Git-Unexpected-behaviour-tp6986736p6986736.html
Sent from the git mailing list archive at Nabble.com.
^ permalink raw reply
* Re: Git: Unexpected behaviour?
From: Carlos Martín Nieto @ 2011-11-11 21:03 UTC (permalink / raw)
To: Jvsrvcs; +Cc: git
In-Reply-To: <1321044904175-6986736.post@n2.nabble.com>
[-- Attachment #1: Type: text/plain, Size: 1590 bytes --]
On Fri, Nov 11, 2011 at 12:55:04PM -0800, Jvsrvcs wrote:
> Unexpected git behaviour
>
[ ... switch branches with local modifications ...]
> #You will see both lines in the master.
>
> Question #1:
> Why was this line added in the *master branch?
>
It wasn't. that line was added in the working directory. When you
switch branches, if the file in the tip of the current branch and the
file in the tip of the target branch don't differ, it's safe to keep
your local changes, so git does. This is to support the use-case where
you start editing a file when the wrong branch is checked out and want
to change to the right one.
>
> --- even further surprising
> In the master branch, now do a commit
> $git commit -a
>
> cat readme.txt ( you will see the line in the master now that was added in
> the test branch )
>
> Question #2:
> Why did this happen?
Because you told git to commit the file with that modification in it.
>
> # Now switch back to the test branch
> $git checkout test
> $cat readme.txt
>
> You will only see the one line: "This was added in the master branch"
>
> Question #3:
> Why did this happen?
Because the file in the 'test' branch only has that line. As you said
yourself, you edited the file but didn't commit.
>
> and NOT the line added in that branch: "this was added in the test branch"
> <= this line is gone
Again, that line wasn't added in any branch but in the working
directory. The active branch was 'test', but doesn't magically mean
that uncommitted changes travel with it.
cmn
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 490 bytes --]
^ permalink raw reply
* Re: Git: Unexpected behaviour?
From: Eugene Sajine @ 2011-11-11 21:04 UTC (permalink / raw)
To: Jvsrvcs; +Cc: git
In-Reply-To: <CAPZPVFb-VbTfkuyg4KtTsaWiNvd37GHeH7crPtqv1fKRbwuyfQ@mail.gmail.com>
On Fri, Nov 11, 2011 at 4:01 PM, Eugene Sajine <euguess@gmail.com> wrote:
>
>
> On Friday, November 11, 2011, Jvsrvcs <jvsrvcs@gmail.com> wrote:
>> Unexpected git behaviour
>>
>> ---
>> # First create a local git repo
>>
>> $mkdir gitexample
>> $git config --global user.name "my name"
>> $git config --global user.email "me@me.com"
>> $git init
>> $git add .
>> $git commit -m 'initial commit'
>>
>> # Create/Edit an empty file
>> $vi readme.txt
>>
>> # add a single line: "this was added in the master branch."
>> $git commit -a
>>
>> # create and checkout a new branch (from master)
>> $git branch test
>> $git checkout test
>>
>> # edit the readme.txt file and do not commit
>> # add the text: "this was added in the test branch.", save and exit
>> $vi readme.txt
>>
>> #now switch back to master
>> $git checkout master
>> $cat readme.txt
>>
>> #You will see both lines in the master.
>>
>> Question #1:
>> Why was this line added in the *master branch?
>>
>>
>> --- even further surprising
>> In the master branch, now do a commit
>> $git commit -a
>>
>> cat readme.txt ( you will see the line in the master now that was added in
>> the test branch )
>>
>> Question #2:
>> Why did this happen?
>>
>> # Now switch back to the test branch
>> $git checkout test
>> $cat readme.txt
>>
>> You will only see the one line: "This was added in the master branch"
>>
>> Question #3:
>> Why did this happen?
>>
>> and NOT the line added in that branch: "this was added in the test branch"
>> <= this line is gone
>>
>> What is the reason for this?
>>
>> 1) Why do I see uncommitted changes in the branches made off master in the
>> master branch?
>> 2) Why, if I commit them in the master, do the disappear in the branch in
>> which they were made?
>>
>> This is confusing, I would think the * master branch would be left
>> untouched. This would solve issue #2.
>>
>>
>> --
>> View this message in context:
>> http://git.661346.n2.nabble.com/Git-Unexpected-behaviour-tp6986736p6986736.html
>> Sent from the git mailing list archive at Nabble.com.
>> --
>> 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
>>
Possible dup, thanks to "smart" HTML filter:
All described is absolutely expected and normal behavior for git. You just
need to learn about it a bit more and understand what branch in git is and
how it works with changes in working directory.
it is best described in here http://progit.org/book/ch3-0.html
^ 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