* Re: reset reports file as modified when it's in fact deleted
From: Junio C Hamano @ 2011-11-12 0:11 UTC (permalink / raw)
To: Jeff King; +Cc: Carlos Martín Nieto, git
In-Reply-To: <20111111182109.GB16055@sigill.intra.peff.net>
Jeff King <peff@peff.net> writes:
> On Fri, Nov 11, 2011 at 08:43:34AM -0800, Junio C Hamano wrote:
>
> 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
The word "update" at the plumbing level simply means "update the path in
the index". At the Porcelain level you have to use "git add" or "git rm"
depending on different kind of "needs update", which may be argued an
inconsistency, but at the plumbing level everything is done with the same
update-index command, and "needs update" is the word that matches your
interpretation.
I however think the topic was about updating the Porclain-ish output that
is similar to "status -s" output. And at that level, paths marked with M/T
and D are dealt differently by end users ("add" vs "rm").
And the ? : expressions the patch is touching is about mapping the state
of the path to your "you must do this" interpretation. What is being
mapped is the state, so it would be more natural to have the variable
"modified_fmt" hold the result of the mapping "you must do...", instead of
calling the variable in terms of "you must do this if you were working at
the plumbing level", which is where the original needs_update_fmt naming
comes from.
>> 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?
The "feature" is more or less "Meh" to me; I do not mind differentiating M
and D there because the necessary information is already there in the
codepath, but if we were to really do that, then the variables must be
renamed. We shouldn't name them after "you must do this at the plumbing
level" like we have done so far, and instead use "the path is in this
state". This is even more so if we were to further split a single "state"
that plumbing layer considers the same and gives the same "needs X" to
different states that Porcelains would give different messages in the
future.
> 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)?
As long as "pass ... back up the stack" does not result in too much
ugliness in the code, I am OK with it.
^ permalink raw reply
* Where to put a git repo?
From: Jvsrvcs @ 2011-11-12 0:03 UTC (permalink / raw)
To: git
We are in the process of setting up a git repo on a Windows 2003 box.
(For speed, we need our build box and git repo on the same machine and build
will not work on Linux as a result of the Installer software we are married
to at the moment).
Using cygwin, where would be the best place (windows path) to put a git
repo?
Is there a convention typically used on Linux system as to where to put the
repo (path)?
We simply want to follow the convention if there is any.
--
View this message in context: http://git.661346.n2.nabble.com/Where-to-put-a-git-repo-tp6987137p6987137.html
Sent from the git mailing list archive at Nabble.com.
^ permalink raw reply
* Re: Git: CVS to Git import
From: Jakub Narebski @ 2011-11-11 23:43 UTC (permalink / raw)
To: Jvsrvcs; +Cc: git
In-Reply-To: <1321053453892-6987037.post@n2.nabble.com>
Jvsrvcs <jvsrvcs@gmail.com> writes:
> Git: CVS to Git import
>
> We are moving from CVS to Git and want to know if anyone has had any
> experience there doing this and could share do's / dont's, best practices
> when doing the initial import.
>
> Also are there any known problems/bugs with the cvs to git import with
> regards to CVS history?
I think that Eric S Raymond "DVCS Migration Guide"
http://www.catb.org/esr/dvcs-migration-guide.html
and reposurgeon tool (to clean up conversion artifacts)
http://www.catb.org/esr/reposurgeon/
might help.
--
Jakub Narębski
^ permalink raw reply
* Git: CVS to Git import
From: Jvsrvcs @ 2011-11-11 23:17 UTC (permalink / raw)
To: git
Git: CVS to Git import
We are moving from CVS to Git and want to know if anyone has had any
experience there doing this and could share do's / dont's, best practices
when doing the initial import.
Also are there any known problems/bugs with the cvs to git import with
regards to CVS history?
Regards,
J.V.
--
View this message in context: http://git.661346.n2.nabble.com/Git-CVS-to-Git-import-tp6987037p6987037.html
Sent from the git mailing list archive at Nabble.com.
^ permalink raw reply
* Re: [RFC/PATCH] remote: add new sync command
From: Jakub Narebski @ 2011-11-11 22:00 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Felipe Contreras, Jeff King, git
In-Reply-To: <7vvcqqr4wg.fsf@alter.siamese.dyndns.org>
On Fri, 11 Nov 2011, Junio C Hamano wrote:
> 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.
Well, it is documented in git-fetch(1), though in slightly piecemeal
fashion.
One difference is that "git remote update" defaults to "default" group
if it is defined, and to "--all" if it isn't. With "git fetch --multiple"
you have to specify it explicitly ("git fetch --multiple" is a no-op,
I think).
--
Jakub Narebski
Poland
^ permalink raw reply
* Re: Git: Unexpected behaviour?
From: Chris Packham @ 2011-11-11 21:31 UTC (permalink / raw)
To: Jvsrvcs; +Cc: git
In-Reply-To: <1321044904175-6986736.post@n2.nabble.com>
Hi,
On 12/11/11 09:55, Jvsrvcs 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
One thing to remember is that this is the same as "git add readme.txt"
and "git commit" (I'll explain why below).
>
> # 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
At this point the changes are in the work tree. They aren't added to the
test branch until you commit them.
>
> #now switch back to master
> $git checkout master
When you have uncommited changes in the work tree that don't conflict
with the contents of the branch you are checking out git will happily
carry them along for you. If they did conflict then git would refuse to
switch to the new branch.
> $cat readme.txt
>
> #You will see both lines in the master.
>
> Question #1:
> Why was this line added in the *master branch?
Because the second change hasn't been committed it isn't in either
branch. It's in the work tree.
> --- 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 asked for it to 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?
Because the second change was committed (in the master branch) it is
no-longer floating in the work tree so when you switch branches you get
the contents of the file in that branch.
>
> 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.
>
Hopefully this will explain things a little better
[work-tree] -- git add -> [index] -- git commit --> [HEAD]
work-tree: the area on the file system where your code is checked out.
index: also known as the staging area, this is represents what will end
up in the next commit.
HEAD: a general term for the current branch.
As you can see that until a change is committed it isn't in _any_
branch. When you type "git checkout test" or "git checkout master" HEAD
will be updated. Changes in the work-tree or the index will be carried
along (provided they don't conflict with the new HEAD).
Hope that helps.
^ permalink raw reply
* Re: Git: Unexpected behaviour?
From: Gelonida N @ 2011-11-11 21:25 UTC (permalink / raw)
To: git
In-Reply-To: <1321045782702-6986770.post@n2.nabble.com>
On 11/11/2011 10:09 PM, Jvsrvcs wrote:
> The thing is that I want my 'master' branch' to reflect what is in the
> 'master' repo - we are using another versioning control system than git for
> the master for the moment.
>
> I want to be able to switch to the master at any moment, do an update there
> with the primary versioning system in use, and get all others commits and
> merge down to my branch from time to time.
>
> It seems to me that this behaviour corrupts the master branch, reflecting a
> change in the master branch that I did not want or expect.
>
> so I suppose the correct work flow would to be *ALWAYS*, commit on the
> branch you are on before switching to another branch? I think this would
> solve the problem.
You can look at
git stash
>
> This just seems a bit odd. I did not commit on the branch, I switched and
> it's on the master now. At any rate, I can work with it, just need to know
> the correct work flow I should take before switching to another branch, and
> that seems to be *ALWAYS* commit before switching to get the expected
> behaviour that seems normal to me.
>
> --
> View this message in context: http://git.661346.n2.nabble.com/Git-Unexpected-behaviour-tp6986736p6986770.html
> Sent from the git mailing list archive at Nabble.com.
^ permalink raw reply
* Re: Git: Unexpected behaviour?
From: Taylor Hedberg @ 2011-11-11 21:14 UTC (permalink / raw)
To: Jvsrvcs; +Cc: git
In-Reply-To: <1321045782702-6986770.post@n2.nabble.com>
If you don't want to make a new commit on the branch you are leaving,
you can use `git stash` to stash away your working directory changes in
a temporary holding place without updating any branch.
^ permalink raw reply
* Re: Git: Unexpected behaviour?
From: Jvsrvcs @ 2011-11-11 21:09 UTC (permalink / raw)
To: git
In-Reply-To: <1321044904175-6986736.post@n2.nabble.com>
The thing is that I want my 'master' branch' to reflect what is in the
'master' repo - we are using another versioning control system than git for
the master for the moment.
I want to be able to switch to the master at any moment, do an update there
with the primary versioning system in use, and get all others commits and
merge down to my branch from time to time.
It seems to me that this behaviour corrupts the master branch, reflecting a
change in the master branch that I did not want or expect.
so I suppose the correct work flow would to be *ALWAYS*, commit on the
branch you are on before switching to another branch? I think this would
solve the problem.
This just seems a bit odd. I did not commit on the branch, I switched and
it's on the master now. At any rate, I can work with it, just need to know
the correct work flow I should take before switching to another branch, and
that seems to be *ALWAYS* commit before switching to get the expected
behaviour that seems normal to me.
--
View this message in context: http://git.661346.n2.nabble.com/Git-Unexpected-behaviour-tp6986736p6986770.html
Sent from the git mailing list archive at Nabble.com.
^ 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
* 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
* 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: [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
* 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] 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] 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 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: 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: [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: 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: 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: 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: 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: 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: 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
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