On Fri, Dec 20, 2013 at 07:51:00AM +0100, Johannes Sixt wrote:
> > for (i = 1; i < argc && *argv[i] == '-'; i++) {
> > const char *arg = argv[i];
> > + const char *optarg;
> >
> > - if (starts_with(arg, "--upload-pack=")) {
> > - args.uploadp
Am 12/18/2013 15:53, schrieb Nguyễn Thái Ngọc Duy:
> The code that's not converted to use parse_options() often does
>
> if (!starts_with(arg, "foo=")) {
> value = atoi(arg + 4);
> }
>
> This patch removes those magic numbers with skip_prefix()
>
> Signed-off-by: Nguyễn Thái Ngọc Duy
>
On Fri, Dec 20, 2013 at 8:06 AM, René Scharfe wrote:
> Am 20.12.2013 00:50, schrieb Duy Nguyen:
>> On Fri, Dec 20, 2013 at 6:32 AM, René Scharfe wrote:
>>> Seeing that skip_prefix_defval is mostly used in the form
>>> skip_prefix_defval(foo, prefix, foo) I wonder if it makes sense to
>>> first ch
Am 20.12.2013 00:50, schrieb Duy Nguyen:
> On Fri, Dec 20, 2013 at 6:32 AM, René Scharfe wrote:
>> Seeing that skip_prefix_defval is mostly used in the form
>> skip_prefix_defval(foo, prefix, foo) I wonder if it makes sense to
>> first change skip_prefix to return the full string instead of NULL
>
On Fri, Dec 20, 2013 at 3:50 AM, Jonathan Nieder wrote:
> Junio C Hamano wrote:
>> Jonathan Nieder writes:
>
>>> This includes the colon in the translated string, to make it easier to
>>> remember to keep the non-breaking space before it.
>>
>> Hmph, recent 3651e45c (wt-status: take the alignment
Hi,
Samuel Bronson wrote:
> Markus Heidelberg wrote:
>> In the buildroot project (it consists of Makefiles) there a lots of
>> those workarounds. There was a patch on the list to replace all
>> $(strip $(subst ",,$(FOO))) with $(call strip_dquotes, $(FOO)), but
>> $(call) is not allowed in git fo
On Fri, Dec 20, 2013 at 6:32 AM, René Scharfe wrote:
> Seeing that skip_prefix_defval is mostly used in the form
> skip_prefix_defval(foo, prefix, foo) I wonder if it makes sense to
> first change skip_prefix to return the full string instead of NULL
> if the prefix is not matched. Would the resu
On Thu, Dec 19, 2013 at 10:44:22AM -0800, Junio C Hamano wrote:
> "brian m. carlson" writes:
> > Yeah, that's the clean fix I was looking for, but couldn't quite come up
> > with. I'm going to re-roll with your fix instead of mine and my tests.
> > Any objections to adding your sign-off?
>
> I w
On Sat, May 30, 2009 at 6:01 PM, Markus Heidelberg
wrote:
> In the buildroot project (it consists of Makefiles) there a lots of
> those workarounds. There was a patch on the list to replace all
> $(strip $(subst ",,$(FOO))) with $(call strip_dquotes, $(FOO)), but
> $(call) is not allowed in git f
Am 18.12.2013 15:53, schrieb Nguyễn Thái Ngọc Duy:
> I reimplemented skip_prefix() again just to realize this function
> already exists. Which reminds me there are a bunch of places that
> could benefit from this function, the same reason that I wanted to
> reimplement it.
>
> So this is series to
(cc-ing area experts)
Hi,
Eric Andrew Lewis wrote:
> Git is smart enough to realize when you make a spelling error and
> enter a non-existent git command. Since you probably do mean what it
> suggests, it follows that the user would want to immediately say “yes,
> I did want to do that,” rather t
Johannes Sixt writes:
> can't use non-numeric string as operand of "!"
> while executing
> "if {!$ateof} {
> set nlines [expr {[winfo height $ctext]
> / [font metrics textfont -linespace]}]
> if {[$ctext compare "$target_scrollpos + $nlines ..."
> (proc
When we have a remote-tracking branch named "frotz/nitfol" from a
previous fetch, and the upstream now has a branch named "frotz". Prior
to this patch fetch would fail to remove "frotz/nitfol" with a "git
fetch --prune" from the upstream. git would inform the user to use "git
remote prune" to fix t
If "fetch --prune" is run with no new refs to fetch, but it has refs
to prune. Then, the header url is not printed as it would if there were
new refs to fetch.
Output before this patch:
$ git fetch --prune remote-with-no-new-refs
x [deleted] (none) -> origin/world
Ou
Git is smart enough to realize when you make a spelling error and
enter a non-existent git command. Since you probably do mean what it
suggests, it follows that the user would want to immediately say “yes,
I did want to do that,” rather than return to the command line to
enter the command again.
e
Hi,
I'm thinking about using Git for web application deployment and thought that I
wouldn't even need to checkout a worktree if I could access the bare git repo
via fuse.
What would be the performance impact? Once the files are in the filesystem
cache
it shouldn't matter anymore, how fast the
On Thu, Dec 19, 2013 at 07:03:33PM +, Adam Spiers wrote:
> I still don't understand a few things about history simplification:
>
> 1. The "--full-history without parent rewriting" correctly asserts
>that commit Q will be shown. But AFAICS this contradicts the
>documented behaviour "Co
On Thu, Dec 19, 2013 at 12:37:53PM -0800, Junio C Hamano wrote:
> Adam Spiers writes:
>
> > On Thu, Dec 19, 2013 at 06:36:45PM +, Adam Spiers wrote:
> >> I wanted to be able to experiment with the TREESAME example given in
> >> the git-log(1) man page, so I built this script which recreates i
Junio C Hamano wrote:
> Jonathan Nieder writes:
>> This includes the colon in the translated string, to make it easier to
>> remember to keep the non-breaking space before it.
>
> Hmph, recent 3651e45c (wt-status: take the alignment burden off
> translators, 2013-11-05) seems to have gone in the
On Thu, Dec 19, 2013 at 12:39:05PM -0800, Junio C Hamano wrote:
> Adam Spiers writes:
>
> > Ah OK, that makes sense now, but not the most intuitive choice of name
> > IMHO. I would have gone for something like --all-commits, but I guess
> > it's way too late to change now.
>
> Besides, it is no
Jonathan Nieder writes:
> This includes the colon in the translated string, to make it easier to
> remember to keep the non-breaking space before it.
Hmph, recent 3651e45c (wt-status: take the alignment burden off
translators, 2013-11-05) seems to have gone in the different
direction when it upd
Adam Spiers writes:
> Ah OK, that makes sense now, but not the most intuitive choice of name
> IMHO. I would have gone for something like --all-commits, but I guess
> it's way too late to change now.
Besides, it is not --all-commits, is it? We do cull irrelevant side
branches IIRC.
--
To unsu
Adam Spiers writes:
> On Thu, Dec 19, 2013 at 06:36:45PM +, Adam Spiers wrote:
>> I wanted to be able to experiment with the TREESAME example given in
>> the git-log(1) man page, so I built this script which recreates it:
>
> [snipped]
>
>> Would it be worth including this in (say) contrib/,
On Thu, Dec 19, 2013 at 11:10:44AM -0800, Jonathan Nieder wrote:
> Adam Spiers wrote:
>
> > Hmm, another related option would be to add a new test case which
> > tests that git log behaves in the way the man page says it does, in
> > this case.
>
> Yes, please! If you have a rough patch in that
On Thu, Dec 19, 2013 at 12:20:52PM -0800, Junio C Hamano wrote:
> Adam Spiers writes:
>
> > 2. What difference does --dense ever make?
>
> It is set by default, and --sparse is its opposite option, i.e. it
> turns revs->dense off.
Ah. It appears to be missing from the man page that it's the de
I learned of "git cherry" some days ago, but only learned of --cherry
and related options to "git log" today[1] (more-or-less by chance).
If the git-cherry(1) manpage had mentioned --cherry, I would have
learned of these options sooner.
[1]: Thu, 11 Apr 2013
Signed-off-by: Samuel Bronson
---
D
Adam Spiers writes:
> 2. What difference does --dense ever make?
It is set by default, and --sparse is its opposite option, i.e. it
turns revs->dense off.
When revs->dense is turned off, the usual treesame logic does not
kick in to rewrite parents in a single strand of pearls (i.e. a
stretch of
Raphaël Hertzog wrote[1]:
> Here's an example of the problematic output:
[...]
> # modifié des deux côtés :debian/control
Thanks for the ping, and sorry to leave this hanging before.
[...]
> --- a/wt-status.c
> +++ b/wt-status.c
> @@ -255,7 +255,7 @@ static void wt_status_print_unmerged_data
Tom Miller writes:
>> But what should happen when we do not give --prune to "git fetch" in
>> such a situation? Should it fail, because we still have frotz/nitfol
>> and we cannot create frotz without losing it?
>
> You talk about this to some extent in an email from 2009. I have linked
> it bel
Adam Spiers wrote:
> Hmm, another related option would be to add a new test case which
> tests that git log behaves in the way the man page says it does, in
> this case.
Yes, please! If you have a rough patch in that direction, that
would be welcome.
Thanks,
Jonathan
--
To unsubscribe from this
On Thu, Dec 19, 2013 at 06:36:45PM +, Adam Spiers wrote:
> I wanted to be able to experiment with the TREESAME example given in
> the git-log(1) man page, so I built this script which recreates it:
[snipped]
> Would it be worth including this in (say) contrib/, and then referring
> to it from
On Thu, Dec 19, 2013 at 01:57:43PM -0500, Marc Branchaud wrote:
> On 13-12-19 10:15 AM, Adam Spiers wrote:
> > If I launch gitk, switch the lower right pane from Patch view mode to
> > Tree view, expand a few directories, and then changing to viewing a
> > different commit, the tree automatically c
Christian Couder writes:
> I think this last one might be useful for people replacing objects
> with objects that have another type.
... which IIUC is strongly discouraged---didn't you have to tighten
it recently?
And that makes it "useful primarily for debugging" unusual
situations.
> And as
On 13-12-19 10:15 AM, Adam Spiers wrote:
> Hi all,
>
> If I launch gitk, switch the lower right pane from Patch view mode to
> Tree view, expand a few directories, and then changing to viewing a
> different commit, the tree automatically collapses again. This is
> really annoying when trying to v
"brian m. carlson" writes:
> On Tue, Dec 17, 2013 at 04:36:06PM -0800, Junio C Hamano wrote:
>> I think all we need to do, in addition to what the existing code
>> does, is to make sure that we _parse_ the object that the tag points
>> at, to avoid this problem. Something like this, perhaps, ins
I wanted to be able to experiment with the TREESAME example given in
the git-log(1) man page, so I built this script which recreates it:
- 8< - 8< - 8< - 8< - 8< -
#!/bin/bash
mkdir git-log-example
cd git-log-example
git init
# I
echo asdf > foo;
On Wed, Dec 18, 2013 at 7:18 PM, Tom Miller wrote:
> On Wed, Dec 18, 2013 at 3:47 PM, Junio C Hamano wrote:
>> Tom Miller writes:
>>
>>> In order to fix branchname DF conflicts during `fetch --prune`, the way
>>> the header is output to the screen needs to be refactored. Here is an
>>> exmaple o
Torsten Bögershausen writes:
> Thanks for an interesting reading,
> please allow a side question:
> Could it be, that "-1 == unlimited" is Linux specific?
> And therefore not 100% portable ?
>
> And doesn't "unlimited" number of files call for trouble,
> having the risk to starve the machine ?
>
On 2013-12-19 01.15, Jeff King wrote:
> On Wed, Dec 18, 2013 at 02:59:12PM -0800, Junio C Hamano wrote:
>
>> Jeff King writes:
>>
Yes, that is locally OK, but depending on how the caller behaves, we
might need to have an extra saved_errno dance here, which I didn't
want to get into
On 12/19/2013 01:04 AM, Jeff King wrote:
> On Wed, Dec 18, 2013 at 11:44:58PM +0100, Michael Haggerty wrote:
>
>> [While doing so, I got sidetracked by the question: what happens if a
>> prune process deletes the "objects/XX" directory just the same moment
>> that another process is trying to writ
On Wed, Dec 18, 2013 at 6:37 PM, Junio C Hamano wrote:
> Christian Couder writes:
>
>> On Wed, Dec 18, 2013 at 1:37 PM, Karsten Blees
>> wrote:
>>> Am 11.12.2013 08:46, schrieb Christian Couder:
+enum repl_fmt { SHORT, MEDIUM, FULL };
>>>
>>> SHORT is predefined on Windows, could you choos
On 12/19/2013 04:26 PM, Johan Herland wrote:
> On Thu, Dec 19, 2013 at 10:31 AM, Michael Haggerty
> wrote:
>> On 12/19/2013 02:11 AM, Johan Herland wrote:
>>> On Thu, Dec 19, 2013 at 12:44 AM, Michael Haggerty
>>> wrote:
A correct incremental converter could be done (as long as the CVS use
On Thu, Dec 19, 2013 at 10:31 AM, Michael Haggerty wrote:
> On 12/19/2013 02:11 AM, Johan Herland wrote:
>> On Thu, Dec 19, 2013 at 12:44 AM, Michael Haggerty
>> wrote:
>>> A correct incremental converter could be done (as long as the CVS users
>>> don't literally change history retroactively) b
Hi all,
If I launch gitk, switch the lower right pane from Patch view mode to
Tree view, expand a few directories, and then changing to viewing a
different commit, the tree automatically collapses again. This is
really annoying when trying to view changes to the tree structure over
time; is there
I've got a better version [1] that fixes everything I can think of
(there's still some room for improvements). I'm going to use it a bit
longer before reposting again. But here's its basic design without
going down to code
New .git file format includes two lines:
-- 8< --
gitid:
gitdir:
-- 8< --
On Wed, Dec 18, 2013 at 07:48:59PM -0600, Tom Miller wrote:
> I did not intend to introduce new lingo. I did some searching through
> history to see if something like this had been worked on before and
> I found a commit by Jeff King that introduced me the the idea of
> "DF conflicts"
I take all
On 12/19/2013 05:06 AM, Eric S. Raymond wrote:
> Michael Haggerty :
>> If you haven't tried cvs2git yet, please start it up somewhere in the
>> background. It might take a while but it should have no trouble with
>> your repos, and then you can compare the tools based on experience
>> rather than
On 12/19/2013 02:11 AM, Johan Herland wrote:
> On Thu, Dec 19, 2013 at 12:44 AM, Michael Haggerty
> wrote:
>> A correct incremental converter could be done (as long as the CVS users
>> don't literally change history retroactively) but it would be a lot of work.
>
> Although I agree with that sen
48 matches
Mail list logo
