* Re: [PATCHv5 2/5] gitweb: Incremental blame (using JavaScript)
From: Petr Baudis @ 2009-11-05 20:22 UTC (permalink / raw)
To: Jakub Narebski
Cc: git, Fredrik Kuivinen, Giuseppe Bilotta, Luben Tuikov,
Martin Koegler
In-Reply-To: <1251805160-5303-3-git-send-email-jnareb@gmail.com>
Hi!
Many thanks for nurturing this patch.
On Tue, Sep 01, 2009 at 01:39:17PM +0200, Jakub Narebski wrote:
> Roads not taken (perhaps that should be part of commit message?):
> * Move most (or all) of "git blame --incremental" output parsing to
> server side, and instead of sending direct output in text/plain,
> send processed data in JSON format, e.g.
>
> {"commit": {
> "sha1": "e83c5163316f89bfbde7d9ab23ca2e25604af290",
> "info": "Kay Sievers, 2005-08-07 21:49:46 +0200",
> "author-initials": "KS",
> ...
> },
> "src-line": 13,
> "dst-line": 16,
> "numlines": 3,
> "filename": "README"
> }
>
> (line wrapping added for readibility). This would require however
> taking care on Perl side to send properly formatted JSON, and on
> JavaScript side including json2.js code to read JSON in gitweb.js
> (unless we rely on eval).
I don't know that much about web programming, what is wrong with
relying on eval?
(BTW, I have always thought that somewhat inevitable course in the
future will be to provide a web API, and basing it on JSON is probably
most natural choice. However, such an initiative needs to come from
actual web programmers.)
> * Using some lightweight JavaScript library (framework), like jQuery,
> Prototype, ExtJS, MooTools, etc. One one hand side this means not
> having to worry about browser incompatibilities as this would be
> taken care of by library; on the other hand side we want gitweb to
> have as few dependences as possible.
Normally, particular version of the library is simply included within
the project. E.g. in Girocco, I use MooTools for the tiny bit of
javascript I do. It is probably overkill to include it just for
incremental blame, but if we ever do much more, I think the much easier
web programming is worth the little trouble.
--
Petr "Pasky" Baudis
A lot of people have my books on their bookshelves.
That's the problem, they need to read them. -- Don Knuth
^ permalink raw reply
* Re: [QGIT PATCH/RFC]
From: Marco Costalba @ 2009-11-05 20:25 UTC (permalink / raw)
To: Abdelrazak Younes; +Cc: git
In-Reply-To: <4AF2AAFD.9000309@lyx.org>
On Thu, Nov 5, 2009 at 11:37, Abdelrazak Younes <younes@lyx.org> wrote:
>
> I recompiled qgit with the Qt version and I didn't notice any performance
> problem with a big repo (Qt).
>
In git we don't need to compute hashes of sha strings because they are
already hashed !
That's the idea of using a custom hashing function that does nothing
but taking the first chars of the sha string. Instead the general
purpose Qt hashing must do real work because it has to work for any
string.
When I tested I _found_ a speed difference, but now I don't remember
of how much. Be sure you have warm cache when doing the test (press
F5) for few times to be sure all is in RAM.
> Just tell me if this is not interesting to you and I'll shut up :-)
>
No, it is very interesting indeed. My bad I have no time for net access today.
If QByteArray is faster then QLatin1String() we should definitely
change. But if I don't remember wrong QLatin1String() is already
implemented above a QByteArray and the methods that we use are
inherited directly from a QByteArray, but I may be wrong. I don't have
access to the sources now. I only remember that when I implemented
that part it took a good amount of time and testing ;-)
Thanks
Marco
^ permalink raw reply
* Re: [QGIT PATCH/RFC]
From: Marco Costalba @ 2009-11-05 20:27 UTC (permalink / raw)
To: Abdelrazak Younes; +Cc: git
In-Reply-To: <e5bfff550911051225s13c6e39dh355dc3ab1c0623f@mail.gmail.com>
On Thu, Nov 5, 2009 at 21:25, Marco Costalba <mcostalba@gmail.com> wrote:
>
> When I tested I _found_ a speed difference, but now I don't remember
> of how much. Be sure you have warm cache when doing the test (press
> F5) for few times to be sure all is in RAM.
>
Sorry, I forgot. Be sure also our custom hashing function is actually
called in your binary and the compiler didn't linked the Qt one
instead :-)
^ permalink raw reply
* Re: [PATCHv3/RFC 4/5] gitweb: Create links leading to 'blame_incremental' using JavaScript
From: Petr Baudis @ 2009-11-05 20:33 UTC (permalink / raw)
To: Jakub Narebski
Cc: git, Fredrik Kuivinen, Giuseppe Bilotta, Luben Tuikov,
Martin Koegler
In-Reply-To: <1251805160-5303-5-git-send-email-jnareb@gmail.com>
Hi!
On Tue, Sep 01, 2009 at 01:39:19PM +0200, Jakub Narebski wrote:
> @@ -4806,6 +4820,10 @@ sub git_tag {
>
> sub git_blame_common {
> my $format = shift || 'porcelain';
> + if ($format eq 'porcelain' && $cgi->param('js')) {
> + $format = 'incremental';
> + $action = 'blame_incremental'; # for page title etc
> + }
>
> # permissions
> gitweb_check_feature('blame')
I'm a bit concerned here. I have somewhat backed out of incremental
blame myself because I have found (in accord with Junio's old findings)
that in most cases, incremental blame can be actually slower than normal
blame because of slow browsers where it takes long to update the page in
each step.
I'm sorry if I missed this in one of your mails, but how fast is
incremental blame in your implementation? If this still might be an
issue, I think it should be configurable whether to use incremental
blame, or perhaps use some quick heuristic wrt. file size (negative
bias) and history length (positive bias) [not sure if that information
is quickly available].
--
Petr "Pasky" Baudis
A lot of people have my books on their bookshelves.
That's the problem, they need to read them. -- Don Knuth
^ permalink raw reply
* Re: [PATCH] MSVC: Windows-native implementation for subset of Pthreads API
From: Andrzej K. Haczewski @ 2009-11-05 20:38 UTC (permalink / raw)
To: Nicolas Pitre; +Cc: kusmabite, git, Johannes Sixt
In-Reply-To: <alpine.LFD.2.00.0911051422590.10340@xanadu.home>
2009/11/5 Nicolas Pitre <nico@fluxnic.net>:
> Why not? At least gcc is quite happy with such a construct. It
> probably makes a copy of the stack before passing it though.
Err... my mind is rotted with all that ugly java, c#, python and ruby,
even c++. I should start taking some medications I suppose... what was
I thinking is that C can't copy-construct a struct. Damn, too much sun
(of java fame)...
That way I rediscovered simple struct construct...man I missed C so much :)
Anyway, the solution with passing pthread_t as pointer saves some
stack, so it's probably not that bad.
--
Andrzej
^ permalink raw reply
* Re: [PATCH] MSVC: Windows-native implementation for subset of Pthreads API
From: Nicolas Pitre @ 2009-11-05 20:36 UTC (permalink / raw)
To: Andrzej K. Haczewski
Cc: git, kusmabite, Johannes Schindelin, Johannes Sixt, Paolo Bonzini
In-Reply-To: <16cee31f0911051209jcc490e2pabeab9a1b6e3b11d@mail.gmail.com>
[-- Attachment #1: Type: TEXT/PLAIN, Size: 1095 bytes --]
On Thu, 5 Nov 2009, Andrzej K. Haczewski wrote:
> 2009/11/5 Nicolas Pitre <nico@fluxnic.net>:
> > On Thu, 5 Nov 2009, Andrzej K. Haczewski wrote:
> >
> >> +static unsigned __stdcall win32_start_routine(void *arg)
> >> +{
> >> + pthread_t *thread = arg;
> >> + thread->value = thread->start_routine(thread->arg);
> >> + return 0;
> >> +}
> >
> > I suppose you could reuse thread->arg for both the argument and the
> > returned value to save a word.
>
> You're right! J6t committed already, what can I do now?
Just post a replacement patch.
> > Why are you casting thread->handle here? Why not simply declaring it as
> > a HANDLE?
>
> Just to silence MSVC warnings. WaitForSingleObject requires HANDLE,
> _beginthreadex() returns uintptr_t. It's just a matter of where would
> I put cast ;).
Wonderful. One could wonder why Windows can't have coherent
interfaces...
Well, given that all existing usages in the tree (run-command.c and
compat/mingw.c) already cast the _beginthreadex() return value instead,
then that might be a good idea to follow the same model.
Nicolas
^ permalink raw reply
* Re: [PATCH] MSVC: Windows-native implementation for subset of Pthreads API
From: Nicolas Pitre @ 2009-11-05 22:15 UTC (permalink / raw)
To: Andrzej K. Haczewski; +Cc: kusmabite, git, Johannes Sixt
In-Reply-To: <16cee31f0911051238v71ec4b57s415efb7bb48999d1@mail.gmail.com>
[-- Attachment #1: Type: TEXT/PLAIN, Size: 990 bytes --]
On Thu, 5 Nov 2009, Andrzej K. Haczewski wrote:
> 2009/11/5 Nicolas Pitre <nico@fluxnic.net>:
> > Why not? At least gcc is quite happy with such a construct. It
> > probably makes a copy of the stack before passing it though.
"a copy of the struct" I meant here.
> Err... my mind is rotted with all that ugly java, c#, python and ruby,
> even c++. I should start taking some medications I suppose... what was
> I thinking is that C can't copy-construct a struct. Damn, too much sun
> (of java fame)...
>
> That way I rediscovered simple struct construct...man I missed C so much :)
Welcome back ! ;-)
> Anyway, the solution with passing pthread_t as pointer saves some
> stack, so it's probably not that bad.
Yep, just what I said. Normally if you pass a structure to a function,
it will be copied beforehand so modifications by the callee won't be
seen by the caller. But in this case we don't care, hence passing the
original structure address is more efficient.
Nicolas
^ permalink raw reply
* Re: Preserving branches after merging on ancestor
From: Jonathan Nieder @ 2009-11-05 22:30 UTC (permalink / raw)
To: Richard Lee; +Cc: git
In-Reply-To: <26217077.post@talk.nabble.com>
Hi Richard,
Richard Lee wrote:
> One way of getting round this problem is to use empty commits on the master
> branch, as shown below.
>
> * 6fc04b5 Merge branch 'feature2'
> |\
> | * 07a117b stuff on feature2
> * | 52f5ba1 Empty commit
> |/
> * 5deaa93 Merge branch 'feature1'
> |\
> | * b163b17 stuff on feature1
> | * 53bb820 stuff on feature1
> | * c9ef14c stuff on feature1
> * | 34227a3 Empty commit
> |/
> * e88d332 Init
>
> But is this correct? It seems rather hackish to create empty commits on the
> master branch just to historically preserve commits on a seperate branch.
> Should I be using feature branches in git like this or another way? For
> example more informative commit messages.
As Eric said, you can avoid the empty commits by passing 'git merge'
the --no-ff option, which would give the history I think you intend:
* 26749ab Merge branch 'feature2'
|\
| * b9cd8ff stuff on feature2
|/
* 829ba2c Merge branch 'feature1'
|\
| * b163b17 stuff on feature1
| * 53bb820 stuff on feature1
| * c9ef14c stuff on feature1
|/
* e88d332 Init
But doing this misses some of the main benefits of feature branches
imho.
If you base each feature branch on the stable release or features it
depends on instead, this gives you the freedom to merge one feature without
the others to another branch. For example:
# wouldn’t feature1 be neat? let me try it.
git checkout -b feature1 v1.0
hack hack hack
# looks good.
git commit -a
# how about an unrelated feature2?
git checkout -b feature2 v1.0
hack hack hack
# looks good.
git commit -a
# but do they work?
git checkout v1.0; # detach head for testing [1]
git merge feature1 feature2
make check
# hmm, these don’t seem to work well together
... (investigating some more)
# looks like feature1 is not ready for prime time
# so let’s just use feature2 for now.
git checkout master
git merge feature2
git branch -d feature2
make check
# looks good; better publish it.
git push origin master
v1.0 --- feature1
\
\-- feature2 [master]
As a nice side-effect, if you work this way then you can develop
feature2 without being distracted by new bugs introduced by feature1.
With many features built this way, the revision graph starts to give
some hints about relationships between features developed around the
same time. For example, with the history
v1.0 --- feature1 --- feature2 -- feature4 -- feature6 - v1.1
\ /
-- feature5 ------------
feature4 and feature5 are not likely to be closely related, but
feature4 and feature6 might be. The exact history of merges is less
important than the general "shape" of the graph.
Thanks for the food for thought.
Hope that helps,
Jonathan
[1] See <http://www.kernel.org/pub/software/scm/git/docs/git-checkout.html#_detached_head>.
^ permalink raw reply
* Re: Automatically remote prune
From: Jay Soffian @ 2009-11-05 23:09 UTC (permalink / raw)
To: Junio C Hamano; +Cc: John Tapsell, Git List
In-Reply-To: <7v3a4sagau.fsf@alter.siamese.dyndns.org>
On Thu, Nov 5, 2009 at 3:05 PM, Junio C Hamano <gitster@pobox.com> wrote:
> The necessary change to "git fetch" shouldn't be too hard to code, as we
> are already doing this in mirror mode.
Actually, mirror mode applies to push only. Unless I'm missing
something obvious.
Thus, adding prune to builtin-fetch duplicates the logic from
builtin-remote, unless I do some refactoring. Hmph, I was hoping for a
15 minute patch. :-(
j.
^ permalink raw reply
* Re: Preserving branches after merging on ancestor
From: Björn Steinbrink @ 2009-11-05 23:28 UTC (permalink / raw)
To: Jonathan Nieder; +Cc: Richard Lee, git
In-Reply-To: <20091105223004.GA3224@progeny.tock>
On 2009.11.05 16:30:04 -0600, Jonathan Nieder wrote:
> But doing this misses some of the main benefits of feature branches
> imho.
>
> If you base each feature branch on the stable release or features it
> depends on instead, this gives you the freedom to merge one feature without
> the others to another branch.
I guess Richard took the "branch topic1, merge topic1, branch topic2,
merge topic2" thing just as an example because that ends up with two
fast-forwards. And your example _still_ has such a fast-forward.
> For example:
>
> # wouldn’t feature1 be neat? let me try it.
> git checkout -b feature1 v1.0
> hack hack hack
> # looks good.
> git commit -a
>
> # how about an unrelated feature2?
> git checkout -b feature2 v1.0
> hack hack hack
> # looks good.
> git commit -a
>
> # but do they work?
> git checkout v1.0; # detach head for testing [1]
> git merge feature1 feature2
> make check
> # hmm, these don’t seem to work well together
> ... (investigating some more)
>
> # looks like feature1 is not ready for prime time
> # so let’s just use feature2 for now.
> git checkout master
> git merge feature2
> git branch -d feature2
> make check
> # looks good; better publish it.
> git push origin master
>
> v1.0 --- feature1
> \
> \-- feature2 [master]
And here you got a fast-forward of master to feature2, i.e. linear
history, which is what Richard was trying to avoid.
Instead of:
A---B---C---D---E (topic2) (master)
\
F---G---H (topic1)
He wants:
F---G---H (topic1)
/
A---B-----------M (master)
\ /
C---D---E (topic2)
So he can see at which point topic2 got merged. This allows to ask "which
commits got merged here" (and for a merge-once topic branch this means:
Which commits are related to that topic), by using for example:
git log M^1..M^2 # Will show C, D and E
In the fast-forward case, there's no way to get that without manually
figuring out where the topic branch started.
Björn
^ permalink raw reply
* Re: [PATCH v2 09/13] Honour the refspec when updating refs after import
From: Sverre Rabbelier @ 2009-11-05 23:51 UTC (permalink / raw)
To: Daniel Barkalow; +Cc: Git List, Johannes Schindelin, Johan Herland
In-Reply-To: <alpine.LNX.2.00.0911050145010.14365@iabervon.org>
Heya,
On Thu, Nov 5, 2009 at 07:53, Daniel Barkalow <barkalow@iabervon.org> wrote:
> Here's a patch (on my original series, which doesn't seem to be in pu any
> more, but should be floating around somewhere).
Why didn't you just base it against sr/vcs-helper which is currently
in pu, now I have to try to find where your original series was, and
rebase this patch against it. Assuming your main goal was to
illustrate the direction you think we should go it would have been a
lot easier that way.
--
Cheers,
Sverre Rabbelier
^ permalink raw reply
* Re: [PATCH v2 13/13] Add Python support library for remote helpers
From: Sverre Rabbelier @ 2009-11-06 0:14 UTC (permalink / raw)
To: Johan Herland
Cc: Git List, Johannes Schindelin, Daniel Barkalow, David Aguilar
In-Reply-To: <200911050855.01164.johan@herland.net>
Heya,
On Thu, Nov 5, 2009 at 08:55, Johan Herland <johan@herland.net> wrote:
> There are a few typos in the above.
Thanks, fixed locally, will include this in the next version.
> Otherwise it all looks good. Nice work!
Cool, thanks!
--
Cheers,
Sverre Rabbelier
^ permalink raw reply
* Re: Automatically remote prune
From: Petr Baudis @ 2009-11-06 0:16 UTC (permalink / raw)
To: John Tapsell; +Cc: Junio C Hamano, Git List
In-Reply-To: <43d8ce650911050005l6d120cb0h374f3c04b3948b25@mail.gmail.com>
On Thu, Nov 05, 2009 at 05:05:50PM +0900, John Tapsell wrote:
> 2009/11/5 Junio C Hamano <gitster@pobox.com>:
> > John Tapsell <johnflux@gmail.com> writes:
> > "what the benefits are to give this information _in the 'branch' output_"
> > was what I meant. From the part you omitted from my message:
>
> I omitted it just because, imho, it's not what I 'care about'. I'm
> not trying to help advanced users (Users that _want_ to keep
> remotes/origin/* clean and users that _want_ to be careful to not lose
> commits are both advanced users, imho). I'm just interested in
> reducing confusion for non-advanced users. So either not-showing
> removed remote branches by default, or showing them but marking them
> as deleted.
Maybe, if your users want to know "what branches does the remote repo
have" instead of "what branches does my 'image' of the remote repo has",
just teach them to run
git remote show origin
instead of
git branch -r origin
as mentioned earlier by Junio?
Of course, users would still need to realize the actual meaning of the
commands and the fact that Git _does_ keep a distinctive 'image of
remote repository', so this may not be the most intuitive solution.
--
Petr "Pasky" Baudis
A lot of people have my books on their bookshelves.
That's the problem, they need to read them. -- Don Knuth
^ permalink raw reply
* Re: Automatically remote prune
From: Petr Baudis @ 2009-11-06 0:17 UTC (permalink / raw)
To: Jay Soffian; +Cc: Junio C Hamano, John Tapsell, Git List
In-Reply-To: <76718490911051509r65af2dd2k2574e2e521fed6f2@mail.gmail.com>
On Thu, Nov 05, 2009 at 06:09:03PM -0500, Jay Soffian wrote:
> On Thu, Nov 5, 2009 at 3:05 PM, Junio C Hamano <gitster@pobox.com> wrote:
> > The necessary change to "git fetch" shouldn't be too hard to code, as we
> > are already doing this in mirror mode.
>
> Actually, mirror mode applies to push only. Unless I'm missing
> something obvious.
Perhaps you are, mirror mode applies to fetch as well; that's how e.g.
repo.or.cz mirror mode is done currently.
Petr "Pasky" Baudis
^ permalink raw reply
* Re: [PATCH v2 09/13] Honour the refspec when updating refs after import
From: Daniel Barkalow @ 2009-11-06 0:19 UTC (permalink / raw)
To: Sverre Rabbelier
Cc: Git List, Johannes Schindelin, Johan Herland, Junio C Hamano
In-Reply-To: <fabb9a1e0911051551r2e13cfb9me0e668adb962f6bd@mail.gmail.com>
On Fri, 6 Nov 2009, Sverre Rabbelier wrote:
> Heya,
>
> On Thu, Nov 5, 2009 at 07:53, Daniel Barkalow <barkalow@iabervon.org> wrote:
> > Here's a patch (on my original series, which doesn't seem to be in pu any
> > more, but should be floating around somewhere).
>
> Why didn't you just base it against sr/vcs-helper which is currently
> in pu, now I have to try to find where your original series was, and
> rebase this patch against it. Assuming your main goal was to
> illustrate the direction you think we should go it would have been a
> lot easier that way.
I didn't understand the version of my patch that contains your changes,
and I didn't know what was in it. I don't know why Junio squashed your
changes into my patch, particularly when I disagreed with those changes.
-Daniel
*This .sig left intentionally blank*
^ permalink raw reply
* Git & Project Workflow
From: Tommy Wang @ 2009-11-06 0:19 UTC (permalink / raw)
To: git
Hi,
I'm trying to set up a project using git, and I'm having a hard time
figuring out the best way to implement one of my workflows.
Lets say I have a repository "main". Some of my developers will have
full access to this repository, while others should have access only
to certain parts of it (and, no, unfortunately the files are scattered
all over the place, and reorganizing isn't an option, so I can't use
subtrees).
I've attempted to solve this project by cloning the project into
another repository "limited". Now, half of my developers can work off
from "main", while the other half can work from "limited".
Incidentally, its okay that the original source is visible in limited,
I just don't want the work we put into "main" to show up in "limited".
So, lets say my "main" developer makes some changes to the project.
Some of his changes are to kept in "main" only, while other changes
need to be pushed into "limited". I can maybe force developers to
keep changes in common files in separate commits, and just cherry pick
them into "limited". "Limited" developers can then pull those changes
into his local repository, resolve conflicts, (rebase), and push them
back into "limited". At some point later in time, lets suppose we
need to push changes made in limited back to main. So, our main
developers will cherry pick again the newest changes into limited (to
keep the conflicts down). Limited developers will then
commit/resolve/rebase their work into limited, and let the main
developers know that they're ready. The main developers will now pull
from limited -- and since we (likely) haven't changed main, the pull
should be pretty conflict free (git does keep track of cherry-commits
in merges, right?).
My question is, is cherry-picking really the best way to do this?
What I'd really like to do is to create the limited repository by
doing a filter-branch and removing secure files out of the repository
entirely. After doing this, though, it makes it difficult/impossible
to move changes between the two repositories. I tried a number of
approaches, including trying to graft the two repositories together
after the filter-branch to make push/pull work as simple
merges/fast-forwards. I would have to figure out way to filter
commits to make sure that main doesn't push a secure file into
limited, and that limited doesn't try to do something silly like
creating a secure file. Perhaps I could use filter-branch to rewrite
these commits as well. But, being that filter-branch totally changes
the commit ids, I figure that this approach really doesn't have any
merit.
I also considered doing something like this:
# create main & limited from upstream source
git clone upstream main
git clone main limited
# remove secure files from limited
cd limited
git rm -r secure files
git commit
# fake a merge to keep histories correct
cd main
git pull -s ours limited
# pulling from limited worked well, and would only get changes made after the rm
cd main
git pull limited master
# pull from main didn't work so well --> but I probably should be
cherry-picking here anyway?
cd limited
git pull main master
I'm not sure why I'm trying so hard to avoid cherry-picking. Probably
due to the fact that developers need to be more intimate with git, and
that it takes considerably more time to look through a list of
commits, and pick out the ones that can be moved from main -> limited.
Is there a way to generate a list of commits based on a list of files
(paths aren't good enough, since my files are scattered all over the
place) that can be found in main but not limited? Perhaps I can write
a script that can be used to automate the cherry-picking from main ->
limited. If we run this script right after we resolve all the
conflicts from a limited -> main merge, we should be able to avoid all
conflicts.
Anyway, I'm hoping for some thoughts/direction on how I may be able to
solve my problem. Perhaps there is a magical solution that is plainly
obvious to someone with more git experience?
Thanks,
Tommy
^ permalink raw reply
* Re: [PATCH v2 09/13] Honour the refspec when updating refs after import
From: Sverre Rabbelier @ 2009-11-06 0:28 UTC (permalink / raw)
To: Daniel Barkalow
Cc: Git List, Johannes Schindelin, Johan Herland, Junio C Hamano
In-Reply-To: <alpine.LNX.2.00.0911051917100.14365@iabervon.org>
Heya,
On Fri, Nov 6, 2009 at 01:19, Daniel Barkalow <barkalow@iabervon.org> wrote:
> I didn't understand the version of my patch that contains your changes,
> and I didn't know what was in it.
Either way, I managed to apply your patch, will send a new version of
the series tomorrow.
> I don't know why Junio squashed your
> changes into my patch, particularly when I disagreed with those changes.
Junio didn't squash anything, it's just that pu still contains v4 of
the series, in which I had squashed my changes in.
--
Cheers,
Sverre Rabbelier
^ permalink raw reply
* Bug in git remote prune?
From: Jay Soffian @ 2009-11-06 0:34 UTC (permalink / raw)
To: git
Let's say you've got the following tracking branches:
refs/remotes/origin/master
refs/remotes/origin/next
refs/remotes/origin/ghost
And origin has only "master" and "next" (ghost has been removed upstream).
Further, let's say you've got a refspec of:
[remote "origin"]
fetch = +refs/heads/master:refs/remotes/origin/master
What should "git remote prune origin" do?
In my opinion, it should prune "next" and "ghost". "ghost" is gone
from upstream, so that's obvious. I think "next" should also be pruned
because the refspec indicates the user is no longer interested in it.
Currently it doesn't do anything (it only considers "master" per the
refspec, which is still on origin, so it doesn't think there is
anything to prune).
Thoughts?
j.
^ permalink raw reply
* Re: [PATCH v2 09/13] Honour the refspec when updating refs after import
From: Daniel Barkalow @ 2009-11-06 0:37 UTC (permalink / raw)
To: Sverre Rabbelier
Cc: Git List, Johannes Schindelin, Johan Herland, Junio C Hamano
In-Reply-To: <fabb9a1e0911051628v2ba15be2s9c3fb06879607cc0@mail.gmail.com>
On Fri, 6 Nov 2009, Sverre Rabbelier wrote:
> Heya,
>
> On Fri, Nov 6, 2009 at 01:19, Daniel Barkalow <barkalow@iabervon.org> wrote:
> > I didn't understand the version of my patch that contains your changes,
> > and I didn't know what was in it.
>
> Either way, I managed to apply your patch, will send a new version of
> the series tomorrow.
Does it make sense now in what it's trying to do? (And does it turn out to
work?) I'm fairly certain it's the easiest way to make the remote appear
most natural to the rest of git, but I don't actually have code that wants
to use it, so I wouldn't know if this just wouldn't work for hg or
something.
> > I don't know why Junio squashed your
> > changes into my patch, particularly when I disagreed with those changes.
>
> Junio didn't squash anything, it's just that pu still contains v4 of
> the series, in which I had squashed my changes in.
Oh, okay. You probably shouldn't squash un-acked changes into other
people's patches when taking over their series.
-Daniel
*This .sig left intentionally blank*
^ permalink raw reply
* Re: Automatically remote prune
From: Jay Soffian @ 2009-11-06 0:38 UTC (permalink / raw)
To: Petr Baudis; +Cc: Junio C Hamano, John Tapsell, Git List
In-Reply-To: <20091106001751.GF17748@machine.or.cz>
On Thu, Nov 5, 2009 at 7:17 PM, Petr Baudis <pasky@suse.cz> wrote:
> On Thu, Nov 05, 2009 at 06:09:03PM -0500, Jay Soffian wrote:
>> Actually, mirror mode applies to push only. Unless I'm missing
>> something obvious.
>
> Perhaps you are, mirror mode applies to fetch as well; that's how e.g.
> repo.or.cz mirror mode is done currently.
Can you please be more specific? There is no mention of mirror in
builtin-fetch.c, only builtin-push.c. Further, the docs for
"remote.<name>.mirror" indicate it's a push option only.
So please explain what you mean by "that's how repo.or.cz mirror mode is done".
Cluelessly yours,
j.
^ permalink raw reply
* Re: [PATCH] gitk: disable checkout of remote branch
From: Junio C Hamano @ 2009-11-06 0:45 UTC (permalink / raw)
To: Jeff King; +Cc: Junio C Hamano, Sverre Rabbelier, Tim Mazid, git
In-Reply-To: <20091105074808.GA12114@coredump.intra.peff.net>
Jeff King <peff@peff.net> writes:
>> Isn't it quite different? What's in 'next' for 1.7.0 is to guess the
>> user's intention when:
>
> Sorry, yes, I just saw Sverre's comment and misread the original
> proposal. Checking out "$remote/$branch" will still detach the HEAD,
> and I don't think anybody has a previous proposal to change that.
Heh, I think both of us forgot that we decided it is safe enough not to
wait for 1.7.0 already, because the situation this kicks in has always
resulted in an error. We have it in master since e3de372 (Merge branch
'jc/checkout-auto-track', 2009-10-30).
^ permalink raw reply
* Re: Preserving branches after merging on ancestor
From: Jonathan Nieder @ 2009-11-06 1:09 UTC (permalink / raw)
To: Björn Steinbrink; +Cc: Richard Lee, git
In-Reply-To: <20091105232848.GA1939@atjola.homenet>
Björn Steinbrink wrote:
> I guess Richard took the "branch topic1, merge topic1, branch topic2,
> merge topic2" thing just as an example because that ends up with two
> fast-forwards.
Hmm, I found Richard’s example pretty realistic. I used to work like
that, and I don’t think I am the only one.
> And your example _still_ has such a fast-forward.
Yep, if you really want to avoid fast-forwards, please use "--no-ff"!
But what I was trying to make clear was that in some workflows, the
fast-forwards are not so harmful. They even make the history a little
cleaner (easier to read and understand).
> Instead of:
>
> A---B---C---D---E (topic2) (master)
> \
> F---G---H (topic1)
>
> He wants:
>
> F---G---H (topic1)
> /
> A---B-----------M (master)
> \ /
> C---D---E (topic2)
>
> So he can see at which point topic2 got merged. This allows to ask "which
> commits got merged here" (and for a merge-once topic branch this means:
> Which commits are related to that topic), by using for example:
>
> git log M^1..M^2 # Will show C, D and E
You can get the same information locally even with a fast-forward:
git log master@{1}..master
But to someone reading the published history, it is not available.
Depending on your way of working, this may or may not be reasonable.
Perhaps your merge commit messages contain important information about
the branch’s overall purpose and provenance, which would be impossible
if there is no merge commit.
On the other hand, if the goal is just to present the fact of a merge,
to explain where a patch falls in the larger scheme of things, then
how large a chunk of changes I decided to call a feature does not seem
too important.
Imagine a patch series, cleaning up some ugly code that has been
bothering me for a while:
base [master] --- A --- B --- C [cleanup]
It looks good, so I merge to master with --no-ff.
base --------- D [master]
\ /
A---B---C [cleanup]
Looking at that code inspires me to build a new feature that is much
easier with the cleaned up version. So I fork a branch from cleanup
(Or master? Their content is the same, but somehow I choose one) and
write some patches for the new feature.
base --------- D [master]
\ /
A---B---C [cleanup] --- E --- F --- G
It looks good, so I merge.
base --------- D --------- H [master]
\ / /
A---B---C---E---F---G
Is this really any easier to read than base---A---B---C---E---F---G?
In hindsight, was this logically really two series, or is the D commit
extra cruft?
Almost always, a fast-forward comes from a continuation of this kind,
since that is what it means for a commit to be the logical commit to
fork from.
Of course, these things are a matter of taste. I just wanted to
explain why a fast-forward could at least sometimes be the right
result from merging a topic branch (and why, in practice, some people
never end up needing to use --no-ff).
Regards,
Jonathan
^ permalink raw reply
* Re: Bug in git remote prune?
From: Junio C Hamano @ 2009-11-06 1:36 UTC (permalink / raw)
To: Jay Soffian; +Cc: git
In-Reply-To: <76718490911051634w2d364b73m567e73039508c857@mail.gmail.com>
Jay Soffian <jaysoffian@gmail.com> writes:
> Let's say you've got the following tracking branches:
>
> refs/remotes/origin/master
> refs/remotes/origin/next
> refs/remotes/origin/ghost
>
> And origin has only "master" and "next" (ghost has been removed upstream).
>
> Further, let's say you've got a refspec of:
>
> [remote "origin"]
> fetch = +refs/heads/master:refs/remotes/origin/master
>
> What should "git remote prune origin" do?
>
> In my opinion, it should prune "next" and "ghost". "ghost" is gone
> from upstream, so that's obvious. I think "next" should also be pruned
> because the refspec indicates the user is no longer interested in it.
>
> Currently it doesn't do anything (it only considers "master" per the
> refspec, which is still on origin, so it doesn't think there is
> anything to prune).
In your scenario, tracking branches for next and ghost couldn't have come
from the refspec you have in the configuration, but they do exist. The
user has added them on purpose, perhaps by temporarily using wildcard
refspec, or perhaps by giving a refspec from the command line.
It does not matter how they got there, but the important thing to keep in
mind is that, even if the remote had refs/heads/{next,ghost}, we wouldn't
update it if we ran "git fetch" now.
In this situation, "git remote prune" should never prune 'next' nor
'ghost'. If we were to implement auto-pruning in 'git fetch', it should
behave the same way.
I would define the logic to decide if refs/remotes/REMOTE/BRANCH is stale
to be:
* See if there exists a refspec (either wildcard or concrete) that may
cause "git fetch" to update the tracking branch in question, if the
remote side had an appropriate ref.
If there is no such refspec, stop here. It is not stale.
In your example, when considering refs/remotes/origin/master, there is
such a refspec, and the "appropriate ref" is "refs/heads/master" on
their side. When considering refs/remotes/origin/{next,ghost}, there
is none. You stop here.
* Then see if that ref exists at the remote side. If it exists, stop
here. It means "git fetch" would update the tracking branch in
question, so it is not stale.
In your example, when considering refs/remotes/origin/master, the
matching remote ref 'refs/heads/master' exists, so our tracking ref is
not stale.
* Otherwise, it is stale, and we can prune it.
Imagine a hypothetical "git fetch" that understands a ref with a magic
value 0{40} to signal "this ref is gone", and imagine what happens if the
origin had 'ghost' that has such a magic SHA-1 in it. It would become
easier to understand how the above logic works.
- When you issue "git fetch" under the condition of your example, think
what would happen to 'next' (which has an ordinary value, not the magic
"delete this" request). Nothing happens. We do not update it.
- Nothing happens to 'ghost' either when you issue "git fetch". It does
not matter if that ref has this magic 'delete this' value.
Nothing happens because we were told by the refspec not to even look at
these refs/heads/{next,ghost} refs on the other side.
^ permalink raw reply
* Re: how to rebase backwards
From: bill lam @ 2009-11-06 1:43 UTC (permalink / raw)
To: David,
=?iso-8859-1?Q?K=E5gedal_=3Cdavidk=40lysator=2Eliu=2Ese=3E?=
Cc: Junio C Hamano, git
In-Reply-To: <877hu4zsyq.fsf@lysator.liu.se>
On Thu, 05 Nov 2009, David Kågedal wrote:
> command. For instance git log --graph master...deply whill show you both
> branches, starting from their common ancestor. "git merge-base deploy
> master" will tell you that the common ancestor is. Etc.
David, thank you for this info.
--
regards,
====================================================
GPG key 1024D/4434BAB3 2008-08-24
gpg --keyserver subkeys.pgp.net --recv-keys 4434BAB3
^ permalink raw reply
* Re: Bug in git remote prune?
From: Jay Soffian @ 2009-11-06 1:58 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vvdho5t9s.fsf@alter.siamese.dyndns.org>
On Thu, Nov 5, 2009 at 8:36 PM, Junio C Hamano <gitster@pobox.com> wrote:
> Nothing happens because we were told by the refspec not to even look at
> these refs/heads/{next,ghost} refs on the other side.
Gotcha, and that's all you had to say, but I appreciate the long
explanation. :-)
j.
^ 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