* Re: [PATCH 4/5] fast-export: Introduce --inline-blobs
From: Drew Northup @ 2011-01-20 13:53 UTC (permalink / raw)
To: Ramkumar Ramachandra
Cc: Jonathan Nieder, Junio C Hamano, Git List, David Barr,
Sverre Rabbelier
In-Reply-To: <20110120045046.GB9493@kytes>
On Thu, 2011-01-20 at 10:20 +0530, Ramkumar Ramachandra wrote:
> Hi,
>
> Jonathan Nieder writes:
> > Junio C Hamano wrote:
> > > Ramkumar Ramachandra <artagnon@gmail.com> writes:
> > > Just thinking aloud, but is it possible to write a filter that converts an
> > > arbitrary G-F-I stream with referenced blobs into a G-F-I stream without
> > > referenced blobs by inlining all the blobs?
> >
> > to avoid complexity in the svn fast-import backend itself.
> > (Complicating detail: such a filter would presumably take responsibility
> > for --export-marks, so it might want a way to retrieve commit marks
> > from its downstream.)
>
> This filter will need to persist every blob for the entire lifetime of
> the program. We can't possibly do it in-memory, so we have to find
> some way to persist them on-disk and retrieve them very
> quickly. Jonathan suggested using something like ToyoCabinet earlier-
> I'll start working and see what I come up with.
Is it worth including the extra dependency? Most systems that I'm in
frequent contact with already have some lightweight BDB implementation
already. I don't currently know of any with TokyoCabinet (or
KyotoCabinet for that matter) already in place. Besides, if all you're
doing is persisting blobs that you're likely to write out to disk
eventually anyway you might as well just do so once you have them and
keep an "index" (not to be confused with the Git Index, just lacking a
better word right now) of what you have in some standard in-memory
format (a heap?). From there you can build each commit into the Git
Index in the proper order once you have the required parts for
each--perhaps even re-using the blobs you've already dumped to disk
(mv'ing them or something).
Granted, there's a good likelihood that I'm missing something here, but
I don't see the point of adding external complexity (beyond what you're
currently stuck dealing with).
--
-Drew Northup
________________________________________________
"As opposed to vegetable or mineral error?"
-John Pescatore, SANS NewsBites Vol. 12 Num. 59
^ permalink raw reply
* Tip for Eclipse users: how to make Git ~30 times faster in Eclipse
From: Intland Software @ 2011-01-20 14:49 UTC (permalink / raw)
To: git
Dear Git users,
A team here at Intland Software recently looked into EGit performance optimization opportunities, and managed to achieve
some impressive results. You might be interested to get our results before the next official EGit version gets released.
In our optimized plugin version, the time required to synchronize a medium sized repo dropped from 10 minutes to 15
seconds. (It is 40 times faster now on that particular repository.)
The Eclipse CDT team reported similar results: their synchronization time dropped from 32 minutes to 1.5 minutes
(roughly 20 times faster now).
Read here how: http://blogs.intland.com/main/entry/20110120
--
Intland staff
^ permalink raw reply
* Re: Creating remote branch called HEAD corrupts remote clones
From: Stephen Kelly @ 2011-01-20 15:05 UTC (permalink / raw)
To: Thomas Rast; +Cc: git
In-Reply-To: <201101201403.39174.trast@student.ethz.ch>
Ok so there was some movement with the result that no one uses what was set up.
Presumably because git developers don't want a bug tracker.
So how can I ensure that this particular issue doesn't get lost? Is
there no way except hope that people get involved in fixing it
straight away, and fix it straight away before they forget about it?
We worked around this on the KDE side by forbidding pushing any ref
with the name HEAD to the remote, but it's still a git bug.
On 1/20/11, Thomas Rast <trast@student.ethz.ch> wrote:
> Stephen Kelly wrote:
>> Why does git not have a bug tracker?
>
> http://thread.gmane.org/gmane.comp.version-control.git/136500
>
>
> --
> Thomas Rast
> trast@{inf,student}.ethz.ch
>
^ permalink raw reply
* Re: [PATCH v2] Introduce new configuation option to override committer information
From: Stephen Kelly @ 2011-01-20 15:24 UTC (permalink / raw)
To: Thomas Rast; +Cc: git, Ramkumar Ramachandra, Erik Faye-Lund, Jonathan Nieder
In-Reply-To: <201101201352.01874.trast@student.ethz.ch>
On Thu, Jan 20, 2011 at 1:52 PM, Thomas Rast <trast@student.ethz.ch> wrote:
> Stephen Kelly wrote:
>>
>> Is this patch going to become part of git, or is it in already?
>>
>> If not it will probably just get lost because there is no issue tracker.
>
> Discussion stalled without an agreement that any patch proposed is
> "good", so if it ends here it will be dropped.
>
> You could probably help getting closer to a solution by:
>
> * Not dropping Cc's all the time. I saw this email just by chance.
Sorry. I've never used a mailing list where you have to keep everyone
in the CC. I use KNode for reading and writing to mailing lists. I
don't see why you can get involved in a thread from the initial mail
presumably because you read the title and decide it's interesting and
then miss the replies even though they have the same title.
How does it work in this case:
Title - Stephen
* Re: Title - Alice
* * Re Title - Bob
* Re Title - Charlie
If you reply to Bob, do you also add Charlie to the CC? Do you search
through everyone in long threads and make sure they're all CC'd?
I'm just trying to understand the mindset/process that everyone else
on this list seems to use.
FWIW there's no need to CC me on replies. I'll see it anyway :)
>
> * Stating *why* this cannot be solved in any other way on the KDE
> end. So far you only said
>
> > > Is it impossible to fix this on the KDE side? I would think a
> > > many-to-one mapping from committer identities to bugzilla account
> > > names could be a useful thing to have in any case.
> >
> > I asked that before coming here, and apparently that is not possible.
I filed a bug with the KDE sysadmins asking if there was a way of
configuring multiple email addresses in bugzilla. I didn't think of
adding some custom keywords to the template as you suggest below.
>
> My gut feeling is that a footer line in the commit along the lines
> of
>
> Bugzilla-Id: Registered Name <registered.email@example.com>
>
> would work. I suspect others have a similar feeling. A good case
> why this is not a feasible solution for (presumably) border cases
> like you would help get rid of it.
Yes, my case is a border case. This solution seems to duplicate the
committer email address in concept. It also requires more work for the
KDE sysadmins.
I think the better solution is to maintain a patched version of git
externally. Silly as that sounds.
>
> * Replying to e.g.
>
> http://mid.gmane.org/201101111542.15185.trast@student.ethz.ch
>
> with (ideally better) ideas of what the semantics should be. My
> assessment is that it either conflicts with user expectations or
> with established git-config mechanisms of how the various files
> override each other.
Yes, I see what you mean in you example. If git config doesn't have
any cases like this already then there's no prior art and two ways
forward. I don't want to bikeshed it, so if you want just pick a
solution and run with it. Otherwise I'll just continue using my
patched version and drop the issue here.
Thanks,
Steve.
^ permalink raw reply
* Re: Creating remote branch called HEAD corrupts remote clones
From: Erik Faye-Lund @ 2011-01-20 15:41 UTC (permalink / raw)
To: Stephen Kelly; +Cc: Thomas Rast, git
In-Reply-To: <AANLkTinNNBupCi09_W60qdDGFc5CN-p=rKaf_FKW0kj1@mail.gmail.com>
On Thu, Jan 20, 2011 at 4:05 PM, Stephen Kelly <steveire@gmail.com> wrote:
> Ok so there was some movement with the result that no one uses what was set up.
>
> Presumably because git developers don't want a bug tracker.
>
> So how can I ensure that this particular issue doesn't get lost? Is
> there no way except hope that people get involved in fixing it
> straight away, and fix it straight away before they forget about it?
>
You could always fix it yourself, and submit a patch.
^ permalink raw reply
* Re: Creating remote branch called HEAD corrupts remote clones
From: Stephen Kelly @ 2011-01-20 16:00 UTC (permalink / raw)
To: kusmabite; +Cc: Thomas Rast, git
In-Reply-To: <AANLkTinoET4vBxVdfSejFmzwRaA=0AVdie5gmMvx44T5@mail.gmail.com>
On Thu, Jan 20, 2011 at 4:41 PM, Erik Faye-Lund <kusmabite@gmail.com> wrote:
> On Thu, Jan 20, 2011 at 4:05 PM, Stephen Kelly <steveire@gmail.com> wrote:
>> Ok so there was some movement with the result that no one uses what was set up.
>>
>> Presumably because git developers don't want a bug tracker.
>>
>> So how can I ensure that this particular issue doesn't get lost? Is
>> there no way except hope that people get involved in fixing it
>> straight away, and fix it straight away before they forget about it?
>>
>
> You could always fix it yourself, and submit a patch.
>
Correct. That would be a big rampup though and I might give up, move
on or forget and then no one would do it because everyone has
forgotten about it. I mean that in the general sense of any bug that
gets posted to this mailing list.
But I'm not trying to change how git people work. I'm just trying to
discover what the states of a bug in git should be understood to be
after it is emailed to this list and before it's in master. So far it
seems there is only one intermediate state: "Limbo, maybe forgotten.
You should email the list again"
Thanks,
Steve.
^ permalink raw reply
* Re: EOL strangeness
From: Graham Sanderson @ 2011-01-20 16:29 UTC (permalink / raw)
To: René Scharfe; +Cc: git
In-Reply-To: <4D37F853.1020805@lsrfire.ath.cx>
Thanks, I think it must have been a bug - I realized that even though
I thought I was on the latest git, I had an older copy hiding in my
path; once I upgraded the problem went away.
On Thu, Jan 20, 2011 at 2:54 AM, René Scharfe
<rene.scharfe@lsrfire.ath.cx> wrote:
> Am 17.01.2011 20:56, schrieb Graham Sanderson:
>> Apologies if someone has answered this before:
>>
>> So we have moved some big teams over to git (awesome thx), and have
>> been using the msysgit default core.autocrlf=true on Windows, and
>> making sure text files are LF on other platforms
>>
>> However we do continue to have a few problems with people storing CRLF
>> in the repository (partly because of lack of understanding, and partly
>> it seems because of eGit on windows which ignores core.autocrlf).
>>
>> Anyway, this much is all fine, and we can fix; what I don't understand
>> is why for files stored as CRLF in the repository it seems
>> indeterminate when or if they show up locally modified (on my window
>> box with core.autocrlf = true) when I pull them from the repository. I
>> assume the idea is that that they "would be" modified if I were to
>> check them in, since they would be converted to LF, however this only
>> happens sometimes and for a seemingly random subset of the files
>> stored incorrectly.
>>
>> It also seems to depend on the state of the local index, as recreating
>> the local index often changes the set of files that are displayed this
>> way (even without any changes to the files), and it also seems to be
>> different on different machines (perhaps based on when they happened
>> to pull code).
>>
>> If anyone can give me a quick mental picture of how this is supposed
>> to work (i.e. at what time the eol conversions are considered) then
>> that'd be great... otherwise I guess I'll go dig in the code.
>
> Perhaps this recent thread is of interest to you, even though it's on a
> slightly different topic and inconclusive:
>
> http://thread.gmane.org/gmane.comp.version-control.git/163794
>
> It would be nice to have the expectations in your case codified in a
> test script -- based on the documentation, if possible.
>
> René
>
^ permalink raw reply
* Re: Creating remote branch called HEAD corrupts remote clones
From: Felipe Contreras @ 2011-01-20 17:32 UTC (permalink / raw)
To: Stephen Kelly; +Cc: git
In-Reply-To: <ih95fg$62b$1@dough.gmane.org>
Hi,
On Thu, Jan 20, 2011 at 1:14 PM, Stephen Kelly <steveire@gmail.com> wrote:
> Stephen Kelly wrote:
>> On Friday we had an issue where a developer pushed a branch called HEAD to
>> the remote server. The result was that other developers could not pull or
>> push.
>
> Does anyone have any thoughts/response on this?
Can you list a series of steps to reproduce this?
> Why does git not have a bug tracker?
Because it's not needed. If you have an issue, post the issue as you
would file a bug:
Which version of git?
Which kind of network transport was used?
Is this reproducible?
Chances are, if this is reproducible in the latest version, someone
would fix it soon enough. If not, and it's important to you, you would
ping back. If other people find this issue, they would send another
email.
In fact, if you really want to help, you could clone the latest
'master' to see if this still happening, narrow down the steps needed
to reproduce this, write a test to trigger it and send a patch.
Certainly, a test case that constantly fails would be a constant
remainder that there is a bug.
Cheers.
--
Felipe Contreras
^ permalink raw reply
* Re: Wish: make commiter email address configurable per-repo
From: Junio C Hamano @ 2011-01-20 18:44 UTC (permalink / raw)
To: Stephen Kelly; +Cc: git
In-Reply-To: <ig7449$lbg$2@dough.gmane.org>
Stephen Kelly <steveire@gmail.com> writes:
> Thomas Rast wrote:
>
>> Stephen Kelly wrote:
>>> So for some git repos in KDE which I work on on work time, I'd like to
>>> set a different committer address. I can't just set GIT_COMMITTER_EMAIL
>>> or whatever in my bashrc, because in other repos I want to use a
>>> different committer email, and don't want it set globally for all git
>>> repos I work on.
>>>
>>> This doesn't seem to be configurable in git config. Can that be changed?
>>
>> See user.email in git-config(1). Most people set it globally, as in
>>
>> git config --global user.email "author@example.com"
>>
>> but there's nothing stopping you from doing
>>
>> git config user.email "alias@example.com"
>>
>> to set it on a per-repo level. (Or just edit .git/config, of course.)
>
> Doesn't this set both the author and the committer?
And the reason why that is a bad thing is...?
^ permalink raw reply
* Re: [PATCH v2] Introduce new configuation option to override committer information
From: Junio C Hamano @ 2011-01-20 19:00 UTC (permalink / raw)
To: Thomas Rast
Cc: Jonathan Nieder, Ramkumar Ramachandra, Git List, Stephen Kelly,
Erik Faye-Lund
In-Reply-To: <201101111542.15185.trast@student.ethz.ch>
Thomas Rast <trast@student.ethz.ch> writes:
> Well, now that I'm rethinking it, the weird thing is that it does not
> override in the way that the user intuitively might expect.
>
> Assume we also had user.authoremail for completeness, and you do
>
> git config --global user.authoremail author@example.com
> git config --global user.committeremail committer@example.com
> git config user.email user@example.com
>
> Probably the user would expect this to result in a uniform
> user@example.com identity for the current repo, but I don't think we
> can twist it that way with the current config infrastructure. The
> obvious option of having user.{author,committer}* override the more
> generic user.* would be contrary to that intuition.
The thing is that the "intuition" is not so cut-and-dried. "email" is
indeed more generic than "authoremail", so it is intuitive for the latter
to override the former. But "$HOME/.gitconfig" is fallback default for
the repository specific .git/config so it also is intuitive for anything
in the latter to override whatever is in the former. Now you have a
conflicting "more specific authoremail in more generic $HOME/.gitconfig vs
more generic email in more specific .git/config---which wins?" situation.
Is there a way to document the rule of precedence clearly? For this
particular case, recommending against setting author/committer-email in
the fallback default $HOME/.gitconfig in the Documentation/config.txt
might be sufficient.
But I am still not convinced why two need to be custom-set differently
when both need to name _you_. After all, Author and Committer are both
identifiers taken from the same namespace to identify real people, so if
you want to use one value for the committer to name _you_, I don't see a
sane reason why you want a different name to name the same _you_ in the
author field.
The specific use case in the thread talks about KDE workflow interpreting
the committer identifier in a particular way as a reason for it to be set
to a particular value, but does not clarify why the author has to be
different from that particular value for the committer.
^ permalink raw reply
* Re: Creating remote branch called HEAD corrupts remote clones
From: Wesley J. Landaker @ 2011-01-20 19:21 UTC (permalink / raw)
To: Felipe Contreras; +Cc: Stephen Kelly, git
In-Reply-To: <AANLkTikvVaSTV8hVjDXLvOEEDv5qr19ybk3Cm--+bgWA@mail.gmail.com>
On Thursday, January 20, 2011 10:32:40 Felipe Contreras wrote:
> Hi,
>
> On Thu, Jan 20, 2011 at 1:14 PM, Stephen Kelly <steveire@gmail.com> wrote:
> > Stephen Kelly wrote:
> >> On Friday we had an issue where a developer pushed a branch called
> >> HEAD to the remote server. The result was that other developers could
> >> not pull or push.
[...]
> Which version of git?
> Which kind of network transport was used?
> Is this reproducible?
FWIW, here is a quick demonstration of at least one problem with having a
branch called HEAD. You can make it and push it fine, but when cloning, you
don't get it.
#!/bin/bash
git init --bare origin.git
git clone origin.git wc1
cd wc1
git commit --allow-empty -m "Initial rev"
git checkout -b HEAD
git commit --allow-empty -m "Make HEAD branch"
git push --all
cd ..
git clone origin.git wc2
diff -u <(cd wc1; git branch -a) <(cd wc2; git branch -a)
diff -u <(cd wc1; git log --all) <(cd wc2; git log --all)
If I do the following from wc2 I can get the branch manually:
git pull origin refs/heads/HEAD:HEAD
I haven't played with it enough to see what other problems might arise.
^ permalink raw reply
* Re: [PATCH v2] Introduce new configuation option to override committer information
From: Jonathan Nieder @ 2011-01-20 19:19 UTC (permalink / raw)
To: Stephen Kelly; +Cc: Thomas Rast, git, Ramkumar Ramachandra, Erik Faye-Lund
In-Reply-To: <AANLkTin-zUbVmJ3gUsDE5+AkECoAzN2Oim4=45JrcT6o@mail.gmail.com>
Stephen Kelly wrote:
> On Thu, Jan 20, 2011 at 1:52 PM, Thomas Rast <trast@student.ethz.ch> wrote:
>> My gut feeling is that a footer line in the commit along the lines
>> of
>>
>> Bugzilla-Id: Registered Name <registered.email@example.com>
>>
>> would work. I suspect others have a similar feeling. A good case
>> why this is not a feasible solution for (presumably) border cases
>> like you would help get rid of it.
>
> Yes, my case is a border case. This solution seems to duplicate the
> committer email address in concept. It also requires more work for the
> KDE sysadmins.
Okay, this stirred my particular combination of lazy person and
busybody. I volunteer to work on modifying the
commit-reading/bug-closing script to take a Bugzilla-Id line into
account when present if the KDE sysadmins are willing to accept such a
modification. Another possibility would be a table (for example a
plain text file) mapping git identities to bugzilla identities. Could
you put me in touch with them?
Thanks for your work to improve tools. I do appreciate it.
Jonathan
^ permalink raw reply
* [PATCH 2/2] Re: rebase -i: explain how to discard all commits
From: Nicolas Sebrecht @ 2011-01-20 19:39 UTC (permalink / raw)
To: Jonathan Nieder
Cc: Matthieu Moy, git, gitster, Kevin Ballard, Yann Dirson,
Eric Raible, Nicolas Sebrecht
In-Reply-To: <20110116020207.GC28137@burratino>
The 15/01/11, Jonathan Nieder wrote:
> Preparing a patch series for submission (as explained under
> INTERACTIVE MODE in the git rebase manual) sometimes involves
> discarding commits representing changes that turned out to be a bad
> idea. Usually this is quite simple to do by deleting the appropriate
> "pick" lines, but if all commits are removed then the "remove
> everything means abort" logic kicks in and the rebase is cancelled.
> One can override that behavior by adding a line with the text "noop".
>
> This is a follow-up to v1.6.0.3~21 (rebase -i: do not fail when there
> is no commit to cherry-pick, 2008-10-10).
>
> Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
> ---
> git-rebase--interactive.sh | 1 +
> 1 files changed, 1 insertions(+), 0 deletions(-)
>
> diff --git a/git-rebase--interactive.sh b/git-rebase--interactive.sh
> index 09aeecf..d9dfc75 100755
> --- a/git-rebase--interactive.sh
> +++ b/git-rebase--interactive.sh
> @@ -1025,6 +1025,7 @@ first and then run 'git rebase --continue' again."
> #
> # If you remove a line here THAT COMMIT WILL BE LOST.
> # However, if you remove everything, the rebase will be aborted.
> +# Use the "noop" command if you really want to remove all commits.
> #
> EOF
Sorry, I think it is confusing. With this help we could understand that
the "noop" will either
(a) discard the interactive rebase
or
(b) _really remove commits_ from that branch
I'm not sure to know how it will act myself. If (a), we could use
something like
"However, if you remove everything or use the "noop" command, the rebase will be aborted."
but if we are in case (b), I guess it is not necessary and we should
point to the 'git reset' command.
--
Nicolas Sebrecht
^ permalink raw reply
* Re: Creating remote branch called HEAD corrupts remote clones
From: Junio C Hamano @ 2011-01-20 19:53 UTC (permalink / raw)
To: git; +Cc: Stephen Kelly, KDE PIM
In-Reply-To: <ih1449$ul6$1@dough.gmane.org>
Stephen Kelly <steveire@gmail.com> writes:
> There were also messages like this:
>
> $ git pull
> remote: Counting objects: 5, done.
> remote: Total 3 (delta 0), reused 0 (delta 0)
> Unpacking objects: 100% (3/3), done.
> From /home/kde-devel/dev/src/playground/git/tmp/remote
> + 1434cd2...dd30974 HEAD -> origin/HEAD (forced update)
Stephen, thanks, I think you have found a bug, not in this step but one
step before this 'git pull', where Bob pushes to the remote for the first
time after making a commit.
This issue is inherent in the way how the 'separate remotes' layout
introduced in 1.6.0 arranges the remote tracking mappings.
The refs/remotes/origin/HEAD in Bob's repository is supposed to be a
symbolic ref that points at the primary branch of the 'origin' remote
(typically its master), e.g. "ref: refs/remotes/origin/master". But in
general, local 'refs/remotes/origin/X' for any value of X is to copy
'refs/heads/X' from the 'origin'.
Oops. If the origin repository has 'refs/heads/HEAD', these rules
obviously conflict with each other.
In this particular case, Bob pushes the change to his refs/heads/master to
the remote to update its refs/heads/master. The push at the same time
tries to pretend that it fetched from the remote to update Bob's tracking
branches, so refs/remotes/origin/master in Bob's repository is also
updated to point at this commit.
However, because Bob's refs/remotes/origin/HEAD is a symbolic ref that
points at his refs/remotes/origin/master, its value is also updated by
this push.
Bob's next fetch from remote will then notice that remotes/origin/HEAD he
has is different from refs/heads/HEAD the remote has, and tries to update
it, which would obviously a non-fast-forward.
I personally think it is reasonable to forbid HEAD or anything all caps
that ends with "_HEAD" as branch names. Opinions?
^ permalink raw reply
* Re: [PATCH 2/2] Re: rebase -i: explain how to discard all commits
From: Jonathan Nieder @ 2011-01-20 19:57 UTC (permalink / raw)
To: Nicolas Sebrecht
Cc: Matthieu Moy, git, gitster, Kevin Ballard, Yann Dirson,
Eric Raible, Johannes Schindelin
In-Reply-To: <20110120193923.GA14184@vidovic>
Nicolas Sebrecht wrote:
> The 15/01/11, Jonathan Nieder wrote:
>> This is a follow-up to v1.6.0.3~21 (rebase -i: do not fail when there
>> is no commit to cherry-pick, 2008-10-10).
[...]
>> # However, if you remove everything, the rebase will be aborted.
>> +# Use the "noop" command if you really want to remove all commits.
[...]
> Sorry, I think it is confusing. With this help we could understand that
> the "noop" will either
>
> (a) discard the interactive rebase
>
> or
>
> (b) _really remove commits_ from that branch
>
> I'm not sure to know how it will act myself. If (a), we could use
> something like
>
> "However, if you remove everything or use the "noop" command, the rebase will be aborted."
>
> but if we are in case (b), I guess it is not necessary and we should
> point to the 'git reset' command.
Okay. I agree that my particular wording was confusing. Are you
saying the "noop" command in general is confusing?
The "noop" is itself a non-operation; if you combine "noop" with other
instructions then the noop itself will have no effect. Meanwhile if
you have _no_ instructions then the rebase is cancelled, while if you
have a single "noop" instruction, that means "I have discarded all the
commits, but please rebase anyway".
Jonathan
^ permalink raw reply
* [PATCH 2/2] Re: rebase -i: explain how to discard all commits
From: Nicolas Sebrecht @ 2011-01-20 20:08 UTC (permalink / raw)
To: Jonathan Nieder
Cc: Nicolas Sebrecht, Matthieu Moy, git, gitster, Kevin Ballard,
Yann Dirson, Eric Raible, Johannes Schindelin
In-Reply-To: <20110120195726.GA11702@burratino>
The 20/01/11, Jonathan Nieder wrote:
> Okay. I agree that my particular wording was confusing. Are you
> saying the "noop" command in general is confusing?
>
> The "noop" is itself a non-operation; if you combine "noop" with other
> instructions then the noop itself will have no effect. Meanwhile if
> you have _no_ instructions then the rebase is cancelled, while if you
> have a single "noop" instruction, that means "I have discarded all the
> commits, but please rebase anyway".
Ok, I think I get it now. What about adding
Use "noop" with no other instruction to fallback to a non-interactive
rebase. If other instructions are present, "noop" has no effect.
?
--
Nicolas Sebrecht
^ permalink raw reply
* Parameter --color-words not documented for "git show"
From: Sebastian Pipping @ 2011-01-20 19:58 UTC (permalink / raw)
To: Git ML
Hello,
I noticed that
git show --color-words
works just fine, but it's not listed in
man git-show
I am referring to this version:
$ git --version
git version 1.7.4.rc2
Thanks,
Sebastian
^ permalink raw reply
* Re: [PATCH 1/2] rebase -i: reword in-editor documentation of "exec"
From: Jonathan Nieder @ 2011-01-20 20:09 UTC (permalink / raw)
To: Matthieu Moy; +Cc: git, gitster, Kevin Ballard, Yann Dirson, Eric Raible
In-Reply-To: <vpq39otrvmk.fsf@bauges.imag.fr>
Matthieu Moy wrote:
> Jonathan Nieder <jrnieder@gmail.com> writes:
>> -# x <cmd>, exec <cmd> = Run a shell command <cmd>, and stop if it fails
>> +# x, exec = run command using shell, and stop if it fails
>
> I don't think this is a good change to remove the <cmd> part. All
> other commands are used with
>
> <command> <sha1> <subject line>
>
> and I don't think the user would be able to guess that exec is
> different without a hint.
>
> If the problem is the wording of the sentence that may imply that
> <cmd> should be the shell itself, then why not
Yes, sorry, I combined two problems into a single patch. That was a
mistake. The current cheat sheet says:
# Rebase 3f14246..a1d7e01 onto 3f14246
#
# Commands:
# p, pick = use commit
# r, reword = use commit, but edit the commit message
# e, edit = use commit, but stop for amending
# s, squash = use commit, but meld into previous commit
# f, fixup = like "squash", but discard this commit's log message
# x <cmd>, exec <cmd> = Run a shell command <cmd>, and stop if it fails
#
# If you remove a line here THAT COMMIT WILL BE LOST.
# However, if you remove everything, the rebase will be aborted.
#
This does not make it clear that the format of each line is
<instruction> <commit id> <explanatory text that will be printed>
but the reader will probably infer that from the automatically
generated pick examples above.
What about the "exec" instruction? By analogy, I might imagine that
the format of that line is
exec <command> <explanatory text that will be printed>
So the "<cmd>" does not address that question for me. It does succeed
in clarifying that "a shell command" does not mean an arbitrary shell
command but a user-specified one.
Meanwhile, it makes the cheat sheet harder to visually scan as a table
i, instruction = action performed by instruction
Maybe "exec" should be explained outside this table? For example,
maybe something along the lines of
x, exec = run an arbitrary command (see below)
A line of the form "exec <command>" will run <command> using your
shell and stop for investigation or amending if the command fails.
If you remove a line here, THAT COMMIT WILL BE LOST.
However, if you remove everything, the rebase will be aborted.
^ permalink raw reply
* [PATCH] Correctly report corrupted objects
From: Björn Steinbrink @ 2011-01-20 20:12 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Will Palmer
The errno check added in commit 3ba7a06 "A loose object is not corrupt
if it cannot be read due to EMFILE" only checked for whether errno is
not ENOENT and thus incorrectly treated "no error" as an error
condition.
Because of that, it never reached the code path that would report that
the object is corrupted and instead caused funny errors like:
fatal: failed to read object 333c4768ce595793fdab1ef3a036413e2a883853: Success
So we have to extend the check to cover the case in which the object
file was successfully read, but its contents are corrupted.
Reported-by: Will Palmer <wmpalmer@gmail.com>
Signed-off-by: Björn Steinbrink <B.Steinbrink@gmx.de>
---
sha1_file.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/sha1_file.c b/sha1_file.c
index 1cafdfa..d86a8db 100644
--- a/sha1_file.c
+++ b/sha1_file.c
@@ -2141,7 +2141,7 @@ void *read_sha1_file_repl(const unsigned char *sha1,
return data;
}
- if (errno != ENOENT)
+ if (errno && errno != ENOENT)
die_errno("failed to read object %s", sha1_to_hex(sha1));
/* die if we replaced an object with one that does not exist */
--
1.7.4.rc2.18.gb20e9
^ permalink raw reply related
* Re: Parameter --color-words not documented for "git show"
From: Thomas Rast @ 2011-01-20 20:27 UTC (permalink / raw)
To: Sebastian Pipping; +Cc: Git ML
In-Reply-To: <4D3893EA.5090907@hartwork.org>
Sebastian Pipping wrote:
>
> I noticed that
>
> git show --color-words
>
> works just fine, but it's not listed in
>
> man git-show
Quote from the latter:
This manual page describes only the most frequently used options.
--
Thomas Rast
trast@{inf,student}.ethz.ch
^ permalink raw reply
* Re: [PATCH 2/2] Re: rebase -i: explain how to discard all commits
From: Thomas Rast @ 2011-01-20 20:34 UTC (permalink / raw)
To: Nicolas Sebrecht
Cc: Jonathan Nieder, Matthieu Moy, git, gitster, Kevin Ballard,
Yann Dirson, Eric Raible, Johannes Schindelin
In-Reply-To: <20110120200827.GB14184@vidovic>
Nicolas Sebrecht wrote:
> The 20/01/11, Jonathan Nieder wrote:
>
> > if you
> > have a single "noop" instruction, that means "I have discarded all the
> > commits, but please rebase anyway".
>
> Ok, I think I get it now. What about adding
>
> Use "noop" with no other instruction to fallback to a non-interactive
> rebase. If other instructions are present, "noop" has no effect.
>
> ?
No, that's quite wrong.
The TODO list is the list of all commits that need to be rebased. It
does not contain commits that (according to patch-id) are already
contained in the upstream (i.e., the base you are rebasing on). If
the list is empty after filtering out such commits, rebase puts 'noop'
as the only command since "empty TODO" is already taken to mean
"abort"
If you then accept this 'noop' rebase, this effectively makes the
rebased branch the same as the base branch, sort of like resetting.
(I for one have never accepted such a rebase; if the TODO only
consists of noop, that means I made a mistake.)
--
Thomas Rast
trast@{inf,student}.ethz.ch
^ permalink raw reply
* Re: Creating remote branch called HEAD corrupts remote clones
From: Jeff King @ 2011-01-20 20:38 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Stephen Kelly, KDE PIM
In-Reply-To: <7v62tjs66r.fsf@alter.siamese.dyndns.org>
On Thu, Jan 20, 2011 at 11:53:16AM -0800, Junio C Hamano wrote:
> The refs/remotes/origin/HEAD in Bob's repository is supposed to be a
> symbolic ref that points at the primary branch of the 'origin' remote
> (typically its master), e.g. "ref: refs/remotes/origin/master". But in
> general, local 'refs/remotes/origin/X' for any value of X is to copy
> 'refs/heads/X' from the 'origin'.
>
> Oops. If the origin repository has 'refs/heads/HEAD', these rules
> obviously conflict with each other.
>
> [...]
>
> I personally think it is reasonable to forbid HEAD or anything all caps
> that ends with "_HEAD" as branch names. Opinions?
Hmm. It seems like the symbolic ref is the culprit, not just HEAD. The
HEAD thing is the most likely, of course, but I could do something like:
git symbolic-ref refs/remotes/origin/convenient-alias \
refs/remotes/origin/some-name-you-dont-like
which is basically the same as the HEAD case (except that the
"convenient alias" for HEAD is "origin" and not
"origin/convenient-alias" due to the lookup table in dwim_ref).
Now imagine the remote creates a branch called convenient-alias. When I
fetch, am I corrupting my local tracking branches by falsely equating
the two? And/or when I push, am I then corrupting the remote?
So I wonder if the safety valve here should be about symbolic refs, and
not about the special name HEAD. Maybe we should not follow symbolic
refs during fetch. So if we are fetching the refspec "foo:bar", and the
RHS "bar" is a symref, we should _not_ follow it, but instead just
overwrite the symref with a regular ref.
For pushing, one rule could be to allow pushing from a named symref, but
not allow the matching rules to use a symref as a source. So I could do:
git push origin convenient-alias:new-name
but
git push origin
would never overwrite upstream's convenient-alias.
I dunno. That's just off the top of my head, so maybe I'm missing some
corner cases. I would be tempted to put the push rule into receive-pack,
so it could look at the local refs, but I don't think receive-pack has
any way of knowing what is a symref and what is not on the pushing end.
-Peff
^ permalink raw reply
* Re: Parameter --color-words not documented for "git show"
From: Sebastian Pipping @ 2011-01-20 20:43 UTC (permalink / raw)
To: Thomas Rast; +Cc: Git ML
In-Reply-To: <201101202127.39962.trast@student.ethz.ch>
On 01/20/11 21:27, Thomas Rast wrote:
> Quote from the latter:
>
> This manual page describes only the most frequently used options.
Okay. Is that a good a idea? Is --abbrev-commit really used more
frequently with "git show" than --color-words is?
Sebastian
^ permalink raw reply
* Re: [PATCH 1/2] rebase -i: reword in-editor documentation of "exec"
From: Junio C Hamano @ 2011-01-20 20:59 UTC (permalink / raw)
To: Jonathan Nieder
Cc: Matthieu Moy, git, Kevin Ballard, Yann Dirson, Eric Raible
In-Reply-To: <20110120200949.GB11702@burratino>
Jonathan Nieder <jrnieder@gmail.com> writes:
> Maybe "exec" should be explained outside this table? For example,
> maybe something along the lines of
>
> x, exec = run an arbitrary command (see below)
Ok, none of the other insns in the insn sheet mention what the argument to
the command means anyway (e.g. "p, pick = replay the commit" doesn't say
explicitly where the commit comes from), so I think the original patch is
probably fine.
If we wanted to be more helpful, perhaps s/(see below)/specified on the
rest of the line/ should be sufficient without adding extra lines.
^ permalink raw reply
* Re: [PATCH] Correctly report corrupted objects
From: Junio C Hamano @ 2011-01-20 21:05 UTC (permalink / raw)
To: Björn Steinbrink; +Cc: git, Will Palmer
In-Reply-To: <20110120201220.GD12418@atjola.homenet>
Björn Steinbrink <B.Steinbrink@gmx.de> writes:
> The errno check added in commit 3ba7a06 "A loose object is not corrupt
> if it cannot be read due to EMFILE" only checked for whether errno is
> not ENOENT and thus incorrectly treated "no error" as an error
> condition.
>
> Because of that, it never reached the code path that would report that
> the object is corrupted and instead caused funny errors like:
>
> fatal: failed to read object 333c4768ce595793fdab1ef3a036413e2a883853: Success
>
> So we have to extend the check to cover the case in which the object
> file was successfully read, but its contents are corrupted.
Hmm, what is the exact code path that read_object() callchain fails to set
errno when it returns a NULL? It is unclear from the above description.
Is there a funny object replacement involved?
> Reported-by: Will Palmer <wmpalmer@gmail.com>
> Signed-off-by: Björn Steinbrink <B.Steinbrink@gmx.de>
> ---
> sha1_file.c | 2 +-
> 1 files changed, 1 insertions(+), 1 deletions(-)
>
> diff --git a/sha1_file.c b/sha1_file.c
> index 1cafdfa..d86a8db 100644
> --- a/sha1_file.c
> +++ b/sha1_file.c
> @@ -2141,7 +2141,7 @@ void *read_sha1_file_repl(const unsigned char *sha1,
> return data;
> }
>
> - if (errno != ENOENT)
> + if (errno && errno != ENOENT)
> die_errno("failed to read object %s", sha1_to_hex(sha1));
>
> /* die if we replaced an object with one that does not exist */
> --
> 1.7.4.rc2.18.gb20e9
^ 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