* Re: git gc and kernel.org
From: Johannes Sixt @ 2009-10-21 8:05 UTC (permalink / raw)
To: Junio C Hamano
Cc: Nicolas Pitre, Johan Herland, git, H. Peter Anvin, ftpadmin
In-Reply-To: <7vaazl8acd.fsf@alter.siamese.dyndns.org>
Junio C Hamano schrieb:
> Junio C Hamano <gitster@pobox.com> writes:
>
>> Johannes Sixt <j.sixt@viscovery.net> writes:
>>
>>> Junio C Hamano schrieb:
>>>> + if (auto_gc) {
>>>> + const char *argv_gc_auto[] = { "gc", "--auto", NULL };
>>>> + run_command_v_opt(argv_gc_auto, RUN_GIT_CMD);
>>> Am I correct that this will produce progress output? If git-daemon runs
>>> receive-pack, then this output will go to the syslog. Do we care?
>> We do, and we don't want that. Thanks for spotting.
>>
>> Would adding "--quiet" to the mix be enough?
>
> Actually I don't know. This originally came from "we _could_ add gc and
> update-server-info to hundreds of post-receive hooks, but any repository
> hosting site that holds many central repositories will exactly have the
> same issue, so why not do this internally", so it may make sense to do
> exactly the same thing as what we do to the output from hooks. What do we
> do to them now? stdout-to-stderr?
Yes.
I'm slightly in favor of adding "--quiet", because even with this option
we see some output:
$ git gc --auto --quiet
Auto packing your repository for optimum performance. You may also
run "git gc" manually. See "git help gc" for more information.
A compromise would be to reduce this message to the first sentence if
--quiet was given. This way users who push via ssh or locally get a short
explanation why "git push" does not finish immediately[*]; and git-daemon
logs only a one-liner in the syslog, which might be useful, too.
[*] Skipping the hint to "run git gc manually" would even be good in this
case, because the hint pertains the remote repository, not the one from
which "git push" was issued.
-- Hannes
^ permalink raw reply
* Re: [RFC] pull/fetch rename
From: Jeff King @ 2009-10-21 7:47 UTC (permalink / raw)
To: Junio C Hamano
Cc: Mike Hommey, Daniel Barkalow, Thomas Rast, git,
Björn Steinbrink
In-Reply-To: <20091021074522.GA13531@coredump.intra.peff.net>
On Wed, Oct 21, 2009 at 03:45:22AM -0400, Jeff King wrote:
> Declaring it a failure depends on what you consider the goal of "git
> remote update" to be. I find it very useful as a shorthand for "fetch
> from _all_ remotes"[1]. Which does save typing over
>
> [...]
>
> On Wed, Oct 21, 2009 at 12:22:35AM -0700, Junio C Hamano wrote:
>
>> *1* The only thing "git remote update" does that "git fetch" does not
>> is that it can serve as "fetch from everywhere" shorthand. But that
>> is something we could have added to "git fetch". So in that sense, I
>> think it may make even more sense to deprecate "remote update" and
>> teach "fetch" how to do that.
...and it would probably help if I had read your footnotes before
responding.
-Peff
^ permalink raw reply
* Re: Creating something like increasing revision numbers
From: David Aguilar @ 2009-10-21 7:47 UTC (permalink / raw)
To: Norbert Preining; +Cc: Daniel Barkalow, git
In-Reply-To: <20091019004447.GC11739@gamma.logic.tuwien.ac.at>
On Mon, Oct 19, 2009 at 02:44:47AM +0200, Norbert Preining wrote:
> Hi all,
>
> thanks everyone for the nice feedback!
>
> On So, 18 Okt 2009, Daniel Barkalow wrote:
> > It's possible as long as you don't think of the "version number" as a
> > property of the commit, but rather a property that some commits get by
> > virtue of having been at some time the commit that's what would be found
> > on that particular server at that particular time. Even though the history
>
> Right! That is a good point. In fact I don't care about (local) commits,
> but about the pushes to the central server.
>
> > of the *content* is non-linear, the sequence of values stored in
> > refs/heads/master on your central server is linear, local, and easy to
> > enumerate.
>
> That is exactely what I need.
If you have any control over how people will use git,
then you can give your constantly-incrementing revision number
more stability by ensuring that everyone uses
'git pull --rebase'.
That'll literally keep the history completely linear.
If someone forgets then it's not a big deal; you'll
just get a merge commit and the number will increment
by 2 instead of by 1.
> Now my follow-up questions:
> - how would one access this "sequence" number on the server
If you've done the "tag the initial commit" as suggested
elsewhere on this thread:
git tag projectname $(git rev-list HEAD | tail -n1)
then you can do this with simply:
git describe --tags
It should output something like:
projectname-101-g20912df
> - is there a way to determine at which of this "sequence" numbers a specific
> file has been changed last?
commit=$(git log --pretty=%H -1 -- <filename>)
git describe --tags $commit
> JAIST Japan Advanced Institute of Science and Technology preining@jaist.ac.jp
> Vienna University of Technology preining@logic.at
> Debian Developer (Debian TeX Task Force) preining@debian.org
Just another happy Debian user here,
--
David
^ permalink raw reply
* Re: [RFC] pull/fetch rename
From: Jeff King @ 2009-10-21 7:45 UTC (permalink / raw)
To: Junio C Hamano
Cc: Mike Hommey, Daniel Barkalow, Thomas Rast, git,
Björn Steinbrink
In-Reply-To: <7v63a99pok.fsf@alter.siamese.dyndns.org>
On Wed, Oct 21, 2009 at 12:22:35AM -0700, Junio C Hamano wrote:
> Some people thought that throwing everything that does something to remote
> under "git remote" was a good idea, and "git remote update" was invented.
> It is a thin wrapper around "fetch" and does what "fetch" does. You need
> to understand "fetch" (i.e. downloads the history and necessary objects,
> and updates the remote tracking branches, without ever touching the work
> tree) to understand "git remote update" anyway, and more importantly, you
> need to understand what they do not do.
>
> It is not even a typesaver. "git fetch" updates from the default remote,
> so does "git remote update". Personally I think the people who invented
> "git remote update" were misguided, and that is why I say it was a failed
> UI experiment that failed, but that is hindsight talking [*1*].
Declaring it a failure depends on what you consider the goal of "git
remote update" to be. I find it very useful as a shorthand for "fetch
from _all_ remotes"[1]. Which does save typing over
$ for i in `git remote`; do git fetch $i; done
And of course, there is "git remote" again, saving us a few keystrokes
over:
$ git config --get-regexp 'remote..*.url' | cut -d. -f2
[1]: And I think this is a useful operation. When collaborating with
developers in multiple repositories, it is nice to see an overview of
what all other people are working on. We have other tools to actually
compare the refs, but the first step is obviously getting those refs up
to date locally.
-Peff
^ permalink raw reply
* Re: git gc and kernel.org
From: Junio C Hamano @ 2009-10-21 7:39 UTC (permalink / raw)
To: Johannes Sixt; +Cc: Nicolas Pitre, Johan Herland, git, H. Peter Anvin, ftpadmin
In-Reply-To: <7vzl7l8b1y.fsf@alter.siamese.dyndns.org>
Junio C Hamano <gitster@pobox.com> writes:
> Johannes Sixt <j.sixt@viscovery.net> writes:
>
>> Junio C Hamano schrieb:
>>> + if (auto_gc) {
>>> + const char *argv_gc_auto[] = { "gc", "--auto", NULL };
>>> + run_command_v_opt(argv_gc_auto, RUN_GIT_CMD);
>>
>> Am I correct that this will produce progress output? If git-daemon runs
>> receive-pack, then this output will go to the syslog. Do we care?
>
> We do, and we don't want that. Thanks for spotting.
>
> Would adding "--quiet" to the mix be enough?
Actually I don't know. This originally came from "we _could_ add gc and
update-server-info to hundreds of post-receive hooks, but any repository
hosting site that holds many central repositories will exactly have the
same issue, so why not do this internally", so it may make sense to do
exactly the same thing as what we do to the output from hooks. What do we
do to them now? stdout-to-stderr?
^ permalink raw reply
* Re: git gc and kernel.org
From: Junio C Hamano @ 2009-10-21 7:23 UTC (permalink / raw)
To: Johannes Sixt
Cc: Junio C Hamano, Nicolas Pitre, Johan Herland, git, H. Peter Anvin,
ftpadmin
In-Reply-To: <4ADEA93E.7060907@viscovery.net>
Johannes Sixt <j.sixt@viscovery.net> writes:
> Junio C Hamano schrieb:
>> + if (auto_gc) {
>> + const char *argv_gc_auto[] = { "gc", "--auto", NULL };
>> + run_command_v_opt(argv_gc_auto, RUN_GIT_CMD);
>
> Am I correct that this will produce progress output? If git-daemon runs
> receive-pack, then this output will go to the syslog. Do we care?
We do, and we don't want that. Thanks for spotting.
Would adding "--quiet" to the mix be enough?
^ permalink raw reply
* Re: [RFC] pull/fetch rename
From: Junio C Hamano @ 2009-10-21 7:22 UTC (permalink / raw)
To: Mike Hommey; +Cc: Daniel Barkalow, Thomas Rast, git, Björn Steinbrink
In-Reply-To: <7v3a5db6ij.fsf@alter.siamese.dyndns.org>
Junio C Hamano <gitster@pobox.com> writes:
> Mike Hommey <mh@glandium.org> writes:
>
>> BTW, shouldn't fetch be deprecated in favour of git remote update ?
>
> Why? People will then be confused because half of them would expect
> "remote update" to somehow affect their working tree, and some others
> would expect their working tree reset to one of the branches from the
> remote, and it won't solve anything. Oh, and it will irritate people who
> are used to type "git fetch", too.
I think the above comment needs to be clarified, so that I will not
discourage you or other people who would want to pursue the part I omitted
from my quote too much, which was:
> (this may require adding some features to git remote update, but you get
> the idea)
Now, I _personally_ think "git remote update" was a half-baked UI
experiment that failed, but as the maintainer I'll still give it benefit
of doubt for a bit longer and let interested parties resurrect and perfect
it, just in case it might turn out to be a good thing. In the rest, when
I say "I think", pretend as if I said _personally_ (i.e. not speaking as
the maintainer who already has given up on it).
I think the original "git remote add" was a good interface, similar to
"git config", as the management interface to the remote system used by the
everyday commands "fetch/pull/push". The everyday commands use the remote
nicknames and their associated data stored in the configuration file.
While you can edit your configuration file directly to manage the remotes,
some people (and recipe book writers) prefer to have a specialized
management command. "git remote add" is such a management interface that
you use once and then you can forget about it. Once you get your remote
configured, the everyday commands will use the data in the configuration
file, and the commands you interract with your remotes will be these
everyday commands, not "git remote".
Some people thought that throwing everything that does something to remote
under "git remote" was a good idea, and "git remote update" was invented.
It is a thin wrapper around "fetch" and does what "fetch" does. You need
to understand "fetch" (i.e. downloads the history and necessary objects,
and updates the remote tracking branches, without ever touching the work
tree) to understand "git remote update" anyway, and more importantly, you
need to understand what they do not do.
It is not even a typesaver. "git fetch" updates from the default remote,
so does "git remote update". Personally I think the people who invented
"git remote update" were misguided, and that is why I say it was a failed
UI experiment that failed, but that is hindsight talking [*1*].
After reading Björn's excerpts, it was clear to me that the names of the
commands have much less to do with the confusion [*2*] than I originally
feared [*3*]. As long as the user needs the same kind of understanding of
what the command does, I do not think changing the command name between
"git remote update" vs "git fetch" and calling everything that has
something to do with remote repositories "remote" would solve anything.
The users also need to understand how to make what these commands do an
integrated part in a larger workflow they use, so that they know what to
do next, which is much more important issue, and at that point the name of
the command is secondary---the concepts counts much more.
"git remote update" even has a slight downside in the "push moves from
here to there, pull moves from there to here" sense. If you never have
seen git, "git remote update $there" may look like you are asking git to
update the remote called $there, presumably with what you have. That is
quite opposite direction from how it actually move things.
[Footnote]
*1* The only thing "git remote update" does that "git fetch" does not is
that it can serve as "fetch from everywhere" shorthand. But that is
something we could have added to "git fetch". So in that sense, I think
it may make even more sense to deprecate "remote update" and teach "fetch"
how to do that.
*2* Granted, if our "pull" were named "push", the natural meaning of the
word "push" that moves things from here to there (as opposed to there to
here) may even confuse people, but both "pull" and "fetch" mean moving
things from farther to closer (and nothing more in the natural meaning),
and the confusion expressed in the thread were not of that kind---nobody
expected us to do anything that involves moving something we have to the
remote, but the confusion was about what happens _after_ something was
moved from there to here.
*3* In a sense I somehow was hoping that the confusion was only about the
push/pull asymmetry as some people claimed. If it were, the problem would
have been very easy to fix; you just do not let pull affect the work tree.
But the confused users were expecting the changes to be reflected to their
work trees, and the confusion was about how that is done. Some wanted
their local changes blown away, some wanted their local histories also get
blown away, some wanted the changes integrated.
^ permalink raw reply
* Re: [RFC] pull/fetch rename
From: Mike Hommey @ 2009-10-21 7:06 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Daniel Barkalow, Thomas Rast, git, Björn Steinbrink
In-Reply-To: <7v3a5db6ij.fsf@alter.siamese.dyndns.org>
On Tue, Oct 20, 2009 at 11:33:40PM -0700, Junio C Hamano wrote:
> Mike Hommey <mh@glandium.org> writes:
>
> > BTW, shouldn't fetch be deprecated in favour of git remote update ?
>
> Why? People will then be confused because half of them would expect
> "remote update" to somehow affect their working tree, and some others
> would expect their working tree reset to one of the branches from the
> remote, and it won't solve anything.
I must be missing the obvious but which one of fetch and remote update
does the above ? I was under the impression that none of them would.
> Oh, and it will irritate people who
> are used to type "git fetch", too.
That's another problem, but my understanding is that git fetch and git
remote update are roughly doing the same thing. Having two commands for
the same thing is confusing. I kind of like the idea to have one
command, remote, to handle, err, remotes. Also note that I said
deprecated, not remove ; that could mean keeping fetch, but pushing the
use of remote update for new users.
Mike
^ permalink raw reply
* Re: [RFC] pull/fetch rename
From: Junio C Hamano @ 2009-10-21 6:33 UTC (permalink / raw)
To: Mike Hommey; +Cc: Daniel Barkalow, Thomas Rast, git, Björn Steinbrink
In-Reply-To: <20091021063008.GA3349@glandium.org>
Mike Hommey <mh@glandium.org> writes:
> BTW, shouldn't fetch be deprecated in favour of git remote update ?
Why? People will then be confused because half of them would expect
"remote update" to somehow affect their working tree, and some others
would expect their working tree reset to one of the branches from the
remote, and it won't solve anything. Oh, and it will irritate people who
are used to type "git fetch", too.
^ permalink raw reply
* Re: [RFC] pull/fetch rename
From: Mike Hommey @ 2009-10-21 6:30 UTC (permalink / raw)
To: Daniel Barkalow; +Cc: Thomas Rast, git, Björn Steinbrink
In-Reply-To: <alpine.LNX.2.00.0910201912390.14365@iabervon.org>
On Tue, Oct 20, 2009 at 07:56:01PM -0400, Daniel Barkalow wrote:
> On Tue, 20 Oct 2009, Thomas Rast wrote:
>
> > Hi all,
> >
> > While everyone is busy in two other UI threads, I figured I might as
> > well toss up another (probably) controversial topic.
> >
> > Especially on IRC, we see many people who are some combination of
> > misunderstanding, misusing or overusing git-pull. I figure this is
> > the result of several factors, notably
> >
> > a) pull/push are not symmetric,
>
> In a certain sense they are; they both update the branches local to one
> repository with the data from the other repository. In this sense, fetch
> is the oddity in that it doesn't update any repository's own branches, but
> just the local information about other repositories' branches.
BTW, shouldn't fetch be deprecated in favour of git remote update ?
(this may require adding some features to git remote update, but you get
the idea)
Mike
^ permalink raw reply
* Re: git gc and kernel.org
From: Johannes Sixt @ 2009-10-21 6:25 UTC (permalink / raw)
To: Junio C Hamano
Cc: Nicolas Pitre, Johan Herland, git, H. Peter Anvin, ftpadmin
In-Reply-To: <7v63a9n5i6.fsf@alter.siamese.dyndns.org>
Junio C Hamano schrieb:
> + if (auto_gc) {
> + const char *argv_gc_auto[] = { "gc", "--auto", NULL };
> + run_command_v_opt(argv_gc_auto, RUN_GIT_CMD);
Am I correct that this will produce progress output? If git-daemon runs
receive-pack, then this output will go to the syslog. Do we care?
-- Hannes
^ permalink raw reply
* Re: ident hash usage question
From: Alex Riesen @ 2009-10-21 6:25 UTC (permalink / raw)
To: Eugene Sajine; +Cc: git
In-Reply-To: <76c5b8580910201519s29b939f3o3f6af8ca50340db1@mail.gmail.com>
On Wed, Oct 21, 2009 at 00:19, Eugene Sajine <euguess@gmail.com> wrote:
>>> How is that? It seams to me that git log <path> will show only commits
>>> where <path> was changed/committed? Considering the fact that I've got
>>> the initial path from the blob, i should get the exact commit history
>>> (or last commit in my example) for the file(s) (Files if renaming
>>> occurred without content change).
>>
>> The blob is present in each commit since it was introduced. Except
>> when your project contains only that one blob, isn't the state of
>> the other parts of an interest?
>>
> I would question this statement. It seems to me that hash of the file
> content is logged only for the commit when it was touched.
> Therefore there is very limited amount of actual commits where the
> same hash can be met.
git rev-list HEAD | while read sha; do git ls-tree $sha; done | grep <blob-sha>
^ permalink raw reply
* Re: [RFC] pull/fetch rename
From: Junio C Hamano @ 2009-10-21 6:22 UTC (permalink / raw)
To: Björn Steinbrink; +Cc: Daniel Barkalow, Thomas Rast, git
In-Reply-To: <20091021030608.GA18997@atjola.homenet>
Björn Steinbrink <B.Steinbrink@gmx.de> writes:
> So that's ten days of #git. I left out a bunch of duplications (most
> were "pull == fetch", "pull == update" and "pull to update
> non-checked-out branch").
Interesting; this shows that people who do not understand what "pull" does
expect different behaviour from "pull", use the word "pull" to express
what they want to happen, expect other people interpret the word to mean
the way they think it does. At the same time, judging from different
behaviour expected by these people, push/pull asymmetry does not seem to
have much to do with the confusion. If the verb used by people who know
git to call this operation were "distim", these people would also say
"distim" and expect different things from it. I would foresee exactly the
same problem if the verb were "update" for that matter.
It is just natural, as everybody learns a new language by listening how
others talk and by imitating them.
Another thing I noticed while lurning on the #git channel for the past few
days is that too much flexibility actually hurts new people. They do not
want flexibility, but want to follow a set recipe. It just overwhelms to
get too much flexibility upfront without enough guidance.
And there are too much historical flexibility that remain merely for
historical reasons. We more or less killed the concept of separate object
store and $GIT_DIR (i.e.one objects/ directory shared between more than
one .git/ directories) when we made receive-pack aware of alternate
repository information---it used to be that objects/ directory did not
belong to a single set of refs/ hierarchy, but now it does and the
receiving end of "git push" uses that knowledge to tell the sender what
not to send in order to minimize the transfer. We will be gradually
killing other kinds of historical flexibility that do not buy much in
practice anymore, and that would reduce the issue of overwhelming
flexibility.
For example, I am in favor of deprecating the "pull $there $src:$dst"
notation. Before we standardized on the separate remote layout, it was
sometimes handy to be able to use $dst that is a local branch, but these
days, especially when repository $there has remote.$there.fetch mapping
configured so that we can compute from $src what remote tracking branch we
should store the fetched commit, the flexibility is more confusing than it
is useful. "pull $there $src" (and "pull $there $src1 $src2" to build an
octopus) should stay, but even there, it probably is a good idea for these
notations to start updating remote tracking branches for $src ($src1 and
$src2 in the octopus case) if the repository is configured to track them
anyway, to match what "pull $there" that uses the default configuration
does.
I am actually even Ok, at least in the long run (like in 3 years), if we
were to deprecate the refspecs with colon given on the command line to
"pull" and "fetch" altogether [*1*]. The rule will become "if you are
going to use tracking branches to store what you fetch, you _must_ always
have the tracking mapping defined in remote.$there.fetch configuration,
and the location where one particular branch from the remote is stored is
always determined by that mapping." It robs us the flexibility to fetch
my 'next' and store it to your 'next' branch today and to your 'mext'
branch tomorrow, and instead you would need to first fetch and then do an
explicit "git branch mext origin/next" if you really want to do so, but I
think the flexibility outlived its usefulness --- the primary value of
these kinds of flexibility is to experiment with various workflows and UI
concepts they allow, but I think we have gained enough experience to start
judging what works (and is useful) and what doesn't (and is Ok to make it
much more cumbersome to make or even impossible to do).
[Footnote]
*1* Except perhaps when deleting branches from the remote with "push", but
even there we _could_ force people to do a deleting push separate from
normal push and say "push --delete $there $this $and $that".
^ permalink raw reply
* Re: ident hash usage question
From: Daniel Barkalow @ 2009-10-21 5:35 UTC (permalink / raw)
To: Eugene Sajine; +Cc: Junio C Hamano, Alex Riesen, git
In-Reply-To: <76c5b8580910201649i76d14f8bod9a84afa6ea6bbb0@mail.gmail.com>
[-- Attachment #1: Type: TEXT/PLAIN, Size: 4248 bytes --]
On Tue, 20 Oct 2009, Eugene Sajine wrote:
> > I am not sure what you mean by "static linking" anymore. Usually the word
> > means that everything you tell the linker to link to the executable is
> > linked, together with objects from libraries. The resulting executable is
> > usable on its own and it does not change behaviour regardless of which
> > version of dynamic libraries you depend on happen to be installed on the
> > target system (because by definition a statically linked executable does
> > not depend on dynamic libraries---that is the whole point of static
> > linking).
> >
>
> There seems to be no misunderstanding in the static linking - i meant
> the same thing. But let me put an example:
>
> I have a program.exe
>
> This program.exe is built basing on two statically linked libraries
> lib1.lib and lib2.lib
>
> I'm not developing any of those libraries, but only my own code of the
> program.exe
>
> Now, somebody changed 2 files in lib1.lib and 5 files in lib2.lib. But
> i don't know that they are changed because it is different CVS module
> or because I'm building against latest released libs or for whatever
> reason...
>
> When i rebuild my program the build supposed to pick up changes from
> the libraries I'm using and relink, that will include 7 changed obj
> files.
>
> How can i say which exactly files are changed in my new version of
> executable comparing to the previous version?
As Nanako points out, you want a version string from each library,
probably with the name of the library in the symbol. So:
static char *lib1_version = "" VERSION_STRING
in lib1/version.cc.
> Currently they can take a look at the revision number of every
> particular file included into the executable, which is put there by
> CVS and compare it with the production. If the version is different,
> then you know which files are changed and you can get diffs on them...
> They also have file path and date and other stuff expanded...
Once you've got the version strings from each of the components, and
you've got the repository for each library, you can compare the version in
the string with other versions, and that one hash expands to the hashes
for all of the files, including things like the Makefile that don't
actually become object files but affect them.
You can also do things like: when you build an executable, write it as a
blob to the repository and make a tag (actually, a note will be
better, but that's newer than I've done this) pointing to it that lists
everything used to build it. If you encounter the executable again later,
it'll have the same hash, and git can find the tag with the other
information.
I've actually done something where I tagged the main tree and a few
libraries with matching tags, built the executable with a 20-byte
sequence of zeros, put it into the repository, then wrote its sha1 to
those 20 bytes, and tagged the executable with a tag based on the source
tag. Then I put it on a microcontroller, sealed it in epoxy, mixed it with
other devices with different firmware revisions, and sent it out. When a
device had a problem, I could ask it for those 20 bytes, ask git for the
tag that pointed to those 20 bytes, and check out exactly the source used
to build it.
> Please note, my personal goal is *to prove that git can do that
> better*, with less intrusion into the code sources, not other way
> around.So, while keeping the info they want to have they might get
> some benefits of git. Although, i understand that there might be no
> cure for this state already, you can tell me that and I will close the
> topic, but I just keep hoping;)
You're not going to be able to avoid having different tracking things in
the source, but git does give you the major advantage that you can have
the build system produce one hash that identifies every single file in the
project, rather than having to have each file identify itself (and
probably overlook files that don't directly produce object code). It's a
big help the day you're trying to figure out if an executable came from
before or after someone's commit to change the compiler options, and it's
fewer strings than you need with CVS.
-Daniel
*This .sig left intentionally blank*
^ permalink raw reply
* Re: [PATCH] pull: refuse complete src:dst fetchspec arguments
From: Daniel Barkalow @ 2009-10-21 4:32 UTC (permalink / raw)
To: Björn Steinbrink; +Cc: Sean Estabrooks, Thomas Rast, git
In-Reply-To: <20091021031528.GB18997@atjola.homenet>
[-- Attachment #1: Type: TEXT/PLAIN, Size: 1172 bytes --]
On Wed, 21 Oct 2009, Björn Steinbrink wrote:
> On 2009.10.20 20:55:25 -0400, Daniel Barkalow wrote:
> > Maybe it should be fine to do:
> >
> > $ git fetch long-url-here master:temp
> > $ git merge temp
> > $ git checkout other-branch-that-also-needs-it
> > $ git merge temp
> >
> > But "temp" is "refs/remotes/temp", not "refs/heads/temp"?
>
> One (maybe important) difference there is that the "pull" gets you:
>
> Merge branch 'pu' of git://git.kernel.org/pub/scm/git/git
>
> Even with "master:tmp". But with fetch+merge (storing in refs/remotes):
>
> Merge remote branch 'tmp'
It would be nice to improve that in general, I think. You may fetch before
merging in order to check out what you're getting, and then lose
FETCH_HEAD (or have not specified the branch), and you have to contact the
remote server again if you want the message with its url.
> As a minor side-effect, having the "tmp" ref makes re-running the pull
> (for whatever reason) cheaper, as without it, the fetch step would
> possibly re-fetch the whole stuff (not reachable through any local ref).
Only if the merge failed, but yes.
-Daniel
*This .sig left intentionally blank*
^ permalink raw reply
* Re: [RFC] pull/fetch rename
From: Daniel Barkalow @ 2009-10-21 4:22 UTC (permalink / raw)
To: Björn Steinbrink; +Cc: Thomas Rast, git
In-Reply-To: <20091021030608.GA18997@atjola.homenet>
[-- Attachment #1: Type: TEXT/PLAIN, Size: 11651 bytes --]
On Wed, 21 Oct 2009, Björn Steinbrink wrote:
> On 2009.10.20 19:56:01 -0400, Daniel Barkalow wrote:
> > But I don't really know; are there IRC logs you can quote or reference
> > with people making the mistake you're trying to help them avoid?
>
> "git pull" is kind of a jack of all trades WRT user errors, so I'll just
> pick up examples of all kinds, this might get long...
>
> [If you read this and find out that you're quoted/referenced here: I
> don't mean to blame or embarrass you, or to point out that you're stupid
> or whatever. Quite contrary, I just want to show how git's pull UI _might_
> be responsible for your mistakes. The comments I made are purely my,
> possibly biased, reaction to what happened.]
>
> That said, here we go:
>
> 1) Unexpected fast-forward even with --no-ff
>
> "git pull --no-ff abc:abc" with "abc" being checked out.
>
> As pull explicitly allows fetches into the checked out branch head, this
> first fast-forwards abc, and updates the working tree/index. And then
> the --no-ff merge is a no-op.
>
> http://colabti.de/irclogger/irclogger_log/git?date=2009-10-20#l2080
> (Should be a catchable special case, and the special --update-head-ok
> handling of "git pull" is from times where git didn't have remote
> tracking branches. I'd argue that that support should be dropped or at
> least disabled when you're using the modern setup, might be kept for
> oldtimers still using .git/remotes/*. Dunno...)
Yup, I think it would be good to ditch --update-head-ok and simplify the
code; I also think it would be nice to prohibit fetching into refs/heads/*
entirely, but there might be advanced users who actually want to do that.
In this case, "git fetch" has already done something the user didn't want,
and the pull-specific portion doesn't actually do anything at all.
> 2) "git pull" taken as "reset --hard"
> git checkout -b foo; git pull origin bar
>
> The user actually just wanted to look at things and thus was ok with:
> git fetch origin; git checkout origin/bar
>
> http://colabti.de/irclogger/irclogger_log/git?date=2009-10-20#l1807
> (user seemed to be so inclined to use "pull" that he initially didn't
> even realize that he didn't want to merge when I asked whether that's
> what he wants)
I think that's a case where the user has been discouraged from using
detached HEAD, and is using "pull" instead of "fetch" in order to update
the junk branch he doesn't actually want. If you don't know you don't need
a local branch, and you branch off of a common ancestor, "pull" does
actually do something you want that "fetch" doesn't.
> 3) User expects "pull" to update all branch heads that have a configured
> upstream
>
> 08:31 dimsuz hi guys! suppose i'm currently on master. then run git
> fetch. which delivers updates to master and other
> branches. I don't merge anything, but do checkout some
> branch (which is not master). Question: will these new
> updates get into this branch automatically after i check
> it out? question2: will branch master contain those
> updates when i ckeck it out later?
> 08:32 Circuitsoft dimsuz. After a fetch, no.
> 08:33 Circuitsoft However, if you pull, any branches that were set
> up as local tracking branches will get updated.
> 08:33 Circuitsoft Otherwise, only remote tracking branches will be
> updated.
>
> http://colabti.de/irclogger/irclogger_log/git?date=2009-10-20#l969
> (No idea about that one, have seen that once before, but it's definitely
> not even remotely as common as the others)
I'd guess that's due to having local branches with no local changes, just
to avoid detached HEAD, and therefore thinking it's normal to have a bunch
of local branches that could be updated without merges. But I'm on a crazy
"everybody really wants detached HEAD and is needlessly scared" kick, and
I'm probably reading too much into it.
> 4) User expects "pull" to create branches
>
> 07:25 fynn Hey, I just pulled a branch from remote, and I don't see
> it in "git branch"
> 07:25 doener fynn: if you "pull" that means "fetch this and merge it
> to what I have checked out"
> 07:25 fynn doener: hm, I just did "git pull" and it showed the new
> branch
> 07:26 fynn but I don't see it in my branches...
> 07:26 fynn doener: should I create that branch as a tracking branch
> first?
> 07:26 doener fynn: you're looking at "git branch -r" or "git branch
> -a", right?
> 07:26 fynn doener: yeah, I'm seeing it in origin/foo, but not
> local.
> 07:26 doener fynn: the "git fetch" should have created a remote
> tracking branch, as usual, not a local branch head
> (which would be shown by just "git branch")
> 07:27 fynn doener: OK, what should I do to create it locally then?
> 07:28 doener fynn: just the usual "git branch foo origin/foo", or to
> checkout at the same time: "git checkout -b foo
> origin/foo" or "git checkout -t origin/foo" (shortcut)
>
> http://colabti.de/irclogger/irclogger_log/git?date=2009-10-19#l830
> (Note how my "fetch this and merge it" is actually inaccurate for just
> "git pull", there is no "this" and that case. I took "pulled a branch"
> to mean that he did "git pull <remote> <branch>", which wouldn't have
> created/update the remote tracking branch [or did patches for that go
> in? I lost track...])
That sounds like a real converse of "push", including creating like-named
local branches. Or, perhaps, this is someone expecting that "pull" is like
"clone" in creating an initial local branch with the name and value of a
specified remote branch.
> 4b) User expects pull to create a branch head
>
> 09:58 araujo git pull origin <new_branch>
> 09:58 araujo will get me the new branch from repo right?
> 10:00 charon araujo: no, that will fetch *and merge* that branch
> 10:00 araujo charon, how to just pull?
>
> http://colabti.de/irclogger/irclogger_log/git?date=2009-10-19#l1152
> (Note how he asked "how to just pull?", even after being told that pull
> isn't what he wants)
That's got to be hg usage. He knows the command isn't "pull", but he's
stuck with the operation it performs being pulling. Or maybe he's thinking
that the operation is pulling, and the command needs different arguments
to not merge.
> 5) User possibly expecting "pull" to be able to act as "reset --hard"
>
> 21:01 aidan What do I do about this: html/config/core.php: needs
> update
> 21:02 aidan git pull (gives that)
> 21:02 Ilari aidan: You have uncommitted changes to that file...
> 21:15 aidan Ilari: how can I just pull master and overwrite any
> changes?
>
> http://colabti.de/irclogger/irclogger_log/git?date=2009-10-18#l2130
> (I'm not sure about that one, "overwrite any changes" might mean "drop
> uncommitted changes and merge" or "just get me the remote's state,
> dropping my commits and uncommitted changes". Most of the time I've seen
> similar requests, the user wanted the latter).
So I think that's a desire for "git checkout ." first of all (with the
assumption that the content without modifications has to come from
somewhere remote). I don't know what's up with people not wanting to save
their commits, though.
> 6) User says "pull" but probably means "fetch"
>
> 14:08 Alien_Freak once I have a clone of a repo I know you can do
> a checkout tag but is there anyway to pull just
> the tag?
>
> http://colabti.de/irclogger/irclogger_log/git?date=2009-10-16#l1664
> (There was no answer, thus it's hard to tell, but I guess he wanted
> something like:
> git init; git fetch --no-tags url tag <tag>; git checkout <tag>
> At least I'm quite sure he didn't mean "pull" as in "git pull")
I don't know; you can actually do:
$ git init; git pull --no-tags <url> tag <tag>
It updates the master branch and working directory from (nothing) to the
fetched tag.
> 7) User expecting "pull" to just do fast-forwards (or so)
>
> 13:18 ohadlevy I'm getting a merge commit message after each
> time i do git pull, i didnt have it before,
> where should I look?
> 13:20 charon ohadlevy: pull merges; you may just have hit lucky so
> far, and always had a fast-forward merge
> 13:20 ohadlevy charon: any way I could avoid these commits?
> just rebasing? its a pure RO repo
>
> http://colabti.de/irclogger/irclogger_log/git?date=2009-10-16#l1579
> (Apparently, user was tricked by the fast-forward behaviour he
> experienced earlier. I don't see any solution to this, except for
> defaulting to fast-forward-only and requiring a --merge flag (which
> might imply --no-ff), but I'm likely influenced by the "git update"
> stuff here)
Again, sounds like the user does want to update local branch state, if
there is any. Probably doesn't want a local branch, what with being
confused at the possibility of having history that's not from the remote.
> 8) "reset --hard" again
>
> 20:10 roger_padactor i commited then did a pull how do i get back to
> my commit. the pull over wrote the files
> 20:11 merlin83 roger_padactor: you can't, pull == fetch + hard
> reset to latest commit
>
> http://colabti.de/irclogger/irclogger_log/git?date=2009-10-14#l2306
> (Someone being told that pull is fetch + reset --hard is actually new to
> me. Only saw that as an expectation previously.)
That's odd. How could you not notice that it doesn't actually do that,
even if you try to get it to?
> 9) More "git pull <remote> A:A"
>
> 19:10 _hp_ another question, how do I add the remote branch to
> track so I don't have to constantly do git pull origin
> masterA:masterA ?
> 19:11 Ilari _hp_: Don't use that src:dest with pull!
> (discussion died)
>
> http://colabti.de/irclogger/irclogger_log/git?date=2009-10-12#l2427
Yup. Oh, and it strikes me that this user must have never made any
commits, because that would give an error (not fast forward) on the fetch
part.
> 10) "pull" mistaken for "cvs update"
>
> 07:25 Avrem how do I use "git pull" to do something like what "cvs
> update" does ?
> 07:25 Avrem which is, replaces files I've deleted
> 07:25 Avrem from that from the central repository
> 07:30 omega I'm not sure, but can't you git checkout <deleted files>
> to get them back?
>
> http://colabti.de/irclogger/irclogger_log/git?date=2009-10-11#l545
> (This adds a new twist to the "scm update" stuff, although svn/hg don't
> seem to have "restore individual files" in their "update" command, so
> this might be cvs-only. But it's so long since I used cvs, I don't even
> know whether this is correct. But it somehow got me thinking about how
> "update" is actually also "downgrade" in svn/hg, something git does via
> "checkout" [which happens to make more sense to me]. And I think it
> shows how "git pull" is taken to mean "update", even when ignoring the
> special behaviour described here. It's not taken to mean "merge this",
> but just "update to upstream").
"cvs update" can definitely discard uncommitted changes, according to the
--help text.
Actually, I wonder if the right formula is update = fetch + checkout.
There are a lot of people (IMHO) want "git fetch origin; git checkout
origin/master", and I think their first idea is "git update", but that
doesn't exist, and they find "pull" as the closest thing.
> So that's ten days of #git. I left out a bunch of duplications (most
> were "pull == fetch", "pull == update" and "pull to update
> non-checked-out branch").
Very interesting. I feel like this is a new thing since I last spent much
time on IRC, when it was all people pushing into non-bare repositories.
Thanks for taking the time to collect this.
-Daniel
*This .sig left intentionally blank*
^ permalink raw reply
* Re: [PATCH] pull: refuse complete src:dst fetchspec arguments
From: Björn Steinbrink @ 2009-10-21 3:15 UTC (permalink / raw)
To: Daniel Barkalow; +Cc: Sean Estabrooks, Thomas Rast, git
In-Reply-To: <alpine.LNX.2.00.0910202044150.14365@iabervon.org>
On 2009.10.20 20:55:25 -0400, Daniel Barkalow wrote:
> Maybe it should be fine to do:
>
> $ git fetch long-url-here master:temp
> $ git merge temp
> $ git checkout other-branch-that-also-needs-it
> $ git merge temp
>
> But "temp" is "refs/remotes/temp", not "refs/heads/temp"?
One (maybe important) difference there is that the "pull" gets you:
Merge branch 'pu' of git://git.kernel.org/pub/scm/git/git
Even with "master:tmp". But with fetch+merge (storing in refs/remotes):
Merge remote branch 'tmp'
As a minor side-effect, having the "tmp" ref makes re-running the pull
(for whatever reason) cheaper, as without it, the fetch step would
possibly re-fetch the whole stuff (not reachable through any local ref).
Björn, undecided...
^ permalink raw reply
* Re: ident hash usage question
From: Nanako Shiraishi @ 2009-10-21 3:09 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Eugene Sajine, Alex Riesen, git
In-Reply-To: <7vbpk1lmvl.fsf@alter.siamese.dyndns.org>
Quoting Junio C Hamano <gitster@pobox.com>
> If your product ships as one main executable _dynamically_ linked with two
> dynamic libraries, and all three components are built from the source
> material under your source control, obviously you would need to make sure
> that the above version.o or some equivalent of what embeds output from
> "git describe HEAD" are linked to the main executable and to the two
> libraries, but the idea is the same.
Doesn't the above strategy also apply to the case where the
libraries are linked statically, too? You get the version
string from the main program and two version strings from the
libraries embedded in the final product.
--
Nanako Shiraishi
http://ivory.ap.teacup.com/nanako3/
^ permalink raw reply
* Re: [RFC] pull/fetch rename
From: Björn Steinbrink @ 2009-10-21 3:06 UTC (permalink / raw)
To: Daniel Barkalow; +Cc: Thomas Rast, git
In-Reply-To: <alpine.LNX.2.00.0910201912390.14365@iabervon.org>
On 2009.10.20 19:56:01 -0400, Daniel Barkalow wrote:
> But I don't really know; are there IRC logs you can quote or reference
> with people making the mistake you're trying to help them avoid?
"git pull" is kind of a jack of all trades WRT user errors, so I'll just
pick up examples of all kinds, this might get long...
[If you read this and find out that you're quoted/referenced here: I
don't mean to blame or embarrass you, or to point out that you're stupid
or whatever. Quite contrary, I just want to show how git's pull UI _might_
be responsible for your mistakes. The comments I made are purely my,
possibly biased, reaction to what happened.]
That said, here we go:
1) Unexpected fast-forward even with --no-ff
"git pull --no-ff abc:abc" with "abc" being checked out.
As pull explicitly allows fetches into the checked out branch head, this
first fast-forwards abc, and updates the working tree/index. And then
the --no-ff merge is a no-op.
http://colabti.de/irclogger/irclogger_log/git?date=2009-10-20#l2080
(Should be a catchable special case, and the special --update-head-ok
handling of "git pull" is from times where git didn't have remote
tracking branches. I'd argue that that support should be dropped or at
least disabled when you're using the modern setup, might be kept for
oldtimers still using .git/remotes/*. Dunno...)
2) "git pull" taken as "reset --hard"
git checkout -b foo; git pull origin bar
The user actually just wanted to look at things and thus was ok with:
git fetch origin; git checkout origin/bar
http://colabti.de/irclogger/irclogger_log/git?date=2009-10-20#l1807
(user seemed to be so inclined to use "pull" that he initially didn't
even realize that he didn't want to merge when I asked whether that's
what he wants)
3) User expects "pull" to update all branch heads that have a configured
upstream
08:31 dimsuz hi guys! suppose i'm currently on master. then run git
fetch. which delivers updates to master and other
branches. I don't merge anything, but do checkout some
branch (which is not master). Question: will these new
updates get into this branch automatically after i check
it out? question2: will branch master contain those
updates when i ckeck it out later?
08:32 Circuitsoft dimsuz. After a fetch, no.
08:33 Circuitsoft However, if you pull, any branches that were set
up as local tracking branches will get updated.
08:33 Circuitsoft Otherwise, only remote tracking branches will be
updated.
http://colabti.de/irclogger/irclogger_log/git?date=2009-10-20#l969
(No idea about that one, have seen that once before, but it's definitely
not even remotely as common as the others)
4) User expects "pull" to create branches
07:25 fynn Hey, I just pulled a branch from remote, and I don't see
it in "git branch"
07:25 doener fynn: if you "pull" that means "fetch this and merge it
to what I have checked out"
07:25 fynn doener: hm, I just did "git pull" and it showed the new
branch
07:26 fynn but I don't see it in my branches...
07:26 fynn doener: should I create that branch as a tracking branch
first?
07:26 doener fynn: you're looking at "git branch -r" or "git branch
-a", right?
07:26 fynn doener: yeah, I'm seeing it in origin/foo, but not
local.
07:26 doener fynn: the "git fetch" should have created a remote
tracking branch, as usual, not a local branch head
(which would be shown by just "git branch")
07:27 fynn doener: OK, what should I do to create it locally then?
07:28 doener fynn: just the usual "git branch foo origin/foo", or to
checkout at the same time: "git checkout -b foo
origin/foo" or "git checkout -t origin/foo" (shortcut)
http://colabti.de/irclogger/irclogger_log/git?date=2009-10-19#l830
(Note how my "fetch this and merge it" is actually inaccurate for just
"git pull", there is no "this" and that case. I took "pulled a branch"
to mean that he did "git pull <remote> <branch>", which wouldn't have
created/update the remote tracking branch [or did patches for that go
in? I lost track...])
4b) User expects pull to create a branch head
09:58 araujo git pull origin <new_branch>
09:58 araujo will get me the new branch from repo right?
10:00 charon araujo: no, that will fetch *and merge* that branch
10:00 araujo charon, how to just pull?
http://colabti.de/irclogger/irclogger_log/git?date=2009-10-19#l1152
(Note how he asked "how to just pull?", even after being told that pull
isn't what he wants)
5) User possibly expecting "pull" to be able to act as "reset --hard"
21:01 aidan What do I do about this: html/config/core.php: needs
update
21:02 aidan git pull (gives that)
21:02 Ilari aidan: You have uncommitted changes to that file...
21:15 aidan Ilari: how can I just pull master and overwrite any
changes?
http://colabti.de/irclogger/irclogger_log/git?date=2009-10-18#l2130
(I'm not sure about that one, "overwrite any changes" might mean "drop
uncommitted changes and merge" or "just get me the remote's state,
dropping my commits and uncommitted changes". Most of the time I've seen
similar requests, the user wanted the latter).
6) User says "pull" but probably means "fetch"
14:08 Alien_Freak once I have a clone of a repo I know you can do
a checkout tag but is there anyway to pull just
the tag?
http://colabti.de/irclogger/irclogger_log/git?date=2009-10-16#l1664
(There was no answer, thus it's hard to tell, but I guess he wanted
something like:
git init; git fetch --no-tags url tag <tag>; git checkout <tag>
At least I'm quite sure he didn't mean "pull" as in "git pull")
7) User expecting "pull" to just do fast-forwards (or so)
13:18 ohadlevy I'm getting a merge commit message after each
time i do git pull, i didnt have it before,
where should I look?
13:20 charon ohadlevy: pull merges; you may just have hit lucky so
far, and always had a fast-forward merge
13:20 ohadlevy charon: any way I could avoid these commits?
just rebasing? its a pure RO repo
http://colabti.de/irclogger/irclogger_log/git?date=2009-10-16#l1579
(Apparently, user was tricked by the fast-forward behaviour he
experienced earlier. I don't see any solution to this, except for
defaulting to fast-forward-only and requiring a --merge flag (which
might imply --no-ff), but I'm likely influenced by the "git update"
stuff here)
8) "reset --hard" again
20:10 roger_padactor i commited then did a pull how do i get back to
my commit. the pull over wrote the files
20:11 merlin83 roger_padactor: you can't, pull == fetch + hard
reset to latest commit
http://colabti.de/irclogger/irclogger_log/git?date=2009-10-14#l2306
(Someone being told that pull is fetch + reset --hard is actually new to
me. Only saw that as an expectation previously.)
9) More "git pull <remote> A:A"
19:10 _hp_ another question, how do I add the remote branch to
track so I don't have to constantly do git pull origin
masterA:masterA ?
19:11 Ilari _hp_: Don't use that src:dest with pull!
(discussion died)
http://colabti.de/irclogger/irclogger_log/git?date=2009-10-12#l2427
10) "pull" mistaken for "cvs update"
07:25 Avrem how do I use "git pull" to do something like what "cvs
update" does ?
07:25 Avrem which is, replaces files I've deleted
07:25 Avrem from that from the central repository
07:30 omega I'm not sure, but can't you git checkout <deleted files>
to get them back?
http://colabti.de/irclogger/irclogger_log/git?date=2009-10-11#l545
(This adds a new twist to the "scm update" stuff, although svn/hg don't
seem to have "restore individual files" in their "update" command, so
this might be cvs-only. But it's so long since I used cvs, I don't even
know whether this is correct. But it somehow got me thinking about how
"update" is actually also "downgrade" in svn/hg, something git does via
"checkout" [which happens to make more sense to me]. And I think it
shows how "git pull" is taken to mean "update", even when ignoring the
special behaviour described here. It's not taken to mean "merge this",
but just "update to upstream").
So that's ten days of #git. I left out a bunch of duplications (most
were "pull == fetch", "pull == update" and "pull to update
non-checked-out branch").
Björn
^ permalink raw reply
* Re: [RFC] pull/fetch rename
From: Wesley J. Landaker @ 2009-10-21 2:01 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Thomas Rast, git, Björn Steinbrink
In-Reply-To: <7v7huplkyj.fsf@alter.siamese.dyndns.org>
On Tuesday 20 October 2009 17:11:32 Junio C Hamano wrote:
> Thomas Rast <trast@student.ethz.ch> writes:
> > Junio C Hamano wrote:
> >> "Wesley J. Landaker" <wjl@icecavern.net> writes:
> >
> > ...
> > There would not be a configuration option.
> > ...
> >
> >> It's not even funny.
>
> Re-read what you were responding to and notice that I was commenting on
> Wesley's proposal that _is_ about a configuration variable.
Yes, I brought up the configuration variable, not Thomas.
My main goal was to try to suggest a transition plan that would be less
painful, but maybe it was actually worse. After reading Junio's response I
think I agree that going down that path might be the worst of both worlds,
but the basic model I was proposing (even if it's a bad idea in this case)
was largely basing on (my perceived impression of) how the recent changes to
push behavior were staged (i.e. with deprecation, new configuration
variables, etc).
I still think that, long term, making push and pull symmetric, EITHER by 1)
making push also update the working tree (in some sane way that I don't have
a proposal for) or 2) making pull be just about transfering objects, not
also merging (in some reasonable way that doesn't break useability, like
also adding "git update" or something at the same time) would be an overall
benefit.
^ permalink raw reply
* Re: [PATCH] pull: refuse complete src:dst fetchspec arguments
From: Sean Estabrooks @ 2009-10-21 1:35 UTC (permalink / raw)
To: Daniel Barkalow; +Cc: Thomas Rast, git
In-Reply-To: <alpine.LNX.2.00.0910202044150.14365@iabervon.org>
On Tue, 20 Oct 2009 20:55:25 -0400 (EDT)
Daniel Barkalow <barkalow@iabervon.org> wrote:
> > Maybe, but it could also just be to create a temp local branch for
> > merging into additional branches afterward with "checkout other;
> > merge temp". This is especially helpful when pulling from an
> > annoyingly long URL instead of from a configured remote.
>
> Maybe it should be fine to do:
>
> $ git fetch long-url-here master:temp
> $ git merge temp
> $ git checkout other-branch-that-also-needs-it
> $ git merge temp
>
> But "temp" is "refs/remotes/temp", not "refs/heads/temp"?
Well that's only one example of possibile uses for fetching directly to
a local branch, perhaps as a new base of further development. Is there
really a compelling reason to force someone to fetch into refs/remotes
and then do the extra step of checking it out locally?
> I think, actually, that creating or changing a local branch is really not
> what "fetch" (or the fetch part of pull) is about. I think that just leads
> to confusion about what's locally-controlled and what's a local memory of
> something remotely-controlled.
Well it's a handy shortcut for several situations. There must be a way
to protect less adroit Git users without removing functionality.
Sean
^ permalink raw reply
* Re: git gc and kernel.org
From: H. Peter Anvin @ 2009-10-21 1:00 UTC (permalink / raw)
To: Mikael Magnusson; +Cc: Git Mailing List, ftpadmin
In-Reply-To: <237967ef0910200208t290d7ba2l15c75081da5448de@mail.gmail.com>
On 10/20/2009 06:08 PM, Mikael Magnusson wrote:
>
> I don't know how you create repos on kernel.org, but by default both
> git init and git clone uses /usr/share/git-core/templates for the new
> repo, for example I put a symbolic ref h -> HEAD there to save some
> typing. You can enable whatever hooks you want there, but they would
> only take effect for new repos.
>
They only take effect for new repos, and any changes I do there get
messed up when git is updated.
-hpa
^ permalink raw reply
* Re: [PATCH] pull: refuse complete src:dst fetchspec arguments
From: Daniel Barkalow @ 2009-10-21 0:55 UTC (permalink / raw)
To: Sean Estabrooks; +Cc: Thomas Rast, git
In-Reply-To: <BLU0-SMTP889B2109047E949E039EFDAEBF0@phx.gbl>
On Tue, 20 Oct 2009, Sean Estabrooks wrote:
> On Tue, 20 Oct 2009 20:15:23 -0400 (EDT)
> Daniel Barkalow <barkalow@iabervon.org> wrote:
>
> Hi Daniel,
>
> > Surely, "where you want the head stored locally" is somewhere that's
> > information about a remote repository, and therefore under "refs/remotes/"
> > (or "refs/tags/" or something) and therefore not possible to be checked
> > out (in the "HEAD is a symref to it" sense).
>
> Maybe, but it could also just be to create a temp local branch for
> merging into additional branches afterward with "checkout other;
> merge temp". This is especially helpful when pulling from an
> annoyingly long URL instead of from a configured remote.
Maybe it should be fine to do:
$ git fetch long-url-here master:temp
$ git merge temp
$ git checkout other-branch-that-also-needs-it
$ git merge temp
But "temp" is "refs/remotes/temp", not "refs/heads/temp"?
> > Actually, I think it would be good to prohibit fetching into a new or
> > existing local branch, whether or not it is checked out. We'd probably
> > need to provide a plumbing method of doing a fetch, though, for script
> > environments that aren't using the normal porcelain meanings of refs/
> > subdirectories. (Defining a bare repo with --mirror as not having local
> > branches, of course)
>
> I'm hoping you don't mean that all fetching to a new local branch should
> be prohibited and you're only talking about the current issue of full
> refspecs on and the pull command. Otherwise i'd say it seems
> unnecessarily restrictive.
I think, actually, that creating or changing a local branch is really not
what "fetch" (or the fetch part of pull) is about. I think that just leads
to confusion about what's locally-controlled and what's a local memory of
something remotely-controlled.
-Daniel
*This .sig left intentionally blank*
^ permalink raw reply
* Re: [PATCH] pull: refuse complete src:dst fetchspec arguments
From: Sean Estabrooks @ 2009-10-21 0:29 UTC (permalink / raw)
To: Daniel Barkalow; +Cc: Thomas Rast, git
In-Reply-To: <alpine.LNX.2.00.0910202001050.14365@iabervon.org>
On Tue, 20 Oct 2009 20:15:23 -0400 (EDT)
Daniel Barkalow <barkalow@iabervon.org> wrote:
Hi Daniel,
> Surely, "where you want the head stored locally" is somewhere that's
> information about a remote repository, and therefore under "refs/remotes/"
> (or "refs/tags/" or something) and therefore not possible to be checked
> out (in the "HEAD is a symref to it" sense).
Maybe, but it could also just be to create a temp local branch for
merging into additional branches afterward with "checkout other;
merge temp". This is especially helpful when pulling from an
annoyingly long URL instead of from a configured remote.
> I don't think it should be possible to fast-forward or create a local
> branch from a remote branch while simultaneously merging it into the
> currently-checked-out local branch.
What is the harm? Nobody is forced to use the facility and it does
have some marginal utility. I'd not fight for it, but i don't yet
understand the argument to prohibit it.
> Actually, I think it would be good to prohibit fetching into a new or
> existing local branch, whether or not it is checked out. We'd probably
> need to provide a plumbing method of doing a fetch, though, for script
> environments that aren't using the normal porcelain meanings of refs/
> subdirectories. (Defining a bare repo with --mirror as not having local
> branches, of course)
I'm hoping you don't mean that all fetching to a new local branch should
be prohibited and you're only talking about the current issue of full
refspecs on and the pull command. Otherwise i'd say it seems
unnecessarily restrictive.
Cheers,
Sean
^ permalink raw reply
* Re: [PATCH] receive-pack: run "gc --auto" and optionally "update-server-info"
From: Nicolas Pitre @ 2009-10-21 0:21 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Johan Herland, git, H. Peter Anvin, ftpadmin
In-Reply-To: <7vljj5lofb.fsf_-_@alter.siamese.dyndns.org>
On Tue, 20 Oct 2009, Junio C Hamano wrote:
> Introduce two new configuration variables, receive.autogc (defaults to
> true) and receive.updateserverinfo (defaults to false). When these are
> set, receive-pack runs "gc --auto" and "update-server-info" respectively
> after it finishes receiving data from "git push" and updating refs.
>
> Signed-off-by: Junio C Hamano <gitster@pobox.com>
Acked-by: Nicolas Pitre <nico@fluxnic.net>
> ---
>
> Nicolas Pitre <nico@fluxnic.net> writes:
>
> > On Tue, 20 Oct 2009, Junio C Hamano wrote:
> >
> >> Nicolas Pitre <nico@fluxnic.net> writes:
> >>
> >> > Still... Hopefully this is going to become redundant information in the
> >> > future with the eventual deployment of smart protocol over HTTP. So I
> >> > think that as a config option being off by default this is a good
> >> > compromize. Site administrators can turn it on by default in
> >> > /etc/gitconfig.
> >>
> >> Ok, something like this?
> >
> > Looks fine to me, except...
>
> Everything you said sounded sensible. Thanks.
>
> Documentation/config.txt | 9 +++++++++
> builtin-receive-pack.c | 18 ++++++++++++++++++
> 2 files changed, 27 insertions(+), 0 deletions(-)
>
> diff --git a/Documentation/config.txt b/Documentation/config.txt
> index cd17814..ba6ed10 100644
> --- a/Documentation/config.txt
> +++ b/Documentation/config.txt
> @@ -1320,6 +1320,11 @@ rebase.stat::
> Whether to show a diffstat of what changed upstream since the last
> rebase. False by default.
>
> +receive.autogc::
> + By default, git-receive-pack will run "git-gc --auto" after
> + receiving data from git-push and updating refs. You can stop
> + it by setting this variable to false.
> +
> receive.fsckObjects::
> If it is set to true, git-receive-pack will check all received
> objects. It will abort in the case of a malformed object or a
> @@ -1355,6 +1360,10 @@ receive.denyNonFastForwards::
> even if that push is forced. This configuration variable is
> set when initializing a shared repository.
>
> +receive.updateserverinfo::
> + If set to true, git-receive-pack will run git-update-server-info
> + after receiving data from git-push and updating refs.
> +
> remote.<name>.url::
> The URL of a remote repository. See linkgit:git-fetch[1] or
> linkgit:git-push[1].
> diff --git a/builtin-receive-pack.c b/builtin-receive-pack.c
> index b771fe9..92173ac 100644
> --- a/builtin-receive-pack.c
> +++ b/builtin-receive-pack.c
> @@ -28,6 +28,8 @@ static int transfer_unpack_limit = -1;
> static int unpack_limit = 100;
> static int report_status;
> static int prefer_ofs_delta = 1;
> +static int auto_update_server_info;
> +static int auto_gc = 1;
> static const char *head_name;
> static char *capabilities_to_send;
>
> @@ -88,6 +90,16 @@ static int receive_pack_config(const char *var, const char *value, void *cb)
> return 0;
> }
>
> + if (strcmp(var, "receive.updateserverinfo") == 0) {
> + auto_update_server_info = git_config_bool(var, value);
> + return 0;
> + }
> +
> + if (strcmp(var, "receive.autogc") == 0) {
> + auto_gc = git_config_bool(var, value);
> + return 0;
> + }
> +
> return git_default_config(var, value, cb);
> }
>
> @@ -672,6 +684,12 @@ int cmd_receive_pack(int argc, const char **argv, const char *prefix)
> report(unpack_status);
> run_receive_hook(post_receive_hook);
> run_update_post_hook(commands);
> + if (auto_gc) {
> + const char *argv_gc_auto[] = { "gc", "--auto", NULL };
> + run_command_v_opt(argv_gc_auto, RUN_GIT_CMD);
> + }
> + if (auto_update_server_info)
> + update_server_info(0);
> }
> return 0;
> }
> --
> 1.6.5.1.107.gba912
>
^ 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